Re: [boost] [serialization] Proposal for an extension API totheArchive concept

From: Joaquín Mª López Muñoz (joaquin_at_[hidden])
Date: 2007-09-27 13:23:26

Robert Ramey ha escrito:

> Joaquín Mª López Muñoz wrote:
>
> >> This sounds to me exactly the 1.34 version.  Its just that the
> >> "hook" is undocumented as I considered it a hack required
> >> to overcome the problems associated with just one type -
> >> shared_ptr.
> >
> > There are important differences with respect to Boost 1.34. Hooking
> > is done at run-time, whereas the Boost 1.34 solution was compile-time.
> > Extension is created lazily, which means you don't pay for it if
> > you're
> > not using it. The extension class can grow in the future without
> > Archive classes needing to be redefined or recompiled.
>
> That's the way it is in 1.34

Well, I think that the differences between the hook proposal and what was
provided by Boost 1.34 are patent to you, so I take your statement as meaning
that you don't deem these differences important rather than not being any
difference at all. Please correct me if I'm wrong.

> > Well, I think our respective positions are clear,
>
> Not to me.

OK, I can try to explain myself better :) If you don't grow tired of this
discussion I'll be happy to elaborate my point as much as needed so that
at least we are both fully knowledgeable of each others' proposals.
Then the final call will be yours, of course.

>
> > and I don't want to
> > beat this to death, but please answer the following: under your
> > proposed
> > scheme, does the type shared_ptr conform to the concept Serializable?
> > Note that the only reasonably acceptable answers are "yes" and "no" :)
>
> As I've said, I don't see ANY functional difference between what
> you propose and what's already implemented in 1.34.  If I remember
> correctly, you're concerns were raised upon seeing the changes in
> the trunk - (aka 1.35).  I'm proposing to go back to 1.34 (with
> a slight change in implementation - no change in interface).  I can't
> see how that is not exactly what you wanted.

What you propose indeed reverts to the situation in Boost 1.34 and
for that I thank you. It solves my particular needs, but what I'm proposing
is IMHO an improvement on that.

My prior question "does shared_ptr conform to the concept Serializable"
is not a rhetoric one, and I ask you to consider it closely. Under your proposed
scheme, you'll have archive implementations (naked_*) which

  1. conform to the Archive concept
  AND
  2. are not able to deal with shared_ptrs.

So seems like shared_ptr is serializable but not always. The strict conclusion,
actually, is that shared_ptr is not serializable, and that's what I'm trying to improve
upon. My proposal seeks to provide shared_ptr support *universally*
so that a user is guaranteed that she'll be able to serialize her shared_ptrs with
any archive provided the archive models the Archive concept --period,
no "special" archives required or anything.

To sum it up, what I propose is to go from situation 1 (your proposal)
where:

  1. The Archive concept does not guarantee serializability of shared_ptrs
  and types relying on the helper API.
  2. There are archive implementations which support an extension of
  the Archive concept by which shared_ptrs and helper API are supported.

to situation 2 where:

  1. The Archive concept is sufficient to guarantee that shared_ptrs and
  types relying on the helper API are serializable.

Did I get my point through so far? I'm not trying to convince you now,
only to make sure I have explained my motivations clearly enough.
When that's the case I can go on and provide further arguments in
favor of my proposal.

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo