On 2025-03-24 at 11:58, Filip via Std-Proposals wrote:
> Just a thought, but could it work by checking only the file name? Files
> that we want to include have mostly unique names, and completely unique
> when the path to them is fully defined.
> It could compute a hash or something and under the hood use some include
> guards.

There is still the problem that not all file systems have paths, and
that the string used in #include doesn't have to be the name of a file.
In my z/OS example, again, type_traits and initializer_list are invalid
file names (so the actual file has some other implementation-defined name).

And the source file might be in EBCDIC, and not UTF-8. :-)

Even if you were able to define what "the same file" means for all file
systems mounts on every operating system, would we then require all
compiler developers to have a complete set for testing?


>
> Cheers, Filip
>
>> Wiadomość napisana przez Simon Schröder via Std-Proposals <std-
>> proposals_at_[hidden]> w dniu 24 mar 2025, o godz. 11:48:
>>
>> 
>>
>> On Mon, Mar 24, 2025 at 11:20 AM Filip via Std-Proposals <std-
>> proposals_at_[hidden] <mailto:std-proposals_at_[hidden]>> wrote:
>>
>>
>> P.S.
>> Maybe worth mentioning is the fact that I never want to include a
>> file more than once.
>>
>>
>> I do occasionally use X-macros that only work with repeated includes.
>> Also, Boost has some weird macro stuff that relies on it. But, you are
>> right that 99.99% of the time I just want to include the header once.
>>
>>
>> P.S.S.
>> Should we not standardize include once since we have a non
>> standard option available everywhere?
>> Shouldn’t we standardize everything that’s useful and thus lower
>> the chance for bugs?
>>
>> If we have a good solution I'd agree. Just standardizing how #pragma
>> once currently works just with a different keyword is slightly
>> different. Yes, it is useful and yes, it generally lowers the chance
>> for bugs. However, the implementations themselves have (incompatible)
>> "bugs" in the sense that it will not always work. If you run into this
>> problem there is no way to fix it yourself (especially when it occurs
>> because of 3rd party libraries). So, if this feature will be
>> standardized, it needs to be better than #pragma once and it needs to
>> work 100% of the time. Nobody has solved this problem so far, so I'd
>> rather advocate for keeping the status quo. (I personally don't trust
>> #pragma once and always use include guards. I also spend less than 1%
>> of my time writing include guards. Chance of undetected bugs in
>> include guards is really low (copy'n'paste???).)
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>