On quinta-feira, 1 de março de 2012 12.44.47, Mathias Hasselmann wrote: > > According to the book it is. But in practice it happens all the time, and > > we know it. > > To which book? C++ compilers and IDEs give zero support in enforcing > direct includes. Considering the mess GNU libc headers are, I even > wonder how to formulate automatic checks for direct includes.
Adding includes is also a source-incompatible change in some situations and we
can't avoid it. Adding a new include means new symbols become defined, new
overloads are produced.
For example, the following code, found in WebKit, compiles under C++98 + POSIX
or C++98 + C99:
#include <cmath>
using namespace std;
int foo() { return isnan(0.); }
But it does not compile under C++11 because there's now a std::isnan. It
happens because cmath indirectly includes math.h, which strictly speaking it
shouldn't.
Another example of things breaking are Q_DECLARE_METATYPE. If you #include a
header that declares a certain type a metatype, you'll break everyone's code
that also had that macro.
> Considering this weakness of C and C++ some have come to the conclusion
> that indirect includes are part of the API. Removing redundant include
> directives from released headers actually is an API break in C/C++.
Which is why I am saying that, in my book, those changes are acceptable and
user code will need to adapt. Therefore, they don't count as an API break. If
you need to use feature X, you need to #include the header that provides it
and you need to link to the library that contains it. Depending on indirect
inclusion and on indirect linking is a bug.
Fortunately, for indirect linking the linker usually complains so those
mistakes don't go far.
> The GNOME guys went the pragmatic approach and now forbid direct
> includes. You always must include the module headers for GTK+ and
> friends now (unless explicitly asking for trouble):
>
> #if !defined (__GTK_H_INSIDE__) && !defined (GTK_COMPILATION)
> #error "Only <gtk/gtk.h> can be included directly."
> #endif
>
> Sadly, considering the slowness of g++ and the complexity of Qt, I doubt
> this is a reasonable approach for Qt.
Yup.
$ perf stat -d -r 10 g++ -fPIE -DQT_SHARED -c -o /dev/null \
-I$QTOBJDIR/include -include QtWidgets/QtWidgets \
-include QtNetwork/QtNetwork -xc++ /dev/null
1043.329965 task-clock # 0.997 CPUs utilized
( +- 1.76% )
3,397,699,525 cycles # 3.257 GHz
( +- 1.60% ) [40.11%]
1.045980458 seconds time elapsed
( +- 1.76% )
This is with an SSD.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Intel Sweden AB - Registration Number: 556189-6027
Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
