Re: [boost] [1.44] Beta progress?

Subject: Re: [boost] [1.44] Beta progress?
From: Robert Ramey (ramey_at_[hidden])
Date: 2010-07-27 13:19:53

Matthias Troyer wrote:
> On 26 Jul 2010, at 18:25, David Abrahams wrote:

>> I think it's crucially important to _correctly_ identify the cause
>> of this impedance mismatch, and so far, I don't think that has
>> happened.
>
> Here is the issue: if one does not want to implement serialization
> from scratch one has to derive from
> boost::archive::detail::common_[io]archive. The *implicit* and not
> documented requirements for such a derived archive are to deal with
> serialization os
>
> - std::string (and optionally std::wstring?)
> - fundamental C++ integral, boolean, and floating point types
> - an *unspecified* list of "primitive" types

> Those primitive types had the semantics of integral types, but no
> concepts were documented for those types, and neither were those
> types one had to support part of the public interface. However, any
> archive still had to correctly serialize those types. would you call
> this missing documentation or specification?

First of all - these are serializable types by virtue of
the fact that they are convertible to integers and references
to integers.  This is why the the issue never came to my attention.
When I "improved" them, I did remove default constructability
because it was convenient and helpful - and it did trip
some compile errors in my archves. I just fixed them.
The whole excersize diminished warnings and potential code breakage so I was
happy with it.  I confess that the impact other archives
didn't occur to me.  Sorry about that.

There is a section in the documentation
Implemenation Notes/Code Structure/Files which implement the library/Archive 
Development
which includes information which I thought would be helpful to those
creating their own versions of the archives implemented inside
the library.  I'm certainly willing to entertain submissions that
enhance and/or improve this part of the documentation.  I can
easily add the list of types used internally, (version_type etc) to
the documentation along with the guarentee that they will
always be convertible to integers and they will be marked
as "primitive".  Would that be helpful?

If you say that really need to know about each type I'm not
going to dispute it.  But I will say I'm not seeing it.

I sort of expect to see something like:

class mpi_oprimitive ... {
    mpioutputfunction m_out;
    template<typename T, std::size_t s>
    mpi_out{
        // uh-oh programming error - no mpi size
        BOOST_STATIC_ASSERT(0 == s);
    }

    mpiout_int<int, 2>(int t){
        mpi_out(MPI_SHORT_INT(t)));
    }
    mpiout_int<int, 4>(int t){
        mpi_out(MPI_LONG_INT(t)));
    }
    ...?
    void save(int t){
        mpiout_int(t, sizeof(t));
    }
    void save(short int t){
        mpiout_int(t, sizeof(t));
    }
    void save(long int t){
        mpiout_int(t, sizeof(t));
    }
    ..?

    mpiout_uint<int, 2>(unsigned int t){
        mpi_out(MPI_SHORT_INT(t)));
    }
    mpiout_uint<int, 4>(unsigned int t){
        mpi_out(MPI_LONG_INT(t)));
    }
    ...?
    void save(unsigned int t){
        mpiout_uint(t, sizeof(t));
    }
    void save(const unsigned short int t){
        mpiout_uint(t, sizeof(t));
    }
    void save(const unsigned long int t){
        mpiout_int(t, sizeof(t));
    }
    ..?
    }
    ...

I'm not even suggesting this, I'm just explaining
why adding "more" to the documentation or
spec or whatever would have occurred to me.

Robert Ramey