Boost logo

Boost :

Subject: Re: [boost] [1.44] Beta progress?
From: Matthias Troyer (troyer_at_[hidden])
Date: 2010-07-26 21:36:22


On 26 Jul 2010, at 18:25, David Abrahams wrote:

>
> On Jul 26, 2010, at 4:15 PM, Matthias Troyer wrote:
>
>>>>>
>>>>> Careful and consistent application of the boost concept check library would have caught any problem arising from models not satisfying stated concepts and operations relying on more than documented concept requirements. In fact, after this release would be a good time to apply BCCL to both libraries, to avoid such issues in the future.
>>>>
>>>> Dave, the issue is that no concepts were defined for the classes under discussion.
>>>
>>> Are you saying that "classes under discussion" (by which I suppose you mean the primitive size type) were assumed by the serialization library to model a particular concept that was never defined?
>>
>> Indeed. The primitive types were implemented using a "strong typedef" which was designed to make them model most of the concepts that the underlying integral type models. However this has never been explicitly stated. What would be needed is that the concept those types model is explicitly defined - then I can easily design Boost.MPI to conform to that concept. However, if this is defined as an
>> declared to be an implementation detail that I am not allowed to use without risking the code to be broken anytime then I have to essentially reimplement Boost.Serialization from scratch.
>>
>>
>> In 1.44 Robert has changed the implementation of the "strong typedef", greatly reducing the concepts the type models.
>
> I understand all that, but none of that seems to be an example of the serialization library making concept assumptions that were not defined.
>
> Such an assumption would basically always take the form:
>
> template <class T>
> void some_serialization_component( T x )
> {
> some_operation_on( x );
> }
>
> or
>
> template <class T>
> class some_serialization_component
> {
> ... some_operation_on( T ) ...
> };
>
> where T is not constrained by any concept in documentation, or some_operation_on( x ) is not a requirement of any concept that constrains T.
>
>> To cope with that Robert had to rewrite parts of Boost.Serialization, but the changes also lead to the breaking of Boost.MPI and most likely also other archives based on Boost.Serialization. As far as I can see Robert removed the default constructor since he did not need it anymore after changing his archives - but he did not realize that there was other code that might get broken.
>
> All this I understand too. And yet, listening carefully in this thread, I haven't yet heard of any instances of under-documentation of concept requirements (or failure to model stated concepts, for that matter) on the part of Boost.Serialization
>
> I think it's crucially important to _correctly_ identify the cause of this impedance mismatch, and so far, I don't think that has happened.

Here is the issue: if one does not want to implement serialization from scratch one has to derive from boost::archive::detail::common_[io]archive. The *implicit* and not documented requirements for such a derived archive are to deal with serialization os

- std::string (and optionally std::wstring?)
- fundamental C++ integral, boolean, and floating point types
- an *unspecified* list of "primitive" types

Those primitive types had the semantics of integral types, but no concepts were documented for those types, and neither were those types one had to support part of the public interface. However, any archive still had to correctly serialize those types. would you call this missing documentation or specification?

Matthias


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk