Re: Software Architecture/Design

/waits patiently for ubiquitous constexpr support... :)

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2235.pdf
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2235.pdf>

On Sat, Jun 5, 2010 at 11:09 AM, Miles Macklin <[email protected]>wrote:

> You can also have the compiler generate the hash so you don't need a
> pre-process and can leave the syntax the same:
>
> data["Position"] = Vector3(3,4,5);
>
> Emil Persson posted a good description here:
>
> http://www.humus.name/index.php?page=News&ID=296
>
> Essentially it involves using a StringHash type with constructors for
> different string lengths, on most compilers the hash will be evaluated at
> compile time.  Example (from the link above):
>
> StringHash(const char (&str)[2]);
> StringHash(const char (&str)[3]);
> StringHash(const char (&str)[4]);
> StringHash(const char (&str)[5]);
>
> StringHash(const char (&str)[4])
> {
>     m_Hash = 0;
>     m_Hash = m_Hash * 65599 + str[0];
>     m_Hash = m_Hash * 65599 + str[1];
>     m_Hash = m_Hash * 65599 + str[2];
> }
>
>
> On Fri, Jun 4, 2010 at 3:54 PM, Tom Plunket <[email protected]> wrote:
>
>> Megan Fox wrote:
>> > That in turn leaves me with some kind of map that I'm
>> > indexing via strings, or via ASCII->int identifiers like
>> > {'P','o','s'}, or something similarly ugly that is either terrible for
>> > performance, or usability, or both.
>> >
>> > Does there exist a structure that deals with this?  Or is everyone
>> > just throwing their data into a hashmap, keeping their strings to a
>> > reasonable length, and balancing collisions vs wasted memory/resize
>> > costs/etc?
>>
>> You could use a hashmap but you don't need to use char* at runtime.
>> One tack I took in the past was to stuff every string into a sixteen
>> byte array, and zero-fill non-content areas.  That way I could
>> directly compare strings with a 128-bit compare.  A more sophisticated
>> strategy would be to generate keys from your strings and preprocess
>> your source files before they hit the compiler.  E.g. the source line:
>>
>> data[SYMBOL("Position")] = Vector3(3, 4, 5);
>>
>> would get replaced by your preprocessor to look like
>>
>> data[0x39293862] = Vector3(3, 4, 5);
>>
>> to the compiler.  It should be pretty easy to inject this step into
>> your compilation, and the "precompiler" would be pretty simple, just
>> matching the SYMBOL and then replacing that substring and optionally
>> storing the hash->string mapping in some other file that can be loaded
>> by the running application.  The slick bit is that you still see in
>> code, while debugging, what you originally typed, but it's a zero-cost
>> operation at runtime since the constant is hard coded.
>>
>>
>> -tom!
>>
>> --
>> _______________________________________________
>> Sweng-Gamedev mailing list
>> [email protected]
>>
>> http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com
>>
>
>
> _______________________________________________
> Sweng-Gamedev mailing list
> [email protected]
> http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com
>
>

_______________________________________________
Sweng-Gamedev mailing list
[email protected]
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com