[boost] Re: Re:Re: Serialization Formal Review #2

From: Fredrik Blomqvist (fredrik_blomqvist_at_[hidden])
Date: 2004-04-26 09:54:53

Robert Ramey wrote:
> 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
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