Re: Software Architecture/Design
Miles Macklin <[email protected]>
| Newsgroups | gmane.games.devel.sweng |
|---|---|
| Message-ID | <[email protected]> |
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