Re: [boost] [1.36.0] Libraries with unmerged changes?

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
> 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
http://www.boostpro.com