From: Douglas Gregor (dgregor_at_[hidden])
Date: 2008-05-27 09:56:10
Beman Dawes wrote:
> John Maddock wrote:
>
>> Beman Dawes wrote:
>>
>>> Yes. Doug and I had a discussion of this, and decided that in the long
>>> run we were better off with the BOOST_NO_* approach.
>>>
>> That's fine with me too.
>>
>
> OK, I propose to add the following:
>
> // Rename versions some current BOOST_HAS_* macros to:
>
> BOOST_NO_CONCEPTS
>
Concepts isn't in the working paper, so we shouldn't change
BOOST_HAS_CONCEPTS to BOOST_NO_CONCEPTS.
> BOOST_NO_DECLTYPE
> BOOST_NO_LONG_LONG
> BOOST_NO_RVALUE_REFS
>
BOOST_NO_RVALUE_REFERENCES would be better (I know this was my fault,
but since we're doing the rename...)
> BOOST_NO_STATIC_ASSERT
>
> BOOST_NO_VARIADIC_TMPL
>
Ugh. BOOST_NO_VARIANT_TEMPLATES would be better (also my fault <g>)
> // New macros:
>
> BOOST_NO_SCOPED_ENUMS // no enum class
> BOOST_NO_RAW_LITS // no raw character or string literals
>
BOOST_NO_RAW_LITERALS?
> BOOST_NO_UNICODE_LITS // no Unicode literals
>
BOOST_NO_UNICODE_LITERALS?
> BOOST_NO_OX_CHAR_TYPES // no char16_t or char32_t
>
BOOST_NO_UNICODE_CHAR_TYPES, perhaps? I'd like the avoid having "0x" in
the macros, because eventually we'll know what the 'x' is.
> BOOST_NO_EXPLICIT_CVT_OP // no explicit operator T()
>
BOOST_NO_EXPLICIT_CONVERSION_OPERATIONS?
> BOOST_NO_DFLT_AND_DEL_FUNCS // no = default or = delete functions
>
I suggest that we split these into two macros, even though they came
from the same proposal.
BOOST_NO_DEFAULT_FUNCTIONS
BOOST_NO_DELETED_FUNCTIONS
> BOOST_NO_CONSTEXPR // no constexpr
>
- Doug