Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2004-11-11 09:24:24

Beman Dawes <bdawes_at_[hidden]> writes:

> At 11:24 AM 11/10/2004, David Abrahams wrote:
> >Beman Dawes <bdawes_at_[hidden]> writes:
> >
> >> The latest draft of the C++ Standard Library Technical Report is now
> >> available at
> >>
> >>
> >> There may be editorial (non-substantiative) changes to the final
> >> version of the TR document, but this latest draft is believed to be
> >> final in terms of technical content. Thus it should be safe for
> >> implementors or users to write code based on this latest draft.
> >>
> >> It will be several years before most compilers come with a full
> >> implementation of the TR. But some vendors (Metrowerks, for example)
> >> are already shipping a few TR components. That brings up the question
> >> of what Boost code does during the transition.
> >>
> >> To insure Boost code works with various TR implementations, some Boost
> >> code will want to use the compiler vendor's version of the TR if the
> >> TR component required is available, but otherwise will want to use
> >> Boost equivalent code. How do we handle that? The TR doesn't provide
> >> in configuration macros, so I guess we will have to roll our own.
> >
> >Provide a switch that allows Boost headers to #include the appropriate
> >TR components and re-publish them with using declarations?
> >
> >It's not perfect; there will be some differences in ADL behavior
> >because those types are actually in different namespaces.
> That sounds like a possibility.
> I was thinking of an approach that used a namespace alias. If a
> vendor's version of the TR was to be used, the alias would be to
> std::tr1, otherwise it would be to the appropriate boost
> sub-namespace. Which particular alias was used would be controlled by
> #ifdef's.

I don't think it will work for boost::shared_ptr unless we're going
to move it to a sub-namespace.

Dave Abrahams
Boost Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at