The include mechanism used in C++ is working just fine, but often
programmers tend to add redundant #include when a simple class fwd
declaration will do.

The problem get worse if a basic H file, one that many other files
refer,  has redundant dummy #includes,  in such case a small
modification may trigger a complete rebuild.

Two rules which we follow in my team
* each xxxx.cc file first statement is: #include xxxx.h - thats
proofs, in some sense, that our H files are compile-able stand alone.
* each H file xxxx.cc is guarded with #ifdef __xxxx___

There are some other, more complex ways in reducing H file dependency,
e.g. preferring member ptr or reference, which can be fwd declared,
over a on board regular member.  It may consume a bit more memory, add
complexity in term of cnstr/dstr or even reduce compiler possible
optimization but it does reduce H file dependency.

That have being said, getting to the point:

1) Is there a tool which can analyze code and remove redundant
#include's?
2) Given the above two coding style - is there a better tool/script?

10x
Rabin

In terms of performance and speeding up compile times where large
numbers of headers are included... what you want to use are
"precompiled headers". Precompiled headers are what they sound like;
the compiler reads a header and generates a binary representation of
the data in the header. Reading the binary representation of the
header file contents is much faster than parsing the contents of the
header each time it needs to be used. You can look at your compiler's
relevant documentation on how to create precompiled headers. For GCC,
if you include a header file and a file exists with the same name but
with a ".gch" suffix, it will assume that the ".gch" file is a
precompiled header, and it will include the precompiled header
instead.

With regard to preprocessor guards (that is, the use of "#ifndef" and
"#define" to prevent multiple inclusions)... you should follow this
practice for any header file whose contents are not expected to change
on each inclusion (i.e. content not controlled by #if...#else
constructs, where the variables on which they depend are expected to
be potentially redefined before each inclusion -- an example of this
is <cassert>). For most header files, this will be the case (i.e., you
should use preprocessor guards). Preprocessor guards do more than
reduce compilation time by eliminating redundant includes; they also
ensure that a source file can include two separate headers that each
depend on and include a common header file (i.e. it ensures that the,
even with very complex dependency graphs, the compiler will not
encounter and, therefore, will not fail as a result of redundant
declarations).

- Michael Safyan

On Nov 1, 8:57 pm, shahav <sha...@gmail.com> wrote:

Neil Butterworth

Uli

--
Sator Laser GmbH
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932

An alternative design is that header files never include other header
files, but rather state their prerequisites in comments, and push the
find-the-transitive-closure-of-the-needed-set-of-includes problem
back to the programmer.  With this approach xxxx.cc begins with
   #include <iostream>
   #include <string>
   #include <vector>
   #include <algorithm>
   #include "project_global_configuration.h"
   #include "low_level_class_used_by_xxxx.h"
   #include "another_low_level_class_used_by_xxxx.h"

I can see advantages (+) and disadvantages (-) of each approach:
Header files include all prerequisites:
+ header file is cleanly self-contained for clients
+ list of prerequisites is implicitly checked by the compiler, i.e.,
   a missing prerequisite will be spotted at the next compile (although
   unnecessary prerequisites may go unnoticed)
