On 8/27/24 4:09 PM, Tiago Freire via Std-Proposals wrote:
>
> I’m going to be a bit ranty here.
>
> People... we are going too far of the rails. I don't think the point
> is to change current behavior, most compilers that matter already have it.
>
> The only thing that it would change if at all would be for some
> obscure compiler that does not have it to have to pick an implementation.
>
> All it has to do is to say that #pragma once precludes the #include
> directive from evaluating the file if that file is the same. That is it!
>
> Whatever that means for that system it’s an implementation detail,
> left for the compiler vendor as an exercise.
>
> Should 2 hard links to the same thing be considered "the same file",
> as far as I'm concerned, any answer you can possibly give here is a
> valid perspective, and you will never get a consensus debating this.
>
> If one compiler looks at the time to resolve a file difference and the
> other does not, as far as I am concerned, they are both standard
> compliant.
>
> It shouldn't be made a requirement that it needs to look at the time
> (it doesn’t even make sense), it may not even be a requirement that it
> may be a file in a drive or a file system.
>
> An include directive requires a "what" and a pragma once says that "if
> the *what* is *this* just skip it".
>
> I'm going to be perfectly honest with you, if you are doing things
> right, these “differences” in behavior they don’t matter at all, they
> never did.
>
> The shear volume of cross-platform projects that use pragma once
> exclusively (despite the fact that they work with different tools),
> say that it doesn’t matter. They don’t seam to mind that the behavior
> is different, like at all.
>
> I have personally never heard of a project that had “use pragma once”
> as part of the codding standard ever revert back to using “include
> guards”, while the opposite is a process that I have over-seen
> countless times.
>
> You are looking at the time of the file? Why?
>
> If your project even as much as needs to distinguish based on symbolic
> links as far as I'm concerned it has serious issues with build hygiene.
>
> You are copying files around? Why?
>
> And if your build fails as a consequence, you kind of deserve it.
> Maybe pragma once is not for you.
>
> As far as I’m concerned not being able to parse included files more
> than once should be the default behavior, because invariably, every
> single time, that’s what you want, always. I have 0 instances where
> that has ever been otherwise.
>
> I mean, I have worked with code where it had this “tricky header file”
> where you would “have to include more than once”, and the second time
> around “it was doing a tricky thing changed behavior that somebody
> thought it was smart”.
>
> It’s not smart, it’s pretentious and there’s no reason it has to work
> that way, and that is fixable. Just fix that and move on, stop making
> life harder for everyone else!
>
> We can pretend all day that all this corner cases and weird behavior
> is normal, it ain’t! If your build does that you have failed to do it
> properly!
>
> Stop wearing those foot guns!
>
> Include directives are kind of broken, I think we can all agree with
> that, it is bad as it is that I have to write WARTS (and that’s what
> they are, they are warts) on my header files just to make something
> that should have been simple work, don’t make me have to be creative
> about it.
>
> Just standardize pragma once, it ain’t perfect (perfect would be
> nothing), but at least it is less warts to deal with, and it doesn’t
> need to be complicated at all.
>
The above is highly opinionated and, in my opinion, rather disrespectful
to those with experience or requirements different from yours.

There is no technical content in the above; none of it is useful for
discussion. From a philosophical standpoint, most of that rant offers
good reasons against standardization from my perspective.

Tom.

> ------------------------------------------------------------------------
>
> *From:*Std-Proposals <std-proposals-bounces_at_[hidden]> on
> behalf of Sebastian Wittmeier via Std-Proposals
> <std-proposals_at_[hidden]>
> *Sent:* Tuesday, August 27, 2024 7:57:56 PM
> *To:* std-proposals_at_[hidden] <std-proposals_at_[hidden]>
> *Cc:* Sebastian Wittmeier <wittmeier_at_[hidden]>
> *Subject:* Re: [std-proposals] Revising #pragma once
>
> Let us make a different example, why distinguishing by file contents
> is bad:
>
> --- preprocessor_tools.h ---
>
> #pragma once
>
> #define STRINGIFY ...
>
> #define CONCAT ...
>
> --- cleanup.h ---
>
> #ifdef STRINGIFY
>
> #undef STRINGIFY
>
> #endif
>
> #ifdef CONCAT
>
> #undef CONCAT
>
> #endif
>
> --- lib1maininclude.h ---
>
> #include "a.h" // may include preprocessor_tools.h
>
> #include "b.h" // may include preprocessor_tools.h, prevented by
> #pragma once - intended!
>
> #include "cleanup.h" // do not bleed symbols
>
> A library1 and a library2 happen to use the same preprocessor_tools.h.
>
> Within each of those libraries #pragma once is used to prevent
> redefinition.
>
> But if both libraries are included, the second library misses out on
> the already undefined symbol definitions.
>
>
> -----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]> 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]>
> *Gesendet:* Di 27.08.2024 18:36
> *Betreff:* Re: [std-proposals] Revising #pragma once
> *An:* Gašper Ažman <gasper.azman_at_[hidden]>;
> *CC:* Jeremy Rifkin <rifkin.jer_at_[hidden]>;
> 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]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
>