STL. Использовать или нет?

Собственно сабж.

Начал читать книгу David Eberly "3D Game Engine Architecture", и в самом начале начинается строительство велосипедов: Array, HashSet, HashMap, String, Set, и т.д.

Автор пишет, что в одном проекте за счет самодельных классов получилось сэкономить 50% памяти (~500 Mb (самодельные классы) против ~1000 Mb (STL)).

Возник вопрос: автор книги не умеет пользоваться STL или на самом деле все так плохо с STL, и нужно писать все самому?

В STL контейнеры ты можешь подставлять собственные аллокаторы памяти,
и тем самым самостоятельно управлять выделением/размещением/удалением памяти.

Так что скорее всего автор пользоваться stl не умеет.

Nighthunter по моему автор книги врёт.50% - ето что то нереальное (если конечно проект не состоит их одних векторов, списков, и прочего). вот у тебя например класс юнита, скажем, каждый юнит занимает по 20кб памяти. Какой будет расход памяти в стл векторе например на элемент? Мне кажется если он и есть, то в любом случае намного меньший, нежели расход на сам юнит.

Nighthunter
Автор не умеет пользоваться STL.

Помню я как-то просматривал исходники разных игр (не помню каких точно, одна из них HL2), игр не много но тем не менее -
ни в одной игре не видел STL. В том же HL2 можно наблюдать самописные контейнеры и т.д.
Возможно из-за того что на практике используются далеко не все возможности STL классов,
поэтому пишут свои лишь с нужным функционалом.
А еще например, в своих классах используют какую-то свою систему отлова ошибок/логов и т.д.

Дело личное!

В книге приводится пример:

class VertexAttribute
{
public:
  VertexAttribute ();
  void* m_pvData; // user-defined per-vertex data
  set<Edge> m_kESet; // adjacent edges
  set<Triangle> m_kTSet; // adjacent triangles
};

The mesh class was used to build the adjacency information for a level surface
extracted from a 3D voxel image. The surface was a collection of 825 KB vertices,
2.5 MB edges, and 1.6 MB triangles. The memory used by the program that built the
adjacency information was 980 MB.

Затем написано про то, что средняя мощность этих множеств ~6 (m_kESet, m_kTSet). Поэтому для хранения небольших множеств автор создает класс SmallSet, который устроен, как обычный несортированный массив.

Класс VertexAttribute приобретает следующий вид:

class VertexAttribute
{
public:
  VertexAttribute ();
  void* m_pvData;
  SmallSet<Edge> m_kESet;
  SmallSet<Triangle> m_kTSet;
};

For the same application the memory usage was 503 MB, nearly a 50 percent reduc-
tion from the version using the STL set. The execution time itself was faster for the
SmallSet version.

Из этого примера экономия памяти очевидна, вот только не понятно зачем было иcпользовать set'ы, а не vector'ы к примеру.

правка: орфография

Nighthunter

> Затем написано про то, что средняя мощность этих множеств ~6 (m_kESet, m_kTSet). Поэтому для хранения небольших множеств автор создает класс SmallSet, который устроен, как обычный несортированный массив.

что значит, что автор выпалил из пушки по воробъям и там где хватало обычного несортированного массива начал хреначить динамические контейнеры.
не скажу что STL - это какая-то универсальная вселенская панацея, которая подходит всегда и везде, например:

class Triangle3D
{
   std::vector< Point3D > points;
public:
  Triangle3D(): points( 3 ) { ... };
   ...
}

это явное непонимание что, зачем и почему.
работать то будет, но мозги еще никто не отменял. %)

весьма сомнительно писать какой-нибудь MyOwnMegaVector<>, если есть std::vector и ничего нового там ты принципиально написать не сможешь - так зачем тратить силы?
но мне вот иногда не хватало STL-я по части, к примеру, интрузивных списков - писал велосипед, т.к. с boost::intrusive_list связываться было обломно по причинам того что boost.

Кармак тоже не умеет STL пользоваться :( Понаплодил самописные idStack, idQueue... И с таким замечательным изобретением, как аллокаторы, не знаком :( Ламер.

Чеширский кот
>Кармак тоже не умеет STL пользоваться :( Понаплодил самописные idStack,
>idQueue... И с таким замечательным изобретением, как аллокаторы, не знаком :(
>Ламер.
Я это уже слышал? ;)

Использовать, но крайне желательно заворачивать во врапперы. Ибо, во-первых, в ряде случаев стандартными средствами приходится записывать так, что иначе, чем "через жёппу", не назовёшь (примеры: проверка, что перебор контейнера по итератору закончился; перебор в обратном порядке; проверка, что в мапе есть элемент с заданным ключом...), а во-вторых, в дальнейшем, в случае чего, можно стл под этим враппером заменить на велосипед, и с остальной программой ничего страшного не случится.

Nighthunter
Автор всё правильно говорит.
На самом деле, обычно из STL'я можно пользоваться только вектором, строкой, потоками ввода вывода.
map, set, hash_map реализованы неэффективно.

Я, например, написал свои аналоги этих контейнеров.
И работают они примерно так.
Set<Тип, NonHashed<ARRAY>,  Стратегия Копирования>
Set<Тип, NonHashed<VECTOR>,  Стратегия Копирования>
Set<Тип, NonHashed<RBTREE>,  Стратегия Копирования>
Set<Тип, Hashed<CHAINING>,  Стратегия Копирования>
Map<Тип, Тип2, NonHashed<ARRAY>,  Стратегия Копирования>
Map<Тип, Тип2, NonHashed<VECTOR>,  Стратегия Копирования>
Map<Тип, Тип2, NonHashed<RBTREE>,  Стратегия Копирования>
Map<Тип, Тип2, Hashed<CHAINING>,  Стратегия Копирования>

Причём каждый конетейнер работает с каждым другим.
Например:
Set<Тип, NonHashed<ARRAY>,  LazyCopying> set1, set3;
Set<Тип, NonHashed<RBTREE>,  EnergyCopying> set2;

set1 += set2;
set3 -= set1;
...

Такой гибкости, конечно, с помощью STL никогда не достичь.

А начёт менеджера памяти, я пробовал использовать его из библиотеки Loki. Объём используемой памяти уменьшился, а время на выделение, удаление увеличилось. Точные цифры на сколько что увеличилоcь/ уменьшилось не помню. Но меня это не устраивало, и я решил не использовать сторонние менеджеры памяти.

Sbtrn. Devil
>Использовать, но крайне желательно заворачивать во врапперы. Ибо, во-первых, в
>ряде случаев стандартными средствами приходится записывать так, что иначе, чем
>"через жёппу", не назовёшь (примеры: проверка, что перебор контейнера по
>итератору закончился; перебор в обратном порядке; проверка, что в мапе есть
>элемент с заданным ключом...), а во-вторых, в дальнейшем, в случае чего, можно
>стл под этим враппером заменить на велосипед, и с остальной программой ничего
>страшного не случится.
Я так сначала сделал, потом заменил велосипедами.

Sbtrn. Devil
Оверхед :)
Если пользоваться семантикой STL, то ничего лишнего писать не придется.

А нафик вообще все эти контейнеры вам?
Особенно всякие мапы и хеши, очереди, строки и другой говномусор больного мозга. Вы же игры пишете