Subject: Re: [boost] [mpi] Boost.MPI broken
From: Robert Ramey (ramey_at_[hidden])
Date: 2010-07-03 00:58:02
Matthias Troyer wrote:
> 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
they all have to be explicitly listed. The archives included in the system
include a few special ones.
binary archives only include std::string, version_type (and maybe
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
types - those convertable to int or unsigned int, don't have to be
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
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
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
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:
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.
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk