Skip to main content
gamedev.net
🔒 Locked

C++ object serialization implementation design

Started by onefriedrice 6 replies 1.5k views
Original Post
onefriedrice
onefriedrice
I need to do some serialization, and I'm wondering what the best route is (apart from using an already-existing library). Coming from Objective-C with a heavy runtime, serialization was a pretty easy job, but I'm wondering what the best design would be in C++. The elements that I need serialized are these: numbers (int or float), strings, arrays, dictionaries (key/value maps), booleans, and then hopefully objects. This question deals with handling the elements, not the actual serialization. I started by creating an abstract 'base' class from which each element would have a subclass with a member function returning an enumeration value to signify its type, but this also means I have to declare all accessor member functions as virtual in the base class, which isn't really nice, especially if other elements are added later. Then I found out about RTTI which would make life much easier. I could just do it using RTTI, but I've also read many comments from people basically saying that RTTI shouldn't ever be necessary and that you just need to design your classes better. So basically my question: Is there some nice way to design the class hierarchy with templates or whatever so that RTTI is indeed unnecessary? Anyone have experience writing something like this? Thanks.
Sneftel
Sneftel
Quote:
Original post by onefriedrice
Then I found out about RTTI which would make life much easier. I could just do it using RTTI, but I've also read many comments from people basically saying that RTTI shouldn't ever be necessary and that you just need to design your classes better.

RTTI, either natively or via an ad-hoc replacement, is crucial to a general-purpose serialization framework.

I have to ask, though: Given the extreme difficulty involved in writing a C++ serialization library that doesn't suck, why don't you use an existing library?

onefriedrice
onefriedrice
Quote:
Original post by Sneftel
I have to ask, though: Given the extreme difficulty involved in writing a C++ serialization library that doesn't suck, why don't you use an existing library?


Any suggestions? Boost?
Antheus
Antheus
Game Programming Gems 3 covers this area pretty well.

If you don't use polymorphic objects, you don't need RTTI or base class. You don't need RTTI in any case, outside of tagging the serialized data.

Then there's always boost::serialization, and possibly other libraries. Unless you're comfortable with concepts involved, such as endianess, in-memory data alignment, templates and inheritance, you're probably better off using one of those.

Sneftel
Sneftel
Quote:
Original post by onefriedrice
Any suggestions? Boost?

Pretty much. It's a fairly mature library. There are things I don't like about it (mostly having to do with syntax) but it's a much better option than rolling your own.
onefriedrice
onefriedrice
Thanks for you who replied. I'm not afraid of templates or data alignment, but I think I'll look into boost or some other library. I mostly have a tendency to fear using 'outside' code, especially non-standard libraries, but that's something I should get over sometime anyway.

Again, thanks.
Sneftel
Sneftel
Quote:
Original post by onefriedrice
Thanks for you who replied. I'm not afraid of templates or data alignment, but I think I'll look into boost or some other library. I mostly have a tendency to fear using 'outside' code, especially non-standard libraries, but that's something I should get over sometime anyway.

You'll find that Boost is much easier to integrate into an application than most 3rd-party libraries, particularly if you skip the (IMHO ridiculous) build system and just download the installer from boost-consulting.com.
wood_brian
wood_brian

There is also this: www.webebenezer.net. The Boost library
hasn't been able to match our approach in terms of build or
run-time performance. There are also major differences
between how we approach multiple, simultaneous versions.
The Boost approach lumps code from multiple versions into
one class; we use separate classes. If the 1.2 version
of a class expands on the 1.1 version, our approach allows
the preservation of a 1.1 object if the receiving of a 1.2
object fails in the 1.2 portion of the code.

A recent thread on clc++m discussed a weakness in current
serialization approaches. The Boost library can be easily
fooled into allocating large amounts of memory in an
attack. This is currently true of our approach as well,
but we have acknowledged it and are working on a fix.
The Boost author has not acknowledged the problem as of
yet. If you want to read that thread search for denial
of service and serialization.

Brian Wood
Ebenezer Enterprises

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.