- lots of duplicate inclusion requires all header files to be guarded
- lots of duplicate inclusion may slow build times (some compilers
   (e.g., gcc) specially optimize the header-file-guard #ifdef/#ifndef
   idiom, but there's still some extra overhead)
- looking at xxxx.cc, it's relatively hard to identify the full set
   of all files it includes, or perhaps more importantly, it's relatively
   hard to tell whether or not it directly *or* *indirectly* includes
   some particular header file that's just had a must-check-all-clients
   change committed

Header files never include other header files:
- if the list-of-prerequisites header comment is wrong, this may not
   be noticed for some time
- programmer has to do the transitive-closure-of-needed-set-of-includes
   manually, and perhaps worse, has to keep it up to date as the software
   structure changes and evolves (this means that if some low-level
   header acquires a new prerequisite, many higher-level clients may
   need an extra #include)
- xxxx.cc now starts with a rather lengthly list of includes
   (e.g., the top-level driver routine of my current C++ project shows
   10 #include <...> statements, followed by 24 #include "..." statements)
+ there are no duplicate includes, so build times are fast
+ looking at xxxx.cc it's easy to tell whether or not it depends on
   some particular header file, and more generally, it's easy to tell
   what other project subsystems it uses
+ this approach follows the KISS rule

Are there other significant advantages/disadvantages?

--
-- "Jonathan Thornburg [remove -animal to reply]" <jth...@astro.indiana-zebra.edu>
    Dept of Astronomy, Indiana University, Bloomington, Indiana, USA
    "C++ is to programming as sex is to reproduction. Better ways might
     technically exist but they're not nearly as much fun." -- Nikolai Irgens

best regards,
Martin

Gerhard

And I would like to add:
- Even an innocent interface change (such as adding another function)
can cause an avalanche of edits all over the source code.
- This approach is completely unacceptable for many organisations for
third-party libraries, because integrating updates will be too painful.
- You can't know if a header was included because it is needed by the
code of xxxx.cc itself or because it was a prerequisite for some other
header.

Bart v Ingen Schenau
--
a.c.l.l.c-c++ FAQ: http://www.comeaucomputing.com/learn/faq
c.l.c FAQ: http://c-faq.com/
c.l.c++ FAQ: http://www.parashift.com/c++-faq-lite/

Stick with the standard include guards, weed out unnecessary includes
from headers, and, more importantly, use pimpl idiom to hide class
implementation, so that class implementation includes only go into class
implementation source files.

--
Max

Perhaps our discussion might be clearer if we focus on a specific
example:  Consider the following inheritance hierarchy, taken from
a C++ project I'm currently working on.  (This needs a window at
least 119 characters wide to display the ASCII-art properly.)

***** Notation *****
D ==> B              D is-a B, i.e. D is derived from B
C --> M              C has-a or points-to-a M, i.e. C contains
                one or more members of type M, M*, and/or M&

Berger_Oliger<physics_system, FD_scheme>
                        |
                        |
                        V
          mesh<physics_system, FD_scheme>
                        |
                        |
                        V
         chunk<physics_system, FD_scheme> ==>
FD_scheme::chunk_base<physics_ystem> ==> chunk_base_common<physics_system>
                                                                      |
                    |
                                                                      |
                    V
                                                                      |
                 radial_fn
                                                                      |
                                                                      V

slice<physics_system> ==> physics_system::slice_base

                    |

                    |

                    V

                  gridfn

As you can see, most of the higher-level classes are templates with
2 template parameters, physics_system and FD_scheme.  These templates
are all instantiated 4 times, once for each combination of two different
choices of  physics_system  and two different choices of FD_scheme.

With headers-include-other-headers, Berger_Oliger.cc would begin with
   #include "mesh.hh"
together with any auxiliary classes directly used in the Berger_Oliger
API.  With headers-don't-include-other-headers, Berger_Oliger would
begin with includes for everything shown in the diagram, together with
all the auxiliary classes used by those classes.

I can understand how one can reasonably debate which of these approaches
is a preferable programming style, but I'm puzzled how either approach
is "almost impossible".

--
-- "Jonathan Thornburg [remove -animal to reply]" <jth...@astro.indiana-zebra.edu>
    Dept of Astronomy, Indiana University, Bloomington, Indiana, USA
    "Most investment bankers' [...] idea of a long-term investment
     is thirty-six hours"  -- Robert Townsend, "Up the Organization"

class x {
     std::string name;
public:
// whatever

  //
  // prerequisites:
  //    <string>
  //

  //
  // This class ...
  //
  class x {
      std::string name;
  public:
  // whatever
  };

I would like to hope that before writing  #include "x.hh"  a programmer
will first read enough of  x.hh  to understand the client API provided
by class x.  In this programming style a prerequisite
  #include <string>
is part of the "#include API", and is explicitly documented in  x.hh .

[I emphasize that I am *not* claiming any originality in this scheme.
For example, Rob Pike famously advocated it 20 years ago in his "Notes
on Programming in C",  http://www.lysator.liu.se/c/pikestyle.html  .
Of course, that doesn't mean it's necessarily a good idea for C++
today -- that's the topic under discussion.]

The one disadvantage that does seem possibly-significant to me is that
headers-include-other-headers lets a header provide a slightly cleaner
abstraction (one with slightly less "mental workload") to clients:

  // instructions in "foo.hh includes whatever other stuff it needs"
  // style:
  To use the foo subsystem, just
    #include "foo.hh"
  then follow the comments in "foo.hh" describing the care and
  feeding of foo objects.

as compared with

  // instructions in "clients of foo.hh include whatever other stuff
  // foo.hh needs" style:
  To use the foo subsystem, just
    #include <iostream>
    #include <string>
    #include <vector>
    #include <map>
    #include "baz.hh"
    #include "quux.hh"
    #include "foo.hh"
  then follow the comments in "foo.hh" describing the care and
  feeding of foo objects.

I don't want to be too dogmatic:  In the past I've always used the
headers-dont-include-other-headers style, but maybe I'm wrong and
should change in some (all?) circumstances.  I find the responses
in this thread (including those that I might disagreee with) very
insightful!

ciao,

--
-- "Jonathan Thornburg [remove -animal to reply]" <jth...@astro.indiana-zebra.edu>
   Dept of Astronomy, Indiana University, Bloomington, Indiana, USA
   "Washing one's hands of the conflict between the powerful and the
    powerless means to side with the powerful, not to be neutral."
                                      -- quote by Freire / poster by Oxfam

--
Max

In fact, adding new #include prerequisites is a lot *less* onerous
than a non-backwards-compatible API change, because it (new #include)
only requires a mechanical change for each *file* using the API,
whereas the (in my experience far more common) non-backwards-compatible
API change may require non-trivial (sometimes *very* non-trivial)
changes at each *call site*.

--
-- "Jonathan Thornburg [remove -animal to reply]" <jth...@astro.indiana-zebra.edu>
   Dept of Astronomy, Indiana University, Bloomington, Indiana, USA
   "Most investment bankers' [...] idea of a long-term investment
    is thirty-six hours"  -- Robert Townsend, "Up the Organization"

1.) It will mess up the change history in any SCC. For a given change,
someone looking at the history will see a change to a header + n *
cc-files where most of the cc-file changes are just edits to include a
new header.
2.) For concurrent development, it will increase the number of files
needing a merge (costing developer time) even though no functional
change to these files has been applied.

br,
Martin

Leaving header file inclusion to the end client amounts to needless
duplication of preprocessor directives and replaces automatic handling
by manual, error-prone management. It is inconceivable to me that this
should work in any project that involves more than a single developer
and more than a few dozens of source files.

--
Gerhard Menzl

Non-spammers may respond to my email address, which is composed of my
full name, separated by a dot, followed by at, followed by "fwz",
followed by a dot, followed by "aero".

R.

Again, my thanks to all who have contributed to this thread -- I've
found the various points of view to be very enlightening.

ciao,

--
-- "Jonathan Thornburg [remove -animal to reply]" <jth...@astro.indiana-zebra.edu>
    Dept of Astronomy, Indiana University, Bloomington, Indiana, USA
    "being able to send information a little bit faster than light is like
     being a little bit pregnant: it has implications which go far beyond the
     immediate direct importance of the phenomenon itself." -- Henry Spencer

1) Read a header file.
2) Cut all #include lines from the header, remove duplicates and store
them as an array-of-includes. Let N be the length of the array.
3) All possible variants of removing headers can be represented by a
string of 1s and 0s of N bits.
4) Treat that string of N bits as a binary number.
5) Do a loop for i in range(0, 2 ** N).
5.1) For every set bit in i paste a corresponding include line into the
header (with all includes removed on step 2) and try to compile the header.
5.2) If the header compiles, save the header and terminate the loop. As
it iterates from 0, current i has the least number of bits set and
therefore corresponds the least number of includes.
5.3) Otherwise, next iteration.

The complexity of this algorithm is O(2 ** N), where N is the number of
unique includes in the header. Might not scale well to large Ns.

One shortcoming of this algorithm is that a successful compile may be
triggered too early by an unrelated header which happens to include
other headers that are required by the header being analyzed. To
overcome this to some extent it may be a good idea to start analyzing
headers with the least number of includes first.

Is there a more interesting solution for automatically removing
redundant headers?

--
Max

((*itr1.second).data || (*itr2.first).data) && someBooolFunc()
or
(iter1.second->data || itr2.first->data) && someBoolFunc()

another example

fun((*iter).data).field
or
fun(iter->data).field