Boost logo

Boost :

From: Robert Ramey (ramey_at_[hidden])
Date: 2004-11-12 11:16:10

"Christoph Ludwig" <cludwig_at_[hidden]> wrote in message
> On Thu, Nov 11, 2004 at 10:35:45PM -0800, Robert Ramey wrote:
> [...]
> > User program which use serialization library generally compile quite
> > No one has reported that serialization adds a disproportionate amount to
> > compile time. I did get one reporte from one user with 80 classes that
> > was starting to get ICEs from VC 7.1 . But that's it.
> >
> > I believe that the size of library has lead some to have reservations
> > regarding performance of the serialization library - compile time, link
> > time, memory size, or execution speed - or its ease of usage. I think
> > such reservations are unfounded. No one who has actually used the
> > has voiced such reservations to me.
> Here is some user experience:


Hmm - I guess I'll have to retract the following statement

> > User program which use serialization library generally compile quite

maybe I can say "reasonably fast". Actually my view was formed by the lack
of complaints and the experience with test programs which do compile quite
fast. Of course the test code doesn't approach the 6M/40 char/line) ~150K
lines of code of this application.

> Besides the problems with the resource usage of the compiler there's
> another point that should IMHO be addressed before the next release:
> The current solution for serializing shared pointers is quite fragile.
> For example, I abonded trials to access my library from Python through
> Boost.Python when the requirements of both libraries conflicted:
> boost/serialization/shared_ptr.hpp has to be included before
> boost/shared_ptr.hpp. And boost/serialization/shared_ptr.hpp includes
> somehow (via config.hpp?) system headers. On the other hand, the
> Python headers need to be included before any system headers. But the
> Boost.Python headers include boost/shared_ptr.hpp... (There is an
> inclusion sequence of system and boost headers that satisfies the
> requirements of all libraries involved, I think. But I did not have
> the time to look into it back then.)

> I don't recall the exact reasons, but I also had to manually register
> the specializations of boost::detail::sp_counted_base_impl. That's an
> implementation detail of shared_ptr that I (as a mere user) don't want
> to know about.

I am aware that the implementation of serialization isn't truely
satisfactory. The problems described are due to a hack used in its
implementation to get access to its private variables. Its a current topic
of discussion as to how serialization of shared_ptr should be implemented.
I suspect that to accomdate serialization with this or any other
serialization library, shared_ptr will have to be enhanced. The current
situation seemed to be the best I could do without messing with shared_ptr
myself. Not a good idea.

I'm hopeful that this will be improved in the future.

Robert Ramey

Boost list run by bdawes at, gregod at, cpdaniel at, john at