Robert Ramey ha escrito:
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,
Suppose we just reverted to 1.34 and documented the helper interace. How would you proposal be different than this? That's what I'm missing.
Well, it depends on whether you state that all conformant Archive types must be implemented by deriving from common_{i|o}archive or not. If derivation from common_{i|o}archive is a requisite for conformance to the Archive concept, then there would be little *conceptual* differences between that situation and my proposal. This is a question for you: In 1.34, is an archive type *required* to derive from common_{i|o}archive to comply with the Archive concept? I'll try to summarize here the different approaches, past, present and proposed, that we have discussed so far, along with their implications regarding serializability of shared_ptrs and other types relying on the helper API. I'd be grateful if you can review the table and confirm whether you agree with it (leaving aside which option you favor, I'm here mostly interested in a correct description of the options): A) Situation in 1.34 * Archive types are not required to derive from common_{i|o}archive. * common_{i|o}archive provides undocumentedly the helper API. * shared_ptr is not Serializable formally speaking. It happens to be serializable for common_{i|o}archive-derived archives only, through an undocumented interface. B) Situation in 1.34, bis * Archive types *are* required to derive from common_{i|o}archive. * common_{i|o}archive provides undocumentedly the helper API. * shared_ptr is Serializable. It happens to be serializable through an undocumented interface, so no other type can formally speaking use that API. C) Situation in 1.34 + documented helper API * Archive types are not required to derive from common_{i|o}archive. * common_{i|o}archive provides the documented helper API. * shared_ptr is not Serializable formally speaking. It happens to be serializable for common_{i|o}archive-derived archives only, as well as any other type relying on the public helper API. D) Situation in 1.34 + documented helper API, bis * Archive types *are* required to derive from common_{i|o}archive. * common_{i|o}archive provides the documented helper API. * shared_ptr and any type relying on the public helper API are Serializable. E) Situation in trunk * Conformant Archive types are allowed not to provide shared_ptr support (e.g. naked_* archives). * shared_ptr is not Serializable formally speaking. It happens to be serializable for some archives only, through an undocumented interface. * No helper API provided. F) Robert's proposal as of 2007/09/08 (http://tinyurl.com/2dfa3m ) * Conformant Archive types are allowed not to provide shared_ptr support or the helper API (e.g. naked_* archives). * Some archive types do provide shared_ptr and helper API, though this is not a requirement of the Archive concept. * shared_ptr and any type relying on the public helper API are not Serializable formally speaking. They happen to be serializable for some archive types only. G) Joaquín's proposal as of 2007/09/26 (http://tinyurl.com/2tuucq ) * Conformant Archive types are required to provide an extension API ({get|set}_extension_obj). This constitutes a revision of the Archive concept. * B.S provides shared_ptr support and the helper API. * shared_ptr and any type relying on the public helper API are Serializable. I've tried to describe the options as dispassionately as I could, so as to lay a common ground for further discussion. Do you see any error in the description? Are you satisfied with this rendering of the available options?
Of course it would mean an expansion of the Archive Concept for just one data type.
But an important one (and more are coming, e.g. std::tr1::shared_ptr). You are of course free to avoid expanding the Archive concept as in E) and F), but the logical implication of this is that shared_ptr is technically not serializable. Nothing wrong about that, if that's your declared intention, but users should know.
Another layer of concept for users to (mis)understand and ask about and whatever.
That's the job of a lib maintainer. I hope you assess every possible extension to your library on the basis of its technical merits. If you plainly state that B.S is closed for extension, well, this discussion is moot.
And there will always be data types whose authors don't wish to expose enough functionality to be compatiable with boost serialization - so were does it end? And all this for just one such datatype so far?
In my particular case, I can assure you that the need of a helper API is a genuine one: I cannot serialize my type efficiently without that API, no matter how much I want to expose the guts of my type for serialization purposes. Please believe me on that, this is not a case of me wanting to keep my type encapulated, "pure", or anything. It's sheer impossibility to do it otherwise. Of course, coming up with some more types that could put the helper API to good use would strengthen my position, that' for sure. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo