RFR (tedious) 8216022: Use #pragma once

[Erik Österlund]

Hi David,

On 2019-01-04 17:29, David Lloyd wrote:
> On Fri, Jan 4, 2019 at 10:00 AM Erik Österlund
> <erik.osterlund at oracle.com> wrote:
>> Hotspot relies on a whole bunch of implementation defined compiler
>> features that are not standardized, that all of our compilers support to
>> work. I think that seems okay as long as all compilers are covered that
>> we build with. If we were to insist on using only completely
>> standardized features, we would have decades of work to get there, if we
>> could do it at all.
> 
> This is a weak logical argument: perhaps it's not 100% standards
> compliant, sure, but that doesn't mean that the idea of complying to
> the standard should be thrown away, or that standards compliance in a
> given situation is not a valid consideration.

Sure. But as mentioned, it's only the Cray C/C++ compiler as of today 
that doesn't support #pragma once. And if a new platform in the future 
comes along that doesn't support #pragma once, that we want to support, 
we can easily switch back with a simple script, like the one Kim pointed 
out.

> 
>> That sounds like a bug. Just because something is implementation
>> defined, doesn't make it okay or expected to not work. Do you know how
>> to reproduce this, and on which platform/compiler/version? Obviously, if
>> this was an issue in our code base, one would quickly notice it doesn't
>> build.
> 
> My understanding of the problem is that it's just a question of
> creating a header file, copying it to two locations (or having
> multiple apparent locations due to symlinking or similar), and then
> including it at both locations.  The include guard can prevent this by
> virtue of having the same macro name in both header files, whereas
> #pragma once does not prevent this as it generally seems to use the
> file path as the identity of the file.  An alternative implementation
> might hash and compare the file contents, but I strongly doubt we'd
> see such an implementation as it would be detrimental to performance
> (and also weak against small changes to the file).
> 
> Another possibility I haven't tried is to put the same file on the -I
> path *directly* more than once, and then simply #include it twice in a
> row.  A reasonable interpretation of "#pragma once" is that it
> includes the given *file* or *full file path* one time, as opposed to
> including the given *file name* one time.  "Sounds like a bug" is the
> tricky phrase here, because it's not standardized, so who is to say
> what the "correct" behavior is?  Mostly it comes down to a given
> person's subjective notion of "common sense"; if everyone had a truly
> confluent notion of common sense, then we'd only have one compiler
> implementation, and wouldn't need standards at all.  Of course, such
> "logic" doesn't hold up to the real world for one nanosecond.
> 

I tried all of these described scenarios locally. They all work fine 
with my GCC compiler, with different include paths and resolving 
symlinks. So I'm not sure what compiler/version has the bug you are 
talking about. Do you know?

Naturally, if you have two copies of a file, then of course that won't 
compile the way it would with include guards. But trying to maintain two 
exact copies of a file, and relying on include guards to always mask 
away one of the two copies, sounds like a *really* bad, and potentially 
dangerous idea, and something we should avoid at any cost. So providing 
a compiler error in such a scenario sounds much safer than allowing that 
kind of setup.

As for the argument that implementation dependent features may do 
whatever they please and hence should be avoided... that's not very 
helpful. For example, we couldn't even use reinterpret_cast without 
relying on implementation dependent features. So if we want to ride on 
our high horses and not use implementation dependent compiler features, 
we would have to rewrite HotSpot as well. In this case, if the path 
resolution was different in a strange compiler causing a file to be 
included twice, then we would simply not be able to build, and then 
decide if a conversion back is the step forward, or fixing the bug in 
that C++ compiler. It would never subtly be able to build but have 
different behaviour. So I'm not sure what the worry is here.

Thanks,
/Erik