Re: Latest TR1 draft

[Jonathan Wakely <cow at compsoc dot man dot ac dot uk>]

On Wed, Nov 10, 2004 at 05:30:59PM +0000, chris wrote:

> Was there a final decision on how things should be "added" to existing 
> headers, like <utility> or <functional>? For now these things could 
> continue living in <tuple> if it would be easier?

Provide a <tr1/utility> header which includes the standard <utility>.

IIRC each standard header will have a corresponding <tr1/xxx> which will
just include the standard header in most cases.

Users can either specify they want <tr1/utility>, or they can use -I to
set the search path to the tr1 sub-dir, or maybe the compiler will be
able to prepend the tr1 dir to the search path if e.g. -std=tr1 is used
(the last idea is just my own speculation).

This meets the requirement in the intro to the TR that says the
components must not be visible unless the user takes specific action.

On a related issue, it was mentioned today on the Boost list that they
will need some mechanism for detecting whether a particular stdlib
provides TR1 components. This will allow Boost to decide whether to use
the stdlib's native TR1 components or use Boost's own versions. Could v3
provide macros such as _GLIBCXX_TR1_MEMORY be used to state which
headers are available ?  Should it be more fine-grained than the header
name, e.g. _GLIBCXX_TR1_MEMORY_WEAK_PTR ?  Or will it be left to the
Boost developers to solve this problem e.g. by just keeping track in
their libstdcpp.hpp header of which components are available in
particular GCC releases ?

jon

-- 
"Any view of the universe that is not strange is false."
	- Neil Gaiman