Date: Fri, 30 Aug 2024 05:29:13 +0000
I see a very dangerous precedent here.
pragma once is already a thing, either you like it or not, you can't stop users from migrating to it because it makes their work easier.
And I often times see this argument thrown around "it doesn't work for what I'm doing, this library is not mine how do I stop them from changing".
How did it became normal that you are taking other people's work, for free, and you think you are entitled to tell other people how they should manage their projects.
And by the way nobody forced you to adopt the tools and processes that you have that caused the duplication problem.
This is not ok.
________________________________
From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of Thiago Macieira via Std-Proposals <std-proposals_at_[hidden]>
Sent: Friday, August 30, 2024 6:43:16 AM
To: std-proposals_at_[hidden] <std-proposals_at_[hidden]>; Jeremy Rifkin <rifkin.jer_at_[hidden]>
Cc: Thiago Macieira <thiago_at_[hidden]>
Subject: Re: [std-proposals] Revising #pragma once
On Thursday 29 August 2024 19:49:17 GMT-7 Jeremy Rifkin wrote:
> Well, the failure mode of a filesystem-based definition in this case
> is a header being duplicated across multiple mounts, with different
> #includes resolving to paths on different mounts, resulting in them
> being #included multiple times. Depending on how the FUSE mounts are
> set up, maybe this sort of header duplication can be avoided.
> Alternatively, e.g. in the case of libraries, a qualified include
> guard should probably be preferred. Alternatively, maybe this is a
> tooling problem and generating forwarding headers as Gašper mentioned
> is the right solution.
Anything that shifts the problem to the user or the IT admin is unacceptable
as a solution. So all I'm taking from here is "it should be avoided for
libraries".
pragma once is already a thing, either you like it or not, you can't stop users from migrating to it because it makes their work easier.
And I often times see this argument thrown around "it doesn't work for what I'm doing, this library is not mine how do I stop them from changing".
How did it became normal that you are taking other people's work, for free, and you think you are entitled to tell other people how they should manage their projects.
And by the way nobody forced you to adopt the tools and processes that you have that caused the duplication problem.
This is not ok.
________________________________
From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of Thiago Macieira via Std-Proposals <std-proposals_at_[hidden]>
Sent: Friday, August 30, 2024 6:43:16 AM
To: std-proposals_at_[hidden] <std-proposals_at_[hidden]>; Jeremy Rifkin <rifkin.jer_at_[hidden]>
Cc: Thiago Macieira <thiago_at_[hidden]>
Subject: Re: [std-proposals] Revising #pragma once
On Thursday 29 August 2024 19:49:17 GMT-7 Jeremy Rifkin wrote:
> Well, the failure mode of a filesystem-based definition in this case
> is a header being duplicated across multiple mounts, with different
> #includes resolving to paths on different mounts, resulting in them
> being #included multiple times. Depending on how the FUSE mounts are
> set up, maybe this sort of header duplication can be avoided.
> Alternatively, e.g. in the case of libraries, a qualified include
> guard should probably be preferred. Alternatively, maybe this is a
> tooling problem and generating forwarding headers as Gašper mentioned
> is the right solution.
Anything that shifts the problem to the user or the IT admin is unacceptable
as a solution. So all I'm taking from here is "it should be avoided for
libraries".
-- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Principal Engineer - Intel DCAI Platform & System Engineering -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
Received on 2024-08-30 05:29:17