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

From: Douglas Gregor (doug.gregor_at_[hidden])
Date: 2005-09-25 11:02:11

On Sep 24, 2005, at 12:54 PM, Beman Dawes wrote:
> The formal review of the Boost TR1 Library by John Maddock begins  
> today,
> Saturday, September 24th, and runs through Wednesday, October 5th.

I am strongly in favor of accepting this library. I think it is very
important to provide a transition path from Boost to vendor
implementations of TR1, and this is it.

----Effort----

I spent an hour or two reading through the documentation and perusing
the code, but didn't actually compile anything because I "know" it
works. At one point I had started to write a Boost.TR1 myself, so I
had a pretty good idea how the implementation would look, and it looks
just like that. Plus, John has a history of solid and well-maintained
libraries, and I don't expect that this would be any exception.

----Overall Comments----

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

----Documentation Comments----

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

   I ask because one day I'd like to stop maintaining Boost.Function,
   and remove it from Boost entirely. It's been standardized in a TR,
   vendors are implementing it, and in a sense our work is done once
   all of the commonly-used standard library implementations have
   it. I see Boost.TR1 as the migration path from Boost to standards,
   and I think we should push users along that path as forcefully as we
   can without them pushing back.

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

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

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

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

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

Great work, John!

   Doug