[config] Add BOOST_NO_RANGE_BASED_FOR macro?
I'm about to add Boost.Filesystem support for C ++11 range-based for statements, and would like to include direct test cases for compilers that have the feature. Is it OK to add a BOOST_NO_RANGE_BASED_FOR macro to trunk? --Beman
On Jul 9, 2012, at 8:19 AM, Beman Dawes wrote:
I'm about to add Boost.Filesystem support for C ++11 range-based for statements, and would like to include direct test cases for compilers that have the feature.
Is it OK to add a BOOST_NO_RANGE_BASED_FOR macro to trunk?
Two options: 1) Can you just test for c++11 support? Range based for loops are pretty basic #if __cplusplus >= 201103L 2) If you have to add a config flag, please match the CXX11 naming scheme and call it something like BOOST_NO_CXX11_RANGE_BASED_FOR -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki
On Mon, Jul 9, 2012 at 12:11 PM, John Maddock <boost.regex@virgin.net> wrote:
2) If you have to add a config flag, please match the CXX11 naming scheme and call it something like BOOST_NO_CXX11_RANGE_BASED_FOR
+1 for that name.
I really don't want to change naming schemes this far into it. If we go down that road, we should also rename the 28 Macros that don't use that scheme. Are you suggesting we should just byte the bullet and change them all? --Beman
On Jul 9, 2012, at 11:34 AM, Beman Dawes wrote:
On Mon, Jul 9, 2012 at 12:11 PM, John Maddock <boost.regex@virgin.net> wrote:
2) If you have to add a config flag, please match the CXX11 naming scheme and call it something like BOOST_NO_CXX11_RANGE_BASED_FOR
+1 for that name.
I really don't want to change naming schemes this far into it. If we go down that road, we should also rename the 28 Macros that don't use that scheme.
Are you suggesting we should just byte the bullet and change them all?
Yes, I am. I suggest that we do the same thing that I did for 1.50 and all the BOOST_NO_0X_* macros. Define new ones, make the old ones have the same value as the new ones, and then, down the road, kill off the old ones. See trunk/boost/config/suffix.hpp. I even think that renaming all the macros (while keeping the old names around; not necessarily changing client code) is worth doing for 1.51. -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki
On Jul 9, 2012, at 11:42 AM, Marshall Clow wrote:
On Jul 9, 2012, at 11:34 AM, Beman Dawes wrote:
On Mon, Jul 9, 2012 at 12:11 PM, John Maddock <boost.regex@virgin.net> wrote:
2) If you have to add a config flag, please match the CXX11 naming scheme and call it something like BOOST_NO_CXX11_RANGE_BASED_FOR
+1 for that name.
I really don't want to change naming schemes this far into it. If we go down that road, we should also rename the 28 Macros that don't use that scheme.
Are you suggesting we should just byte the bullet and change them all?
Yes, I am.
I suggest that we do the same thing that I did for 1.50 and all the BOOST_NO_0X_* macros. Define new ones, make the old ones have the same value as the new ones, and then, down the road, kill off the old ones.
See trunk/boost/config/suffix.hpp.
I even think that renaming all the macros (while keeping the old names around; not necessarily changing client code) is worth doing for 1.51.
(Putting his money where his mouth is) Here's a patch vs. the trunk which renames all the macros in the table "Macros that describe C++11 features not supported" (with the notable exception of BOOST_NO_LONG_LONG) to have consistent names. For example: BOOST_NO_VARIADIC_MACROS --> BOOST_NO_CXX11_VARIADIC_MACROS All the old names are then #defined to be the same as the new names; All the code and tests in config has been updated to use the new names. All the old names have been put into the "Boost Deprecated Macros" table. The goal here is no changes to client code (including code in boost outside of the config library). This seems to work fine on my system (Mac with gcc and clang) Now Beman can define "BOOST_NO_CXX11_RANGE_BASED_FOR" and it will match the style with other macros. Comments? -- Marshall
On Mon, Jul 9, 2012 at 4:57 PM, Marshall Clow <mclow.lists@gmail.com> wrote:
On Jul 9, 2012, at 11:42 AM, Marshall Clow wrote:
On Jul 9, 2012, at 11:34 AM, Beman Dawes wrote:
On Mon, Jul 9, 2012 at 12:11 PM, John Maddock <boost.regex@virgin.net> wrote:
2) If you have to add a config flag, please match the CXX11 naming scheme and call it something like BOOST_NO_CXX11_RANGE_BASED_FOR
+1 for that name.
I really don't want to change naming schemes this far into it. If we go down that road, we should also rename the 28 Macros that don't use that scheme.
Are you suggesting we should just byte the bullet and change them all?
Yes, I am.
I suggest that we do the same thing that I did for 1.50 and all the BOOST_NO_0X_* macros. Define new ones, make the old ones have the same value as the new ones, and then, down the road, kill off the old ones.
See trunk/boost/config/suffix.hpp.
I even think that renaming all the macros (while keeping the old names around; not necessarily changing client code) is worth doing for 1.51.
(Putting his money where his mouth is)
Here's a patch vs. the trunk which renames all the macros in the table "Macros that describe C++11 features not supported" (with the notable exception of BOOST_NO_LONG_LONG) to have consistent names. For example: BOOST_NO_VARIADIC_MACROS --> BOOST_NO_CXX11_VARIADIC_MACROS
All the old names are then #defined to be the same as the new names; All the code and tests in config has been updated to use the new names. All the old names have been put into the "Boost Deprecated Macros" table.
The goal here is no changes to client code (including code in boost outside of the config library). This seems to work fine on my system (Mac with gcc and clang)
Now Beman can define "BOOST_NO_CXX11_RANGE_BASED_FOR" and it will match the style with other macros.
Comments?
Why, again, are we preferring inserting CXX11 versus not? I.e., why is BOOST_NO_CXX11_RVALUE_REFERENCES better than BOOST_NO_RVALUE_REFERENCES? - Jeff
On Jul 9, 2012, at 5:15 PM, Jeffrey Lee Hellrung, Jr. wrote:
On Mon, Jul 9, 2012 at 4:57 PM, Marshall Clow <mclow.lists@gmail.com> wrote:
Here's a patch vs. the trunk which renames all the macros in the table "Macros that describe C++11 features not supported" (with the notable exception of BOOST_NO_LONG_LONG) to have consistent names. For example: BOOST_NO_VARIADIC_MACROS --> BOOST_NO_CXX11_VARIADIC_MACROS
All the old names are then #defined to be the same as the new names; All the code and tests in config has been updated to use the new names. All the old names have been put into the "Boost Deprecated Macros" table.
The goal here is no changes to client code (including code in boost outside of the config library). This seems to work fine on my system (Mac with gcc and clang)
Now Beman can define "BOOST_NO_CXX11_RANGE_BASED_FOR" and it will match the style with other macros.
Comments?
Why, again, are we preferring inserting CXX11 versus not? I.e., why is BOOST_NO_CXX11_RVALUE_REFERENCES better than BOOST_NO_RVALUE_REFERENCES?
Because when the C++ committee puts out a new standard, and changes how rvalue references work, we can then define a new flag BOOST_NO_CXX17_RVALUE_REFERENCES, and it will be easy to explain to everyone what the differences are. -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki
On Mon, Jul 9, 2012 at 5:21 PM, Marshall Clow <mclow.lists@gmail.com> wrote:
On Jul 9, 2012, at 5:15 PM, Jeffrey Lee Hellrung, Jr. wrote:
On Mon, Jul 9, 2012 at 4:57 PM, Marshall Clow <mclow.lists@gmail.com> wrote:
Here's a patch vs. the trunk which renames all the macros in the table "Macros that describe C++11 features not supported" (with the notable exception of BOOST_NO_LONG_LONG) to have consistent names. For example: BOOST_NO_VARIADIC_MACROS --> BOOST_NO_CXX11_VARIADIC_MACROS
All the old names are then #defined to be the same as the new names; All the code and tests in config has been updated to use the new names. All the old names have been put into the "Boost Deprecated Macros" table.
The goal here is no changes to client code (including code in boost outside of the config library). This seems to work fine on my system (Mac with gcc and clang)
Now Beman can define "BOOST_NO_CXX11_RANGE_BASED_FOR" and it will match the style with other macros.
Comments?
Why, again, are we preferring inserting CXX11 versus not? I.e., why is BOOST_NO_CXX11_RVALUE_REFERENCES better than BOOST_NO_RVALUE_REFERENCES?
Because when the C++ committee puts out a new standard, and changes how rvalue references work, we can then define a new flag BOOST_NO_CXX17_RVALUE_REFERENCES, and it will be easy to explain to everyone what the differences are.
That makes sense. I guess no one has strong opposition against the CXX11 macro additions? - Jeff
(Putting his money where his mouth is)
Here's a patch vs. the trunk which renames all the macros in the table "Macros that describe C++11 features not supported" (with the notable exception of >BOOST_NO_LONG_LONG) to have consistent names. For example: BOOST_NO_VARIADIC_MACROS --> BOOST_NO_CXX11_VARIADIC_MACROS
All the old names are then #defined to be the same as the new names; All the code and tests in config has been updated to use the new names. All the old names have been put into the "Boost Deprecated Macros" table.
The goal here is no changes to client code (including code in boost outside of the config library). This seems to work fine on my system (Mac with gcc and clang)
Now Beman can define "BOOST_NO_CXX11_RANGE_BASED_FOR" and it will match the style with other macros.
Comments?
Based on casting a mark 1 eyeball over the diffs, I'm happy with that going in. John.
(Putting his money where his mouth is)
Here's a patch vs. the trunk which renames all the macros in the table "Macros that describe C++11 features not supported" (with the notable exception of >BOOST_NO_LONG_LONG) to have consistent names. For example: BOOST_NO_VARIADIC_MACROS --> BOOST_NO_CXX11_VARIADIC_MACROS
BOOST_NO_VARIADIC_MACROS means "variadic macros are not supported". BOOST_NO_CXX11_VARIADIC_MACROS means "C++11 variadic macros are not supported, but other variadic macros may be". This is why we have NO_CXX11_FUNCTIONAL, for example, and not just NO_FUNCTIONAL - <functional> is present, but the C++11 portions aren't.
A slight correction but still... On 2012-07-10 10:18:04 +0000, Peter Dimov said:
BOOST_NO_VARIADIC_MACROS means "variadic macros are not supported".
I'm sorry, but I think this is incorrect. AFAIK, the above naming would mean: "Variadic macros -- the feature required by the C++ standard -- are not supported". And of course, there was no such feature required before C++11. For language extensions, there is a convention to call such macros in the positive form using the word "has", e.g. BOOST_HAS_VARIADIC_MACROS. More info: http://boost.org/libs/config/doc/html/boost_config/boost_macro_reference.htm...
BOOST_NO_CXX11_VARIADIC_MACROS means "C++11 variadic macros are not supported, but other variadic macros may be".
This is correct, in a way, given that a future C++ standard may refine the variadic macros somehow.
This is why we have NO_CXX11_FUNCTIONAL, for example, and not just NO_FUNCTIONAL - <functional> is present, but the C++11 portions aren't.
This statement is correct, since the header <functional> was already required in C++03. -- Pyry Jahkola pyry.jahkola@iki.fi https://twitter.com/pyrtsa
On Tue, Jul 10, 2012 at 4:03 AM, John Maddock <boost.regex@virgin.net> wrote:
(Putting his money where his mouth is)
Here's a patch vs. the trunk which renames all the macros in the table "Macros that describe C++11 features not supported" (with the notable exception of >BOOST_NO_LONG_LONG) to have consistent names. For example: BOOST_NO_VARIADIC_MACROS --> BOOST_NO_CXX11_VARIADIC_MACROS
All the old names are then #defined to be the same as the new names; All the code and tests in config has been updated to use the new names. All the old names have been put into the "Boost Deprecated Macros" table.
The goal here is no changes to client code (including code in boost outside of the config library). This seems to work fine on my system (Mac with gcc and clang)
Now Beman can define "BOOST_NO_CXX11_RANGE_BASED_FOR" and it will match the style with other macros.
Comments?
Based on casting a mark 1 eyeball over the diffs, I'm happy with that going in.
OK, I'm on board. I'll wait until Marshall applies his patch before adding the range-based-for-statement macro. I noticed that clang's feature macro shortened the name to "range_for". Does anyone object to BOOST_NO_CXX11_RANGE_FOR as our macro name? --Beman
On Jul 10, 2012, at 6:44 AM, Beman Dawes wrote:
On Tue, Jul 10, 2012 at 4:03 AM, John Maddock <boost.regex@virgin.net> wrote:
(Putting his money where his mouth is)
Here's a patch vs. the trunk which renames all the macros in the table "Macros that describe C++11 features not supported" (with the notable exception of >BOOST_NO_LONG_LONG) to have consistent names. For example: BOOST_NO_VARIADIC_MACROS --> BOOST_NO_CXX11_VARIADIC_MACROS
All the old names are then #defined to be the same as the new names; All the code and tests in config has been updated to use the new names. All the old names have been put into the "Boost Deprecated Macros" table.
The goal here is no changes to client code (including code in boost outside of the config library). This seems to work fine on my system (Mac with gcc and clang)
Now Beman can define "BOOST_NO_CXX11_RANGE_BASED_FOR" and it will match the style with other macros.
Comments?
Based on casting a mark 1 eyeball over the diffs, I'm happy with that going in.
OK, I'm on board.
I'll wait until Marshall applies his patch before adding the range-based-for-statement macro.
Committed in revision 79400. Since the -commits list is still down, here's a list of the old macros and the new ones: BOOST_NO_AUTO_DECLARATIONS BOOST_NO_CXX11_AUTO_DECLARATIONS BOOST_NO_AUTO_MULTIDECLARATIONS BOOST_NO_CXX11_AUTO_MULTIDECLARATIONS BOOST_NO_CHAR16_T BOOST_NO_CXX11_CHAR16_T BOOST_NO_CHAR32_T BOOST_NO_CXX11_CHAR32_T BOOST_NO_TEMPLATE_ALIASES BOOST_NO_CXX11_TEMPLATE_ALIASES BOOST_NO_CONSTEXPR BOOST_NO_CXX11_CONSTEXPR BOOST_NO_DECLTYPE BOOST_NO_CXX11_DECLTYPE BOOST_NO_DECLTYPE_N3276 BOOST_NO_CXX11_DECLTYPE_N3276 BOOST_NO_DEFAULTED_FUNCTIONS BOOST_NO_CXX11_DEFAULTED_FUNCTIONS BOOST_NO_DELETED_FUNCTIONS BOOST_NO_CXX11_DELETED_FUNCTIONS BOOST_NO_EXPLICIT_CONVERSION_OPERATORS BOOST_NO_CXX11_EXPLICIT_CONVERSION_OPERATORS BOOST_NO_EXTERN_TEMPLATE BOOST_NO_CXX11_EXTERN_TEMPLATE BOOST_NO_FUNCTION_TEMPLATE_DEFAULT_ARGS BOOST_NO_CXX11_FUNCTION_TEMPLATE_DEFAULT_ARGS BOOST_NO_LAMBDAS BOOST_NO_CXX11_LAMBDAS BOOST_NO_LOCAL_CLASS_TEMPLATE_PARAMETERS BOOST_NO_CXX11_LOCAL_CLASS_TEMPLATE_PARAMETERS BOOST_NO_NOEXCEPT BOOST_NO_CXX11_NOEXCEPT BOOST_NO_NULLPTR BOOST_NO_CXX11_NULLPTR BOOST_NO_RAW_LITERALS BOOST_NO_CXX11_RAW_LITERALS BOOST_NO_RVALUE_REFERENCES BOOST_NO_CXX11_RVALUE_REFERENCES BOOST_NO_SCOPED_ENUMS BOOST_NO_CXX11_SCOPED_ENUMS BOOST_NO_STATIC_ASSERT BOOST_NO_CXX11_STATIC_ASSERT BOOST_NO_STD_UNORDERD BOOST_NO_CXX11_STD_UNORDERD BOOST_NO_UNICODE_LITERALS BOOST_NO_CXX11_UNICODE_LITERALS BOOST_NO_UNIFIED_INITIALIZATION_SYNTAX BOOST_NO_CXX11_UNIFIED_INITIALIZATION_SYNTAX BOOST_NO_VARIADIC_TEMPLATES BOOST_NO_CXX11_VARIADIC_TEMPLATES BOOST_NO_VARIADIC_MACROS BOOST_NO_CXX11_VARIADIC_MACROS -- Marshall
On Tue, Jul 10, 2012 at 10:02 AM, Marshall Clow <mclow.lists@gmail.com> wrote:
...
Committed in revision 79400.
You missed the required addition of _cxx11 to the names of the test functions:-) I fixed those at the same time as adding the BOOST_NO_CXX11_RANGE_BASED_FOR macro. That allowed config_info and config_test to pass on all the gcc/intel/microsoft compilers I've got installed locally. We need to keep an eye on the full regression tests for several days to make sure there are no snafus. --Beman
On Tue, Jul 10, 2012 at 12:17 PM, Beman Dawes <bdawes@acm.org> wrote:
On Tue, Jul 10, 2012 at 10:02 AM, Marshall Clow <mclow.lists@gmail.com> wrote:
...
Committed in revision 79400.
You missed the required addition of _cxx11 to the names of the test functions:-)
I fixed those at the same time as adding the BOOST_NO_CXX11_RANGE_BASED_FOR macro. That allowed config_info and config_test to pass on all the gcc/intel/microsoft compilers I've got installed locally.
We need to keep an eye on the full regression tests for several days to make sure there are no snafus.
I thought you had changed your mind to RANGE_FOR...? - Jeff
On Jul 10, 2012, at 12:17 PM, Beman Dawes wrote:
On Tue, Jul 10, 2012 at 10:02 AM, Marshall Clow <mclow.lists@gmail.com> wrote:
Committed in revision 79400.
You missed the required addition of _cxx11 to the names of the test functions:-)
I fixed those at the same time as adding the BOOST_NO_CXX11_RANGE_BASED_FOR macro. That allowed config_info and config_test to pass on all the gcc/intel/microsoft compilers I've got installed locally.
Great! I checked the config test this morning; but very few had cycled. -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki
On Mon, Jul 9, 2012 at 11:54 AM, Marshall Clow <mclow.lists@gmail.com> wrote:
On Jul 9, 2012, at 8:19 AM, Beman Dawes wrote:
I'm about to add Boost.Filesystem support for C ++11 range-based for statements, and would like to include direct test cases for compilers that have the feature.
Is it OK to add a BOOST_NO_RANGE_BASED_FOR macro to trunk?
Two options: 1) Can you just test for c++11 support? Range based for loops are pretty basic #if __cplusplus >= 201103L
Range-base for statement support is like all the other C++0x features - they are being added to most compilers release by release. None of the major vendors seem to be waiting until all features are ready in their compilers.
2) If you have to add a config flag, please match the CXX11 naming scheme and call it something like BOOST_NO_CXX11_RANGE_BASED_FOR
We are using the BOOST_NO_CXX11_ scheme for header files only. None of the 28 feature macros we already have use a BOOST_NO_CXX11_ prefix. See http://www.boost.org/doc/libs/1_50_0/libs/config/doc/html/boost_config/boost... --Beman
On Jul 9, 2012, at 11:28 AM, Beman Dawes wrote:
2) If you have to add a config flag, please match the CXX11 naming scheme and call it something like BOOST_NO_CXX11_RANGE_BASED_FOR
We are using the BOOST_NO_CXX11_ scheme for header files only. None of the 28 feature macros we already have use a BOOST_NO_CXX11_ prefix.
Seehttp://www.boost.org/doc/libs/1_50_0/libs/config/doc/html/boost_config/boost...
Well, shame on us. I could argue about BOOST_NO_CXX11_SMART_PTR BOOST_NO_CXX11_ALLOCATOR BOOST_NO_CXX11_ATOMIC_SMART_PTR but those are "related to" header files. IM(NS)HO, these should all be BOOST_NO_CXX11 macros. For example, BOOST_NO_NULLPTR should be BOOST_NO_CXX11_NULLPTR (but we're not going to change that today) -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki
participants (7)
-
Beman Dawes -
Jeffrey Lee Hellrung, Jr. -
John Maddock -
Marshall Clow -
Peter Dimov -
Pyry Jahkola -
Stephan T. Lavavej