on Tue Jul 15 2008, "Emil Dotchevski" <emil-AT-revergestudios.com> wrote:
On Tue, Jul 15, 2008 at 7:11 PM, David Abrahams <dave@boostpro.com> 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