Date: Thu, 3 Feb 2022 17:09:11 -0500
On Thu, Feb 3, 2022 at 4:10 PM Miguel Ojeda via Liaison <
liaison_at_[hidden]> wrote:
> On Thu, Feb 3, 2022 at 10:02 PM Ville Voutilainen
> <ville.voutilainen_at_[hidden]> wrote:
> >
> > So, nothing, I'm merely telling you that you have failed to prove your
> > bold claim.
> > Your subsequent bold claim that it's 'reality' instead of a bold claim
> > also remains unsubstantiated.
>
> I did prove `#pragma once` is widely used everywhere (= all kinds of
> domains / companies / entities).
>
> In fact, given the Reddit C++ post, one could even think it is the
> _most_ widely used form in C++ (vs. the guard: 2.3k vs 1.2k), for
> whatever that poll is worth.
>
> The problem is that for simple projects built by one developer on their
local machine, the problem cases almost never arise, so it looks like it
works. But then that package gets released and gets built outside the
comfortable cozy environment it started with, and it doesn't.
When I end up talking to compiler vendors they tell me they have to support
#pragma once because it's common enough that it's a portability issue, but
that they can not guarantee that it actually works.
State of the art seems to be sniffing the guard pattern, and watching for
files that have it being opened with exactly the same path spelling and
avoiding reopening them. If a file evades detection by some means, for
example the path doesn't have an identical spelling, then the preprocessor
still does its job.
> > Those projects already have the form they are already using. There's
> > no need for a standards
> > committee to take an action to give them what they already have,
> > especially when what's being proposed
> > gives them something else, including a different spelling.
>
> I bet some users would complain to us that we standardized `#once ID`
> but not what they used. One way or the other, we can't win.
>
> I'm sure they would because it doesn't solve the most common complaint
about include guards, that it's hard to make sure the ID is
universally unique and doesn't get copy pasted in a refactoring.
>
liaison_at_[hidden]> wrote:
> On Thu, Feb 3, 2022 at 10:02 PM Ville Voutilainen
> <ville.voutilainen_at_[hidden]> wrote:
> >
> > So, nothing, I'm merely telling you that you have failed to prove your
> > bold claim.
> > Your subsequent bold claim that it's 'reality' instead of a bold claim
> > also remains unsubstantiated.
>
> I did prove `#pragma once` is widely used everywhere (= all kinds of
> domains / companies / entities).
>
> In fact, given the Reddit C++ post, one could even think it is the
> _most_ widely used form in C++ (vs. the guard: 2.3k vs 1.2k), for
> whatever that poll is worth.
>
> The problem is that for simple projects built by one developer on their
local machine, the problem cases almost never arise, so it looks like it
works. But then that package gets released and gets built outside the
comfortable cozy environment it started with, and it doesn't.
When I end up talking to compiler vendors they tell me they have to support
#pragma once because it's common enough that it's a portability issue, but
that they can not guarantee that it actually works.
State of the art seems to be sniffing the guard pattern, and watching for
files that have it being opened with exactly the same path spelling and
avoiding reopening them. If a file evades detection by some means, for
example the path doesn't have an identical spelling, then the preprocessor
still does its job.
> > Those projects already have the form they are already using. There's
> > no need for a standards
> > committee to take an action to give them what they already have,
> > especially when what's being proposed
> > gives them something else, including a different spelling.
>
> I bet some users would complain to us that we standardized `#once ID`
> but not what they used. One way or the other, we can't win.
>
> I'm sure they would because it doesn't solve the most common complaint
about include guards, that it's hard to make sure the ID is
universally unique and doesn't get copy pasted in a refactoring.
>
Received on 2022-02-03 22:09:25