Subject: Re: [boost] [1.44] Beta progress?
From: Robert Ramey (ramey_at_[hidden])
Date: 2010-07-26 14:41:09
Matthias Troyer wrote:
> On 25 Jul 2010, at 23:56, Robert Ramey wrote:
>
>> Matthias Troyer wrote:
> Yes, what is missing is the list of special types and their
> interface. In the past they were all STRONG_TYPEDEF, and the
> semantics of STRONG_TYPEDEF was the same as that of the underlying
> integral type. That has changed and broken some code.
>
> The basic issue is that an archive deriving from
> detail::common_[io]archive has to support the fundamental C++ types,
> std:: string, and that collection of special types. In order to
> serialize those special types I need to be able to know something
> about them! The specific list of concepts they model is less
> important than that list being stable (as long as serialization can
> be implemented efficiently). Besides the default constructor it would
> be good to have a type member specifying the (current) implementation
> type:
>
> #define BOOST_ARCHIVE_STRONG_TYPEDEF(T, D) \
> class D : public T { \
> public: \
> typedef T implementation_type; \
> explicit D(const T t) : T(t){} \
> D() : T() {} \
> }; \
A month or so ago I had most of these types implemented with
STRONG_TYPEDEF. In addition to these I had a few
implemented "by hand": tracking_type, class_name_type. So
moving a few from the STRONG_TYPEDEF column to the
"hand rolled" column didn't raise any red flags. I found that
I had to add the following operations to these types:
For T
T:base_type // where base_type is some integer supported by binary_primitive
and text_primitive.
convertable to T::base_type &
convertable to const T::base_type
operator ==
operator<
This was totally ad hoc- I was just "making things work" Of course
STRONG_TYPEDEF supports all of these except base_type which
could easily be added to it at no cost. Soooooo we could
define such a concept and that would solve the current
dilema, avoid future problems, and make mpi_archives
easier to write and more robust. In principle I see this as
an improvement. Of course the devil is in the details.
I see the utility of augmenting STRONG_TYPEDEF but
I wonder about it. if you have code T:base_type and
T is not one of the types we're using - it won't have
this available - compiler error. Wouldn't it be better
to specify the implicit requirements as above and just
know that T will be converted to what one wants? and
sizeof(T) can be applied to both the (now) more elaborate
types as well as C++ primitives.
> and also use the implementation_type member in the other special
> classes. That way you could change those integer types at any time
> without causing any breakage in Boost.MPI. Right now I have to
> manually set these types:
>
> BOOST_MPI_DATATYPE(boost::archive::class_id_optional_type,
> get_mpi_datatype(int_least16_t()), integer);
Though it's off topic at this point, I've never understood what this macro
is for. why do these special types need handling different than any
other common c++ primitive types like integers. Wasn't it enough
for these types to be convertable to integers and references to integers?
> and if you should change class_id_optional_type to be something else
> than int_least16_t the code will break again.
To repeat, I've no problem with the general idea. lets see some
fleshing out of the details.
Robert Ramey