Re: [boost] [TR1 Review] TR1 Formal Review Beginning

From: John Maddock (john_at_[hidden])
Date: 2005-09-26 05:02:46

> - We should find a way to strongly encourage people to help make
>   Boost's components meet the requirements in TR1. Making the
>   "_tricky" tests show up as failures in the regression tests would be
>   a great start.

I'm hoping we get more of our runtime tests to work with std::tr1:: names as 
well as with boost:: names as well.  The current tr1 tests do this for type 
traits, but that's it so far....

> - Why must users explicitly enable use of the underlying TR1 library,
>   instead of explicitly disabling it?

Ah, a philisophical question :-)

I choose BOOST_HAS_XXXX rather than BOOST_NO_XXXX since TR1 is not actually 
part of the standard, it's an optional extension.

> - "Configuration" bullets for each library: shouldn't Boost.Config
>   define BOOST_HAS_TR1_xxx, not the user?

Yes, that's the intention, there just aren't any changes needed to 
Boost.Config yet (but hold on does gcc-4 have any TR1 components yet?)

> - "Polymorphic function wrappers", standard conformity: Should also
>   add a sentence: "The member function target() can only access
>   pointer-to-member targets when they have been wrapped in mem_fn."
>
> - Mathematical Special Functions, hash tables, etc.: Should these go
>   under a seperate heading for TR1 parts *not* supported by Boost? A
>   quick glance through the documentation of the Boost.TR1 library
>   makes it seem like they are supported.

Understood, I've never really been sure how to handle the unsupported parts, 
well actually they are supported if the underlying standard library supports 
them.  But maybe they need to be moved to their own table of contents to 
make this clear?

> - "Tuples", Standard Conformity: Replace "withy" withy "with" :)
>
> - "Testing": Typo "third part implementations".
>
> ----Code Comments----
>
> - The redirecting headers (boost/tr1/tr1/memory) check __GNUC__ to
>   determine whether they should #include_next or use
>   BOOST_TR1_STD_HEADER; we should probably have a
>   BOOST_HAS_INCLUDE_NEXT macro to indicate #include_next support.

Good point.

> - The redirecting headers themselves use some interesting preprocessor
>   logic, but it looks correct to me. I'd tried something similar,
>   although I missed the case of circular #includes inside the vendor's
>   headers when I did it.

Yep, it was surprising hard to do, I'm not even sure that it is right in 
every possible case, but it's probably as close as we can get for now: the 
difficult part is we need to have one std lib header "unwrapped" so that 
Boost.Config can work, but all the others *must* be wrapped, even those that 
aren't changed in TR1 in case they #include something that is modified by 
TR1 (which would lead to horrid cyclic dependencies if we don't take steps 
to stop it).

> - The header tr1/detail/config.hpp uses BOOST_HAS_TR1 to turn on
>   support for "everything", where "everything" consists of
>   BOOST_HAS_TR1_REFERENCE_WRAPPER and BOOST_HAS_TR1_SHARED_PTR. Should
>   there be more?

Um, embarrassment :-(

Maybe one or two more ;-)

John.