- MarkoPolo
- Постоялец
Phoenics
WSTRING - это ведь не char*? Что-то не хочется юзать std::string. Придется перепахать весь код...
Yamazaru
CRC32 используют часто для проверки целостности сетевых пакетов, а они ведь небольшие и поиск по таблице быстрее, и я что-то в нете не нашел нормальных статей по SBDM...
BDSM...
MarkoPolo
CRC32 оказывается хорош именно для того, для чего создавался - проверка целостности произвольных данных большого объёма (> 100 bytes). А на коротких (1-30 bytes) строках он проигрывает специализированным алгоритмам вроде того же SDBM или Jenkins'а. Особенно где много строк отличающихся одним символом или начинающихся одинаково (file paths).
Насчёт скорости, то lookup по таблице это больше шансов на cache miss. Кстати вот сравнение, CRC32 отстаёт, но не намного.
Ищи по SDBM, это я так название запомнил, как что-то схожее с вариантом Lastrick'а )
Вообще таких хеш функций немало, причём каждый автор приводит доказательства и avalanche вроде как на голову разбивающий соперников. Так что если это критично, то выбирать нужно в каждом конкретном случае.
MarkoPolo
Да у меня юникод WSTRING это typedef от std::basic_string<wchar>. Его можно заменить на std::string легко.
Но тебе весь код переписывать не надо будет, так как у std::string имеет конструктор от char* и следовательно ты можешь кидать туда свои char* строки и std::string будет только внутри этого класса крутится. Т.е. например такая запись вполне нормально прокатит:
LinkName Linker; char * str = "Some string"; Linker.isExist(str); Linker.GetNumber( "My string");
А есть ли у кого-нибудь тесты хоть какие-нибудь? Стоит ли оно того?
Phoenics
Я считаю, что мешая в коде std::string и char* некрасиво. Конструктор то он имеет, да вот только, как по мне, конструировать стринг долго. Поэтому надо, либо так, либо наоборот. А вообще, код легко переделать под char*, только мне все равно что-то не нравиться.
Yamazaru
будем смотреть...
the_siv
В UE3 такие отхэшированные строки есть и активно используются. Имхо, показатель. А вообще зависит от задач.
Если вам нужно не только собрать строки в кучу, но и хотя бы иногда их менять (ну там, знаете, локализация, новые строки, вдруг неожиданно новые языки), то самое правильное -- вынести их в отдельный файл максимально простого формата. Например, CSV. А уже потом из этого файла грузить в игру или парсить и превращать в другие файлы (например, инсталлятор). С переводчиками тогда очень удобно работать. С геймдизайнерами. И с прочими, кому вредно лазать в код, но полезно редактировать текст.
Я на DTF примерно об этом статью написал когда-то. Взгляните, может, пригодится: http://dtf.ru/articles/read.php?id=50790
Надо сначала имхо разграничить строки по их использованию - внутредвижковъе / текст для игръ.
Внутридвижковъе спокойно можно в рантайме хешировать и юзать в движке поинтер стринга для сравнения / ключа. Таким образом даже не нужно собирать таблицу в билде - она собирается сама в рантайме.
А для локализации нужна таблица отдельно, собранная каким-то образом и которую можно записать в каком-то формате, в котором ето потом будут переводить. Там вообще другое.
Внутридвижковъе строки из нашего проекта, с уже 100% готовъм артом занимают 230 кб - 8к стрингов.
> Внутридвижковъе строки из нашего проекта, с уже 100% готовъм артом занимают 230 кб - 8к стрингов.
А можно чуть поподробнее: что это за "внутренние" строки движка в таком внушительном количестве?
Kvinto
пути/имена ресурсов/всякие там "ключики" для парсеров. Все что для internal use
Kvinto
> что это за "внутренние" строки движка в таком внушительном количестве
Да, ето ключики и референсъ арта - имена текстур, мешей, анимаций, материалов и в основном - текстур. У нас имена абсолютнъе от рута игръ и иногда там по 30-50 символов в одном имени. Даже как можно посчитать, в среднем 40 символов получается.
Ето можно бъло сопримизировать - на етапе експорта немного переименовать арт, но такая економия реально почти ничего не даст - 230кб на фоне некоторъх других штук - минорная минорность, вот я их так и оставил.
Тема в архиве.