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

From: Robert Ramey (ramey_at_[hidden])
Date: 2006-01-31 16:19:37

Gennadiy Rozental wrote:
>> 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
>
> Group of volunteers and me at the moment working on Boost.Test
> documentation update. If you have any particular requests and/or
> willing to participate - please let us hear it.
>
>> conceptual
>> transparency, idiot-proofness etc seem to lose importance.
>
> You need to be more clear for me to understand what exactly you are
> "missing"

This is not a critism of Boost Test but an observation on how
things get prioritised in all boost libraries.  I thnk that adding
the "new features" is more interesting than making a better
manual and examples so the latter tends to lag.

But to answer your question about what I'm "missing" What
I would like to see is:

Introduction
Tutorials small commented example at narrative
    Min Test facility
    Unit Test framwork
    Program Test ...
Implementation.

Or maybe

Introduction
Minimal Test facility
    Tutorial - commented example and nararative
    Refererence-
   Implementation notes, etc
UnitTest Framework - includes all the faciltiy of the Minimal Test facility 
+ ?
    Tutorial - commented example and nararative
   Implementation notes, etc
?
Other stuff
    Usage advice
    specific compiler issues
    etc.
...

Basically I would love to copy the the tutorial to my own
project and edit it to make my test.  That might sound
ridiculous - but that's would I would like to be able it do.

>> 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 conceivable compilers - LOL
>>
>> c) better - more features - compiler support at discretion 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.
>
> Essentially the state of affairs is like this already. There is the
> Minimal Testing Facility component (header only). There is the Unit
> Test Framework that works on most compilers.

I suspected as much but it doesn't jump out from a cursory examination
of the manual.

> And there are new features that ifdefed out for old compilers.

Which is ok by me.

> But my position is that we need to consciously
> move away from old compilers to make code base healthier.

> Requirement for feature compiler support is also scaring. I would really 
> prefer
> not to do this.

I'm not sure what this refers to.  I would be just happy to know that
boost test won't be improved in such a way that it breaks my old stuff
that doesn't use the new features.

>
>> 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.
>
> This looks like two contradictory goals: you may not be able to solve
> someone problem in 2 hour using facility with minimal functionality

LOL - again I think you're underestimating the impact even a minimal
facility can have.  Remeber that the usual alternative is to do no unit
testing at all.

I envision a common situation - (In fact, at this very moment I'm stuck
on another project and I find my self in this exact situation).  I'm working
on my next wizbang project and I'm under huge pressure to fix a bug.
I've been working on it for days with no luck.  Now I realize that its
much deeper than I thought and that it could be anywhere.  In desperation
I look to boost and find Boost Test.  The introduction shows me
the joys of unit testing which I havn't been using.  I'm really
desperate and will try anything that only takes two hours to try.
I down load boost headers.  Copy the tutorial example from
boost test an make a test for one mof my routines.  2 hours.
Still havn't found my bug but since I still don't know what to do
I repeat the processes for the rest of the program.  The bug
turns out to be pretty stupid and easy to spot - if I had only
thought to look at the right place.  I leave the boost test
stuff in becuase now its "free".  I've been kidnapped into
the boost community in spite of myself.

Contrast that the current situation.  I look into boost test.
Well reading the documents is a couple of hours.  Then
there is bjam and library building and linking.  Right away
I'm on to something else.

Now you can argue that the world shouldn't be like this
and maybe your right - but I think that boost test could
work as described above - just by making the manual
easier to read - so I have high hopes for the new
manual.

Robert Ramey

PS

fyi - my current situation is programming a gameboy color
to implement a hangglidng flight instrument.  This thing
is a bitch to program.  I could sure use boost test
here - any chance of a straight "C" version?

RR