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
> 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.
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk