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

Вот hash_map и hash_set точно тормозы, их выборка должна быть O(1), но как показала практика, они ничем не быстрее map на основе RB-tree с ее O(n log(n))

viv
>San
>А когда ты выйдешь за пределы своей взятой памяти?
А что мне мешает оценить сколько памяти мне может понадобиться? К тому же механизмы таких аллокаций могут быть разными. Ну, типа, выделяем метр, юзаем его по-чорному (с точки зрения контейнера происходит тот же маллок, но уже не надо лезть в кучу). Кончается метр - выделяем еще один.

>Ты кстати вообще писал эти волщебные аллокаторы?
Вообще, мне хватает стандартных. Если понимать как работает стл и где у него узкие места, то можно жить и так.
Когда-то чисто из спортивного интереса пейсал аллокатор для чего-то мелкого, что просило память очень часто и по чуть-чуть.

>Для прикола спроси где ему std::string нужен. Еще веселее, чем мапа
Ты не поверишь, для строк :)

cppguru
>Ну обычно - в мапах хранится соответствие неких строковых имён каким-то пачкам
>байт. И по этим именам радостно делается поиск. Отсюда вопрос, почему бы не
>делать это где-то в тулзе и в коде прошивать сразу адреса этих структур вместо
>строковых имён?
Вот тут согласен абсолютно. Индексация по строкам уместна лишь в редакторе/дебаге.

Пример с мапой:

class SomeClass
{
enum Event
{
 SomeEvent1, SomeEvent2...
};
 ...
 typedef std::map<Event, functor_void> events_t;
 events_t m_events;
 void execEvent(Event evt);
 ...
};

...

SomeClass sc;
sc.execEvent(SomeClass::SomeEvent1);

Кот Шрёдингера
>Я это уже слышал? ;)
Здрысни! :)

P.S. А чего ты ожидал услышать на пятом круге ада? ;)

viv
>Особенно всякие мапы и хеши, очереди, строки и другой говномусор больного мозга. Вы же игры пишете
Кстати да. С некоторых пор не вижу особого смысла даже в C++, все спокойно делается на старом добром C.
NightmareZ
>Из-за таких как ты я не мог больше двухсот юнитов в старкрафте создать и шестидесяти тысяч в казаках.
А больше то железо и не потянуло-бы, да и играбельность упала бы.

San
>typedef std::map<Event, functor_void> events_t;
У тебя там этих ивентов сотни и тысячи? или их всего десяток? Если так, то поиск по массивчику будет и проще, и быстрее...

Ну и опять же непонятно, зачем динамически подвешивать сигналы к ивентам, когда это можно сделать заранее. Это как раз сильно похоже на ошибку архитектуры. Такое может быть, когда 3rd party прикручиваешь, но они как раз стремятся к более простым интерфейсам и обычно не требуют шаблонных функторов.

cppguru
Надо, юзернейм. Потому как кол-во этих эвентов легко может меняться в процессе разработки.
ЗЫ В Таймшифте есть стл? :) Я буду ну просто очень удивлен, если нет.

ЗЫЫ Чисто поток сознания: У меня создается впечатление, что девелоперов колбасит и кидает из одной крайности в другую. Когда-то давно было модно сделать все до крайности универсальным. Вплоть до виртуальных рендеров и т.п. Потом понесло в сторону упрощения всего и все опять же до крайности. Бритва Оккама сработала, но отсекла здравый смысл по самое небалуйся. Вот уже наблюдаются призывы вернуться back in time к plain C. Но в мире ведь в принципе нет абсолютных вещей.
Вот Hello world я бы писал на С или бейсике (по приколу потомушта), если мне надо гуевую утилитину - возьму Дельфи, если (...), то (...)

San
Стл нет, есть свои вектор и хеш-мапа. И ими никто не злоупотребляет. Т.е. никаких конструкций vector<vector<vector<...>>> и мап для колбэков с ивентами.

Апдейт: а ивенты все спокойно обрабатывают в switch-case. Проще надо, проще.

viv
> Нафик вообще нужен твой ресурс менеджер?
А как без него?

cppguru
> Любой мэп в игре — скорей всего, ошибка проектирования. Ресурс менеджеры тем более.
Можно про ресурс менеджеры поподробней?

P.S. Я в танке :)

cppguru
Всё следует упрощать до тех пор, пока это возможно, но не более того (с) :)
Кстати, а что, стл жутко тормозил и вы от него отказались? Или вам в принципе не нужен его функционал был?

San
Это давно было, но думаю что нужна была управляемость и предсказуемость. Ну и аллокатор нормальный. Аллокаторы в STL неюзабельные, это общеизвестно.

И минус алгоритмы. И плюс ассерт в operator[]. И плюс realloc в resize(). И плюс push_back() по ссылке. И минус std::pair. И минус reverse iterators.

Как видишь, много набирается.

Правка: и плюс поддержка своей статистики памяти в контейнерах.

Nighthunter
>> Любой мэп в игре — скорей всего, ошибка проектирования. Ресурс менеджеры тем более.
>Можно про ресурс менеджеры поподробней?
Ну и зачем нужен ресурс менеджер в игре? Я вот могу сказать, что D3D вполне себе менеджит все ресурсы. Особенно если всё MANAGED ;).

San
>У меня создается впечатление, что девелоперов колбасит и кидает из одной крайности в другую.
Не надо всё буквально понимать. Я лишь предлагаю подумать в правильном направлении. Если думать об оверхедах и кеш-миссах, читать дизасм и смотреть в профайлер, то можно и std::map разогнать %) Лучше конечно чтобы его не приходилось разгонять.

>Вот уже наблюдаются призывы вернуться back in time к plain C
На консолях и не уходили от него, если брать лучшие тайтлы. На ps2 чтоли от него уходить? Да и на некстгене, если нужна производительность, возвращаются родные старые интринсики. Виртуальные функции на SPU не работают, например.

cppguru
> а ивенты все спокойно обрабатывают в switch-case

Скажем так делегаты, сигнал-слоты, клозюры и прочие гуманоиды может и не очень быстры по сравнению с указателями на функции, но они такие удобные...=) А вложенные свичи во вложенные свичи, которые вложены в какую то глобальную функцию-мусоросвалку меня как то совсем не превликают. Люди мы же уже это проходили и коммунизм на этом не построили... и мне казалось мы уже живем в веке лямбда-программирования... А мир на одном PS не сошелся. Вон даже в SM5.0 по моему будет ООП, хотя мое личное мнение оно там не к чему.

С начала попробовал использовать vector, но мне как-то не понравилось, так как его неудобно адресовать, нужно указывать типа: Set ((float*)data).
Намного удобнее использовать старые добрые указатели + несколько функций-шаблонов для управления ими.
Стринг мне сразу не понравился, потому что не даёт нужный функционал, зато даёт кучу лишнего.
В другом пока ещё не пытался разобраться.

cppguru
> Виртуальные функции на SPU не работают, например.
Say wha?