Re: [boost] [1.44] Beta progress?

Subject: Re: [boost] [1.44] Beta progress?
From: Matthias Troyer (troyer_at_[hidden])
Date: 2010-07-22 13:09:17

On 22 Jul 2010, at 11:32, Robert Ramey wrote:

> Matthias Troyer wrote:
>> On 21 Jul 2010, at 23:26, Robert Ramey wrote:
>> 
>>> Robert Ramey wrote:
>>>> Matthias Troyer wrote:
>>>> 
>>>>>> If Matthias or Robert can fix the Sun compilation issues, I'll be
>>>>>> quite content.
>>>>> 
>>>>> Robert should be able to fix it by reintroducing default
>>>>> constructor for his "strongly typedef'ed" classes, and by making
>>>>> one private default constructor public again.
>>>> 
>>>> Hmmm - I'm not so sure about that but I'll take a look at it.
>>>> 
>>> 
>>> I'm looking at this now. I see
>>> 
>>> item_version_type - private default constructor
>>> version_type - private default constructor
>>> class_id_type - public default constructor
>>> 
>>> I suspect that I made no conscious decision to make the private one
>>> private. I can make those public if you think that would help.  I
>>> don't see how it would though.
>>> 
>>> also I have
>>> 
>>> BOOST_ARCHIVE_STRONG_TYPEDEF(class_id_type, class_id_optional_type)
>>> 
>>> which has a public constructor of class_id_optional_type (which I
>>> suspect is the culprit).  Since
>>> class_id_optional_type is derived from class_id_type (via
>>> strong_typedef), that would explain why class_id_type has a public
>>> default constructor and the other's don't.
>>> 
>>> If I'm understanding this correctly, we're dealing with a
>>> compilation error with the sun compiler whose error message has yet
>>> to be revealed to us. I think we need better information to know
>>> what the correct fix is.
>> 
>> 
>> The problem comes from this line in boost/mpi/datatype_fwd.hpp:
>> 
>> template<typename T> MPI_Datatype get_mpi_datatype(const T& x = T());
>> 
>> The compilation error is in the regression logs on the web page and
>> in case of version_type complains that the default constructor is
>> private. In case of class_id_optional_type the problem is that the
>> BOOST_ARCHIVE_STRONG_TYPEDEF in archive/basic_archive.hpp does not
>> define a default constructor on the trunk, while it did in 1.43 and
>> before. Strangely the BOOST_STRONG_TYPEDEF in
>> serialization/strong_typedef.hpp still does have a default
>> constructor.
>> 
>> Adding the missing default constructor and making the private ones
>> public will solve the Sun issues.
> 
> I've looked at this in a little more detail and I've got a few questions:
> 
> Why does MPI (or any other library) need to construct an object
> of type "boost::archive::version_type"?  The reason I ask is that I'm
> concerned that a reason for doing this might be to get the size of
> the type.  The class name skeleton suggests this.  The problem is
> that the version_type used internally by the archive class is different
> than the one stored in the file.  So making this change would just
> hide a problem.  In fact, I think this (or something like it) is what
> broke MPI in the first place.

No, this is not what caused the break, and making these default constructible again does not "hide a problem".

But indeed we need the size of the type IN MEMORY to be able to send it over the net and we need to default construct the object to receive into it. SO far those types have been default constructible, but you now changed that - this is what causes the compilation errors.

Please recall that we send directly from memory to memory via the network and don't use files or the representation in files.

Matthias