Date: Mon, 2 Sep 2024 15:03:34 +0300
On Mon, 2 Sept 2024 at 13:34, Tiago Freire <tmiguelf_at_[hidden]> wrote:
>
> > An #include has no need to tell two files apart. Could you please explain what you're talking about here?
>
> It needs to find a file, not just any file, it needs to find a specific file. Which has an identity, it doesn't go about looking at inodes to figure if the file I specified is the one I actually intended.
> You don't go about "hey what happens if network files recycle inodes, include doesn't work".
> That include files work based of file paths alone is not a cause for confusion, and so shouldn't pragma once.
Well, Jonathan and Gasper covered most of this. That explanation or
the comparisons in it don't make any
sense. Sure, an #include "foo.h" won't open a "randomlychosen.txt".
But other than that, yes, it opens whichever
file the include paths at that point point to, so it might not be the
same "foo.h" everywhere. And that's just fine.
Include guards will prevent 99% of mishaps.
#pragma once is not like that *at all*. When it is encountered in a
header, we don't just look at whatever files relevant
to that build context, we look at previously-opened files, and try to
match exactly them for sameness, which is a definition
with different trade-offs.
I don't get how this "is not a cause for confusion". Yeah, there's
nothing confusing as such about a case where a header
is included multiple times due to a failing pragmaonce match, your
code just doesn't compile. But the reasons for that are
rather inexplicable. And the cases where a pragmaonce failing in the
other direction causes files not to be included
are more inexplicable still; look at Tom's horror story for splendid
example of that.
Cool, don't look at inodes, don't look at mtimes, don't look at
anything. The end result is more failing builds, for users other than
you. No vendor is going to ship that sort of crap, and none of them
are going to speak in favor of standardizing such a beast.
And neither are any people who are aware of and have sympathy for the
use cases that don't work with it. A relatively safe
prediction is that that's enough people to sink the proposal.
>
> > An #include has no need to tell two files apart. Could you please explain what you're talking about here?
>
> It needs to find a file, not just any file, it needs to find a specific file. Which has an identity, it doesn't go about looking at inodes to figure if the file I specified is the one I actually intended.
> You don't go about "hey what happens if network files recycle inodes, include doesn't work".
> That include files work based of file paths alone is not a cause for confusion, and so shouldn't pragma once.
Well, Jonathan and Gasper covered most of this. That explanation or
the comparisons in it don't make any
sense. Sure, an #include "foo.h" won't open a "randomlychosen.txt".
But other than that, yes, it opens whichever
file the include paths at that point point to, so it might not be the
same "foo.h" everywhere. And that's just fine.
Include guards will prevent 99% of mishaps.
#pragma once is not like that *at all*. When it is encountered in a
header, we don't just look at whatever files relevant
to that build context, we look at previously-opened files, and try to
match exactly them for sameness, which is a definition
with different trade-offs.
I don't get how this "is not a cause for confusion". Yeah, there's
nothing confusing as such about a case where a header
is included multiple times due to a failing pragmaonce match, your
code just doesn't compile. But the reasons for that are
rather inexplicable. And the cases where a pragmaonce failing in the
other direction causes files not to be included
are more inexplicable still; look at Tom's horror story for splendid
example of that.
Cool, don't look at inodes, don't look at mtimes, don't look at
anything. The end result is more failing builds, for users other than
you. No vendor is going to ship that sort of crap, and none of them
are going to speak in favor of standardizing such a beast.
And neither are any people who are aware of and have sympathy for the
use cases that don't work with it. A relatively safe
prediction is that that's enough people to sink the proposal.
Received on 2024-09-02 12:03:49