Re: [boost] [1.44] Beta progress?

Subject: Re: [boost] [1.44] Beta progress?
From: Matthias Troyer (troyer_at_[hidden])
Date: 2010-07-26 19:45:47

>  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.

The reason is that the MPI archives can deal with more types than just the builtin C++ types. For compound types we use their serialize function to actually create the corresponding MPI datatype. The problem now is that these "primitive" types do not have a serialize function, and thus, like for the builtin types, we have to manually specify the correct MPI datatype. What I need for that is not the integer value of the variable that is stored in the type (which I could get by casting to any integer), but the type of it. Now I could probably write a set of overloaded  functions to figure out which conversion is the best and from that deduce that type, but it would be easier and safer to have the type accessible as a member. In any case I will not do anything unless I can expect a stable interface and do not have to rely again on what you call implementation details.

> 
> 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.

Having the base_type  or however you call it accessible, and having a documented interface to these primitive types and a stable list of them should be enough. Any additional type will need a change to Boost.MPI, just as any change in the interface of these types.

Matthias