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

From: David Abrahams (dave_at_[hidden])
Date: 2006-01-31 16:23:53

"Robert Ramey" <ramey_at_[hidden]> writes:

> David Abrahams wrote:
>> "Robert Ramey" <ramey_at_[hidden]> writes:
>
>>  In my experience, Boost.Test is
>> overpowered for the purposes of Boost regression testing,
>
> Now that is an interesting observation that I would tend to agree with.
>
> It really points to the design of boost test itself. I understand the
> the problem - library development gets driven be feature comparisons
> with other libraries, wish lists, "cool" features, and I think more
> mundane aspects like a good "user directed" manual, conceptual
> transparency, idiot-proofness etc seem to lose importance.
>
> Actually, maybe my concerns can be addressed by going back
> into boost test and using the "minimal" option.  

That might help, but the author is opposed to adding the facilities
needed to make that viable for me.  I can't turn off the crash
handlers on Windows, for example, so debugging a problem in a "minimal
test" application is often prohibitive.

> As I said before, I think that Boost Test could be much, much
> more important than it is in drawing new users to boost. For
> this to happen I would like to see:
>
> a) an easier to read and use manual
>
> b) a minimal level implemented as header only so that users
> in need of immediate gratification could get it.  This would
> address the user who turns to boost because he's under
> huge pressure to find a bug.   Solving someone's problem
> in less than two hours is going to turn anyone into a boost
> booster.
>
> I realize that the above is my own personal wish list so
> we have a lot of conceptual recursion here.
>
>> Windows it tends to stand in the way of debugging by "handling"
>> crashes as exceptions rather than invoking JIT or the debugger.
>
> Hmmm - I don't we want to invoke the debugger in the
> regression tests.  

What happens on the testers machine if it runs this program?

     #include <cassert>
     int main() { assert(0); }

If it throws up a dialog and if we have no test monitor to kill it, I
agree that we ought to have something in place to make sure no dialog
comes up.  But I was sure the test script *did* start a monitor that
could kill off any hung applications (?)

> I practice I fire up my debugger on any failed
> test and set my VC debugger to trap on any exception - this
> works great for me.

IIRC, you only get to see the program state after the program has
unwound to the exception handler in the test library.  That's too
late.

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