Re: #include file optimizer
On 09/11/09 20:01, shahav wrote:
On Nov 9, 4:27 am, Maxim Yegorushkin<maxim.yegorush...@gmail.com>
wrote:
...
The original question, however, was concerned with redundant includes
which trigger recompilation that otherwise would be unnecessary.
A good way to cope with this problem has long been known:
* Make header files self-contained by having them include whatever they
require.
* Don't expose implementation details in header files by separating
interfaces and implementation. It can be done with by utilizing Pimpl
idiom or abstract interfaces and factory functions.
--
Max
In the last year, I've being working on a medium size project, say
about 120mm. The code was a "wiled west" - no standards at all.
We did modify the code by adding coding style. beside being supported
by a powerful regression sometimes we compared assembly code to
verify automatic applied coding style changes, e.g. removing tones of
redundant (), or preferring xxx-> over (*xxx).
Hm, (*xxx). is two symbols longer than xxx->. Why is the first one better?
What i'm looking for, is a similar tool/capability as in doxigen, to
analyze the code and remove redundant includes.
A different option would be writing a script which iterate-ly compiles
the same module and on each iteration add -D__xxxx__ to prevent that
module participation, similar effect as removing the include....
The algorithm could work as follows:
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
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]