Re: [Boost-users] Serialization newbie needs help

From: Dominick Layfield (dom.layfield_at_[hidden])
Date: 2007-08-20 21:35:05

"Robert Ramey" <ramey_at_[hidden]> wrote:
> Actually, I've considered reviewing all the email in this list and 
> summarizing
> the results in a section "Hints and Troubleshooting Tips".  I think this
> is useful and necessary and useful, but I just havent gotten around to it.

That sounds ideal.

 > > 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!   :-)
 >
> LOL - I haven't had time to make any real apps lately.

So... no example at all?

My problem is that I just don't see when pointer serialization would be a big 
win.  But I can't tell if I just have a limited perspective.  That's why I was 
genuinely hoping that you could provide a concrete example.

Naturally, a system that "just works" no matter what structure is thrown at it 
sounds very enticing.

However, as you have acknowledged, the system is not foolproof, and user gotchas 
remain.  One way to eliminate the gotchas would be to reduce the scope of the 
library.  Clearly, this is unlikely to happen, as (i) you've invested a lot of 
time and effort getting the pointer magic to work, and (ii) there are probably a 
lot of applications out there that would break if you did so.

I for one would certainly appreciate a simplified version which omitted the 
pointer magic, and thus removed the const trap and similar issues.  If I want to 
set up pointers within an object, then I can do so manually using the 
type-specific load()/save() functions.

Obviously, I can just switch to a different serialization library (e.g. s11n). 
But as much as possible, I would like to stick with whatever is most "standard". 
  And as part of the Boost family, I'm guessing that boost::serialization is top 
dog here.  Would that be right?  Is this library included in any of the proposed 
  C++ standards (TR2, C++0x)?

 > > 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.
 >
> And that's the one thing I didn't do - I believe I "borrowed" it from Jens 
> Maurer.

Hah!  Ooops.  Well, that compliment backfired!  ;-)

Let's try again:  I *really* appreciate the built-in support for all the STL 
container classes.  So far, these have "just worked" perfectly for me.  Nice work!

> One tiny point. I'm aware that the "const" trap is annoying.  But I've 
> become
> convinced that the annoyance is small compared to the hassles it saves me
> and users from.  I suspect that those who have a problem with aren't in the
> habit of using "const" everywhere they can.

It does seem bizarre to have to const-cast an object just so that it can be 
output.  I presume that the majority of objects that are to be serialized are 
not intrinsically constant, so this needs to be done the majority of the time. 
And it looks dangerous.

What does the const-cast actually mean in this context?  I assume it means: "I 
promise that no other thread is going to modify the object (or anything its 
pointers point to) while the serialize() operation is pending.  Is that correct? 
    If so, then shouldn't it be solved explicitly with concurrent programming 
primitives (i.e. mutexes or similar)?

-- Dominick