Re: #pragma once behavior

I like the sound of resolved path identity from search, including the constructed full path and the index within include paths. if I was writing a compiler from scratch, i'd problem do something like this: SHA2(include-path-search-offset-integer-of-found-header-to-support-include-next) + SHA2

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 because: - It's

Re: #pragma once behavior

On Sat, Sep 7, 2024 at 5:34 AM Richard Biener via Gcc wrote: > > > > > 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 h

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 #pragma once there will be cases that aren't handled. >

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 the most clear failure mo

Re: #pragma once behavior

On Fri, Sep 6, 2024, 7:42 PM Jeremy Rifkin wrote: > Hi Andrew, > Thanks for the thoughts and quick reply. > > > Not always. because inodes are not always stable on some file systems. > > And also does not work with multi-mounted devices too. > > Unusual filesystems and multiple mounts are indeed

Re: #pragma once behavior

Hi Andrew, Thanks for the thoughts and quick reply. > Not always. because inodes are not always stable on some file systems. > And also does not work with multi-mounted devices too. Unusual filesystems and multiple mounts are indeed the failing. As I mentioned, there's no silver bullet; they each

Re: #pragma once behavior

> Could a "uses the relative search path" fact be used to mix into the > file's identity? This way the `once` key would see "this content looked > for things in directory `library_a`" and would see that > `library_b/library_main.hpp`, despite the same content (and mtime) is > actually a different c

Re: #pragma once behavior

On Fri, Sep 6, 2024 at 5:49 PM Jeremy Rifkin wrote: > > Thanks Andrew, I appreciate the context and links. It looks like the > prior implementation failed to handle links due to being based on file > path, given cpp_simplify_pathname. Do you have thoughts on the use if > device ID + inode as a way

Re: #pragma once behavior

Thanks Martin, There's some context on N2896 in the meeting minutes: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2941.pdf I think the key thing about N2896 is that it left unqualified #once implementation-defined, which is no better than the current state of affairs. I'm trying to approach

Re: #pragma once behavior

Thanks Andrew, I appreciate the context and links. It looks like the prior implementation failed to handle links due to being based on file path, given cpp_simplify_pathname. Do you have thoughts on the use if device ID + inode as a way to also accommodate symbolic links and hard links without the

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 my question up-front: Would GCC

Re: #pragma once behavior

There was a recent related proposal for C23. https://www9.open-std.org/JTC1/SC22/WG14/www/docs/n2896.htm See also the email by Linus Torvalds referenced in this paper. Note that this proposal was not adopted for ISO C23. I can't find when it was discussed, but IIRC the general criticism was t

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 question up-front: Would GCC ever b

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 compiler to implement "#pragma once". I

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 removed and in fact the opposite h

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.