есть необходимость, в качестве ID`а для получения некоторого объекта, использовать строку. сейчас этот способ работает в run-time, и работает не плохо. но это делает невозможным статическую проверку соответствия типов, по понятным причинам.
гуглением, нашел алгоритм создания хеш-суммы строки в compile-time: http://arcticinteractive.com/2009/04/18/co...hing-boost-mpl/
это кажется идеальное решение моей задачи, за исключением того, что строка необходимая алгоритму, должна разбиваться на части по 4 символа, или посимвольно, так же, по понятным причинам.
т.е., вместо привычной теперешней записи ID`ов, придется писать так:

что абсолютно не юзабельно  

вопрос в том, как строку типа "object.method", корректно передать в этот алгоритм?

всем спасибо.

зы

http://liveworkspace.org/code/b3380d0e18eb...22710478202c062

Это сообщение отредактировал(а) boostcoder - 14.2.2011, 22:25

наверное, правильнее не подстраиваться под имеющуюся реализацию, а написать подходящую, не использующую boost::mpl::string.

как правильно написано в конце этой статьи, надо ждать constexpr которое уже есть в гцц 4.6 .

также есть вот такой вариант http://2x2is11.blogspot.com/2010/11/c-how-...ng-hash-at.html
хотя полученные им хеши не константы времени компиляции, фактически они получаются во время компиляции, может это можно как-то использовать.

спасибо.
я тоже нагуглил что-то подобное: http://chrissavoie.com/articles-mainmenu-29/15/14-hashing
но в обоих случаях, при таком примере:

получаю одинаковые ошибки:


и еще. при тестах: http://arcticinteractive.com/2009/04/18/co...hing-boost-mpl/
обнаружил странные результаты.
в следующем коде, последние пять результатов - разные.
я полагал, что при записи подряд более 4ех символов, последние будут игнорировать. а получается что нет.
кто-то может объяснить такое поведение?

http://liveworkspace.org/code/6d3cdaf592c7...d84591ef10fa51d

Это сообщение отредактировал(а) boostcoder - 13.2.2011, 06:25

почему последние, а не первые ?

Добавлено через 1 минуту и 37 секунд
подсказка : '....' - это обычное число, и на него распространяются те же правила переполнения..

упс, запутался 

Добавлено через 2 минуты и 38 секунд
да. все верно.
у этих строк значения одинаковые:

можно избавиться от ' ', но к сожалению запятая останется...
т.е. строка будет задаваться как STR(a,b,c,d,e,f,g)
при этом будет возможность задать свой алфавит символов... 
т.е. например запятую можно будет обозвать как comma.. 
для этого 
1. для каждого символа создается свой тип
2. чтоб не было коллизий, имени типа символа задать общий уникальный префикс
3. определить макрос, который из переданной последовательности символов, создаст последовательность типов..

Добавлено через 9 минут и 58 секунд
вот пример: http://forum.vingrad.ru/forum/topic-268064...1931740/13.html
избавиться от _3 в LIST_OF_CHARS_3 тоже можно посредством эллипсиса.. 

я тут всерьез подумываю о pre-build-step`е на котором, некоторая утилитка, из вызовов типа ".registry(&t, "type")" и ".on("method", &type::method)", создаст записи типа ".registry(&t, 0xf363e2)" и ".on(0x552a6b3, &type::method)" соответственно.
или, привязать пользователей к gcc-4.6   
ну не вижу я другого решения...

это естественно менятся на  что то типа : struct char_a { enum { value = 'a'}; };

но ни один из вариантов хорошим не назовешь, ибо оба через одно место...


по переписке разработчиков выяснил, что ориентировочная дата выхода релиза - осень этого года 
в репозитариях его нет. т.е. остается либо собирать самому, либо искать чьи-то сборки.

Добавлено через 28 секунд

да. я понял.

для этого для начала нужно представлять концепцию..
а вариантов куча, вот например еще один :

этого очень не хочется...  


этого сейчас тоже нет.
выглядит так:

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

Это сообщение отредактировал(а) boostcoder - 13.2.2011, 15:01

для того чтоб была статическая проверка, надо будет все равно определить тип... 
тем более что, тип используется минимум в двух  (при отправке и приеме).. 

вот что к примеру мешает сейчас добавить макрос, для такого использования :


?

ничего не мешает. просто я стремился избавиться от макросов и другой кодогенерации. и сейчас нет ни одного макроса. хотелось бы чтоб так и осталось  

вопрос был в принципе не о макросе.. а о третьей точке - о точке определения нового типа..
Как по Вашему, она должна быть или Вы ее специально избегаете ?

Добавлено через 14 минут и 8 секунд
макросы,  в принципе, можно реализовать так, чтоб их присутствие не было в хидерах пользователя.. 



Это сообщение отредактировал(а) mes - 13.2.2011, 16:47