RFR (tedious) 8216022: Use #pragma once

[David Lloyd]

On Fri, Jan 4, 2019 at 7:20 AM Andrew Haley <aph at redhat.com> wrote:
> On 1/4/19 11:07 AM, Florian Weimer wrote:
> > The guards occasionally cause bugs because they are not globally unique
> > or not spelled correctly in both places in the header file.
>
> Yeah, I know. That's the usual non-performance-related pro-#pragma
> once argument. After GCC and a bunch of other compilers implemented
> optimized include guards I thought that #pragma once would go away,
> but evidently not.  :-)

Not a reviewer, but...

The whole thing is starting to seem like a really bad idea to me.
I've been asking around and I can't find anyone who thinks this kind
of change is a good idea; while this clearly isn't a scientific poll,
it does not on the other hand raise my confidence any.  It was pointed
out to me that the GCC documentation has been recommending against
this practice perhaps as early as 3.4.

It boils down to this: #pragma once isn't standardized; there's simply
no guarantee it will be supported on a given compiler.  This problem
seems *far* more significant to me than the risk of forgetting to
update a macro name here or there (something that can be caught on
code review), on the occasion that a header file is renamed or
relocated such that it requires a change (and how often is this likely
to happen anyway?).

In addition, it was pointed out to me that if, for some reason, a
header file ends up in more than one location on the include path,
#pragma once will (probably, as it's not standardized) allow it to be
included twice, which #ifdef guards avoid.  This is perhaps not a real
concern in this particular code base though.

In the end though this is an example of the kind of change that I for
one would never allow in one of my projects: it's large, potentially
impacts portability, and yet in the end it's not really necessary,
being really just a style issue when it comes right down to it.
Include guards are standard and portable.  '#pragma once' is not.

-- 
- DML