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