Dominick Layfield wrote:
Frank Birbacher wrote:
I now noticed that the link I posted does not reference excatly what I meant to point at. Your code makes me think that you have not read what I wanted you to read. Here it goes.
READ THIS:
http://www.boost.org/libs/serialization/doc/rationale.html#trap
Well, Hector may not have read this, but I did! And it seems that I have the same problem as him. If I make the object I want to serialize a const, the (completely incomprehensible) compile error goes away. Any chance this could be added to a boost::serialization FAQ?
you mean change the section named "rationale" to "FAQ"?
It appears that I have a choice between (i) doing a const_cast on every object I want to save,
and (ii) inserting a BOOST_CLASS_TRACKING(XXX, boost::serialization::track_never) line into my source code. Both are ugly, and although the former might be safe, it certainly looks dangerous!
The "Compile time trap" section of the documentation doesn't actually explain what "object tracking" is all about. Neither (amusingly) does the Boost->Serialization->Reference->Special Considerations->Object Tracking section!
Hmmm - well it's intended to. Maybe I just thought the meaning of the term "Object Tracking" obvious.
After re-reading these sections several times, I realized that this is all related to serializing pointers.
Object tracking can also save space if things are being serialized via references.
To my mind, it is not at all intuitive what should happen if I try to serialize a pointer to an object.
What Boost::serialization seems to do is to serialize the object itself, but wrapped up in some magic that remembers the object was output/input through a pointer. i.e. if I create a my_class object, then output a pointer to the object, the object itself is output, and when I come to input the pointer, the library silently creates an object of type my_class, then puts a pointer to the object into my pointer. Is that about right?
That's about right. Basically, the serialization library does automatically (almost) exactly what you would have to do by hand it save a class instance and reconstitute the same instance at another time and/or place.
If so, this is (1) not transparent,
The very first sentence of the overview states "Here, we use the term "serialization" to mean the reversible deconstruction of an arbitrary set of C++ data structures to a sequence of bytes. Such a system can be used to reconstitute an equivalent structure in another program context. Depending on the context, this might used implement object persistence," That's what the system does - and everthing follows from that.
and (2) seems ludicrously complex.
LOL - it is. It started out simpler though
As alluded to in the documentation, this creates a morass of problems (object-tracking, memory leaks etc.). Having said that, I have to applaud the tour-de-force of C++ wizardry required to make all of this magic work.
TA - DA - thank youl
To quote Bjarne Stroustrup, "...but you have to be very clever. If any of you have seen some of the Boost stuff, you don't want to be that clever!" (from his recent Waterloo talk)
LOL - maybe so. maybe C++ should be fixed up so one doesn't have to be that clever to make libraries to avoid re-doing the same stuff over and over. Or maybe its time to start thinking about a whole new language given what we've learned about what we need to do. But really, all the "excess" cleaverness is only there to address some really need. Take your choice - stay away from "clever code" and condem yourself to a "groundhog day" life of writing the same stuff over and over with minor variations or use the "clever stuff" and concentrate your brain power and creativity on breaking new ground.
It seems to me that a cleaner, simpler (and less ambitious) solution would just be to make serialization of pointers an error.
This would be exceedingly easy to do. Just make a dervation from an archive which traps attempts to serialize a pointer. In fact, I've been looking for a case study on archive adaptors and this is a great example.
What on earth does it actually mean to serialize a pointer?
Exactly what you think it means - see above
And why would I want to do such a thing, anyway?
I don't know what your application is. Robert Ramey