----- Mensaje original ----- De: Robert Ramey <ramey@rrsd.com> Fecha: Viernes, Septiembre 7, 2007 5:42 pm Asunto: Re: [boost][serialization][trunk]please bring us archive helpers back Para: boost@lists.boost.org
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. [...] Under the 1.34 helper system, a few calls were added to the class hierarchy at high level. This basically added a set of pointers to helper classes which were handled by smart_ptr so they would automatically be destroyed when the archive was destroyed.
If you want this functionality in he new system a) create a "helper manager" class b) move the helper manager code from the 1.34 release into this new class. c) mixin you new "helper manager" along with "naked_text_iarchive" and - voila - you have the old functionality as it was before.
I'm sure this wouldn't be hard to do.
This can be done, but makes the archive types to be used dependent on the types to be serialized!! This is a wrong approach, IMHO. Consider the following: I have a type foo for which I need a serialization helper, let's call it foo_ser_helper, which I embed into B.S by means of a foo_ser_hlp_manager as you suggest: struct foo_text_iarchive: naked_text_iarchive, foo_ser_hlp_manager {...}; Now, the problem is that user code willing to serialize my foo can't use a regular text_iarchive but have to resort to foo_text_iarchive instead. This is annoying enough because I force the user to change her code in a rather surprising way (considering she need not change archive types for serializing "normal" types), but things can get worse: if now some other author provides a class bar under similar conditions: struct bar_text_iarchive: text_iarchive, bar_ser_hlp_manager {...}; what should someone do in order to serialize the following data type? struct udt { foo f; bar b; }; So, I think providing archive types specialized for serializing specific types basically breaks down the architectural design of B.S, which is based on the separation of type-agnostic archives and archive-agnostic serialization code: this is too good to depart from. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo