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