Matthias Troyer wrote:
Hi,
The attached patch fixes the compilation problem on MacOS X - could someone please check whether this also works on other platforms?
The fundamental problem is the definition of the set of "primitive" types that any archive class needs to support to be compatible with Boost.Serialization. In the past those had been the fundamental builtin types and std::string.
This has now changed to include a list of 10 additional types that were previously serialized using their serialize() function.
I'm not seeing this.
This change in the list of primitive types that every archive needs to support has been a serious breaking change and will most likely also impact other archives.
I'm not seeing this either.
Robert, it would be good if you could add an explicit list of all primitive types that every archive needs to support to the documentation and archive concept, and announce any upcoming changes?
all archives need to support all primitive types. But that doesnt' mean that they all have to be explicitly listed. The archives included in the system only include a few special ones. binary archives only include std::string, version_type (and maybe collection_size_type) because they have changed. All the rest are just written out in binary. text archives only a few special ones like string, char and wchar. All the other primitive types - those convertable to int or unsigned int, don't have to be explicitly specified. A number of types like class_id, .... are implicitly convertable to ints and so don't need special handling - it's done automatically. The are and always have been marked primitive. The only really new case is item_version_type. I tried to handlle it as non-primitive but that created other issues that I'd prefer not to go into here. So if +BOOST_MPI_DATATYPE(boost::archive::class_id_reference_type, get_mpi_datatype(int_least16_t()), integer); wasn't needed before, it shouldn't be needed now nor vice-versa. I think you've over looked the implicit conversion of these types to "true" primitives like int. On the other hand - something like +BOOST_MPI_DATATYPE(boost::archive::version_type, get_mpi_datatype(uint_least8_t()), integer); merit's scrutiny since an 8 bit object in some i/o systems - e.g. text streams will be rendered as an ascii character rather than an integer - which would create problems. On the other, other hand. I believe that MPI is a type of binary archive, so the above issue, doesn't show up as a problem. Also the only reason for special handling of version_type and item_verion_type is to maintain historical compatibility. It's likely that MPI doesn't need to consider this. When I looked at the error message. It seemed that all that was needed would be: BOOST_MPI_DATATYPE( for 3 new types (at most). But since I have no idea what the function of that macro is, I didn't feel comfortable looking into it. Thanks for working on it. Robert Ramey
Ideally though it would be great if those types could get their serialize() function back so that they do not need to be treated ad primitive types.
Matthias