Re: Software Architecture/Design

Or user defined literals.

Mobile MSN

On Jun 5, 2010, at 12:09 PM, "Charles Nicholson" <[email protected]<mailto:[email protected]>> wrote:

/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
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2235.pdf>

On Sat, Jun 5, 2010 at 11:09 AM, Miles Macklin <<mailto:[email protected]>[email protected]<mailto:[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>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 <<mailto:[email protected]>[email protected]<mailto:[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
<mailto:[email protected]>[email protected]<mailto:[email protected]>
<http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com>http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com


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


<ATT00001.c>

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