On Fri, 30 Aug 2024, 00:12 Jeremy Rifkin, <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]> wrote:
>
>>
>>
>> On Tue, 27 Aug 2024, 17:47 Tiago Freire via Std-Proposals, <
>> 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]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
>