Robert Ramey ha escrito:
"JOAQUIN LOPEZ MU?Z" wrote:
cons: A naked archive implementation, while conforming with the concept requirements, will fail to handle shared_ptr and any type relying on the helper API.
And will not force everyone who doesn't happen to be using shared_ptr to pay a penalty. This is pro for me.
With the {get|set}_extension_obj proposal, those who are not using shared_ptr do not pay a penalty -- the extension object is never created.
So, how to make B.S provide shared_ptr and helper support whitout polluting the archive concept with too specific provisions? My proposal is to add a single "hook" to the Archive concept which is as agnostic as possible and can be leveraged in the future for unforeseen necessities beyond shared_ptr and helper support. [...] 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.
I proposed making this much simpler.
make a helper api which is similar to that which 1.34 has. The only difference is that it is not implemented in the base class but rather as a mix in - similar to the way shared_ptr_helper is now.
So we would have
naked_archive archive = naked_archive + helper api
and the old shared_ptr serialization would be put back in. The implemenation would be the same, its just taht the calles would be implemented in the mix-in rather than in the base.
Well, I think our respective positions are clear, 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" :) Joaquín M López Muñoz Telefónica, Investigación y Desarrollo