Re: [Boost-bugs] [Boost C++ Libraries] #4214: Use collection_size_type/version_type consistently (fixes Boost.MPI)

Subject: Re: [Boost-bugs] [Boost C++ Libraries] #4214: Use collection_size_type/version_type consistently (fixes Boost.MPI)
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2010-05-16 17:34:28

#4214: Use collection_size_type/version_type consistently (fixes Boost.MPI)
--------------------------------------+-------------------------------------
  Reporter:  dgregor                  |       Owner:  ramey        
      Type:  Patches                  |      Status:  reopened     
 Milestone:  Boost 1.44.0             |   Component:  serialization
   Version:  Boost Development Trunk  |    Severity:  Problem      
Resolution:                           |    Keywords:               
--------------------------------------+-------------------------------------

Comment(by ramey):

 Actually I'm pretty unhappy with it as well.

 I'm interested in getting it addressed in a definitive way.  But as you
 can see, it requires a lot of thought to get it "right".

 Right now I'm concerned that the change which created the issue here might
 have created binary_?archives.  This would be a huge hassle to deal with.

 It never occurred to me that both boost::serialization::version_type and
 boost::archive::version_type exist.  Obviously this is a bad idea and
 likely the source of some problems that I'm not aware of.  So clearly, the
 concepts of class version and archive library version are muddled.

 A couple of random but related observations:

 a) collection_size is sort of a problem.  unsigned int was unsatisfactory.
 So we made collection_size_type.  But it turns out that each collection
 (vector, list, etc.) has it's own size_type - e.g. vector::size_t.  So
 collection_size_type isn't really any more "correct" than the original
 "unsigned int".  In practice it's probably not a problem. But someday it
 could pop up.

 b) The library has evolved much more since it's acceptance than is
 generally appreciated.  It's MUCH less of a hack than it used to be and
 much more regular.  This occurred over years as bugs were fixed.  Also a
 large number of issues came up as people almost immediately started to put
 serialization code into DLLS.   Every compiler has it's own rules for
 things like code stripping.  These rules vary between debug and release
 versions for each compiler.  And of course each compiler has it's own
 attribute syntax for adding the information that these rules use.  See
 force_include.hpp. This raises lot's of issues in that, as far as I can
 tell, dynamic linking isn't in any way addressed in the C++ standard.

 c) A number of things like EXPORT and now VERSION were "almost correct".
 Of course this turns out to be worse than "wrong" because it makes the
 issues harder to tease apart.  I think EXPORT is almost there. VERSION is
 still a festering sore.

 d) Applying fixes to the serialization library is much harder than other
 libraries because one wants to avoid invalidating existing archives.

 Given all this, along with the fact that I've continually tweaked it, it's
 absolutely amazing to me that the library works as well as it does.

 I'm happy to consider/integrate any changes you want to make in these or
 other areas.

 Robert Ramey

-- 
Ticket URL: <https://svn.boost.org/trac/boost/ticket/4214#comment:5>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.