Re: [boost] [serialization][trunk] please bring usarchive helpers back

From: Joaquín Mª López Muñoz (joaquin_at_[hidden])
Date: 2007-09-07 10:38:21

Robert Ramey ha escrito:

> Joaquín Mª López Muñoz wrote:
>
> > As I see it, the helper interface does not litter the serialization
> > code, it merely provides an extension API for users implementing
> > non-trivial serialization schemes --note that the helper themselves
> > are not part
> > of B.S but belong in the different serializable types, much like the
> > associated serialize() functions.
>
> I didn't really see this.  In large part due to the fact that no one
> over the years as expressed a need for it.  The only reason
> I had to add it was to accomodate design issues with smart_ptr
> which makes it impossible to serialize without special help. So
> I always considered it a pathalogical case.

I think helpers (or some other extension mechanism) are required to
implement non-intrusive serialization of classes with shared_ptr semantics
--to put it more formally, copyable types T internally holding a pointer
to some shared resource of type R where T is not constructible
from a R* (or this construction does not have sharing semantics). This
includes shared_ptr, the class I'm working on and I'm sure there are many
other cases. It's not so usual, but it's bot pathological.

[...]

> As, I've said, based on experience so far, I've been of the idea that
> the only case where one would ever need this is shared_ptr.
>
> So we can think about this.

Thank you for considering my petition. I'll try to show you that there's
genuine value in having helpers (or some equivalent stuff) back
besides solving my particular problem.

> Lately I've become more focused on improving performance of the
> serialization library and this provided part of the motivation for
> eliminating helpers for those who don't need them.

Yep, I guess a mix-in helper for shared_ptr is faster than helpers because
the latter incur the extended_type_info lookup for the helper, right?
Anyway, you can have the helper interface for extensibility and the
mix-in helper for shared_ptr and some other native types you'd wish
to have built-in support for.

>  Another very significant issue was that making the helper concept official
> would mean that I would
> have to document it which would lead to people asking questions about
> it which would lead to people spending a lot of time telling me how it
> could/should be enhanced, and me responding, etc, etc, etc.  So I was
> and still am interested in shrinking down the serialization library by
> factoring that which is orthogonal to serialization.

You can see it this way: if you provide the helper interface, next time
someone (like me) comes whining at you about serialization of T not
being possible with B.S standard API (as is the case for T=shared_ptr)
you can answer him back "use the helper API" instead of burdening
yourself with the task of providing native support for the type
(as was the case for  T=shared_ptr). Less work in the long run :)

> Perhaps the best resolution is to just make a mix-in class equivalent
> to the previous helper functionality.  It would seem to me that this
> would give you every thing we both need.

I'm not sure I'm getting this: would you mind elaborating this design?

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