Date: Mon, 24 Jun 2013 12:44:13 -0400
On Jun 24, 2013, at 12:14 PM, "Nelson, Clark" <clark.nelson_at_[hidden]> wrote:
>> 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.
>
I generally agree with your goals, but as I said on the call, I'm okay with not solving that issue for the very limited case of the use of the new header files.
There is any easy workaround, as suggested by Tom Plum, of putting an <optional> (or whatever header) later in your search path that would be found if the implementation does not supply one.
I don't like the idea of adding macros for these headers to existing files.
John.
>> 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.
>
I generally agree with your goals, but as I said on the call, I'm okay with not solving that issue for the very limited case of the use of the new header files.
There is any easy workaround, as suggested by Tom Plum, of putting an <optional> (or whatever header) later in your search path that would be found if the implementation does not supply one.
I don't like the idea of adding macros for these headers to existing files.
John.
Received on 2013-06-24 18:44:17