Date: Wed, 19 Jun 2013 14:51:42 -0700
On Wed, Jun 19, 2013 at 2:00 PM, Richard Smith <richard_at_[hidden]>wrote:
> On Wed, Jun 19, 2013 at 1:56 PM, Nelson, Clark <clark.nelson_at_[hidden]>
> 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>); }
> On Wed, Jun 19, 2013 at 1:56 PM, Nelson, Clark <clark.nelson_at_[hidden]>
> 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>); }
Received on 2013-06-19 23:51:44