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

Henry Skoglund henry at tungware.se
Tue Oct 11 22:18:51 CEST 2022


On 2022-10-11 22:04, Thiago Macieira wrote:
> ...
>> // 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.
>
Sometime in the far future when Qt requires c++20 things might improve:
we could use std::source_location::filename
(https://en.cppreference.com/w/cpp/utility/source_location/file_name )

||
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20221011/91e53204/attachment.htm>


More information about the Development mailing list