Robert Ramey ha escrito:
Joaquín Mª López Muñoz wrote:
This sounds to me exactly the 1.34 version. Its just that the "hook" is undocumented as I considered it a hack required to overcome the problems associated with just one type - shared_ptr.
There are important differences with respect to Boost 1.34. Hooking is done at run-time, whereas the Boost 1.34 solution was compile-time. Extension is created lazily, which means you don't pay for it if you're not using it. The extension class can grow in the future without Archive classes needing to be redefined or recompiled.
That's the way it is in 1.34
Well, I think that the differences between the hook proposal and what was provided by Boost 1.34 are patent to you, so I take your statement as meaning that you don't deem these differences important rather than not being any difference at all. Please correct me if I'm wrong.
Well, I think our respective positions are clear,
Not to me.
OK, I can try to explain myself better :) If you don't grow tired of this discussion I'll be happy to elaborate my point as much as needed so that at least we are both fully knowledgeable of each others' proposals. Then the final call will be yours, of course.
and I don't want to beat this to death, but please answer the following: under your proposed scheme, does the type shared_ptr conform to the concept Serializable? Note that the only reasonably acceptable answers are "yes" and "no" :)
As I've said, I don't see ANY functional difference between what you propose and what's already implemented in 1.34. If I remember correctly, you're concerns were raised upon seeing the changes in the trunk - (aka 1.35). I'm proposing to go back to 1.34 (with a slight change in implementation - no change in interface). I can't see how that is not exactly what you wanted.
What you propose indeed reverts to the situation in Boost 1.34 and for that I thank you. It solves my particular needs, but what I'm proposing is IMHO an improvement on that. My prior question "does shared_ptr conform to the concept Serializable" is not a rhetoric one, and I ask you to consider it closely. Under your proposed scheme, you'll have archive implementations (naked_*) which 1. conform to the Archive concept AND 2. are not able to deal with shared_ptrs. So seems like shared_ptr is serializable but not always. The strict conclusion, actually, is that shared_ptr is not serializable, and that's what I'm trying to improve upon. My proposal seeks to provide shared_ptr support *universally* so that a user is guaranteed that she'll be able to serialize her shared_ptrs with any archive provided the archive models the Archive concept --period, no "special" archives required or anything. 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, only to make sure I have explained my motivations clearly enough. When that's the case I can go on and provide further arguments in favor of my proposal. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo