Date: Thu, 20 Jun 2013 09:42:12 -0400
On Jun 19, 2013, at 9:02 PM, "Nelson, Clark" <clark.nelson_at_[hidden]> wrote:
>>> The advantage is to all users of a compiler that's not based on
>> one of those
>>> two front ends. (Again, that seems so obvious that I'm
>> suspecting some sort
>>> of misunderstanding.)
>>
>> Those users would benefit more from us recommending that
>> implementations provide __has_feature than they would from us
>> recommending that implementations provide these two macros in
>> <cstddef>.
>
> Let's be really, really clear. Those users will not, strictly speaking,
> benefit from our making a recommendation. They will benefit from their
> implementer(s) actually following that recommendation. And it is inevitable
> that, at least in some cases, there will be a delay before that happens. I'm
> concerned about what happens in the interim.
>
>> If we have the former, I don't see value in the latter, so
>> I don't see value in us recommending both (just a burden on us to
>> keep around those two vestigial macros forever).
>
> The value is in the interim before everyone has an implementation of
> __has_include.
>
>>> We're not going to have another teleconference before the
>> mailing, so we're
>>> going to have to try to develop/recognize consensus on this
>> point over the
>>> reflector.
>>
>> Are there options on the table other than __has_feature and macros
>> in <cstddef>?
>
> Not at the moment, at least. All I'm saying is that people should express
> up-or-down opinions even if they don't have anything else to contribute to
> the discussion, to make sure we have a significant sample size.
>
>> Per above, I'm personally in favor of __has_feature, and I'm
>> weakly
>> opposed to macros in <cstddef> if we have __has_feature.
>
> In case it's not already obvious, I'm strongly in favor of the macros, and
> weakly in favor of __has_feature in addition.
>
I am in favor of the __has_include solution. We're talking about a very narrow part of the whole proposal, which is the issue of dealing with the presence of new headers.
The recommendation we discussed on the teleconference was to use __has_include. While it is true that only a few implementations have that currently, it is reasonable to expect that other implementations will add it as they add support for the other macros we suggest.
After all, 2 compilers with __has_include is better than the zero compilers that define the other macros we are recommending :-)
I am very troubled by the <cstddef> vs. <stddef.h> issue that was brought up and consider that a compelling reason not to introduce macros into either or both of those headers.
John.
>>> The advantage is to all users of a compiler that's not based on
>> one of those
>>> two front ends. (Again, that seems so obvious that I'm
>> suspecting some sort
>>> of misunderstanding.)
>>
>> Those users would benefit more from us recommending that
>> implementations provide __has_feature than they would from us
>> recommending that implementations provide these two macros in
>> <cstddef>.
>
> Let's be really, really clear. Those users will not, strictly speaking,
> benefit from our making a recommendation. They will benefit from their
> implementer(s) actually following that recommendation. And it is inevitable
> that, at least in some cases, there will be a delay before that happens. I'm
> concerned about what happens in the interim.
>
>> If we have the former, I don't see value in the latter, so
>> I don't see value in us recommending both (just a burden on us to
>> keep around those two vestigial macros forever).
>
> The value is in the interim before everyone has an implementation of
> __has_include.
>
>>> We're not going to have another teleconference before the
>> mailing, so we're
>>> going to have to try to develop/recognize consensus on this
>> point over the
>>> reflector.
>>
>> Are there options on the table other than __has_feature and macros
>> in <cstddef>?
>
> Not at the moment, at least. All I'm saying is that people should express
> up-or-down opinions even if they don't have anything else to contribute to
> the discussion, to make sure we have a significant sample size.
>
>> Per above, I'm personally in favor of __has_feature, and I'm
>> weakly
>> opposed to macros in <cstddef> if we have __has_feature.
>
> In case it's not already obvious, I'm strongly in favor of the macros, and
> weakly in favor of __has_feature in addition.
>
I am in favor of the __has_include solution. We're talking about a very narrow part of the whole proposal, which is the issue of dealing with the presence of new headers.
The recommendation we discussed on the teleconference was to use __has_include. While it is true that only a few implementations have that currently, it is reasonable to expect that other implementations will add it as they add support for the other macros we suggest.
After all, 2 compilers with __has_include is better than the zero compilers that define the other macros we are recommending :-)
I am very troubled by the <cstddef> vs. <stddef.h> issue that was brought up and consider that a compelling reason not to introduce macros into either or both of those headers.
John.
Received on 2013-06-20 15:42:19