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

From: Beman Dawes (bdawes_at_[hidden])
Date: 2008-05-29 22:30:26

AlisdairM wrote:
> Beman Dawes wrote:
> 
>>> BOOST_NO_DECLTYPE                       // no decltype
>>> BOOST_NO_LONG_LONG                      // no [unsigned] long long
>>> type BOOST_NO_RVALUE_REFERENCES              // no r-value
>>> references BOOST_NO_STATIC_ASSERT                  // no
>>> static_assert BOOST_NO_VARIADIC_TEMPLATES             // no
>>> variadic templates BOOST_NO_SCOPED_ENUMS                   // no
>>> enum class BOOST_NO_RAW_LITERALS                   // no raw
>>> character or string                                          //
>>> literals BOOST_NO_UNICODE_LITERALS               // no Unicode
>>> literals BOOST_NO_UNICODE_CHAR_TYPES             // no char16_t or
>>> char32_t BOOST_NO_EXPLICIT_CONVERSION_OPERATIONS // no explicit
>>> operator T() BOOST_NO_DEFAULT_FUNCTIONS              // no =
>>> default functions BOOST_NO_DELETED_FUNCTIONS              // no =
>>> delete functions BOOST_NO_CONSTEXPR                      // no
>>> constexpr
>>    BOOST_NO_EXTERN_TEMPLATE                // no extern template
> 
> Sorry for the late contribution...
> 
> Other potential macros to consider:
> 
>   BOOST_NO_REFERENCE_COLLAPSING
BOOST_NO_REFERENCE_COLLAPSE ?

>   BOOST_NO_DEFAULT_FUNCTION_TEMPLATE_PARAMETERS (bit long!)
Yes, but clear. What do others think?

>   BOOST_NO_REFERENCE_QUALIFIERS
What's that?

>   BOOST_NO_STD_TYPE_TRAITS // std guarantees impl support
>   BOOST_NO_TYPE_ALIAS
>   BOOST_NO_AUTO_DECLARATIONS
>   BOOST_NO_INHERITING_CONSTRUCTORS
>   BOOST_NO_DELEGATING_CONSTRUCTORS
>   BOOST_NO_EXTENDED_FRIENDS
>   BOOST_NO_NULLPTR
>   BOOST_NO_INLINE_NAMESPACES
>   BOOST_NO_EXTENDED_UNIONS

Also, BOOST_NO_RELAXED_PODS

> 
> 
> This still leaves:
>   new style function declarations
>   __func__
>   extended sizeof
>   right-angle bracket behaviour
>   lambda (careful naming wrt boost lambda lib)
>   preprocessor updates - these macros may be in PP lib already
> 
> 
> plus all the features pending voting in the Antipolis meeting next
> month...

I have to write a test case for each feature, so I've mostly been 
concentrating on features that I have a compiler for. But, yep, those 
are good suggestions.

If anyone would like to contribute test .ipp files for the above, I'd 
appreciate it. John Maddock's docs are quite clear as to how the process 
works.

Thanks,

--Beman