Re: [boost] [1.44] Beta progress?

Subject: Re: [boost] [1.44] Beta progress?
From: Robert Ramey (ramey_at_[hidden])
Date: 2010-07-22 13:32:49

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.

Robert Ramey

> Matthias
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost