Subject: Re: [boost] [1.44] Beta progress?
From: Matthias Troyer (troyer_at_[hidden])
Date: 2010-07-26 16:15:31
On 26 Jul 2010, at 13:22, David Abrahams wrote:
> On Jul 26, 2010, at 11:51 AM, Matthias Troyer wrote:
>> On 26 Jul 2010, at 05:05, David Abrahams wrote:
>>> [sent from tiny mobile device]
>>> On Jul 26, 2010, at 1:56 AM, "Robert Ramey" <ramey_at_[hidden]> wrote:
>>>> As I've said - I just never thought about this. On
>>>> the other hand, I don't think the "detail" interface
>>>> has changed very much (if at all) over time. I can't
>>>> honestly say I know this - because as I've said -
>>>> I never thought about it. I suspect that it hasn't
>>>> changed much because we haven't had much
>>>> if any breakage originating in this area.
>>> 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. 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk