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