Date: Fri, 30 Aug 2024 05:01:32 +0000
There's no misunderstanding.
I've also referred to "copies" (which was dropped).
Several mount points that don't resolve to the same inode as far as I see it, they work effectively as different copies of the same file.
The issue doesn't change. It's a failure to curate the environment that the compiler sees.
It still requires the presence of an include tree that hits different copies of the same file, why are they not hitting the same copy? Why are all include paths not hitting the same mount point?
As far as I see it, this issue is no different than defining the same class in 2 different headers. It's an ODR violation. The only difference here is at the include level.
At what point do we consider this to be user error?
I find it weird that you duplicate stuff (instead of deduplicating) and be surprised "omg my compiler is seeing double, this doesn't work.."
________________________________
From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of Jonathan Wakely via Std-Proposals <std-proposals_at_[hidden]>
Sent: Friday, August 30, 2024 1:23:28 AM
To: Jeremy Rifkin <rifkin.jer_at_[hidden]>
Cc: Jonathan Wakely <cxx_at_[hidden]>; C++ Proposals <std-proposals_at_[hidden]>
Subject: Re: [std-proposals] Revising #pragma once
On Fri, 30 Aug 2024, 00:12 Jeremy Rifkin, <rifkin.jer_at_[hidden]<mailto:rifkin.jer_at_[hidden]>> wrote:
I’m not sure they’re trivial to deal with, at least in a way that could be standardized. While it's defined source code lives in files, the concept of a path/filesystem is not defined outside the stdlib. Maybe this could be worded along the lines of if a filesystem exists, #pragma once behaves as if by std::filesystem::equivalent, otherwise implementation defined. But "filesystem" would need to be defined.
I'm not talking about specifying it. I'm saying that determining whether a file foo and a symlink that resolves to foo are "the same" is very easy. And likewise, two hard links are very easy to identify as "the same".
The hard problems people have brought up involve a file being mounted at two different locations, where the paths are distinct and the device IDs or inode numbers are distinct.
Describing the hard problems in terms of symlinks and hard links suggests a failure to understand the actual problem.
Jeremy
On Thu, Aug 29, 2024 at 17:25 Jonathan Wakely via Std-Proposals <std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>> wrote:
On Tue, 27 Aug 2024, 17:47 Tiago Freire via Std-Proposals, <std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>> wrote:
I agree that pragma once should mean same file and not file with same bits.
But I disagree on everything else.
I used pragma once exclusively on all my libraries quite successfully, they are well organized and no such confusion could occur by design, "as a well orchestrated build should".
If you are in a situation where this causes problems, either by having multiple copies of the same library or by using symbolic or hard links, and they all end up on the same include stack. Well... then don't do that then! Seems like a you problem.
More than once you've talked about problems caused by hard links and symbolic links being user error. That makes me think your don't actually understand the issues, because hard links and symbolic links are trivial to deal with here. Those aren't the problems people are worried about.
I've also referred to "copies" (which was dropped).
Several mount points that don't resolve to the same inode as far as I see it, they work effectively as different copies of the same file.
The issue doesn't change. It's a failure to curate the environment that the compiler sees.
It still requires the presence of an include tree that hits different copies of the same file, why are they not hitting the same copy? Why are all include paths not hitting the same mount point?
As far as I see it, this issue is no different than defining the same class in 2 different headers. It's an ODR violation. The only difference here is at the include level.
At what point do we consider this to be user error?
I find it weird that you duplicate stuff (instead of deduplicating) and be surprised "omg my compiler is seeing double, this doesn't work.."
________________________________
From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of Jonathan Wakely via Std-Proposals <std-proposals_at_[hidden]>
Sent: Friday, August 30, 2024 1:23:28 AM
To: Jeremy Rifkin <rifkin.jer_at_[hidden]>
Cc: Jonathan Wakely <cxx_at_[hidden]>; C++ Proposals <std-proposals_at_[hidden]>
Subject: Re: [std-proposals] Revising #pragma once
On Fri, 30 Aug 2024, 00:12 Jeremy Rifkin, <rifkin.jer_at_[hidden]<mailto:rifkin.jer_at_[hidden]>> wrote:
I’m not sure they’re trivial to deal with, at least in a way that could be standardized. While it's defined source code lives in files, the concept of a path/filesystem is not defined outside the stdlib. Maybe this could be worded along the lines of if a filesystem exists, #pragma once behaves as if by std::filesystem::equivalent, otherwise implementation defined. But "filesystem" would need to be defined.
I'm not talking about specifying it. I'm saying that determining whether a file foo and a symlink that resolves to foo are "the same" is very easy. And likewise, two hard links are very easy to identify as "the same".
The hard problems people have brought up involve a file being mounted at two different locations, where the paths are distinct and the device IDs or inode numbers are distinct.
Describing the hard problems in terms of symlinks and hard links suggests a failure to understand the actual problem.
Jeremy
On Thu, Aug 29, 2024 at 17:25 Jonathan Wakely via Std-Proposals <std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>> wrote:
On Tue, 27 Aug 2024, 17:47 Tiago Freire via Std-Proposals, <std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>> wrote:
I agree that pragma once should mean same file and not file with same bits.
But I disagree on everything else.
I used pragma once exclusively on all my libraries quite successfully, they are well organized and no such confusion could occur by design, "as a well orchestrated build should".
If you are in a situation where this causes problems, either by having multiple copies of the same library or by using symbolic or hard links, and they all end up on the same include stack. Well... then don't do that then! Seems like a you problem.
More than once you've talked about problems caused by hard links and symbolic links being user error. That makes me think your don't actually understand the issues, because hard links and symbolic links are trivial to deal with here. Those aren't the problems people are worried about.
-- Std-Proposals mailing list Std-Proposals_at_[hidden]<mailto:Std-Proposals_at_[hidden]> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
Received on 2024-08-30 05:01:39