[Development] Using '#pragma once' instead of include guards?

[Thiago Macieira]

On Tuesday, 11 October 2022 12:31:36 PDT Alejandro Exojo wrote:
> I suggest that you don't look at the implementation of things like
> Q_OFFSETOF, then. ;-)
> 
> // This macro can be used to calculate member offsets for types with a non
> standard layout. // It uses the fact that offsetof() is allowed to support
> those types since C++17 as an optional // feature. All our compilers do
> support this, but some issue a warning, so we wrap the offsetof() // call
> in a macro that disables the compiler warning.

And we had a lengthy discussion on whether it was acceptable to use offsetof 
and such like in our public headers. It was touch and go for a while.

But as the comment you quoted says, offsetof() on non-stdlayout types is 
recognised by the standard explicitly. It's not required, but the standard 
says it's permitted.

The pragma, on the other hand...

> Same example. The comment on Q_OFFSETOF hints that C++17 seems to allow for
> optional implementations to go beyond what the standard specifies. Why is
> not standardized then? I think the same could be said about this pragma.
> What it does is conceptually very simple, and if it only can hurt on very
> corner cases, then it's a matter of weighting the tradeoffs.

... can't be standardised because the standard can't come up with a meaningful 
description of what a file is. It's unable to add text that explains the 
behaviour compilers should have, because it doesn't even have the concept of 
files and filesystem where the compiler is running.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Cloud Software Architect - Intel DCAI Cloud Engineering