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