Re: [boost] [TR1 Review] TR1 Formal Review Beginning

From: Jonathan Wakely (cow_at_[hidden])
Date: 2005-10-04 18:16:32

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.