TR library extensions

[Pétur Runólfsson]

Matt Austern wrote:
> We aren't supplying any of the TR extensions yet.  I think we should.

I agree.

> Doing all of it will be tremendously hard (one of the components
> requires serious numerical work), but we should at least start on it so
> we have a framework for contributions.

I don't think all of it needs to be written from scratch. Many
of the Boost components can probably be imported from Boost, except
that everything needs to be uglified. The unordered_* containers
can probably be based on the current hash_* containers.

> What do people think about directory structure and naming conventions
> and such?

I vote for include/tr1.

A -std= option is needed that adds include/tr1 to the include path,
because the new tr1 headers should not be visible if -std=c++98 is
given. A preprocessor macro is needed for the same reason (as some
proposals make changes to existing components). Maybe -std=tr1 and
__TR1__ ?

The implementation will probably take a while to settle down. Should
the additions be put in a separate library so that non-compatible
changes can be made without breaking programs that only use C++98?

Petur