On 2018-10-07 20:39, Thiago Macieira wrote:
On Sunday, 7 October 2018 01:56:47 PDT Lars Knoll wrote:
Hi,
Just a quick question: Does anybody have any good arguments against us
starting to use #pragma once instead of header guards throughout our code
base?
Yes, two:
a) not supported everywhere
b) not well-defined behaviour when it comes to anything but the simplest
organisation
For example, I have ~/src as a bind-mount to ~/dev/src. That means
~/src/qt/qt5/qtbase/src/corelib/global/qglobal.h
~/dev/src/qt/qt5/qtbase/src/corelib/global/qglobal.h
are actually the same file, but they aren't for the effects of #pragma once
because the paths differ.
Another problem is qcompilerdetection.h, qprocessordetection.h,
qsystemdetection.h, qtypeinfo.h, etc. which depend on the header guards to
break the include cycle. Ditto for qlist.h + qstringlist.h and
qbytearraylist.h
...
...
I recommend against changing Qt.
Hi, but isn't C++17's __has_include preprocessor cmd an implicit
endorsement of #pragma once? I mean, they both assume that the file
namespace is stable and idempotent.
The example with ~/src as a bind-mount to ~/dev/src above, reminds me of
the old pointer aliasing problems in C++. But cannot it be solved by
requiring #pragma once to always call realpath() first, i.e. always test
on "the canonicalized absolute pathname" that realpath() returns?
Rgrds Henry
_______________________________________________
Development mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/development
