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

From: Robert Ramey (ramey_at_[hidden])
Date: 2006-01-31 14:44:04

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.  If its not possible
now it should be easy for boost test to be jiggered around
so that functionality is of several levels - for example

a) minimal - see below

b) standard - sufficient facilities for simple regression testing - works
on all concievable compilers - LOL

c) better - more features - compiler support at descretion of
the boost test library author.  Would require a table of which
features are supported by which compilers.  This would be free
as the table is already generated by the boost regression testing.

d) delux - every bell and whistle ever suggested that the library
author wants to implement.

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

Robert Ramey