Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2008-07-16 10:06:44

on Wed Jul 16 2008, "Emil Dotchevski" <> wrote:

> On Tue, Jul 15, 2008 at 10:29 PM, David Abrahams <dave_at_[hidden]> wrote:
>> I was talking about relying on dependent libraries catching bugs in a
>> dependency (e.g. serialization's tests uncovering breakage in type
>> traits). Sounds like you're talking about the other direction, sort of.
> I agree that we don't want to rely on dependent libs to catch bugs in
> a dependency, but sometimes this does happen.


> When a serialization
> library test fails, we can't without further investigation assume that
> some other library is to blame, even if the serialization library
> tests pass with the last and the next release of Boost.

Now you seem to be making the opposite point; that it might be a
Boost.Serialization bug.

>>> For example, you might depend on an implementation detail of another
>>> library without knowing it (note that "not knowing it" isn't always a
>>> matter of being careless.)
>> It isn't?
> Not always. For example, the dependency may be indirect, through
> another library. Or, it might be due to buggy or incomplete
> documentation.

Somebody was careless in that case.

>>> This might become source of regressions, which are typically
>>> undetected until the implementation of the dependent library changes.
>> Sure. What's your point?
> That it is a bad idea to avoid testing an (even stable) library
> against the (unstable) trunk just because this may produce bogus
> failures.

OK, I guess

Dave Abrahams
BoostPro Computing

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