Re: [boost] [Release 1.34] Supported Compilers - another view

From: David Abrahams (dave_at_[hidden])
Date: 2006-02-02 08:33:34

"Gennadiy Rozental" <gennadiy.rozental_at_[hidden]> writes:

>>> Actually Boost.Test is quite stable for a while now.
>>
>> It's not a predisposition; it's borne of experience.  Every time I try
>> to use the library, thinking it's probably the right thing to do, and
>> wanting to like it, I find myself wondering what I've gained for my
>> investment.  Until you can hear that and respond accordingly --
>> instead of dismissing it as the result of predisposition -- Boost.Test
>> is going to continue to be a losing proposition for me.
>
> I am not quite sure what you want me to hear. How should I enhance the 
> library for you to find it worth your investements.

You could make the minimal facility more usable.

>>> BOOST_CHECK don't; if expression throw an exception you need to start a
>>> debugger to figure out what is going on - using Boost.Test in majority of
>>> the cases it's clear from test output.
>>
>> It's hard to imagine what test output could allow me to diagnose the
>> cause of an exception.  Normally, the cause is contained in the
>> context (e.g. backtrace, etc.) and that information is lost during
>> exception unwinding.
>
> It depends how you organize you program. My exception classes frquently 
> report failure location along with erro cause. So instead of stepping throw 
> whole stack inside the debugger I jump directly into source code.

The failure location is often not very interesting, and the more
encapsulated and highly factored my program gets, the more that's
true.

>>> And I think you are seriously mistaken.
>>
>> That may be so.  Maybe you should point me at some Boost regression
>> tests that benefit heavily from Boost.Test so I can get a feeling for
>> how it is used effectively.
>
> Not a partucular test. But in a amoung current test modules under /libs 
> about 200 modules using test tools different from simple 
> BOOST_CHECK/BOOST_ASSERT

Yes, but it's the ones that just use BOOST_CHECK that I claim are not
gaining a whole lot from the library.

>>> #define BOOST_TEST_MAIN
>>> #include <boost/test/unit_test.hpp>
>>>
>>> BOOST_AUTO_TEST_CASE( t )
>>> {
>>>  // here you go:
>>> }
>>>
>>> Is this a hi barrier?
>>
>> It depends.  Do I have to link with another library?  If so, then add
>> the lines of the Jamfile (and Jamfile.v2) to what I need to start
>> with.  What about allowing JIT debugging?  Will this trap all my
>> failures or can I get it to launch a debugger?
>
> You could use
>
> #include <boost/test/included/unit_test.hpp>
>
> BOOST_AUTO_TEST_CASE( t )
> {
> // here you go:
> }
>
> No need for linking. Catching system error you could disable in either 
> Jamfile on in environment.

Oh?  That's an improvement in convenience, to be sure.  Maybe I'll try
again.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com