Re: #pragma once behavior

ecause constant search configuration relative identity sounds better. as they could be defined to be different identities wrt #pragma once. it's the semantically safer option. and the canonical example that fails (same content, different path, same mtime) would succeed with this choice. pick ho

Re: #pragma once behavior

Hi, > IIRC it’s already deprecated It appears it was undeprecated in 2003. > What can pragma once do that include guards can‘t? What’s the issue > to solve? Include guard collisions? There is nothing #pragma once does that include guards can't. The reason people turn to it is b

Re: #pragma once behavior

; > I don't have a good answer for such a case. Of course, no matter how one > > approaches #pragma once there will be cases that aren't handled. > > > > The criteria to optimize for, imo, is which has the most clear failure > > mode. Contents happening match c

Re: #pragma once behavior

> Am 07.09.2024 um 07:27 schrieb Jeremy Rifkin : > >  >> >> This is why I said what is the a same file if you can't rely on inodes >> working? > > I don't have a good answer for such a case. Of course, no matter how one > approaches #pragm

Re: #pragma once behavior

> This is why I said what is the a same file if you can't rely on inodes > working?  I don't have a good answer for such a case. Of course, no matter how one approaches #pragma once there will be cases that aren't handled. The criteria to optimize for, imo, is which has t

Re: #pragma once behavior

ndif (and > > that is documented here: > > https://gcc.gnu.org/onlinedocs/cppinternals/Guard-Macros.html) so does > > it make sense to really standardize `#pramga once` here or just push > > other implementations to add a similar optimization instead? > > > > Thanks, > > A

Re: #pragma once behavior

ad? > > Thanks, > Andrew Pinski > >> >> Cheers, >> Jeremy >> >> On Sep 6 2024, at 12:25 am, Andrew Pinski wrote: >> >> > On Thu, Sep 5, 2024 at 10:04 PM Jeremy Rifkin wrote: >> >> >> >> Hello, >> >&

Re: #pragma once behavior

emy On Sep 6 2024, at 8:26 am, Ben Boeckel wrote: > On Fri, Sep 06, 2024 at 00:03:23 -0500, Jeremy Rifkin wrote: >> Hello, >> >> I'm looking at #pragma once behavior among the major C/C++ compilers as >> part of a proposal paper for standardizing #pragma once. (Thi

Re: #pragma once behavior

2:25 am, Andrew Pinski wrote: > > > On Thu, Sep 5, 2024 at 10:04 PM Jeremy Rifkin wrote: > >> > >> Hello, > >> > >> I'm looking at #pragma once behavior among the major C/C++ compilers as > >> part of a proposal paper for standardizi

Re: #pragma once behavior

o approach this with a focused paper on just providing a clear set of mechanics for #pragma once. I do recognize the uphill battle and legitimate concern about "blessing" an unreliable feature. My thesis is that #pragma once is unreliable today because every implementation approaches it

Re: #pragma once behavior

fickleness of mtime? Cheers, Jeremy On Sep 6 2024, at 12:25 am, Andrew Pinski wrote: > On Thu, Sep 5, 2024 at 10:04 PM Jeremy Rifkin wrote: >> >> Hello, >> >> I'm looking at #pragma once behavior among the major C/C++ compilers as >> part of a proposa

Re: #pragma once behavior

On Fri, Sep 06, 2024 at 00:03:23 -0500, Jeremy Rifkin wrote: > Hello, > > I'm looking at #pragma once behavior among the major C/C++ compilers as > part of a proposal paper for standardizing #pragma once. (This is > apparently a very controversial topic) > > To put m

Re: #pragma once behavior

m was that the regular form is not reliable and difficult to standardize any specific rules and that the form with ID does not add much value over traditional include guards. Martin Am Freitag, dem 06.09.2024 um 00:03 -0500 schrieb Jeremy Rifkin: > Hello, > > I'm looking at #p

Re: #pragma once behavior

On Thu, Sep 5, 2024 at 10:04 PM Jeremy Rifkin wrote: > > Hello, > > I'm looking at #pragma once behavior among the major C/C++ compilers as > part of a proposal paper for standardizing #pragma once. (This is > apparently a very controversial topic) > > To put my ques

#pragma once behavior

Hello, I'm looking at #pragma once behavior among the major C/C++ compilers as part of a proposal paper for standardizing #pragma once. (This is apparently a very controversial topic) To put my question up-front: Would GCC ever be open to altering its #pragma once behavior to bring it mo

Re: #pragma once

Drgt <[EMAIL PROTECTED]> writes: > It seems, that "#pragma once" isn't in ISO, and will never be, especially > because it is Microsoft (am I right ?) C extension. > (http://gcc.gnu.org/ml/gcc/2004-06/msg01887.html) I believe that gcc was actually the first compi

Re: #pragma once

On Sun, 2006-08-13 at 19:48 +0300, Drgt wrote: > Hi. > > It seems, that "#pragma once" isn't in ISO, and will never be, especially > because it is Microsoft (am I right ?) C extension. > (http://gcc.gnu.org/ml/gcc/2004-06/msg01887.html) #pragma once has not been re

Re: #pragma once

Drgt wrote: Hi. It seems, that "#pragma once" isn't in ISO, and will never be, especially because it is Microsoft (am I right ?) C extension. Why not implement it yourself and propose a patch.

#pragma once

Hi. It seems, that "#pragma once" isn't in ISO, and will never be, especially because it is Microsoft (am I right ?) C extension. (http://gcc.gnu.org/ml/gcc/2004-06/msg01887.html) But I still asking GCC developers, that this simple-in-use thing would be in GCC, and you not "