> But if both libraries are included, the second library misses out on the
already undefined symbol definitions.

This would fail with traditional include guards too, unless cleanup.h takes
extra care to handle the include guard identifier.

I think this case is worth considering, it’s similar to what is discussed
in 5.1 and 5.2. I do not think it’s a compelling argument against this
unqualified #pragma once behavior though.

Jeremy

On Tue, Aug 27, 2024 at 12:58 Sebastian Wittmeier via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> 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
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>