Maps, Lists, Serialization


There are a couple of main reasons why I am still not using Juce near exclusively over MFC. These are maps, lists, and MFC’s Serialization (Rich Edit controls would be nice too :slight_smile: ).

Maps, MFC Style, I use often, especially for something I just did, it holds about 700k string keys/values. I do a large number of lookups, exceedingly large, putting these in any other format of lookup would take a lot longer then the current seven seconds to load.

Lists, don’t use often, but MFC’s way about them is unique, and described in the serialization area.

Everything of value(?) in MFC is derived from CObject. CObject has a Serialization function which should be derived from. It can be setup so you can do a dump of near anything, to memory, file, wherever, and reload it later to bring any object to its previous state. Doing this in your own things is easy, and for my latest project would be a synch to emulate, except for two major hurdles. CArchive is the main function that is used for serialization, and you can pass in any CObject derived class for it to serialize or unserialize. In my project I have it archive out three variables, one array (MFC templated array, mine is defined as CArray<binStruct,binStruct>), and one map (CMapStringToString). What’s nice is that my serialization function is as follows:

Serialize(CArchive& ar) { if( ar.IsStoring() ) { ar << m_SelectedObject; ar << m_IsLoaded; ar << m_NumberOfObjects; m_Objects.Serialize(ar); m_Lang.Serialize(ar); } else if( ar.IsLoading() ) { ar >> m_SelectedObject; ar >> m_IsLoaded; ar >> m_NumberOfObjects; m_Objects.Serialize(ar); m_Lang.Serialize(ar); } }
It saves and loads my state quite well (I rebuild the rest of the classes and informationlater in the function, snipped out, from the serialized data). I could emulate this well enough in Juce, except I havn’t found any array or map, except for the one’s in mfc, that can dump and reload their information like that. I’ve been thinking, what about a pseudo class (like multi-subclassing a listener) for serialization, and a number of classes would subclass it already, such as your array classes and such. Mayhaps putting in a map, from like the standard set, with such functionality, duplicating some of the ones from MFC, such as the string/string one?


try the stl and boost

please try not to mention mfc round here! :wink:


Yes, I’m sure the stl map classes will be better than MFC’s!

I’ve thought about doing maps and things, but haven’t quite got round to it yet. Probably will do at some stage.

Serialisation’s a tricky one - seems like whenever I’m doing something that needs to be serialised, it’s never suitable for being done by generic serialisation code. E.g. I’m always loading/saving objects as XML, but having a generic serialisation method would be no good, as you need more control over the structure, tag and attribute names if you want your XML to be human-readable.


Yes, I have stl and boost and use it frequently, but its missing a couple things that mfc impliments. And do note, the only reason I mention mfc is because I am trying to replace it in my work. :smiley:

The main thing I’ve been looking at is serialization. As in my above case, trying to serialize a juce array, or stl maps, involves a few more lines then just one, as in mfc… XML would be bad for this, because they dump I made is 37 megs, as binary, having that as xml would increase it… to probobly a few hundred.

Nicely enough though, my serialized objects from mfc (the 37 meg file) compresses to ~750kb, even the source files combined are well over 40 megs…

I could care less about it being human-readable, I need to open for speed and size, xml is neither…

And don’t worry, I hate mfc through and through, especially the way it handles controls, has to be the worst gull-awful setup ever devised, but a few thoughts permeate mfc that do make many tasks very simple, not to mention, since it comes with a certain platform, that program up there is 14kb in release mode… compilied for speed, not size… My source code files are larger then that…

Wierdly enough, the mfc pattern is rather similier to java, near everything inherits from a base class, and it impliments a few things in that base class, such as isKindOf, Serialize, etc… like java has toString and Copy and such…

EDIT: Looked at that boost article above, unsure how they figured that, but I do serializing of non CObject derived classes quite often, why do they say the mfc method is only for derived classes, I could serialize stl array’s if I wanted, although it would involve writing a few extra lines which still involves more unnecessary work…