C++ Logo

sg10

Advanced search

Re: [SG10] Updates to SD-6: N4190

From: Ed Smith-Rowland <3dw4rd_at_[hidden]>
Date: Fri, 09 Jan 2015 10:41:19 -0500
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
>> won't
>> 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
>> multiple
>> compiler versions and multiple compilers and even within one
>> compiler
>> across a version of C++ or two. I think it would be good to make
>> sure
>> that each feature to be removed has a feature macro for the new
>> replacing feature so for builds against older C++ versions and
>> compilers
>> 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++
versions.
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
macros.

User-space apps may be under rules about which version of C++ is
allowed. SD-6 allows experimentation and an eventual transition. And
testing.

>
> 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.
>
> Clark
> _______________________________________________
> Features mailing list
> Features_at_[hidden]
> http://www.open-std.org/mailman/listinfo/features
>

Received on 2015-01-09 17:42:09