Date: Fri, 30 Aug 2024 05:15:31 +0300
On Fri, 30 Aug 2024 at 02:29, Jeremy Rifkin via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> > #include "library2/public.hpp" # boom, library2/utils.hpp does not get included
>
> This has already been presented. While I have shared I think this is
> rare and such a "main header" should not use include guards in the
> first place, it is compelling.
>
> In case it's not already abundantly clear: A content-based definition
> is the only way to make #pragma once work for a setup like yours with
> multiple mounts. But perhaps such a feature shouldn't bend over
> backwards to support such a case.
Except content-based definition doesn't make it work for a setup like
Gasper's, because
it will slow down the builds compared to using include guards. And it
breaks users who don't
even have multiple mounts. So the proposed content-based definition
doesn't solve the problems
people already have, and it introduces problems for other people too.
That doesn't sound viable.
<std-proposals_at_[hidden]> wrote:
>
> > #include "library2/public.hpp" # boom, library2/utils.hpp does not get included
>
> This has already been presented. While I have shared I think this is
> rare and such a "main header" should not use include guards in the
> first place, it is compelling.
>
> In case it's not already abundantly clear: A content-based definition
> is the only way to make #pragma once work for a setup like yours with
> multiple mounts. But perhaps such a feature shouldn't bend over
> backwards to support such a case.
Except content-based definition doesn't make it work for a setup like
Gasper's, because
it will slow down the builds compared to using include guards. And it
breaks users who don't
even have multiple mounts. So the proposed content-based definition
doesn't solve the problems
people already have, and it introduces problems for other people too.
That doesn't sound viable.
Received on 2024-08-30 02:15:46