Subject: Re: [SG10] __has_include
From: Nelson, Clark (clark.nelson_at_[hidden])
Date: 2013-06-19 17:57:48
> > 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 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
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
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
SG10 list run by email@example.com