C++ Logo


Advanced search

Re: [SG10] Draft: ready for the mid-term mailing?

From: Nelson, Clark <clark.nelson_at_[hidden]>
Date: Mon, 24 Jun 2013 16:14:15 +0000
> 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.


Received on 2013-06-24 18:14:44