Boost logo

Boost :

From: Peter Dimov (pdimov_at_[hidden])
Date: 2007-06-06 11:03:41

David Abrahams wrote:
> on Wed Jun 06 2007, "Martin Bonner" <>
> wrote:
>> David Abrahams wrote:
>>> "Emil Dotchevski" <> wrote:
>>>> The more extensive the refactoring you're doing is, the more
>>>> important it is for you to update often, so you don't deviate from
>>>> everyone else's work too much.
>>> If that's true, it implies we have libraries with coupled
>>> implementation details [, that] should never happen IMO
>> Hmm. It's quite easy to depend by accident on implementation
>> details. My favourite example is a component that doesn't document
>> that it returns things in a particular order. However in version 1,
>> for ease of implementation, it stores things in a std::map - and
>> thus actually returns them in ascending order; in version 2 it
>> upgrades to an unordered_map - and returns things in an arbitrary
>> order. The result is that a dependant component breaks. The fault
>> is in the dependant component (it relied on undocumentend
>> behaviour), but finding that before the change can only be done by
>> the most intensive code review (and extensive documentation).
>> Having said all that, I agree that libraries with coupled
>> implementation details should be avoided - but we need to cope with
>> accidental coupling.
> Probably. I only said "should," not "does" never happen. In any
> case, it will be rare, and in the context of the discussion, if your
> library depends on my implementation details, it deserves to break
> when I update my library.

Hypothetically speaking - I'm not saying that this will be a problem in
practice - you can't break your dependencies (on the -stable branch) even
when they deserve it, since the automatic merge script will reject your
change as causing regressions.

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