From: Robert Ramey (ramey_at_[hidden])
Date: 2002-03-22 13:05:36
From: "Vahan Margaryan" <vahan_at_[hidden]>
Subject: Re: [boost] Serialization Draft Submission # 2
Date: Fri, 22 Mar 2002 09:53:50 +0400
> > Fellow programmers
> > I have just uploaded draft # 2 of my proposal for a boost library to
> > address saving and restoring of C++ objects. Serialization.zip
> I have written a similar system for my former company. Some of the things
> that I have discovered that might be interesting to you in your development:
> 1. When loading containers, it's better to use their specific features to
> achieve maximum performance. Specifically:
> a) You can call 'reserve' for a vector, before reading in the elements.
> b) When reading in map, set, multimap, multiset, you can call insert(end( ),
> t) instead of insert(t). When you write out a tree-based associative
> container, the elements are written out sorted. Therefore, when you read
> them back, you can assume that each consecutive item should be inserted at
> the end. The assumption isn't always valid, because sometimes the predicate
> depends on volatile stuff, like values of pointers. In that case, insert at
> end( ) is the same as plain insert. In the more frequent case, when
> predicates are not sensitive to changes in pointer values, insert at end( )
> is much faster.
> c) Hash containers differ across implementations. Whenever the
> implementation allows, it makes sense to determine an optimal number of hash
> buckets during loading and call resize( ). Then both loading of the hash
> table and the further operation of the container is faster.
> These modifications affect the speed of loading very significantly, when
> many objects and containers are deserialized. I have observed a 3x increase
> in performance in one particular case.
> 2. Compatibility issues:
> I tried to use the library under MSVC 6.0, and it worked, after a couple of
> minor changes.
This is great news for me.
> a) There is no <hash_map> in the standard library, and some libraries,
> including the one coming with MSVC 6.0, don't have it in their distribution
> I commented the line including <hash_map> out in serialization.hpp. I guess
> some kind of ifdef is needed there.
> b) MSVC gives several compile errors related to comparison set::iterator ==
> set::const_iterator. When I swap them (const_iterator == iterator), it
> works. This is a bug in the old Dinkum library. The new Dinkum library
> doesn't have this bug, but shipped with MSVC is the old one... Specific
l> ocations where I get this error are
> serialization.hpp, line 930,
> serialization.cpp, line 53
> serialization.cpp, line 115
> Additional compilation problems may arise, as more stuff gets
Thank you for your feedback. This kind of information is extremely valuable to me. I have no other way of getting such information other than through boost members who try the library.
So far all issues raised except one address issues related to the implementation of the library rather than its interface. These have been less common things like diamond shaped inheritance situtations, This is to be expected as I believe almost all requirements requested during the previous dscussion of draft # 1.
The one exception is the discussion refering to XML and "describe". I believe that this is a much larger topic than is apparent so far. I will address this subject in more detail when I upload draft #3 next week. The next draft will be functionally identical but address bug/quirks/refinements in the implementation.
Many thanks for very useful and high quality feedback.
The only feedback that I have found slightly off putting are those that start with the sentence "I havn't had a chance to look at .... but ...." . Even then it has been well meaning and not nasty. The contribution of civility to the productivity of efforts such as these is grossly underestimated. The boost organizers have to be congratulated for addressing this explicity and maintaining a high standard.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk