C++ Logo

std-proposals

Advanced search

Re: [std-proposals] Revising #pragma once

From: Tiago Freire <tmiguelf_at_[hidden]>
Date: Tue, 27 Aug 2024 16:45:50 +0000
I agree that pragma once should mean same file and not file with same bits.

But I disagree on everything else.
I used pragma once exclusively on all my libraries quite successfully, they are well organized and no such confusion could occur by design, "as a well orchestrated build should".

If you are in a situation where this causes problems, either by having multiple copies of the same library or by using symbolic or hard links, and they all end up on the same include stack. Well... then don't do that then! Seems like a you problem.
I'm not trying to dunk on a "serious project" with a "quite amateurish build execution", I'm pretty sure there are legacy reasons as to why your project ended up in this awkward situation, my advice is just don't use it for your project then.

There's no reason why everyone else has to code like its 1990 just because your project got problems.


My 2c

________________________________
From: Gašper Ažman <gasper.azman_at_[hidden]>
Sent: Tuesday, August 27, 2024 5:34:42 PM
To: std-proposals_at_[hidden] <std-proposals_at_[hidden]>
Cc: Tiago Freire <tmiguelf_at_[hidden]>
Subject: Re: [std-proposals] Revising #pragma once

#pragma once is unimplementable.

That's because it doesn't mean "don't include a file with the same bytes", it means "don't include the same file". And the second you have the same file accessible through two separate fuse mountpoints, no amount of stat() will help you identify it's the same file.

We hit this in our build-farms all the time, I had to write tooling to kill it.

Don't make me explain this in-committee, again.

On Tue, Aug 27, 2024 at 4:32 PM Tiago Freire via Std-Proposals <std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>> wrote:
I like pragma once, should be standardized, but the problem is in the details of the wording.

I know that the paper acknowledges that some compiler issues a warning if they appear in the source file, and that the paper doesn't advocate for the warning either way. But the note seems to suggest otherwise.
It would be best if the standard had no notion of what a source file is, and you should remove the note that a compiler could issue a warning, let that just be a vendor detail.

The description of how the directive should behave isn't the best, describing in in terms of an ifdef block is not good.


________________________________
From: Std-Proposals <std-proposals-bounces_at_[hidden]<mailto:std-proposals-bounces_at_[hidden]>> on behalf of Jeremy Rifkin via Std-Proposals <std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>>
Sent: Tuesday, August 27, 2024 4:01:08 PM
To: Jeremy Rifkin via Std-Proposals <std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>>
Cc: Jeremy Rifkin <rifkin.jer_at_[hidden]<mailto:rifkin.jer_at_[hidden]>>
Subject: [std-proposals] Revising #pragma once

Hi,
I have drafted a proposal for standardizing #pragma once. This has been previously proposed a few years ago and I recognize that on top of being difficult to standardize, existing opinions on this topic may render the paper dead on arrival. However, due to its widespread nature and concerns about portability contributing to it not being used more I think it's worth revisiting. I have uploaded the first draft at: https://jeremy-rifkin.github.io/cpp-proposals/drafts/pragma-once-draft-1.html.

Cheers,
Jeremy
--
Std-Proposals mailing list
Std-Proposals_at_[hidden]<mailto:Std-Proposals_at_lists.isocpp.org>
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals

Received on 2024-08-27 16:45:54