Hi Matthias! A little later I noticed that even the inclusion of vector_135.hpp does not suppress these item_version variables to occur! Maybe this is a bug? I'm glad to read that there will be a strong typedef in the future such that I can filter out things as I want to. In the mean-time I just threw out the corresponding lines of code from vector.hpp to stop it from writing out these variables which is not very nice, but well we don't live in a perfect world anyway... :) Sebastian On Fri, 2008-08-01 at 09:15 -0700, Matthias Troyer wrote:

Hi Sebastian,

Indeed, the item version appeared in 1.34 even for primitive types, and as you point out correctly, not as a BOOST_STRONG_TYPEDEF. At the same time I optimized the array serialization, and with the two developments going in parallel I missed this small change in 1.34, so that while 1.35 and 1.34 are both compatible with all versions prior to 1.33, they are not mutually compatible. For 1.36 it was decided to have compatibility to 1.34 and earlier, and have the workaround for 1.35. It was too late to do any major change like you suggest, but my plan for 1.37 is indeed to make this a BOOST_STRONG_TYPEDEF so that it can be filtered, and actually to skip it for all non-versioned types.

I would recommend you to use the vector_135.hpp header for now.

Matthias

On 1 Aug 2008, at 06:21, Sebastian Weber wrote:

...

Hi!

I just switched to the new 1.36.0 beta release and was very confused by the new scheme how optimized arrays are handled within archives as I have implemented an HDF5 archive by myself. After a while I found out how to fix it by browsing SVN changesets - is there some documentation about it I overlooked? Well, now I even see that I have to include serialization/vector_135.hpp to avoid this strange item_version tag to appear which distracts my archives. This is fine, but this is a meta-information, wouldn't it be possible to use some BOOST_STRONG_TYPEDEF to inject this item_version variable as some specific meta-type which I can then filter in my archive?

Greetings,

Sebastian

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

Hmm is there any article or paper explaining the trick and why it's different of the classic idiom using the ellipsis argument to discrimiante the correct call to the inner function.

Comments in http://svn.boost.org/svn/boost/trunk/boost/detail/is_incrementable.hpp could answer some of your questions.

IN the same vein, why using a static reference instead of constructing the object in place in the sizeof operator ?

Because we don't know how to construct a variable of type T. Should we use default constructor T()? But what if it does not have it? Roman Perepelitsa.