Boost logo

Boost :

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

on Tue Jul 15 2008, "Emil Dotchevski" <> wrote:

> On Tue, Jul 15, 2008 at 7:11 PM, David Abrahams <dave_at_[hidden]> wrote:
>> on Tue Jul 15 2008, "Emil Dotchevski" <> wrote:
>>> Here is an example: adding the Exception library "broke" several other
>>> libraries that were throwing ints or enums through
>>> boost::throw_exception. The fact is that boost::throw_exception has
>>> always required that its argument is of type that derives from
>>> std::exception, but it did nothing to enforce this requirement. Now it
>>> does enforce it which exposed the bugs in the other libraries. This is
>>> a good thing.
>> That was one of the kinds of cases I had in mind when wondering if it
>> was a good idea to rely on dependent libraries' tests to discover
>> problems in a library.
> As opposed to?

I don't understand your question.

> I mean, it's not like you want to rely on other libraries to catch
> your bugs, but you can't be 101% sure you're not using other libraries
> inappropriately.

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.

> 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?

> This might become source of regressions, which are typically
> undetected until the implementation of the dependent library changes.

Sure. What's your point?

Dave Abrahams
BoostPro Computing

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