Just a simple thought why the file name is not as easy as it sounds. First
idea: just take the file name (but no path to the file). Every library
might have something like config.h. So, this would not work. We could just
take the paths as mentioned in the #includes: e.g. I include
boost/config.h. However, within the boost library the include is just
config.h without the preceding boost/ . This also doesn't work. We might
use the absolute path to the header. But, users might use symbolic links in
the absolute path. You could, theoretically compute a hash for the file.
But, the compiler does not know when the file has changed the last time and
needs to recompute it every time. For this, the compiler reads the full
file. In the same way the compiler can also just look for the include guard
at the first two lines (or right after some comments at the beginning of
the file). After that it just has to make sure that #ifdef's and #endif's
are balanced. No other parsing is necessary. And compilers already do some
similar optimizations. We don't gain anything in performance and would just
hope we gain something in usability.

On Mon, Mar 24, 2025 at 11:58 AM Filip <fph2137_at_[hidden]> 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.
>
> 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]> 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
>
>