[config] What to call macros to indicate deprecated/removed components
We now have several former C++ features which are removed in C++17: auto_ptr random_shuffle binders unary/binary_function And we're getting requests for configuration macros for these, the question is what to call them? We could stick with the (easy to implement) existing naming and just use: BOOST_NO_<FEATURE> or we could use: BOOST_<STD>_REMOVED_<FEATURE> which is a bit more work as all the scripts that rely on the BOOST_NO/BOOST_HAS convention need updating. Any other suggestions/preferences? Thanks, John. --- This email has been checked for viruses by AVG. http://www.avg.com
On 16 April 2017 at 11:57, John Maddock via Boost <boost@lists.boost.org> wrote:
We could stick with the (easy to implement) existing naming and just use:
BOOST_NO_<FEATURE>
or we could use:
BOOST_<STD>_REMOVED_<FEATURE>
which is a bit more work as all the scripts that rely on the BOOST_NO/BOOST_HAS convention need updating.
No strong opinion, but do we want the default to be that they're available?
Daniel James wrote:
No strong opinion, but do we want the default to be that they're available?
This is a good point in principle, but as things are added and then removed, the correct default for, say, <codecvt>, flips from not available (in C++03) to available (in C++11) to again not available (in C++20).
On 04/16/17 13:57, John Maddock via Boost wrote:
We now have several former C++ features which are removed in C++17:
auto_ptr
random_shuffle
binders
unary/binary_function
And we're getting requests for configuration macros for these, the question is what to call them?
We could stick with the (easy to implement) existing naming and just use:
BOOST_NO_<FEATURE>
or we could use:
BOOST_<STD>_REMOVED_<FEATURE>
which is a bit more work as all the scripts that rely on the BOOST_NO/BOOST_HAS convention need updating.
Any other suggestions/preferences?
Previously, we followed the "no macro = no defect" approach, which, if we consider the presence of the deprecated comonents a defect, would result in BOOST_CXX17_NO_REMOVED_RANDOM_SHUFFLE meaning random_shuffle is _present_ when the macro is _defined_. I think such behavior would be rather contrived, so IMHO it's better to define BOOST_CXX17_REMOVED_RANDOM_SHUFFLE when random_shuffle is missing. OTOH, that would also mean that the code will not be compatible with a "perfect compiler implementing the latest standard" with no macros defined. Not sure how useful this is.
On Sun, Apr 16, 2017 at 6:57 AM, John Maddock via Boost wrote:
We now have several former C++ features which are removed in C++17:
auto_ptr
random_shuffle
binders
unary/binary_function
And we're getting requests for configuration macros for these, the question is what to call them?
We could stick with the (easy to implement) existing naming and just use:
BOOST_NO_<FEATURE>
or we could use:
BOOST_<STD>_REMOVED_<FEATURE>
which is a bit more work as all the scripts that rely on the BOOST_NO/BOOST_HAS convention need updating.
Any other suggestions/preferences?
Thanks, John.
I like BOOST_NO_FEATURE for features just outright removed. Removal probably doesn't require a C++ standard version in the macro since its effects are the same even if it happens many times over, for some reason. (e.g. If std::exchange was removed in C++20, then added back in C++2y, then removed in C++2z, there would be no difference between BOOST_CXX20_REMOVED_STD_EXCHANGE and BOOST_CXX2Z_REMOVED_STD_EXCHANGE.) I just didn't like BOOST_NO_CXX17_FEATURE style if FEATURE does not even exist in C++17 because it is misleading compared to the other macros which check for existence of features.[1] Glen [1] https://github.com/boostorg/config/pull/131
Boost - Dev mailing list wrote
I like BOOST_NO_FEATURE for features just outright removed.
Removal probably doesn't require a C++ standard version in the macro since its effects are the same even if it happens many times over, for some reason. (e.g. If std::exchange was removed in C++20, then added back in C++2y, then removed in C++2z, there would be no difference between BOOST_CXX20_REMOVED_STD_EXCHANGE and BOOST_CXX2Z_REMOVED_STD_EXCHANGE.)
Glen
+1. But it would also have exactly the same effect as BOOST_NO_CXX14_STD_EXCHANGE, so perhaps that could also be used instead of BOOST_NO_STD_EXCHANGE. Marcel -- View this message in context: http://boost.2283326.n4.nabble.com/config-What-to-call-macros-to-indicate-de... Sent from the Boost - Dev mailing list archive at Nabble.com.
John Maddock wrote:
We now have several former C++ features which are removed in C++17:
auto_ptr
random_shuffle
binders
unary/binary_function
And we're getting requests for configuration macros for these, the question is what to call them?
We could stick with the (easy to implement) existing naming and just use:
BOOST_NO_<FEATURE>
We already have BOOST_NO_AUTO_PTR (and use it). It was originally introduced for C++98 libraries that didn't have auto_ptr _yet_, but the effects are entirely the same.
or we could use:
BOOST_<STD>_REMOVED_<FEATURE>
Depends on what we want <STD> to mean. Currently, we can interpret it as a prefix that says "<FEATURE> has been first introduced in <STD>", so, for instance, if std::bind is removed, we'll call it CXX11_BIND, consequently the macro would be BOOST_NO_CXX11_BIND. Or, as the above suggests, <STD> may tag the standard in which a change is taking place, hence BOOST_NO_CXX20_BIND. The first one makes more sense to me. For another example besides auto_ptr, consider what we'll do when <codecvt> is removed. We already have BOOST_NO_CXX11_HDR_CODECVT, would it not be stupid to introduce BOOST_NO_CXX20_HDR_CODECVT just to keep our brass door handles shiny? Whether <codecvt> is missing for one reason or another, it's missing.
participants (6)
-
Andrey Semashev -
Daniel James -
Glen Fernandes -
John Maddock -
Marcel Raad -
Peter Dimov