On Thu, Nov 11, 2004 at 10:35:45PM -0800, Robert Ramey wrote: [...]
User program which use serialization library generally compile quite fast. 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 he 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
"Christoph Ludwig" <cludwig@cdc.informatik.tu-darmstadt.de> wrote in message news:20041112094527.GA14367@cdc-ws9.cdc.informatik.tu-darmstadt.de... that library
has voiced such reservations to me.
Here is some user experience:
[snip] Hmm - I guess I'll have to retract the following statement
User program which use serialization library generally compile quite fast.
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