Library TR draft available
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. --Beman
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. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
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
Beman Dawes <bdawes@acm.org> writes:
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.
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 http://www.boost-consulting.com
Beman Dawes wrote:
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.
However, some Boost code might want to use the Boost version of the component, even if one is provided in std::tr1; and we also need to keep in mind that only some parts of std::tr1 may be missing. TR1-namespace-level global solutions can't work.
On Fri, Nov 12, 2004 at 04:51:42PM +0200, Peter Dimov wrote:
Beman Dawes wrote:
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.
However, some Boost code might want to use the Boost version of the component, even if one is provided in std::tr1;
To avoid ODR violations, would that mean all code that exists in both Boost and TR1 would have to be in boost::detail, so that e.g. boost::shared_ptr could be std::tr1::shared_ptr but Boost.SomeThing could still use boost::detail::shared_ptr if it wanted to ? Would that _somewhat_ reduce ADL issues, since boost::shared_ptr would _always_ be declared by a using declaration, for either std::tr1::shared_ptr or boost::detail::shared_ptr ? (hmm, I think it might change the symptoms but not really lessen the problem)
and we also need to keep in mind that only some parts of std::tr1 may be missing. TR1-namespace-level global solutions can't work.
The stdlib/xxx.hpp headers could be made to know which components are available in which versions of each stdlib and to define the a set of macros like these: BOOST_USE_NATIVE_SHARED_PTR BOOST_USE_NATIVE_REGEX BOOST_USE_NATIVE_RESULT_OF Users could explicitly choose either the Boost-provided or native stdlib-provided implementations by setting BOOST_USE_NATIVE_RESULT_OF or BOOST_NO_NATIVE_RESULT_OF before the config headers are included. Figuring out which macros are needed, based on which TR1 implementations have which bits missing would be a laborious process, but could start with a baseline assumption that all components are missing and have bits added as it's shown they're available. Those are my incomplete thoughts on the matter, for what they're worth, jon -- "A well-written program is its own heaven A poorly written program is its own hell" - The Tao of Programming
Beman Dawes wrote:
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.
However, some Boost code might want to use the Boost version of the component, even if one is provided in std::tr1;
To avoid ODR violations, would that mean all code that exists in both Boost and TR1 would have to be in boost::detail, so that e.g. boost::shared_ptr could be std::tr1::shared_ptr but Boost.SomeThing could still use boost::detail::shared_ptr if it wanted to ?
Would that _somewhat_ reduce ADL issues, since boost::shared_ptr would _always_ be declared by a using declaration, for either std::tr1::shared_ptr or boost::detail::shared_ptr ?
(hmm, I think it might change the symptoms but not really lessen the problem)
and we also need to keep in mind that only some parts of std::tr1 may be missing. TR1-namespace-level global solutions can't work.
The stdlib/xxx.hpp headers could be made to know which components are available in which versions of each stdlib and to define the a set of macros like these:
BOOST_USE_NATIVE_SHARED_PTR BOOST_USE_NATIVE_REGEX BOOST_USE_NATIVE_RESULT_OF
Users could explicitly choose either the Boost-provided or native stdlib-provided implementations by setting BOOST_USE_NATIVE_RESULT_OF or BOOST_NO_NATIVE_RESULT_OF before the config headers are included.
Figuring out which macros are needed, based on which TR1 implementations have which bits missing would be a laborious process, but could start with a baseline assumption that all components are missing and have bits added as it's shown they're available.
Personally I would rather not see Boost components replaced with std::tr1 versions, I would rather that: boost::something always gave you the Boost version, for reasons of portability, extra features or just personal preference some users may prefer this. std::tr1 gives you the tr1 version if it's available, otherwise the Boost version. 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. Just another 2c... John.
At 06:01 AM 11/13/2004, John Maddock wrote:
Personally I would rather not see Boost components replaced with std::tr1
versions, I would rather that:
boost::something always gave you the Boost version, for reasons of portability, extra features or just personal preference some users may prefer this. std::tr1 gives you the tr1 version if it's available, otherwise the Boost
version.
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? Presumably the tr1 subtree would go in the boost directory? --Beman
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.
At 10:54 AM 11/14/2004, John Maddock wrote:
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).
Let's look at some examples: // example 1: tr1 directory lives in boost #include <boost/tr1/regex.hpp> // example 2: tr1 directory lives in boost-root #include <tr1/regex.hpp> // example 3: tr1 directory lives in boost-root/libs and // user doesn't wish to modify compiler's include search paths #include <libs/tr1/regex.hpp> // example 4: tr1 directory lives in boost-root/libs and // user modifies compiler's include search paths to search // boost-root/libs #include <tr1/regex.hpp> I like example 1 the best. Clear to the reader. Easy for the user. Very similar to how other boost supplied headers are treated. Doesn't foul up boost tools which search the boost directory for header files. --Beman
// example 1: tr1 directory lives in boost #include <boost/tr1/regex.hpp>
I like example 1 the best. Clear to the reader. Easy for the user. Very similar to how other boost supplied headers are treated. Doesn't foul up boost tools which search the boost directory for header files.
Agreed, John.
At 05:44 AM 11/15/2004, John Maddock wrote:
// example 1: tr1 directory lives in boost #include <boost/tr1/regex.hpp>
I like example 1 the best. Clear to the reader. Easy for the user. Very
similar to how other boost supplied headers are treated. Doesn't foul up boost tools which search the boost directory for header files.
Agreed,
Assuming others also agree, can we talk you into taking on the project:-? --Beman
At 11:18 AM 11/16/2004, John Maddock wrote:
Assuming others also agree, can we talk you into taking on the
project:-?
I should have seen that coming :-)
I guess I don't mind, but I probably won't get around to it before Christmas; so if someone wants to just get on with it now, that's fine by me too ;-)
After Christmas is fine AFAIK. Thanks for volunteering! --Beman
On Nov 12, 2004, at 9:51 AM, Peter Dimov wrote:
Beman Dawes wrote:
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.
However, some Boost code might want to use the Boost version of the component, even if one is provided in std::tr1; and we also need to keep in mind that only some parts of std::tr1 may be missing. TR1-namespace-level global solutions can't work.
Why not keep all of the Boost versions in namespace boost, but create a boost::tr1 namespace that has the appropriate using declarations for the std versions (when a TR1 implementation is available) or the Boost versions (when a TR1 implementation is not available). If we're feeling really brave we could eventually call the boost:: versions deprecated :) Doug
On Fri, 12 Nov 2004 13:32:46 -0500, Doug Gregor <dgregor@cs.indiana.edu> wrote:
Why not keep all of the Boost versions in namespace boost, but create a boost::tr1 namespace that has the appropriate using declarations for the std versions (when a TR1 implementation is available) or the Boost versions (when a TR1 implementation is not available). If we're feeling really brave we could eventually call the boost:: versions deprecated :)
What is the policy anyway with regards to boost components that are in TR1? Are their interfaces now fixed to the TR1 ones? For example, there was a discussion recently on constructing boost::function's with constant values. Regards, Rogier
Rogier van Dalen <rogiervd@gmail.com> writes:
On Fri, 12 Nov 2004 13:32:46 -0500, Doug Gregor <dgregor@cs.indiana.edu> wrote:
Why not keep all of the Boost versions in namespace boost, but create a boost::tr1 namespace that has the appropriate using declarations for the std versions (when a TR1 implementation is available) or the Boost versions (when a TR1 implementation is not available). If we're feeling really brave we could eventually call the boost:: versions deprecated :)
What is the policy anyway with regards to boost components that are in TR1? Are their interfaces now fixed to the TR1 ones?
No. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
At 09:51 AM 11/12/2004, Peter Dimov wrote:
Beman Dawes wrote:
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.
However, some Boost code might want to use the Boost version of the component, even if one is provided in std::tr1; and we also need to keep in mind that only some parts of std::tr1 may be missing. TR1-namespace-level
global solutions can't work.
Yes, we need to be able to accommodate both of those cases. --Beman
participants (7)
-
Beman Dawes -
David Abrahams -
Doug Gregor -
John Maddock -
Jonathan Wakely -
Peter Dimov -
Rogier van Dalen