C++ Logo

std-proposals

Advanced search

Re: [std-proposals] Revising #pragma once

From: Ville Voutilainen <ville.voutilainen_at_[hidden]>
Date: Mon, 2 Sep 2024 00:22:55 +0300
On Mon, 2 Sept 2024 at 00:14, Henry Miller via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
>
>
> -
> On Sun, Sep 1, 2024, at 12:24, Tiago Freire via Std-Proposals wrote:
> > Hence you don't specify it. If stat'ing or <insert function name here>
> > returns the same information for what are different files, then <insert
> > function name here> is not the way to distinguish different files.
> > Submit a bug report and fix that implementation for that platform.
> >
>
> It will be closed WON'T FIX. the iso standards comittee does not have the ability to force this issue. Best case they will do a ten year transisition and so you a looking at, C++37 before this works. we are talking about this because modules are taking longer than hoped in the real world but I it seems likely they will be universal before then.

One would think such bug reports will just be closed as invalid. Those
functions do what they're supposed to do. Their design intent
isn't to make #pragma once work.

That's the insurmountable problem with standardizing something like
#pragma once. Its proponents seem to suggest a portable facility
for detecting "it's the same file" exists. It doesn't. Such a 'simple'
facility is nowhere to be found as a portable mechanism, and that
speaks
volumes; the problem is hard and complicated, and there are various
trade-offs that can be chosen to build it from underlying mechanisms.
Just slapping one set of trade-offs onto a newly standardized facility
that then works differently from some of the existing practice is
technically
doable, but why should we spend energy fiddling with facilities
related to textual inclusion, when we have little to no evidence of
there being
an actual need for it, nor that a particular trade-off is better than others?

Received on 2024-09-01 21:23:11