Re: [Boost-users] Serialization newbie needs help

From: Dominick Layfield (dom.layfield_at_[hidden])
Date: 2007-08-18 18:51:34

"Robert Ramey" <ramey_at_[hidden]> wrote:
 >> goes away.  Any chance this could be added to a boost::serialization
 >> FAQ?
 >
 > you mean change the section named "rationale" to "FAQ"?

Ermm... Yes, I suppose so.  There ought to be some section that a newbie who is 
having problems would immediately look to see if this is a common problem.

In my browser, the "Rationale" section of the documentation appears unexpanded 
by default.  And even when I expand it, "Compile time trap when saving a 
non-const value" doesn't seem (when skimming the docs) relevant to the static 
assertion error.  It also didn't appear in my Google search for the cryptic 
error message that the compiler produced.

 >> 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.

As a newbie, I can tell you that it wasn't obvious to me!  :-)

As I said, I wouldn't have expected the serialization library to do any 
automagical pointer stuff, so from this perspective, it's very hard to see what 
object tracking is, and why it would be necessary.

 >> What on earth does it actually mean to serialize a pointer?
 >
 > Exactly what you think it means - see above.

Well, once you've got an idea in your head about what should happen when a 
pointer is serialized (and had that concept for years, and written a whole 
library to implement it!), it probably seems obvious and "natural" that it 
should work that way.

But to a newbie (to boost::serialization, not to C++), this behavior is rather 
surprising.  For example if I do:

     my_class mc;
     my_class* mc_ptr = &mc;
     cout << mc_ptr;

I don't get the my_class object sent to stdout.  I get the value of the pointer 
itself.  If I wanted the actual object displayed, I would dereference the 
pointer.  So my intuition would be that boost::serialization would work in a 
similar way: if I wanted the object itself output/input, I would do it explicitly.

I'm not trying to say that your approach is wrong.  All I'm attempting to point 
out is that other people may have very different (and quite reasonable) 
expectations about what should happen.

 >> And why would I  want to do such a thing, anyway?
 >
 > I don't know what your application is.

Sorry.  What I meant was "Why would someone want this?" or "Why is this a useful 
feature?"

Fundamentally, there are two approaches to dealing with pointer serialization: 
(1) disallow it altogether; or (2) serialize the pointed-to object, and do all 
the clever object-tracking stuff.

The first approach has the benefit of simplicity .  So the only reason to take 
the second approach would be if automagic pointer serialization is really useful.

However, I can't think of an example of when this would be really useful.  Hence 
my question.

But if you could provide me an example of when pointer serialization shines, 
then I would say "Aha! Now I understand why Robert went to so much trouble to 
make this work.", and I could be at peace with the world again!  :-)

BTW, I don't want to sound like I'm bashing your library, so let me end with a 
compliment.   I think the symmetric design of serialize(), with the same 
function used for both input and output, is one of the prettiest idioms I've 
seen in years.

-- Dominick