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