At 11:24 AM 11/10/2004, David Abrahams wrote:
Beman Dawes <bdawes@acm.org> writes:
The latest draft of the C++ Standard Library Technical Report is now available at http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1711.pdf
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. That approach would have some ADL issues too. --Beman