|
Boost : |
From: Beman Dawes (bdawes_at_[hidden])
Date: 2004-11-10 17:26:10
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
>> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk