From: David Abrahams (dave_at_[hidden])
Date: 2008-07-16 01:29:10
on Tue Jul 15 2008, "Emil Dotchevski" <emil-AT-revergestudios.com> wrote:
> On Tue, Jul 15, 2008 at 7:11 PM, David Abrahams <dave_at_[hidden]> wrote:
>> on Tue Jul 15 2008, "Emil Dotchevski" <emil-AT-revergestudios.com> 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
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.)
> 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 http://www.boostpro.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk