Matthias Troyer wrote:
On 26 Jul 2010, at 13:22, David Abrahams wrote: In 1.44 Robert has changed the implementation of the "strong typedef", greatly reducing the concepts the type models. To cope with that Robert had to rewrite parts of Boost.Serialization, but the changes also lead to the breaking of Boost.MPI and most likely also other archives based on Boost.Serialization. As far as I can see Robert removed the default constructor since he did not need it anymore after changing his archives - but he did not realize that there was other code that might get broken.
I've been thinking about this some more and now I remember a little more about the history and rationale for the way things are the way they are. When I factored out the class ?_?primitive I had in mind that this would be the "C primtive" layer which would include serialization for the c++ primitive types. The _?archive layer would handle other types with special handling or passing them on to the "primitive" class. I ended up with two prmitive classes text and binary. text used stream - binary just saved/loaded the raw bytes. At the time you posed the question of why not use least16_t, etc in the primitive class. I wasn't sold on the idea as it broke my original concept, but it did make me wonder - if maybe it wasn't a better idea. In fact, I think the original C made a big mistake in making primtives (int, etc) whose size vary from machine to machine. I'm thinking we would have better off using int16,etc as primitives and typedef int for each machine. So when I made the internal serializable types for archives, I made sure that they would all be convertible to int, unsigned int, etc. so that text_primitive could handle them without having to list them one by one and tie them to some specifc sort of integer. I got all this for free using STRONG_TYPEDEF. When a few of the types changed and I had to make them more complicated, I had some problems and made these types "less" than integers. This let me trap mis-use of these numbers which don't have all features that integers do - e.g. it makes no sense to add version #. Since I included conversions to c++ primitives - all my archives worked. The only changes I had to make were fixing inadvertant usage of these types as integers which before were generating warnings and now were generating errors. I never thought of of other archives. I guess i just presumed that they would use either text_primitive or binary_primitive or that they wouldn't be any more problem than my archive classes were. I knew little of MPI but I did know it derived from binary_archive so it would never occur to me that there would be a problem. I just assumed it worked just as binary_archive does - just send the bytes. Looking a little more, it seems that it sends the data as MPI types. so you have to convert each kind of integer. I'm still not getting why implicit convesion operators don't do class_id_type -> int16_t -> int ->send as mpi_integer or something like that. In otherwords, if this works for text_archives, why doesn't it work for mpi_archives? The "new" types do convert to integers or typedefs of integers (note: NOT STRONG_TYPEDEF) so I'm surprised this comes up - even in mpi. Anyway - the underlying concept for STRONG_TYPEDEF is "convertible to underlying type" which I thought I implemented in the "hand rolled" implementations. So, I'm not sure what should be added to the hand rolled implementions to address this. Note that I'm not declining to do anything, I'm just not sure what best thing to do is. Robert Ramey