From: John Maddock (john_at_[hidden])
Date: 2004-11-14 10:54:49
> >In other words I'm suggesting a tr1 subdirectory in the Boost tree
> >containing the tr1 headers, which would either be wrappers to the std or
> >Boost versions as required.
> That would seem to cater to both boost users and boost developers,
> allowing either to specify the boost library always (by simply ignoring
> the tr1 subtree), or the native tr1 code if available but the boost code
> otherwise (by #including from the tr1 subtree and using the std::tr1
> namespace). It works regardless of whether full or partial native tr1
> implementations are available. It isolates all the messy #ifdefs into the
> tr1 subtree headers, so regular boost code doesn't have to be littered
> with tr1 related #ifdefs.
> I like it. Will there be serious ADL issues?
I don't know, let me think, we're talking about ADL finding components in
namespace std::tr1 right? As long as the function arguments are from the
same namespace, it doesn't matter what that namespace is actually called
(boost or std::tr1), unless we have a mixture of code (some really in tr1,
some in boost), in which case there's probably not much we can do.
More seriously, users cannot specialise templates in namespace std::tr1,
because that may not be where the declarations really live: this may be an
issue for type_traits for example.
Even so I would expect the number of gotcha's to be reasonably small, at
least as a first approximation; using declarations sure beat reimplementing
everything in another namespace!
> Presumably the tr1 subtree would go in the boost directory?
I don't know, lets see what folks want: whatever this directory would have
to be in the users include path (as well as the regular boost tree).
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk