patha/definealla.h and pathb/defineallb.h have the same content in the example (no byte is different). And could even have the exact same timestamp.   Some file systems could even store them just once (deduplication, copy-on-write), although they may belong to different libraries and declare names in different namespaces.   If you say that #pragma once is the wrong tool for those cases, then you deviate from the current behavior. I do not think that gcc goes so far at the moment (ignoring not only path, but header file name).   a) is #pragma once the right name, if it changes behavior to established practice b) using file contents even between different file names and directories is very dangerous for subtle bugs and interdependencies. Should this in this case be allowed at all into the standard.     -----Ursprüngliche Nachricht----- Von:Jeremy Rifkin <rifkin.jer_at_[hidden]> Gesendet:Di 27.08.2024 19:08 Betreff:Re: [std-proposals] Revising #pragma once An:std-proposals_at_[hidden]; CC:Sebastian Wittmeier <wittmeier_at_[hidden]>; > I.e. a.h could prevent b.h from being included? Or patha/a.h couild prevent pathb/b.h?  Correct, it can. While this may feel weird initially, it is true to the concept of single inclusion.  > That could lead to interdependencies between different libraries.  I don’t immediately see how. I might be missing something though.  > There are some preprocessor tricks, where you define macros and then include files, which use the defined macros.  Such cases, relying on multiple inclusion, would have to mot use #pragma once/traditional include guards.  >  But as patha/definealla.h and pathb/defineallb.h are the same They are at least one byte different in your example (A vs B).  Cheers, Jeremy   On Tue, Aug 27, 2024 at 11:47 Sebastian Wittmeier via Std-Proposals <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]> > wrote: So the proposed #pragma once would only care for file contents, not for path or filename? I.e. a.h could prevent b.h from being included? Or patha/a.h couild prevent pathb/b.h?   That could lead to interdependencies between different libraries.   There are some preprocessor tricks, where you define macros and then include files, which use the defined macros. Some of the include files could accidentally (e.g. taken from the same original source) be the same between different projects.     E.g. (simple example)   ------------- patha/definealla.h and pathb/defineallb.h ------------- #pragma once   #define basename A #include "usebasename.h" #undef basename   #define basename B #include "usebasename.h"     #undef basename   ---------------------------------------------------------------------------------------   patha/usebasename.h and pathb/usebasename.h would be different depending on the needs of libarary a and library b. But as patha/definealla.h and pathb/defineallb.h are the same and both use #pragma once, the latter would not be included, although they have differents paths and different names!           -----Ursprüngliche Nachricht----- Von:Jeremy Rifkin via Std-Proposals <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]> > Gesendet:Di 27.08.2024 18:36 Betreff:Re: [std-proposals] Revising #pragma once An:Gašper Ažman <gasper.azman_at_[hidden] <mailto:gasper.azman_at_[hidden]> >; CC:Jeremy Rifkin <rifkin.jer_at_[hidden] <mailto:rifkin.jer_at_[hidden]> >; std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]> ; This paper proposes #pragma once mean don’t #include the same contents again. Unlike GCC which will perform multiple inclusion if mtime differs. This paper leaves open the possibility of implementations doing their own fast path checks of inode, stat, etc., but ultimately the file contents are what matter.  Jeremy -- Std-Proposals mailing list Std-Proposals_at_[hidden] <mailto:Std-Proposals_at_[hidden]> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals