> Ahhh so I can get rid of that. Cool. So even though it's declared as static in the class, I can define it in the implementation file w/o getting duplicate symbol stuff?
Yup. The whole idea is that you can basically declare an object as many times as you want, but only define it once. Think class forward declaration. There you have a name being introduced to the scope of which the compiler knows nothing about. It just knows the name is a class. And that is all it needs to know at that point. It's more or less the same with declaring objects.
I honestly think you are tired and need some rest. You know this stuff :) But do reread about the differences between declaration and definition of a variable too. The first simply introduces the name in the scope. It does not create the object, doesn't allocate memory for it and doesn't run its constructor. It simply tells the compiler "here I have a name m_vEntries and that name is of type std::vector<SCRIPT_MSGMAP_ENTRY *>. Hold on to that name. I'm going to create that object soon"
The latter allocates memory, and creates the object by running its constructor.
Often the distinction is blurred by the fact we also define a variable when we declare it. We can force a variable to be only declared with the extern keyword. But with static data members, the compiler treats your declaration as just a declaration as opossed to your regular data members.
> I'm quite excited about starting the script writing process and the handler's to respond to the messages.
And I'm quiet curious as to the end result after I read the other related thread in the Game forum. If there is one thing I wanted to ask, is for you guys to make it as generic as possible and... release it :)
Seeing as how this data structure is filled only once but used for lookup very often, a std::map might be the wrong choice. A std::vector that is sorted once, with lookups done using binary search, would be a better option in terms of space, and often in terms of speed too, mostly due to locality of access in the linear sequence of the vector as opposed to the separate nodes of the map. (Unless, of course, you use a custom allocator.)
Basically you would use a std::vector and the macros as they are, except for END_SCRIPT_MSGMAP, which you modify like this:
where SCRIPT_MSGMAP_ENTRY_SORTER is a very simple functor that compares two SCRIPT_MSGMAP_ENTRY objects by their ID.
#define END_SCRIPT_MSGMAP \
std::sort(m_vEntries.begin(), m_vEntries.end(), SCRIPT_MSGMAP_ENTRY_SORTER()); \
Thanks for the suggestion. I like it. And yes we were thinking a map might not be the best choice.
We are attempting to make this system as genre-free as possible so that it could be used as a script system for any type of game regardless of genre and regardless of engine type. Since it is message-based and since any number of parameters and any type of parameters can be passed to the message functions, the opportunities for expansion are limitless.
This has not been an easy thing to create and without the help of the MFC site, and my book MFC internals, it would not have been possible. I don't feel bad using the code since we are modifying it quite a bit to use more modern container structures. The only downfall of course is that it cannot be put into a DLL using the 2005 STL library. MS still does not have a version of the STL that is compatible across module boundaries.