Re: [boost] [C++0x] More config macros needed

Subject: Re: [boost] [C++0x] More config macros needed
From: Beman Dawes (bdawes_at_[hidden])
Date: 2009-05-12 21:15:41

On Tue, May 12, 2009 at 5:11 PM, Stewart, Robert <Robert.Stewart_at_[hidden]> 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