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
> 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.
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.
- 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.
- 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".
- 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!
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk