Re: [boost] [1.44] Beta progress?

Subject: Re: [boost] [1.44] Beta progress?
From: Matthias Troyer (troyer_at_[hidden])
Date: 2010-07-27 13:52:10

On 27 Jul 2010, at 11:19, Robert Ramey wrote:

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

Robert, I don't see how implicit serializability by virtue of implicit conversion is a part of the serializability concept. Yes, it works for the text archive, and it works for the binary archive since you just copy the bits there - but does every archive have to check all possible conversions?

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

Let's try to improve the situation.

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

Yes, that would be very useful, 

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

Unfortunately it is not as easy since an arbitrary number of datatypes can be created by the user, e.g. for pairs, structs, arrays, ... . Hence there is not a limited list of types but a general template, and thus no automatic conversion takes place.

Matthias