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