Re: [boost] [1.44] Beta progress?

Subject: Re: [boost] [1.44] Beta progress?
From: David Abrahams (dave_at_[hidden])
Date: 2010-07-26 20:25:02

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.

--
David Abrahams
BoostPro Computing
http://boostpro.com