Robert Ramey ha escrito:
I put the archive helper in as an ad hoc solution to a particular problem. I was always unsatisfied with it as I didn't like the idea of decorating the main serialization library code with special cases. Its my belief that this is what makes libraries die of old age.
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.
However, at the time it seemed expedient so I included it for this one case (shared pointer) and left it undocumented on purpose.
Eventually I found what to me is a much better solution and this is implemented in the next release. This is to use multiple inheritance to add the helper in as a mix-in. This is the way I plan to support this kind of thing in the future. It doesn't change the published API of the serialization library itself. However I will add a section in the documentation - if its not already there describing this technique.
I believe that using mix-in to ad helpers will be equivalent to adding them in at runtime as they are now.
I included the shared_ptr helper mix-in in the in the library in order to not change the current api and in recognition of shared_ptrs priviledged status as a boost component.
I didn't expect anyone to notice this change, as no one had posted a problem which required helpers and it was undocumented.
With all due respect (and admiration for your great lib) I think the mix-in idea has many flaws as compared with the former helper interface. Let me state several points supporting my thesis and addressing some of the claims you make above; I'd be grateful if you could discuss them with me: 1. You state that the mix-in approach "doesn't change the published API of B.S". I don't think so: if I decide to implement an Archive type I must explicitly handle shared_ptr (or decide not to do it, I guess this is what your naked_* archive versions are for), so definitely this shows through the API I'm expected to implement. 2. Having an ad-hoc extension for one particular type seems to me a recipe for disaster. Consider the following: some environments are already providing std::tr1::shared_ptr, which of course does not have built-in serialization capabilities. How am I supposed to serialize this? Are you going to add another mix-in to your Archive classes to handle this as well? 3. You say that adding mix-ins is equivalent to adding helpers, but I think the approaches are radically different. Addition of a mix-in is a. made at compile time b. part of the implementation of the archive while addition of a helper is a. made at run-time b. part of the serialization code for a type Mix-in are closed for extension where helpers are open: If I need a helper for serializing some T and I'm using an Archive whitout special support for that T, all hope is lost. 4. IMHO the helper API in B.S 1.34 is a simple yet powerful capability, and does not look forced or clumsy at all. It simply provides a way to add state info to an archive object, which is in a sense a state machine transtitioning its way during the serialization process. I contend that helpers allow for implementing serialization for types which otherwise would be impossible to serialize or should rely on inefficient detours: a. boost::shared_ptr (unless adhoc provisions are made) b. std::tr1::shared_ptr c. STL containers iterators. d. The lib I'm writing, which is the original cause why I started this thread, provides a class called flyweight<T> where flyweights with the same value share their representation by holding internal pointers to the same T value. Serializating this is trivial with the aid of a saving helper that maps T*s to flyweight<T>s --without helpers, the best I can come up with involves T duplication in the serialization stream and inefficient creation of flyweights on saving time. Of course I'm aware helpers were undocumented and I was basically using them at my own risk, so I'm not complaining about my code being broken by the switch from B.S 1.34 to trunk, I just want to convince you that helpers are indeed a useful general-purpose capability that should be made public, and that the proposed mix-in alternative is flawed. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo