Re: [boost] [1.44] Beta progress?

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

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.

Matthias