Boost logo

Boost :

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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at