Re: [boost] Breaking existing libraries

Subject: Re: [boost] Breaking existing libraries
From: Thorsten Ottosen (thorsten.ottosen_at_[hidden])
Date: 2008-11-23 14:51:51

Dave Handley skrev:
> Thorsten Ottosen wrote:
> 
>> Dave Handley skrev:
>>> Comments inlined:
>>>
>>> Markus Werle writes:
>>>
>>> <snip>
>>
>>> I've got one final point to make here.  I went through and reviewed 
>>> the code changes in boost.range that Tom is referring to.  I wouldn't 
>>> be happy putting this type of code change through in my own 
>>> libraries. Changing the functionality of a default constructed object 
>>> just to get rid of a single test against bool in a couple of 
>>> functions (ostensibly for performance) seems to me misguided.
>>
>> That is of course a valid view. But take to the extreame, it means we 
>> would have to give up the "you don't pay for what you don't use" mantra.
> 
> It doesn't mean that at all.  All this discussion is doing is persuading 
> me that I shouldn't use boost.range in my own code because breaking 
> changes will wreck my own code base.  If I want functionality like 
> boost.range, I should probably go and write my own version.  I would 
> prefer this not to be the case - unfortunately, so much of the 
> discussion here and in the other thread is reinforcing that view.  This 
> sort of thing has the pernicious side effect of marginalising boost.
> 
>>
>>> Furthermore, having different functionality in debug and release, for 
>>> most major users of a library, is just dangerous.  The size and empty 
>>> functions for example assert in debug, but just silent fail in release.
>>
>> "Silently fail" is a bit strong here. I mean, if there are any 
>> unit-test set up, I would expect them to trigger an assert in 
>> debug-mode. I don't consider that "silent".
> 
> Read that again - I said silently fail in release.  When you are dealing 
> in an environment with several million lines of code, it isn't beyond 
> the realm of imagination that every code path isn't covered by unit 
> tests.  In that case, a silent fail in release is pretty much 
> unacceptable since you are risking not the stability of your production 
> code, but the correctness of it.
> 
>>
>>>  The issingular function is even worse, it tells you whether a range 
>>> is singular in debug, but always returns false in release.
>>
>> IIRC, is_singular is not documented. So using it is on your own risk. 
>> It could disappear in the next release or whatever.
> 
> I can't tell what the state of the documentation said before 1.35 so I 
> can't comment here.  Can someone please explain how to get versioned 
> documentation on boost? 

I have looked it up, and its not documented. Period.

Anyway, I'm sorry you feel the way you do. I don't intentionally try
to break people's code, and I have put an enourmous effort into the code 
I've submitted to boost.

FWIW, boost.range is not changing anymore.

-Thorsten