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 _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development