> The reason #include "works" even if inode numbers are reused or paths are not unique is not because including them by pathname makes it work. It's because the headers files have include guards in them,

Wrong! Unless you are modifying files as you compile. It has never happened that 2 distinct files occupy the same filepath and the compiler had to make a decision between one of them. (except maybe on a MAC, think smort… screw that platform).



From: Jonathan Wakely <cxx_at_[hidden]>
Sent: Monday, September 2, 2024 12:41 PM
To: std-proposals_at_[hidden]p.org
Cc: Ville Voutilainen <ville.voutilainen_at_[hidden]>; Tiago Freire <tmiguelf_at_[hidden]>; Tom Honermann <tom_at_[hidden]>
Subject: Re: [std-proposals] Revising #pragma once



On Mon, 2 Sept 2024 at 11:35, Tiago Freire via Std-Proposals <std-proposals_at_[hidden]<mailto:std-proposals_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.

The reason #include "works" even if inode numbers are reused or paths are not unique is not because including them by pathname makes it work. It's because the headers files have include guards in them, so they're based on the content of the file (and the last-seen state of whether the guard macro is defined at the point of inclusion). If you took all the include guards out, then most compilations would fail. The fact the files are resolved simply using a pathname doesn't affect anything.

When we're talking about preventing multiple inclusion, we need to compare to how we solve that today (header guards) not how we find which file to include (pathnames).






________________________________
From: Ville Voutilainen <ville.voutilainen_at_[hidden]<mailto:ville.voutilainen_at_[hidden]>>
Sent: Monday, September 2, 2024 12:06:28 PM
To: std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]> <std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>>
Cc: Tiago Freire <tmiguelf_at_hotmail.com<mailto:tmiguelf_at_[hidden]>>; Tom Honermann <tom_at_[hidden]<mailto:tom_at_[hidden]>>
Subject: Re: [std-proposals] Revising #pragma once

On Mon, 2 Sept 2024 at 06:24, Tiago Freire via Std-Proposals
<std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>> wrote:
>
> Don't define what system calls are needed in the standard.
> This was always going to be platform dependent.
>
> We know for sure that comparing file paths alone would do the trick. Which doesn't even require opening files, the only thing it requires is to exist to register a hit for your #include directive.
> If you need more than that to tell 2 files apart then you can't even guarantee what the "#include" directive is doing.
>
> Is anyone going to argue that "#include" directives are unimplementable?

I continue to fail to understand these arguments along the lines of
"then #include doesn't work either". An #include
has no need to tell two files apart. Could you please explain what
you're talking about here?

--
Std-Proposals mailing list
Std-Proposals_at_lists.isocpp.org<mailto:Std-Proposals_at_[hidden]>
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals