Another set of macros to deprecate (and then remove)?
There are a set of macros in Boost.config that describe "features that are not required by the C++ standard" Some of these features have been incorporated into C++11. I propose that we retire these macros, and have people use the shiny C++11 versions. In particular: BOOST_HAS_STATIC_ASSERT should be ! BOOST_NO_CXX11_ASSERT BOOST_HAS_VARIADIC_TMPL should be ! BOOST_NO_CXX11_VARIADIC_TEMPLATES BOOST_HAS_RVALUE_REFS should be ! BOOST_NO_CXX11_RVALUE_REFERENCES BOOST_HAS_CHAR_16_T should be ! BOOST_NO_CXX11_CHAR_16_T BOOST_HAS_CHAR_32_T should be ! BOOST_NO_CXX11_CHAR_32_T I'm using "!" here generically; in code you would replace #ifdef OLD_MACRO with #ifndef NEW_MACRO etc. I don't think this will be very disruptive; very few boost libraries use these macros. Opinions? Other macros that fit into this group? -- 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
2012/12/13 Marshall Clow <mclow.lists@gmail.com>
There are a set of macros in Boost.config that describe "features that are not required by the C++ standard"
Some of these features have been incorporated into C++11.
I propose that we retire these macros, and have people use the shiny C++11 versions.
In particular: BOOST_HAS_STATIC_ASSERT should be ! BOOST_NO_CXX11_ASSERT BOOST_HAS_VARIADIC_TMPL should be ! BOOST_NO_CXX11_VARIADIC_TEMPLATES BOOST_HAS_RVALUE_REFS should be ! BOOST_NO_CXX11_RVALUE_REFERENCES BOOST_HAS_CHAR_16_T should be ! BOOST_NO_CXX11_CHAR_16_T BOOST_HAS_CHAR_32_T should be ! BOOST_NO_CXX11_CHAR_32_T
Aren't char_16_t and char_32_t optional in C++11? FWIU, the macros BOOST_NO_CXX11_* are for features required in C++11, aren't they? Regards, Kris
On Dec 13, 2012, at 8:06 AM, Krzysztof Czainski <1czajnik@gmail.com> wrote:
2012/12/13 Marshall Clow <mclow.lists@gmail.com>
There are a set of macros in Boost.config that describe "features that are not required by the C++ standard"
Some of these features have been incorporated into C++11.
I propose that we retire these macros, and have people use the shiny C++11 versions.
In particular: BOOST_HAS_STATIC_ASSERT should be ! BOOST_NO_CXX11_ASSERT BOOST_HAS_VARIADIC_TMPL should be ! BOOST_NO_CXX11_VARIADIC_TEMPLATES BOOST_HAS_RVALUE_REFS should be ! BOOST_NO_CXX11_RVALUE_REFERENCES BOOST_HAS_CHAR_16_T should be ! BOOST_NO_CXX11_CHAR_16_T BOOST_HAS_CHAR_32_T should be ! BOOST_NO_CXX11_CHAR_32_T
Aren't char_16_t and char_32_t optional in C++11?
I don't believe that they are.
FWIU, the macros BOOST_NO_CXX11_* are for features required in C++11, aren't they?
They are for C++11 features that are part of the language, but that compilers and/or standard libraries haven't implemented (yet). You could certainly make an argument that we should be able to take advantage off of pre-C++11 compilers that implement char16_t and char32_t, and I would be sympathetic to that argument - but I can't find any uses of BOOST_HAS_CHAR_16_T and BOOST_HAS_CHAR_32_T in Boost at this time. -- 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 Dec 13, 2012, at 8:09 AM, Andrey Semashev <andrey.semashev@gmail.com> wrote:
On Thu, Dec 13, 2012 at 7:53 PM, Marshall Clow <mclow.lists@gmail.com> wrote:
BOOST_NO_CXX11_ASSERT
Why not BOOST_NO_CXX11_STATIC_ASSERT?
Because apparently I can't type :-( You are correct; the replacement should be: BOOST_NO_CXX11_STATIC_ASSERT -- 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 Thu, Dec 13, 2012 at 07:53:06AM -0800, Marshall Clow wrote:
There are a set of macros in Boost.config that describe "features that are not required by the C++ standard"
Some of these features have been incorporated into C++11.
I propose that we retire these macros, and have people use the shiny C++11 versions.
In particular: BOOST_HAS_STATIC_ASSERT should be ! BOOST_NO_CXX11_ASSERT
I'm curious why Boost is changing from a positive macro "system has feature X" to a negative one. Of the two options: #ifdef BOOST_HAS_X ... or #ifndef BOOST_NO_X ... I personally find the former much easier to read and the latter double-negative version awkward enough to be error prone. Am I alone in this opinion? Thanks, -Steve
On Dec 14, 2012, at 8:38 AM, Steve M. Robbins <steve@sumost.ca> wrote:
On Thu, Dec 13, 2012 at 07:53:06AM -0800, Marshall Clow wrote:
There are a set of macros in Boost.config that describe "features that are not required by the C++ standard"
Some of these features have been incorporated into C++11.
I propose that we retire these macros, and have people use the shiny C++11 versions.
In particular: BOOST_HAS_STATIC_ASSERT should be ! BOOST_NO_CXX11_ASSERT
I'm curious why Boost is changing from a positive macro "system has feature X" to a negative one. Of the two options:
#ifdef BOOST_HAS_X ...
or
#ifndef BOOST_NO_X ...
I personally find the former much easier to read and the latter double-negative version awkward enough to be error prone. Am I alone in this opinion?
Here's my understanding, based on reading the docs at: http://www.boost.org/doc/libs/1_52_0/libs/config/doc/html/boost_config/boost... For things that are in the standard, we note their absence. For example: BOOST_NO_STDC_NAMESPACE and BOOST_NO_CXX11_RVALUE_REFERENCES For optional (extra?) language/library features, we note their presence BOOST_HAS_TR1 or BOOST_HAS_SGI_TYPE_TRAITS The macros that I am proposing deprecating were once "extra" language/library features, but have become part of the C++11 standard, and already have equivalents of the BOOST_NO_XXX variety. I'd really rather not have two different macros that describe the same thing. Besides, no one is using them in boost, anyway ;-) -- 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 December 14, 2012 10:52:29 AM Marshall Clow wrote:
On Dec 14, 2012, at 8:38 AM, Steve M. Robbins <steve@sumost.ca> wrote:
On Thu, Dec 13, 2012 at 07:53:06AM -0800, Marshall Clow wrote:
There are a set of macros in Boost.config that describe "features that are not required by the C++ standard"
Some of these features have been incorporated into C++11.
I propose that we retire these macros, and have people use the shiny C++11 versions.
In particular: BOOST_HAS_STATIC_ASSERT should be ! BOOST_NO_CXX11_ASSERT
I'm curious why Boost is changing from a positive macro "system has feature X" to a negative one. Of the two options:
#ifdef BOOST_HAS_X ...
or
#ifndef BOOST_NO_X ...
I personally find the former much easier to read and the latter double-negative version awkward enough to be error prone. Am I alone in this opinion?
Here's my understanding, based on reading the docs at: http://www.boost.org/doc/libs/1_52_0/libs/config/doc/html/boost_config/boo st_macro_reference.html
For things that are in the standard, we note their absence. For example: BOOST_NO_STDC_NAMESPACE and BOOST_NO_CXX11_RVALUE_REFERENCES
For optional (extra?) language/library features, we note their presence BOOST_HAS_TR1 or BOOST_HAS_SGI_TYPE_TRAITS
Thanks. This proves that the choice is deliberate. However, it doesn't answer whether using the double-negative is a good idea. Why not use BOOST_STDC_NAMESPACE and BOOST_CXX11_RVALUE_REFERENCES instead? -Steve
Here's my understanding, based on reading the docs at: http://www.boost.org/doc/libs/1_52_0/libs/config/doc/html/boost_config/boo st_macro_reference.html
For things that are in the standard, we note their absence. For example: BOOST_NO_STDC_NAMESPACE and BOOST_NO_CXX11_RVALUE_REFERENCES
For optional (extra?) language/library features, we note their presence BOOST_HAS_TR1 or BOOST_HAS_SGI_TYPE_TRAITS
Thanks. This proves that the choice is deliberate.
However, it doesn't answer whether using the double-negative is a good idea. Why not use BOOST_STDC_NAMESPACE and BOOST_CXX11_RVALUE_REFERENCES instead?
I think the idea is that the "normal" state of affairs (in this case meaning the latest language standard being fully supported) involves no config macros being defined, and the more "abnormal" the state of affairs gets (e.g.language feature not supported, compiler has a bug, etc.) the more config macros have to be defined. I'm not sure what the underlying reason for that is, but I'll venture a guess: perhaps the hope is that as time goes by and support for older compilers is dropped, there will be language features that work with all supported compilers, compiler bugs that no longer affect any supported compilers, etc., and the config library can then simply "forget" about those features and bugs as it forgets about older (unsupported) compilers. Otherwise as time goes by and more language standards are made, the config library would keep accumulating knowledge about how to detect support for various language features, but most of that knowledge would be unnecessary. Perhaps the config library authors can confirm whether my speculation about the rationale is correct. Regards, Nate
On 17.12.2012, at 07:00, Nathan Ridge wrote:
Perhaps the config library authors can confirm whether my speculation about the rationale is correct.
My guess would be that in addition to your reasons, it's a matter of implementation. If standard feature support macros are positive, for the implementation it either means - having every compiler/stdlib config header define every single feature macro, which is a lot of syntactic overhead (i.e. greater risk of stupid mistakes like forgetting one, slightly more work when adding a new platform, and of course the annoying fact that when adding a new perfectly compliant platform, "do nothing" is not the right thing to do) or - having a core header that defines every single macro, and then have the specific headers undefine them as needed, which strikes me as needlessly complicated. Also, it means a slight parsing overhead over just not having any code for features that are supported. Sebastian
On 17/12/2012 05:08, Steve M. Robbins wrote:
Thanks. This proves that the choice is deliberate.
However, it doesn't answer whether using the double-negative is a good idea. Why not use BOOST_STDC_NAMESPACE and BOOST_CXX11_RVALUE_REFERENCES instea
NO macros are for defects HAS macros are for features
Thanks. This proves that the choice is deliberate.
However, it doesn't answer whether using the double-negative is a good idea. Why not use BOOST_STDC_NAMESPACE and BOOST_CXX11_RVALUE_REFERENCES instea
NO macros are for defects HAS macros are for features
Correct, that was the original intention. Double negative or not, it makes it quite explicit what the workaround is for. John.
participants (8)
-
Andrey Semashev -
John Maddock -
Krzysztof Czainski -
Marshall Clow -
Mathias Gaunard -
Nathan Ridge -
Sebastian Redl -
Steve M. Robbins