[Dune] redundant includes in headers

[Jö Fahlke]

Am Fri, 19. Aug 2011, 15:43:47 +0200 schrieb Oleh Krehel:
> I've noticed this group of includes in fvector.hh:
> 
> #include<cmath>
> #include<cstddef>
> #include<cstdlib>
> #include<complex>
> #include<cstring>
> 
> Are they really necessary? Because when I've commented them away,
> everything still works.

What does "everything" mean in your case?  The right test would be "make
headercheck".

Even "make headercheck" will not catch all cases where includes are missing,
depending on the compiler.  Some of the standard headers (say header A) may
include (part of) other standard headers (say header B), so that you can use
features from header B without including it, as long as you included header A.
Unfortuneately, you cannot portably rely on that, since other compilers or
standard libraries may handle header interdependencies differently.  The only
exception I know is that you can omit "#include <iosfwd>" if you have done an
"#include <ios>", because the standard actually mandates that the latter
includes the former.  But I don't think we make very much use of those header
in Dune.

If you can show that fvector.hh does not actually directly use any of the
features from a particular include (according to the C++-Standard), then we
may consider removing that include.

> But in fiedmatrix.hh it's definitely redundant:
> 
> #include <cmath>
> #include <cstddef>
> #include <iostream>
> 
> #include <dune/common/misc.hh>
> #include <dune/common/exceptions.hh>
> #include <dune/common/fvector.hh> // includes again <cmath> and <cstddef>
> 
> I realize that it's not a priority and redundancies don't break anything,
> but perhaps removing them could save a few milliseconds of build time:)

Well, in this case it would be correct and portable to omit "#include
<dune/common/fvector.hh>".  But it would be a maintanence headache: If
somebody in the future changes fvector.hh such that it no longer needs
<cstddef>, he can no longer simply remove that include.  First he must check
whether any other source file includes fvector.hh (directly *or* indirectly),
and then must adapt any that make the implicit assumption that fvector.h
includes <cstddef>.

While this is a headache in itself, it could be done for the core of Dune, by
someone who doesn't have anything better to do with his time.  The even bigger
issue arises when you consider external libraries or applications on top of
Dune: whoever changes fvector.hh cannot possibly have access to all the code
that uses it, so he cannot adapt that code.  And deprecation is impossible in
this case, so there would be no smooth transition for the users.

> I've read that the static analyzer features of eclipse or clang can
> automatically
> find the redundant/unused includes.

Since the header a feature is defined/declared in is not nessessarily the
header you should include to get that feature, these analyzers will need
information they cannot possibly obtain from the source files alone.  At least
if you want their result to be maintainable, not merely correct C++-code for
the machine they were executed on.  It possible that they have this
information built in for the standard library, but we would still need to feed
them that information for Dune in a machine-readable format.

Bye,
Jö.

-- 
There's no evolution in the US.  It's not allowed.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 828 bytes
Desc: Digital signature
URL: <https://lists.dune-project.org/pipermail/dune/attachments/20110819/4ead3216/attachment.sig>