As Beman pointed out I should have replied to this before - basically I just agree with everything - but here we go anyway: Jonathan Wakely wrote:
Here's my lengthy review of Boost.TR1 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.
I think by and large the native version *has* to be used by default, otherwise the Boost and std versions end up competing for the std::tr1 namespace. Teaching Boost.Config about various std libs is obviously an ongoing process. One thing I must investigate is whether it's possible to rename std::tr1 a little like STLport does so that the Boost verions can be used even when std versions are available.
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.)
Yep, the library is all config stuff really, it's a matter of keeping Boost.Config up to date with new releases.
* 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.)
Yep, will do, or else add them to the Boost.Config docs.
Typo in usage.html says "doing will cause them to cease working." (not "doing so")
Well spotted, thanks. Thanks for the review, John.