Re: [boost] [1.44] Beta progress?

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