Re: [boost] [1.44] Beta progress?

Subject: Re: [boost] [1.44] Beta progress?
From: Matthias Troyer (troyer_at_[hidden])
Date: 2010-07-27 09:48:00

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 one thing that might fit what you are looking for: all the special primitive types had been "strong typedefs", where the strong typedef is documented here:

http://www.boost.org/doc/libs/1_43_0/libs/serialization/doc/strong_typedef.html

included in this documentation is the use of the default constructor of such a "strong typedef", but those types can no longer be default constructed.

I don't think though that this is the real issue here. The real issue is that Robert has viewed these types as implementation details although they are important for anyone wanting to implement an archive.

Matthias