C++ Logo

SG10

Advanced search

Subject: Re: [SG10] Draft: ready for the mid-term mailing?
From: Nelson, Clark (clark.nelson_at_[hidden])
Date: 2013-06-24 11:14:15


> I have an alternate suggestion for the __cpp_lib_header_* macros.
>
> If a library provide needs to update a header (e.g., <utility> to
> define something like __cpp_lib_header_optional), why don't we
> just require them to provide the <optional> header, and if they
> don't implement the feature the complete contents of the file
> would be:
>
> #define __cpp_lib_header_optional 0

That's an interesting idea, but it doesn't fail safely, and therefore it
doesn't provide a seamless upgrade path.

The nice thing about all the other stuff we are planning to recommend for
feature-testing is that, if the programmer follows them, his program will
work on an implementation that has made no changes at all for C++14. This
approach doesn't have that characteristic; on an implementation of C++11 or
C++98, it will just fail to build.

That is *the* characteristic that I'm trying to achieve with these
recommendations. I know that, for new headers, achieving it requires
compromising on some other desirable principle. But to me, if a seamless
upgrade path is achievable at all, that's the way to go. And the
__cpp_lib_header_* macros provide a seamless upgrade path.

Clark


SG10 list run by sg10-owner@lists.isocpp.org