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

From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2006-02-01 20:00:55

> Autolinking is nonportable, and you have to set up _some_ kind of path
> so that the libraries can be found by the linker.

Not if you are using bjam

> It has to build once for each toolset, and then again each time the
> test library changes.  Yes, a small inconvenience, but an
> inconvenience nonetheless.

1. If you are doing a lot of testing it's tiny work in comparison with all 
the test you are building/running
2. You could always choose to use inlined version. On powerful box 
compilation time difference is almost negligable

>> And if Boost.<any other component you depend on> breaks you are not?
>
> I can usually fix those, or workaround the problem.  With Boost.Test
> my workaround for any problem is to fall back on BOOST_ASSERT and
> wonder why I bother.

So essencially you don't use any tools you dont have direct control over. 
And again see next statement

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

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

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

>> #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.

Gennadiy