Re: [boost] Breaking existing libraries

Subject: Re: [boost] Breaking existing libraries
From: Dave Handley (dave_at_[hidden])
Date: 2008-11-23 10:04:06

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?  The documentation that gets included in the download zips appears 
to me to be only partial (I can't find any documentation for range there for 
example).

Dave