Here's my lengthy review of Boost.TR1
* What is your evaluation of the design?
Good. At one point I thought this library would provide its contents in boost::tr1, as equivalent but more portable / widely available versions of the TR1 libraries, but I'm glad to see it puts everything in std::tr1 instead. I think it's important, so users get used to that. Doug raised the question of whether the native implementations should be used by default, but I think that can be done bit by bit as more native implementations appear and Boost.Config learns which platforms provide which parts. One thing I think is missing is a macro to say "use as much as possible from my native compiler/library, but use Boost versions of the rest." This matters e.g. if a user trusts their compiler vendor more than Boost (maybe because they have a support contract and know they'll get preferential treatment, or they just don't like the Boost website ;-) AFAICT a user would have to manually define the right BOOST_HAS_TR1_XXX macros for their compiler (which would be tedious to define for cross-platform code.) Boost.Config should be taught which compilers provide which parts so users just define one macro. Again, this can come later (and I'll try to help with the GCC parts.)
* What is your evaluation of the implementation?
Good. I like the option of <boost/tr1/memory.hpp> or <memory> (with suitable include path settings.) This gives other Boost headers a consistent way to use them and users the choice. I don't think the restriction on putting the headers in a dir called "include" matters. I like that the relatively fine-grained macros let you pick and choose between the Boost versions and native ones. This would let you use the lock-free shared_ptr from Boost with a vendor's result_of, which might take advantage of some compiler trick that Boost can't use, or whatever other criteria matter to you. The pre-processor tricks to ensure the right things are included are clever but not too complex and without totally obfuscating the affected code (no more so than some other parts of Boost.) The headers will have to be changed with care, but I certainly can't see any easier way of implementing it. Will this library ever go away or will it have to be supported forever? I assume it will stay, so that dead platforms such as MSVC6 can use std::tr1, so I wonder whether having it around permanently might complicate maintenance of other parts of Boost. It probably doesn't matter: if anything in the current Boost.TR1 design causes problems with later native TR1 implementations or parts of Boost it could be changed if it needs to be. A worse consequence of this would be that the TR1 features have to stay in Boost - so Doug has to continue to maintain Boost.Function! Maybe Boost.Function and Boost.TR1 (and the rest) would have to stay until some "Boost v2" that drops support for pre-TR1 compilers.
* What is your evaluation of the documentation?
Very good. It might be useful to list all the BOOST_HAS_TR1_XXX macros on the Configuration page, so you can glance at them all at once (most people will know what components each macro relates to.) Otherwise you have to read through a lot of text on the "TR1 By Subject" page to see what's available. Typo in usage.html says "doing will cause them to cease working." (not "doing so")
* What is your evaluation of the potential usefulness of the library?
Very useful indeed. It gives a portable way to use tr1 on any platform that Boost supports. It would be silly for e.g. boost::regex to compete with std::tr1::regex by being incompatible, or trying to discourage use of the standard versions. This lib helps them maintain close compatibility (by using one to provide the other) and allows users to be agnostic about which they use. Boost has served its purpose of developing these libraries and now can gracefully hand over to the compiler vendors to provide them. This library also helps users to write portable code by providing another TR1 implementation to compile and test against.
* Did you try to use the library? With what compiler? Did you have any problems?
Yes, with GCC 3.4, 4.0 and 4.1 and I had problems when I tried to use the native TR1 bits from GCC 4. I've let John know about this already. Basically GCC doesn't provide a compiler switch to use the TR1 headers, and adding $GCC_ROOT_DIRECTORY/include/c++/4.X.Y/tr1 to your include path doesn't work, due to some bugs I've found in the GCC headers. The only way to use the headers is to include them as e.g. <tr1/memory> The fix is simple and I think John is going to work it into the BOOST_TR1_STD_HEADER() macro. I'll investigate the bugs in the GCC headers tomorrow and they'll get fixed by someone. I'll also try to document GCC's TR1 support.
* How much effort did you put into your evaluation? A glance? A quick reading? In-depth study?
About waist-deep study. Not very in-depth, but it's quite a small library. I spent a couple of evenings reading and testing it.
* Are you knowledgeable about the problem domain?
Yes, reasonably. I'm familiar with Boost.Config and the tricks done to include the right things in the right places. I've followed the progress of the TR1 report and helped with parts of GCC's implementation.
* Do you think the library should be accepted as a Boost library?
Yes.