Re: [Boost-users] Serialization newbie needs help

From: Robert Ramey (ramey_at_[hidden])
Date: 2007-08-20 23:50:30

Dominick Layfield wrote:
> "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.

There are a couple of demos in the "example" directory which demonstrate
this facility.  The are small examples for illustrative purposes, but they
are not contrived and represent the kinds of things that are interesting
for people to do.

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

This is the motivation from my personal perspective.

Also, any library submission to boost must compare favorably with
in every aspect with any alternative system known to man.  Otherwise
someone in the review process will make a huge deal that this one
feature is so important that lack there of should disqualify the library
for acceptance.

> However, as you have acknowledged, the system is not foolproof, and
> user gotchas remain.

No system is foolproof.  Gotchas always exist.  That's why we
get paid the big bucks.

>One way to eliminate the gotchas would be to
> reduce the scope of the library.

This you can do yourself by just not using this feature (serialization
of pointers)  I took great pains to be sure that the inclusion of
this feature didn't inflict any kind of cost on those who don't use
this feature.

> Clearly, this is unlikely to
> happen, as (i) you've invested a lot of time and effort getting the
> pointer magic to work,

LOL - you're right - can't throw away something that works

> and (ii) there are probably a lot of
> applications out there that would break if you did so.

Hmmm - sounds like you've answered your own question about
its utility.

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

This reminds me of an old joke.  Man goes to a doctor and says
"every time I touch my belly button it hurts."  The doctor says
"You mean like this" YOWWW - "yeah like that" so the doctor
says "Well, don't do that!"

> Obviously, I can just switch to a different serialization library
> (e.g. s11n).

I believe that library also has serialization of pointers

> 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)?

This serialization library will never be part of any C++ standard.

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

Well, Matthias Troyer has spent a fair amount of time improving that.

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

The objects being serialized can't be changed during the serialization 
process
unless tracking is turned off.  If one is tracking and thereby saving only
one copy of the object, and changing it in the middle tracking won't work.

Because normally one doesn't want to change data while its being saved
one will typically have something like the following in his program.

FileSave(const MyData & md){
    // create archive
    oa << md; // no need for "const cast" because md is already "const"
    ...
}

Now if you find that you have to use a "const cast" you should really
think about why the data you're trying to save can be changing while
its being saved.  If saving data changes it as a side effect - you've
most likely got a conceptual error in the program design.  Using
your approach - give me an example where avoid the "const" trap
is a hard to do or makes the code ugly and I'll show you a program
that is fundamentally mis-concieved.

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

Close - but no cigar.  "const" cannot guarentee that other threads
don't modify it.  But it can guarentee that the process of serialization
itself doesn't do it.  That is it's intent.

Robert Ramey