On Wed, Jun 19, 2013 at 2:00 PM, Richard Smith <richard@metafoo.co.uk> wrote:
On Wed, Jun 19, 2013 at 1:56 PM, Nelson, Clark <clark.nelson@intel.com> wrote:
>> I objected that I did not want including <cstddef> to require the
>> implementation to perform header search for <optional> and
>> <dynarray>
>> (and whatever other headers we add in the future). I would expect
>> issuing these file system requests to have a measurable cost.
>
> OK. And you don't think it's practical for <cstddef> just to know the right answer, and unconditionally define either or both of those two macros as appropriate?

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

It also means that others can't use the same facility in other libraries (i.e., not the standard library).

It also means that systems like './configure' scripts on *nix operating systems that want to craft programs to test for specific features end up with significantly more elaborate constructs. This tends to matter because such systems rely on running 100s of compiles of tiny inputs in a very short time. Making the inputs not tiny would be really unfortunate. As Richard has proposed it they could instead compile: int main() { return __has_include(<optional>); }