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).
John.