Subject: Re: [SG10] Updates to SD-6: N4190
From: Ed Smith-Rowland (3dw4rd_at_[hidden])
Date: 2015-01-09 09:41:19
On 01/08/2015 08:26 PM, Nelson, Clark wrote:
> Taking your questions out of order:
>> 2. Are the replacement features in the same headers? The above
>> work if the old and new features are in different headers. It
>> looks like
>> the powers that be tried to make that the case but I haven't
>> looked hard.
> I'm afraid I don't know. Presumably someone knows all about the
> newer facilities that made the deprecated facilities obsolete, but
> that information doesn't seem to have made it into the standard.
>> 1. There are people who may need to support code bases across
>> compiler versions and multiple compilers and even within one
>> across a version of C++ or two. I think it would be good to make
>> that each feature to be removed has a feature macro for the new
>> replacing feature so for builds against older C++ versions and
>> can know when to switch when the new feature is available.
> The question is, once someone writes code that uses a new/better
> facility in place of a deprecated/removed facility, would they
> really want or need to keep around the code that uses the removed
> facility? How would they benefit by doing so?
Portability - across compilers and even within a compiler across C++
I see portability as the main goal with SD-6: If a newer feature is not
available on one of your target platform/compiler combinations you have
to roll back to the older facility. Different compilers are at
different places toward full feature support.
For example, in my world, I have systems that use a lot of C++14 (linux
gcc-4.9/5.0). I use SD-6 macros to switch to new features and allow old
ones for this code base on MinGW-w64 gcc-4.8 that doesn't even have SD-6
User-space apps may be under rules about which version of C++ is
allowed. SD-6 allows experimentation and an eventual transition. And
> It seems that what we really want is feature-test macros for the
> new facilities that made these obsolete. Personally, I don't even
> know in what standard they were introduced; I can only guess that
> it was probably C++11. Do we want to continue to expand that table?
This is actually my point. I think we should expand that table both in
language and in library as a way of future-proofing SD-6. So if C++17,
20, ... touches these features we'll have something we can readily just
bump the date on. I'll look into this over the weekend. I'll look at
the header question too.
> Features mailing list
SG10 list run by herb.sutter at gmail.com