RFR (tedious) 8216022: Use #pragma once
Erik Österlund
erik.osterlund at oracle.com
Thu Jan 3 19:26:12 UTC 2019
On 2019-01-03 19:39, Andrew Haley wrote:
> On 1/3/19 3:50 PM, Erik Österlund wrote:
>
>> I think the value of moving to #pragma once instead of using include
>> guards is that it is easy to mess up include guards. Admittedly, at
>> least I tend to get them wrong quite often, and every time I get
>> annoyed that we don't use #pragma once
>
>
>> ... Might be exaggerating a bit... but still.
>
> Maybe. :-)
>
> But seriously, how often do you actually have to create a new header
> file, or even edit the part of a header file that touched the include
> guards? The reason this bug hasn't got much love at GCC is that over
> there nobody (including, until today, me) could ever see the point of
> include guards. It seems to me that they are a rather fragile way of
> fixing a nonexistent problem.
It happens quite a lot actually. For example, it looks like there are
currently 126 barrier set files, of which 67 are header files. I had
something to do with most of them. I will never forget the include guard
horrors when *BarrierSetAssembler was renamed.
Sometimes I think the include guard horrors make us grow files too
large, because of that extra overhead of creating a new file. Same goes
for renaming or moving files that obviously have the wrong name or are
in the wrong directory, like memory/heap.hpp, that should arguably be
code/codeHeap.hpp.
Not to talk about when the "vm" directory was dropped. We are still
living in the aftermath of that, and include guards now inconsistently
sometimes have the VM_ prefix and sometimes not depending on how old the
file is and how the author of new files since then have thought about
it. Did they want to blend in with the old (wrong) prefix, or use the
correct prefix? Or when the gc_interface/gc_implementation directories
were removed, making all GC files move. Ouch.
> But hey, if it's really important to you, go ahead. This issue isn't
> something I'm prepared to go to the barricades for.
>
Okay, thanks Andrew!
/Erik
More information about the hotspot-dev
mailing list