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:
>>> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk