[config] C++0x macros
There was some past discussion of changing the C++0x BOOST_HAS_* macros to BOOST_NO_*. Several participants thought that was better for the long run. Who needs to do what to make this happen? The motivation for asking is that I'm starting to update some Boost code that could benefit from C++0x features and so would like to start using these macros. Also, a C++03 workaround for the lack of the C++0x keyword "constexpr" is to simply omit it. Should we have a BOOST_CONSTEXPR macro defined as "constexpr" for platforms that support constexpr, otherwise as null? --Beman
on Sun May 25 2008, Beman Dawes <bdawes-AT-acm.org> wrote:
There was some past discussion of changing the C++0x BOOST_HAS_* macros to BOOST_NO_*. Several participants thought that was better for the long run. Who needs to do what to make this happen?
IIRC the convention is BOOST_HAS_* when it's describing a nonstandard feature and BOOST_NO_* when it's describing a standard feature that is not supported be the compiler. In other words, IIUC, BOOST_NO_* is reserved for describing nonconformances.
The motivation for asking is that I'm starting to update some Boost code that could benefit from C++0x features and so would like to start using these macros.
of course, the fact that nonstandard features are now becoming standard makes things somewhat awkward.
Also, a C++03 workaround for the lack of the C++0x keyword "constexpr" is to simply omit it. Should we have a BOOST_CONSTEXPR macro defined as "constexpr" for platforms that support constexpr, otherwise as null?
That's not a bad idea. I wonder whether it might not be better just to #define constexpr in that case, and use that symbol. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
David Abrahams wrote:
on Sun May 25 2008, Beman Dawes <bdawes-AT-acm.org> wrote:
There was some past discussion of changing the C++0x BOOST_HAS_* macros to BOOST_NO_*. Several participants thought that was better for the long run. Who needs to do what to make this happen?
IIRC the convention is BOOST_HAS_* when it's describing a nonstandard feature and BOOST_NO_* when it's describing a standard feature that is not supported be the compiler. In other words, IIUC, BOOST_NO_* is reserved for describing nonconformances.
Yes, that's my understanding too.
The motivation for asking is that I'm starting to update some Boost code that could benefit from C++0x features and so would like to start using these macros.
of course, the fact that nonstandard features are now becoming standard makes things somewhat awkward.
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.
Also, a C++03 workaround for the lack of the C++0x keyword "constexpr" is to simply omit it. Should we have a BOOST_CONSTEXPR macro defined as "constexpr" for platforms that support constexpr, otherwise as null?
That's not a bad idea. I wonder whether it might not be better just to
#define constexpr
in that case, and use that symbol.
I thought of that, and decided it wasn't a good idea to define a symbol that non-boost code might also be using and/or redefining. But that's only a weak opinion, and I'm open to reconsidering it. What do others think? --Beman
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.
Also, a C++03 workaround for the lack of the C++0x keyword "constexpr" is to simply omit it. Should we have a BOOST_CONSTEXPR macro defined as "constexpr" for platforms that support constexpr, otherwise as null?
That's not a bad idea. I wonder whether it might not be better just to
#define constexpr
in that case, and use that symbol.
I thought of that, and decided it wasn't a good idea to define a symbol that non-boost code might also be using and/or redefining. But that's only a weak opinion, and I'm open to reconsidering it. What do others think?
BOOST_CONSTEXP maybe? John.
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 BOOST_NO_DECLTYPE BOOST_NO_LONG_LONG BOOST_NO_RVALUE_REFS BOOST_NO_STATIC_ASSERT BOOST_NO_VARIADIC_TMPL // New macros: BOOST_NO_SCOPED_ENUMS // no enum class BOOST_NO_RAW_LITS // no raw character or string literals BOOST_NO_UNICODE_LITS // no Unicode literals BOOST_NO_OX_CHAR_TYPES // no char16_t or char32_t BOOST_NO_EXPLICIT_CVT_OP // no explicit operator T() BOOST_NO_DFLT_AND_DEL_FUNCS // no = default or = delete functions BOOST_NO_CONSTEXPR // no constexpr Comments or suggestions? --Beman
AMDG Beman Dawes wrote:
// New macros:
BOOST_NO_SCOPED_ENUMS // no enum class BOOST_NO_RAW_LITS // no raw character or string literals BOOST_NO_UNICODE_LITS // no Unicode literals BOOST_NO_OX_CHAR_TYPES // no char16_t or char32_t BOOST_NO_EXPLICIT_CVT_OP // no explicit operator T() BOOST_NO_DFLT_AND_DEL_FUNCS // no = default or = delete functions BOOST_NO_CONSTEXPR // no constexpr
Comments or suggestions?
I would prefer to spell out the names completely. e.g. BOOST_NO_EXPLICIT_CONVERSION_OPERATOR. In Christ, Steven Watanabe
From: Steven Watanabe Beman Dawes wrote:
// New macros:
BOOST_NO_SCOPED_ENUMS // no enum class BOOST_NO_RAW_LITS // no raw character or string literals BOOST_NO_UNICODE_LITS // no Unicode literals BOOST_NO_OX_CHAR_TYPES // no char16_t or char32_t BOOST_NO_EXPLICIT_CVT_OP // no explicit operator T() BOOST_NO_DFLT_AND_DEL_FUNCS // no = default or = delete functions BOOST_NO_CONSTEXPR // no constexpr
Comments or suggestions?
I would prefer to spell out the names completely. e.g. BOOST_NO_EXPLICIT_CONVERSION_OPERATOR.
Yes, it's really hard to figure out what some of the names stand for. Best regards, Robert
Steven Watanabe wrote:
AMDG
Beman Dawes wrote:
// New macros:
BOOST_NO_SCOPED_ENUMS // no enum class BOOST_NO_RAW_LITS // no raw character or string literals BOOST_NO_UNICODE_LITS // no Unicode literals BOOST_NO_OX_CHAR_TYPES // no char16_t or char32_t BOOST_NO_EXPLICIT_CVT_OP // no explicit operator T() BOOST_NO_DFLT_AND_DEL_FUNCS // no = default or = delete functions BOOST_NO_CONSTEXPR // no constexpr
Comments or suggestions?
I would prefer to spell out the names completely. e.g. BOOST_NO_EXPLICIT_CONVERSION_OPERATOR.
There is a practical limit on the length of names because the config mechanism uses them for file names. But perhaps we can make them less cryptic, and still hold them to a reasonable length, say 32 characters. How about: 12345678901234567890123456789012 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_CHAR16_CHAR32_TYPES // no char16_t or char32_t BOOST_NO_EXPLICIT_CONVERSION_OP // no explicit operator T() BOOST_NO_DEFAULT_OR_DELETE_FUNCS // no = default or = delete functions BOOST_NO_CONSTEXPR // no constexpr Thanks, --Beman
Beman Dawes wrote:
There is a practical limit on the length of names because the config mechanism uses them for file names. But perhaps we can make them less cryptic, and still hold them to a reasonable length, say 32 characters.
It's not absolutely essential for the test filenames to have the same name as the macro - as long as you can find one from the other :-) Personally I'd go for more descriptive names as well, HTH, John.
John Maddock wrote:
Beman Dawes wrote:
There is a practical limit on the length of names because the config mechanism uses them for file names. But perhaps we can make them less cryptic, and still hold them to a reasonable length, say 32 characters.
It's not absolutely essential for the test filenames to have the same name as the macro - as long as you can find one from the other :-)
Personally I'd go for more descriptive names as well,
That's my preference too, so since we aren't limited by filenames, here is a more explicit set (taking into consideration comments from Doug and others): 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 Iff voted into the WP: BOOST_NO_CONCEPTS // no concepts I'll do BOOST_NO_SCOPED_ENUMS, to make sure I've got the config process right, and then work on the others as time permits. --Beman
Beman Dawes wrote:
John Maddock wrote:
Beman Dawes wrote:
There is a practical limit on the length of names because the config mechanism uses them for file names. But perhaps we can make them less cryptic, and still hold them to a reasonable length, say 32 characters. It's not absolutely essential for the test filenames to have the same name as the macro - as long as you can find one from the other :-)
Personally I'd go for more descriptive names as well,
That's my preference too, so since we aren't limited by filenames, here is a more explicit set (taking into consideration comments from Doug and others):
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
Iff voted into the WP: BOOST_NO_CONCEPTS // no concepts
I'll do BOOST_NO_SCOPED_ENUMS, to make sure I've got the config process right, and then work on the others as time permits.
--Beman
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Beman Dawes wrote:
Beman Dawes wrote:
John Maddock wrote:
Beman Dawes wrote:
There is a practical limit on the length of names because the config mechanism uses them for file names. But perhaps we can make them less cryptic, and still hold them to a reasonable length, say 32 characters. It's not absolutely essential for the test filenames to have the same name as the macro - as long as you can find one from the other :-)
Personally I'd go for more descriptive names as well, That's my preference too, so since we aren't limited by filenames, here is a more explicit set (taking into consideration comments from Doug and others):
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
Iff voted into the WP: BOOST_NO_CONCEPTS // no concepts
BOOST_NO_LAMBDA_FUNCTIONS Joe Gottman
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_DEFAULT_FUNCTION_TEMPLATE_PARAMETERS (bit long!) BOOST_NO_REFERENCE_QUALIFIERS 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 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... AlisdairM -- AlisdairM
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
Beman Dawes wrote:
BOOST_NO_UNICODE_LITERALS // no Unicode literals
Grrr... At least one compiler beta is supporting u and U literals, but not U8 literals. Although irritating, I guess that's a sign we need finer grained macros for these. Because the case is significant, there is a bit of a naming issue, too. Maybe: BOOST_NO_UTF8_LITERALS // no u8 literals BOOST_NO_CHAR16_T_LITERALS // no u literals BOOST_NO_CHAR32_T_LITERALS // no U literals Comments? --Beman
On Thu, 2008-05-29 at 09:58 -0400, Beman Dawes wrote:
Beman Dawes wrote:
BOOST_NO_UNICODE_LITERALS // no Unicode literals
Grrr... At least one compiler beta is supporting u and U literals, but not U8 literals.
Will that vendor be supporting U8 literals before the final release? We don't need to cope with non-released compilers. - Doug
Douglas Gregor wrote:
On Thu, 2008-05-29 at 09:58 -0400, Beman Dawes wrote:
Beman Dawes wrote:
BOOST_NO_UNICODE_LITERALS // no Unicode literals Grrr... At least one compiler beta is supporting u and U literals, but not U8 literals.
Will that vendor be supporting U8 literals before the final release? We don't need to cope with non-released compilers.
Good point. The product manager actually thought UTF-8 literals were supporting, so maybe they will appear in the final release. We can always just define BOOST_NO_UNICODE_LITERALS until all three flavors are fully supported. That probably makes more sense. For every macro, a separate test case .ipp file has to be written and then tested for every compiler. Given the number of new C++0x features, the Boost macros will become unmanageable if they are too fine grained. --Beman
On Thu, May 29, 2008 at 5:46 PM, Beman Dawes <bdawes@acm.org> wrote:
Douglas Gregor wrote:
On Thu, 2008-05-29 at 09:58 -0400, Beman Dawes wrote:
Beman Dawes wrote:
BOOST_NO_UNICODE_LITERALS // no Unicode literals Grrr... At least one compiler beta is supporting u and U literals, but not U8 literals.
Will that vendor be supporting U8 literals before the final release? We don't need to cope with non-released compilers.
Good point. The product manager actually thought UTF-8 literals were supporting, so maybe they will appear in the final release.
We can always just define BOOST_NO_UNICODE_LITERALS until all three flavors are fully supported. That probably makes more sense.
For every macro, a separate test case .ipp file has to be written and then tested for every compiler. Given the number of new C++0x features, the Boost macros will become unmanageable if they are too fine grained.
Wouldn't it make much sense to define the macros on an 'as needed' basis instead of having a macro for every possible C++0x feature? I.e. for now just define macros for C++0x features already present in existing c++ compilers. -- gpd
Giovanni Piero Deretta wrote:
On Thu, May 29, 2008 at 5:46 PM, Beman Dawes <bdawes@acm.org> wrote:
Douglas Gregor wrote:
On Thu, 2008-05-29 at 09:58 -0400, Beman Dawes wrote:
Beman Dawes wrote:
BOOST_NO_UNICODE_LITERALS // no Unicode literals Grrr... At least one compiler beta is supporting u and U literals, but not U8 literals. Will that vendor be supporting U8 literals before the final release? We don't need to cope with non-released compilers. Good point. The product manager actually thought UTF-8 literals were supporting, so maybe they will appear in the final release.
We can always just define BOOST_NO_UNICODE_LITERALS until all three flavors are fully supported. That probably makes more sense.
For every macro, a separate test case .ipp file has to be written and then tested for every compiler. Given the number of new C++0x features, the Boost macros will become unmanageable if they are too fine grained.
Wouldn't it make much sense to define the macros on an 'as needed' basis instead of having a macro for every possible C++0x feature? I.e. for now just define macros for C++0x features already present in existing c++ compilers.
That's mostly what I've been doing, at least if you count beta compilers as "existing". --Beman
Beman Dawes wrote:
OK, I propose to add the following:
// Rename versions some current BOOST_HAS_* macros to:
BOOST_NO_CONCEPTS BOOST_NO_DECLTYPE BOOST_NO_LONG_LONG BOOST_NO_RVALUE_REFS BOOST_NO_STATIC_ASSERT BOOST_NO_VARIADIC_TMPL
// New macros:
BOOST_NO_SCOPED_ENUMS // no enum class BOOST_NO_RAW_LITS // no raw character or string literals BOOST_NO_UNICODE_LITS // no Unicode literals BOOST_NO_OX_CHAR_TYPES // no char16_t or char32_t BOOST_NO_EXPLICIT_CVT_OP // no explicit operator T() BOOST_NO_DFLT_AND_DEL_FUNCS // no = default or = delete functions BOOST_NO_CONSTEXPR // no constexpr
Comments or suggestions?
--Beman
Jumping in at this point in the conversation, why not just define the BOOST_NO_* macros and define the BOOST_HAS_* as being !BOOST_NO_*. That way we get both? I know that eventually people will want to remove one or the other, but we could introduce a backwards-compatibility header that triggers a deprecation warning or something when it comes to that. Sean Hunt
Sean Hunt wrote:
Beman Dawes wrote:
OK, I propose to add the following:
// Rename versions some current BOOST_HAS_* macros to:
BOOST_NO_CONCEPTS BOOST_NO_DECLTYPE BOOST_NO_LONG_LONG BOOST_NO_RVALUE_REFS BOOST_NO_STATIC_ASSERT BOOST_NO_VARIADIC_TMPL
// New macros:
BOOST_NO_SCOPED_ENUMS // no enum class BOOST_NO_RAW_LITS // no raw character or string literals BOOST_NO_UNICODE_LITS // no Unicode literals BOOST_NO_OX_CHAR_TYPES // no char16_t or char32_t BOOST_NO_EXPLICIT_CVT_OP // no explicit operator T() BOOST_NO_DFLT_AND_DEL_FUNCS // no = default or = delete functions BOOST_NO_CONSTEXPR // no constexpr
Comments or suggestions?
--Beman
Jumping in at this point in the conversation, why not just define the BOOST_NO_* macros and define the BOOST_HAS_* as being !BOOST_NO_*. That way we get both?
That's an interesting idea, although perhaps a little to cute. What do others think? Does it add value or just confuse? Thanks, --Beman
Beman Dawes <bdawes@acm.org> writes:
Sean Hunt wrote:
Jumping in at this point in the conversation, why not just define the BOOST_NO_* macros and define the BOOST_HAS_* as being !BOOST_NO_*. That way we get both?
That's an interesting idea, although perhaps a little to cute. What do others think? Does it add value or just confuse?
Well, for one thing it would mean that those of us who have started to use the BOOST_HAS_ variants won't suddenly find our code broken. Anthony -- Anthony Williams | Just Software Solutions Ltd Custom Software Development | http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL
anthony.ajw@gmail.com wrote:
Beman Dawes <bdawes@acm.org> writes:
Sean Hunt wrote:
Jumping in at this point in the conversation, why not just define the BOOST_NO_* macros and define the BOOST_HAS_* as being !BOOST_NO_*. That way we get both? That's an interesting idea, although perhaps a little to cute. What do others think? Does it add value or just confuse?
Well, for one thing it would mean that those of us who have started to use the BOOST_HAS_ variants won't suddenly find our code broken.
The plan would be to (1) leave the BOOST_HAS_ variants in place, at least for a while, and (2) volunteer to convert to the BOOST_NO_ form for any libraries where the developer would like help. --Beman
anthony.ajw@gmail.com wrote:
That's an interesting idea, although perhaps a little to cute. What do others think? Does it add value or just confuse?
Well, for one thing it would mean that those of us who have started to use the BOOST_HAS_ variants won't suddenly find our code broken.
Personally I'd rather have "one true macro" for each feature or defect, if necessary it's not hard to fix up the old code is it (and no I'm not expecting *you* to make that change)? Or are you using the C++0x macros in non-Boost code? Regards, John.
"John Maddock" <john@johnmaddock.co.uk> writes:
anthony.ajw@gmail.com wrote:
That's an interesting idea, although perhaps a little to cute. What do others think? Does it add value or just confuse?
Well, for one thing it would mean that those of us who have started to use the BOOST_HAS_ variants won't suddenly find our code broken.
Personally I'd rather have "one true macro" for each feature or defect, if necessary it's not hard to fix up the old code is it (and no I'm not expecting *you* to make that change)? Or are you using the C++0x macros in non-Boost code?
No it's not hard to do the fixes, and I'm fine with doing it myself for boost.thread. However, I still think it's preferable to have both options at least for a while to give people a chance to switch (as per Beman's suggestion). And finally, yes, I do use the boost config macros outside boost. It's clearer to use BOOST_HAS_RVALUE_REFS than the equivalent "is this GCC in C++0x mode" test, and it'll still work when other vendors ship compilers with rvalue-ref support (assuming boost keeps track). How about for 1.36.0 we provide both, and for 1.37.0 we drop the HAS variants? This gives people (both within boost and without) a full boost release to make the switch. Anthony -- Anthony Williams | Just Software Solutions Ltd Custom Software Development | http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL
Anthony Williams wrote:
How about for 1.36.0 we provide both, and for 1.37.0 we drop the HAS variants? This gives people (both within boost and without) a full boost release to make the switch.
That sounds fine: given that we have actually documented the HAS_* versions, we should have at least one release with them marked as deprecated but still supported. John.
Beman Dawes wrote:
Sean Hunt wrote:
Jumping in at this point in the conversation, why not just define the BOOST_NO_* macros and define the BOOST_HAS_* as being !BOOST_NO_*. That way we get both?
That's an interesting idea, although perhaps a little to cute. What do others think? Does it add value or just confuse?
I think it just confuses the issue and doubles the number of macros a developer has to think about. - Doug
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
Beman Dawes wrote:
David Abrahams wrote:
That's not a bad idea. I wonder whether it might not be better just to
#define constexpr
in that case, and use that symbol.
I thought of that, and decided it wasn't a good idea to define a symbol that non-boost code might also be using and/or redefining. But that's only a weak opinion, and I'm open to reconsidering it. What do others think?
This will cause problems for compilers where the Boost configuration is wrong (, e.g., we don't realize that constexpr is supported) and the user is relying on constexpr in her own code. I think it's better to stick with BOOST_CONSTEXPR, as ugly as it is :(. - Doug
participants (14)
-
AlisdairM -
Anthony Williams -
anthony.ajw＠gmail.com
-
Beman Dawes -
David Abrahams -
Douglas Gregor -
Giovanni Piero Deretta -
Joe Gottman -
John Maddock -
Peter Dimov -
Robert Kawulak -
Sean Hunt -
Sebastian Redl -
Steven Watanabe