On Tue, May 12, 2009 at 5:11 PM, Stewart, Robert <Robert.Stewart@sig.com> wrote:
Beman Dawes wrote: On Monday, May 11, 2009 10:15 PM
GCC 4.3 and even more so 4.4 have implemented significant portions of the C++0x core language, and provide lots of C++0x standard library components too.
Microsoft 2010 beta 1 will ship "real soon", and it too will have some major C++0x core language features, and also some C++0x standard library components.
Thus we need more config macros, particularly those aimed at the standard library. A possible approach:
BOOST_NO_CONCEPTS // needed to tell if headers have been conceptized
BOOST_NO_*_HDR // for each new C++0x header; * is name of header
For example, BOOST_NO_CHRONO_HDR is defined unless header <chrono> is present.
I noticed the need for such macros, too, at BoostCon. I was thinking we need one for each feature.
BOOST_NO_AUTO BOOST_NO_DECLTYPE BOOST_NO_REFREF BOOST_NO_VARIADICS etc.
We've already got these: BOOST_NO_AUTO_DECLARATIONS BOOST_NO_AUTO_MULTIDECLARATIONS BOOST_NO_CHAR16_T BOOST_NO_CHAR32_T BOOST_NO_CONSTEXPR BOOST_NO_DECLTYPE BOOST_NO_DEFAULTED_FUNCTIONS BOOST_NO_DELETED_FUNCTIONS BOOST_NO_EXPLICIT_CONVERSION_OPERATORS BOOST_NO_EXTERN_TEMPLATE BOOST_NO_LONG_LONG BOOST_NO_RAW_LITERALS BOOST_NO_RVALUE_REFERENCES BOOST_NO_SCOPED_ENUMS BOOST_NO_STATIC_ASSERT BOOST_NO_UNICODE_LITERALS BOOST_NO_VARIADIC_TEMPLATES So we are filling in some of the missing pieces rather than starting from scratch.
The only reason I can think of to provide one for each header is so that Boost headers can include standard headers rather than compatibility code. Is that what you had in mind?
Yes. Suppliers seem to be adding C++0x library components on a header by header basis, rather than waiting until they have a full set and then supplying them all at once. Thus the need to have macros for each header.
If so, then the header macros should only be undefined when the corresponding header is complete.
The problem with waiting for a header to be totally complete means waiting a long time. For example, several vendors are already, or will soon be, shipping a number of new C++0x headers. But their implementations aren't "complete" because they don't have concepts yet. The headers are perfectly usable, however, so there is no reason not to take advantage of them now. For some of these compilers we many have to wait several years before concepts become available, and the headers become "complete". At least that's my thinking. --Beman