Peter Dimov wrote:
Robert Ramey wrote:
a) The author of boost shared pointer doesn't want to include serialization implementation in his implementation of boost::shared_ptr
The author of boost::shared_ptr wants to, but it isn't straightforward and will take time; and you aren't helping me much, I might add.
Hmmm I understood that you didn't want to include serialization inside the implementation of shared_ptr but had insisted on and totally non-intrusive one which depended only on public interface of shared_ptr. That's what I was refering to. And I'm not unsympathetic to this point of view. In fact its exactly the reason I want to avoid including code to implement one specific type (shared_ptr) inside the serialization implementation. Shifting the problem from one library to a different libray may be a solution for one developer - but its not a solution for boost as a whole. So far the only concrete constructive suggestion I've seen is the one I just posted.
The latest updates to shared_pointer checked into CVS about 10 days ago break current serialzation of shared pointer. In no way will I have time to fix this before 15 April.
You can see now why I don't consider "access to the implementation" a viable approach.
I never failed to see your point - I just never really saw an attractive resolution. Lacking such a resolution - I've "made it work" which is more than anyone else has done.
It is not reasonable to cease any further work on boost::shared_ptr because the serialization library depends on a specific implementation.
Maybe, but it will leave some developers in the lurch and the issue has been out there for over a year.
Your other suggestion was "add a serialize member to shared_ptr and just make it work." This is easier said than done. The serialization library is fairly complex and figuring out the best way to extend it non-intrusively with the necessary support requires more time than I have at the moment.
Welcome to the club. Robert Ramey