Re: [boost] Re: refactoring type traits tests

From: David Abrahams (dave_at_[hidden])
Date: 2002-10-08 07:09:01

"John Maddock" <jm_at_[hidden]> writes:

> > > 1) Should we use boost.test?
> > > ~~~~~~~~~~~~~~~~~~~
> > >
> > > As it stands IMO no: the tests are both compile time and run time tests,
> and
> > > yes this really does make a difference (gory details and compiler bugs
> > > omitted here...).
> >
> > Not obvious to me why, without the gories.
> 
> OK here are some of the gory details:  

<snip>

OK, I understand all of that. Thanks for the explanation.

> > > In particular the compiler requirements column is now almost
> > > meaningless.  The thing is we now have so many fixes checked in that
> > > most of the traits work most of the time with most compilers.  I
> > > guess we could remove the PCD legends and replace with comments
> > > containing broad generalisations.
> >
> > I think that the category "requires compiler support" is still
> > useful. However, there are cases where a trait is not an atom, but
> > composed of other traits which need compiler support. In those cases,
> > it's very helpful to know that you just need to just need to
> > specialize the atomic traits in order to make the others work.
> 
> Good point, but doesn't the dependency tree vary depending upon the
> compiler?

I don't know. I hope not. I mean, "requires compiler support" should
mean that even with a perfectly conforming compiler we can't implement
it, today. Shouldn't all non-atomic traits requiring compiler support
have the same implementation on all compilers?

> All good points, and all lot of work!

I don't think it would be too bad, especially now that they're
refactored, if:

1. We make a list of all the things we think it's important to
   say/know about a trait.

2. We check that in as the first piece of documentation, like a
   template

3. We treat each trait individually. Maybe each should have its own
   web page for detailed info. We just look at the implementation and
   the test results for each one.

-- 
           David Abrahams * Boost Consulting
dave_at_[hidden] * http://www.boost-consulting.com