Replace game data XML (!) with hashmap

[Quintus]

SMC currently stores it’s game state as in-memory XML. WTF?

// Game Action data
extern CEGUI::XMLAttributes Game_Action_Data_Start;
extern CEGUI::XMLAttributes Game_Action_Data_Middle;
extern CEGUI::XMLAttributes Game_Action_Data_End;

This is never written out to disk, hence there is absolutely no need to use XML for this. These variables should all be replaced with something based on std::map. Maybe extract the type-conversion code from SMC’s own XmlAttributes and work with subclasses? Or just rename it to something more generic?

[Luiji]

Perhaps at some point in it's evolution it was written to disk, or at least was going to be. It'd be use std::map/std::unordered_map/etc. That raises my next question: should we rely purely on std::map or on std::unordered_map, should we use an external hash map library like Google SparseHash, or perhaps we should use std::unordered_map when detected by configure but use something like SparseHash when it's not available?

[Quintus]

std::unordered_map is an interesting option — I’ve not yet looked detailed on C++11, but it seems very good for this purpose. Regarding SparseHash, I think we should rely on the standard library as much as viable, because that minimizes our external dependency list, which is already quite large. As C++11 is not that new anymore (3 years!) I guess that with the next Ubuntu LTS release most current mayor Linux distributions should have a C++11-capable compiler. It should be no problem to rely on its features.

Vale, Quintus

[Luiji]

If we want to support earlier versions of gcc we can use std::tr1::unordered_map, which was defined in C++ Technical Report 1 (2005-2007). It's just a draft but a number of vendors opted to support it early.

It shouldn't be hard to add a little configure check to see whether std::unordered_map or std::tr1::unordered_map is available and fall back to std::map in the worst case scenario.

The only platform I'd worry about being way behind in terms of GCC would be RHEL/CentOS. I've had so many problems with those platforms because of old GCCs.

[Quintus]

It shouldn't be hard to add a little configure check

Yes, that should be relatively easy. I think we should go that route.

The only platform I'd worry about being way behind in terms of GCC would be RHEL/CentOS

Ahem. I highly doubt RHEL/CentOS maintainers want to immediately ship SMC 2.0.0. When they decide to do so in five or ten years, they will most likely also ship a newer GCC that supports C++11. I’m not willing to make workarounds in SMC’s code for these distributions, which are usually not meant to be used as game computers anyway, but targetted at either server or office use.

Vale, Quintus

[Quintus]

Btw. when we decide to go C++11, we can probably replace boost::thread with the C++11 thread library. Just a thought...

[Luiji]

Gotta love dependency squashing. ;)

[Quintus]

Just for the record, on the MinGW ML they’re currently discussing cross-platform thread alternatives in C and C++. The C++11 std::thread has been mentioned as being the best option so far: http://sourceforge.net/p/mingw/mailman/message/32214718/

Vale, Quintus