I believe all STL is handled. Serialization of other boost components will have to be the responsibility of their authors or others. Yes, of course. I didn't mean that it should be the serializer's responsibility to support all components. Just that _initially_ having a reasonable set of
Robert Ramey wrote: the most important components would greatly boost ;-) the libs usability from the end-users perspective.
There has been some discussion of where the serialization code for other boost libraries should reside. I don't have strong feelings about this other than I would prefer that it reside outside the serialization library itself. The only exception I would make is for the STL serialization which has no where else in boost to reside and it has a "special" status as and official C++ library.
I agree with this view.
Regarding shared_ & weak_ptr. If the implementation path Robert outlines in the documentation is to be used I guess an official patch to shared_count is necessary. Would be interesting to hear what the smart pointer experts think.
I agree - the silence is deafining. I know there are applications that use my smart pointer serialization code right now. I implemented and tested it but I don't really know for a fact that it addresses all aspects that need to be addressed such as exception safety, threading, and who knows what else.
I too am worried about possible showstoppers regarding thread-safety and such. More "boost-eyes" need to look at this IMO.
Otherwise, I still think the solution I outlined in my previous review that doesn't require modifying shared_ptr could be considered. Downside being that it most likely adds a special-cased codepath to the serializer, but as I said I think it would be worth it.
I would hope that the developer's maintaining shared pointer will address this. putting special case code inside the serialization library would be a serious mistake. Between code, tests, and documentation, its approaching 30,000 lines.
It's of course not a first-hand choice to add special cases, but on the other hand a construct for non-intrusive smart-ptr handling would be able to handle handle other _closed implementation_ pointers too.
* Parts of the library that might become standalone boost libraries The library already provides good separation of components. tatic_warning, strong typedef, pfto, stack_allocate etc are all given candidates that would just need better documentation and (fast-track?) reviews.
A little bit more is going to be required. They've been tested in the context of serialization and that's OK. I think they need to be more polished and that's a little more work than it first appears. Also a separate review would probably fine tune their interface, implementation and capability.
Yes, I don't think there's a need to rush it either. They could simply be "harvested" when the need & time allows.
* What is your evaluation of the documentation?
I would also like to see an improved reference documentation that clearly states the requirements on the types/concepts involved.
Hmmm - that seems pretty unanimous - pretty much a first for boost as far as I know.
Well, simple pre- and post-conditions and a spec about what concepts a type to be serialized has to conform to would cover most of it IMO. I also agree with Dave Abrahams view that this is something all libs should have and whether some miss it is more of a defect in that lib's documentation.
I support the separation of documentation (and implementation) of other boost components that like to support serialization. A simple index with links would suffice I think but most importantly a _consistent_ structure should be agreed upon which new components can follow.
I followed the boost document on how to write documentation. The only wrinkle I added was the right hand index/contents window. I'm pretty pleased with this.
Hmm, my point here wasn't about the main documentation but how an index containing an overview of which components from boost, STL etc have serialization capabilities could be built and linked to the main docs.
One of my tests added support for the STL container adaptors std::stack, queue and priority_queue. I think direct support for them could be convinient since they hide the native containers. I attach my implementation. Feel free to comment
I took a short look. The name stack_hack sort of begs some sort of comment. The main thing is that any component of this type has got to be submitted with a test.
Yes I understand that. I have some simpler tests but before I'd take the time to integrate with the full boost::test etc I wanted to see if the code was considered useful. The idea used in the impl. is that the std::container adaptors hide the adapted container behind a 'proteced' guard and can thus not take advantage of the built in serialization for stl-containers. My "hack" was to inherit from std::stack/queue to get access to the container and then forward it to the serializer (at the expense of one extra copying step). Also see the comments at the top of the .hpp files. In particular this turns the serialization of std::priority_queue into a O(n) operation since the heap interface is bypassed. Regards // Fredrik Blomqvist