RFR (tedious) 8216022: Use #pragma once

[Erik Österlund]

Hi Dmitry,

On 2019-01-08 15:28, Dmitry Samersoff wrote:
> On 05.01.2019 14:31, Andrew Haley wrote:
>
> My $.2
>
>> It's that the question of "is this the same
>> file?" is extremely difficult to answer definitively.
> I'm second to Andrew with this concern and I trust a human more than a
> compiler here.
>
> Human mistake could be recognized and fixed easily, at the cost of
> simple python script to verify guards at worst.
>
> But if the compiler makes the wrong decision to include/not include a
> file, then the problem will cost a fortune to resolve.

Compilers are deterministic, humans or not. If a compiler implementation 
of #pragma once is broken, that would not go unnoticed. The build will 
deterministically not build due to duplicate definitions of whatever is 
in that header. You would never be able to finish building but with 
weird bugs introduced.

> In addition, the ability to manually define macros to enforce a specific
> order of inclusion is sometimes very useful.

I'm not sure what you mean by this.
1) Include guards vs pragma once has nothing to do with the include 
order. It's just different ways of folding the file contents after 
duplicated inclusions.
2) You can't perform #include in macros - that is not allowed by the 
preprocessor. You can only use macros to generate the string of your 
include, such has how we include OS specific headers, but not use macros 
to generate #includes, that are evaluated.
3) If you depend on the order of includes, your code is very shady and 
needs fixing.

/Erik

> -Dmitry
>
>> On 1/4/19 3:59 PM, Erik Österlund wrote:
>>
>>> On 2019-01-04 15:59, David Lloyd wrote:
>>>> 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.
>>> 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.
>> It's not a bug, exactly. It's that the question of "is this the same
>> file?" is extremely difficult to answer definitively. Not all
>> filesystems give you a reliable way to answer that question. Sure, you
>> can kludge around the problem with modification times and maybe even a
>> collision-free hash, but getting it really correct is not going to be
>> efficient, and not even possible until that question is rigorously
>> defined. There's a good reason why #pragma once still isn't standard.
>>