C++ Logo

sg10

Advanced search

Re: [SG10] __has_include

From: Richard Smith <richard_at_[hidden]>
Date: Wed, 19 Jun 2013 17:36:44 -0700
On Wed, Jun 19, 2013 at 3:57 PM, Nelson, Clark <clark.nelson_at_[hidden]> wrote:
>> > That is probably practical for <cstddef>, but less so for <stddef.h>,
>> > which is frequently provided by the compiler implementer rather than
>> > by the C++ standard library implementer. If we're happy for <stddef.h>
>> > to not provide these macros, then the suggestion of putting them in
>> > <cstddef> seems fine to me.
>
>> I would find that really confusing, and really hard to explain to users. I hope I don't have to.
>
> I just want to be sure I understand: Are you saying that you think that
> adding a couple of macros to the list of things <cstddef> is supposed to do
> would be confusing? To me that seems remarkably straightforward, so I'm
> wondering if I've misunderstood you.

I read this as saying that it would be confusing to have the macros in
<cstddef> but not in <stddef.h>. And I agree with that sentiment.

>> I honestly don't understand the advantage of using macros defined in
>> <cstddef> rather than a very simple, well understood compiler feature
>> implemented by at least two frontends I'm aware of.
>
> 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>. 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).

> What's missing from the discussion that has happened on the reflector is
> that, during the meeting, we discussed just adding __has_include to the list
> of things recommended by SG10. As far as I'm concerned, there's no downside
> to that; we might as well try it.
>
> But personally, I'm leaning in the direction of also recommending macros
> specific to the two new headers added to C++14. To me, two macros seems like
> a small cost, and a little redundancy in this case might actually be a good
> thing.

[See above.]

> 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>?

Per above, I'm personally in favor of __has_feature, and I'm weakly
opposed to macros in <cstddef> if we have __has_feature.

Received on 2013-06-20 02:36:46