On Thursday, September 13, 2012 13:56:33 Till Oliver Knoll wrote:
Am 13.09.2012 um 10:19 schrieb Stephen Kelly <stephen.ke...@kdab.com>:
...
flag -Wl,--no-undefined you won't get the error when you build a static
library, but only when you link the target that uses that static library.
Mysterious.
Okay, I get your point there: however I still don't consider those points as
bad in my situation, because
- I never do static libraries
In the future you might. "Always be prepared".
- I hardly ever #include dependencies in *headers* (only if there's no other
way, as outlined previously), so it is extremely unlikely that there will
be a stray #include after some refactoring - Yes, I worked in (small, but
highly disclipined) teams like that in the past 10+ years like that and the
scenario you described never - ever - occured.
That doesn't make it a good idea. Having an entire team so highly disciplined
is rare, but I don't think even that solves the problem. There are stray
includes in Qt. Mistakes happen. In reviews, people look at a patch, not
whether an include at the top of the file can/should be removed.
Refactoring can cause mistakes like this even in highly disciplined teams. In
your case a stray include from which nothing requires linking would require
humans who have better things to do than make up for lack of tool support to
catch errors like this.
Additionally:
* You don't know who will maintain the code in 5/10 years. Maybe your company
will be bought by $BIG_CORPO_WITH_CRAPPY_DEV_METHODS
* From a consultant point of view, I'm sometimes working with other peoples
code. No matter how disciplined I am, I can't expect that every team I visit
is going to keep track of includes with human methods as carefully as is
required without the tooling help.
So doing "module includes"
worked for us - I agree that on Linux by default you might not catch such
an "undefined symbol" when compiling a shared library, but on Windows and
Mac you do
You never know when a codebase will be ported to another OS.
Addtionally - The stray include in a public header problem *does* happen on
Windows/Mac.
As a reminder, in case it's still not clear, I'm talking about two orthogonal
issues that you expose yourself too.
1) Stray, forgotten includes which cause your downstreams to have headers
installed which are not used.
2) Substituting compiler errors for linking errors.
- so no, in my case it cannot happen that you "only notice it
way later downstreams" when trying to link to that library
So yes, I agree with you that in a very large project such stray #includes
might lead to confusion. But my point is that it works for me
By the same logic, turning off all compiler warnings is 'not a bad idea per
se'.
A highly disciplined team can simply see code that causes undefined behaviour
as they write it and correct themselves, right?
and I
disagree with the statement in general that "module imports" are bad per
se,
I maintain that they are a bad idea. This is just friendly advice that I'm
broadcasting and justifying. You can do what you want :).
because they help *me* to better organise my includes
That 'organization requirement' is a side effect of using module includes.
You want
#include <QtCore/QFile>
#include <QtCore/QObject>
#include <QtGui/QFont>
instead of
#include <QtCore/QFile>
#include <QtGui/QFont>
#include <QtCore/QObject>
right? I don't think that adds quality over
#include <QFile>
#include <QFont>
#include <QObject>
or
// QtCore
#include <QFile>
#include <QObject>
// QtGui
#include <QFont>
or any other variation (including non-sorted), especially considering the cost
of preventing the tooling from informing you of the problems.
and avoid having
wrong dependencies in the first place.
... by relying on humans getting it right every time (not just once!) instead
of having tooling catch it every time.
Additionally if you have a large project to build then the linking failure
might happen 30 minutes after the point where I get a compile failure.
So we have a common agreement that in both cases the tools tell us that
something is wrong.
Not in the case of a stray unused forgotten include. You have no tooling
telling you about that.
You just rely on humans always realizing it as they are typing/refactoring
even if they're thinking more about the urgent deadline next Wednesday-week
instead of thinking about the includes at the top of a several hundered line
file.
So your previous statement that I "disable the tools"
is not quite correct: in my case it is just the linker telling me that I
should have linked to something, instead of the compiler.
1) Not in the case of a stray unused forgotten include.
2) That's suboptimal.
You've
just wasted all that time (and now you get to spend time tracking down the
root cause - I've already fixed it).
Just the link time can be considered wasted!
Try building webkit or llvm/clang some time :).
Consider a library with several hundred cpp files all of which are several
thousand lines of code. Consider a stray include in the first one. I get the
error notification immediately. You compile all other objects and get a link-
time error much later.
So I wasted a little bit more time than you, I had to relink. But for me the
advantages to have the #includes properly organised and the dependencies
made explicit outweighs that disadvantage.
'Organized' as above?
Your buildsystem makes the dependencies explicit anyway.
Because hey, 95% I spend coding,
and the rest setting up the *.pro files (in fact I copy/paste them these
days from previous project), so it's not like every day you encounter such
"mysterious linking errors". ;)
Not if you only work on small projects with small teams.
Anyway, my advice is: Don't use module includes.
Take it or leave it :).
Thanks,
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
