Re: #include optimization

From: Peter van Merkerk (merkerk_at_deadspam.com)
Date: 09/30/04 

Date: Thu, 30 Sep 2004 10:58:19 +0200

CBFalconer wrote:
> Keith Thompson wrote:
>
>>Dan.Pop@cern.ch (Dan Pop) writes:
>>
>>>Keith Thompson <kst-u@mib.org> writes:
>>>
>>>>Dan.Pop@cern.ch (Dan Pop) writes:
>>>>
>>>>>ramesh25@gmail.com (Ramesh) writes:
>>
>>>>>>I am currently maintaining a legacy code with a very very large
>>>>>>code base. I am facing problems with C/C++ files having a lot
>>>>>>of un-necessary #includes. On an average every C/C++ file has
>>>>>>around 150+ .h files included. I find 75% of the files
>>>>>>unnecessary and could be removed. Considering the fact that I
>>>>>>have a huge code base, I can't manually fix it.
>>>>>
>>>>>If it ain't broken, don't fix it.
>>>>
>>>>Unless fixing it will make future maintenance easier, which is
>>>>probably the case here.
>>>
>>>Why?
>>
>>Because.
>>
>>Take a look at what's been said so far. The source files have an
>>average of about 150 #include directives, most of which are
>>unnecessary. It's a "very very large code base". It seems fairly
>>obvious to me that the whole thing is a mess, and that cleaning it
>>up would make it easier to maintain. (I'm tempted to suggest the
>>possibility of throwing it away and starting from scratch, but
>>that's probably not feasible.)
>>
>>Maybe it isn't really a problem, or maybe the unnecessary #includes
>>are such a small part of the problem that eliminating them wouldn't
>>really help, which is why I qualified my statement with the word
>>"probably". But since Ramesh specifically said that it's a
>>problem, and he's asking for ways to fix it, I'm not going to
>>assume that he's mistaken about the premise for his question.
>
>
> Actually it is a job that can be attacked and checked piecemeal.
> Remove the (presumably) useless includes in one file by commenting
> out (thus retaining line numbers) and compile it to an object
> file. Do a binary compare against the original object file. If
> identical, all is well.

Even if binary compare shows that there are differences all may be well
too. I learned this the hard way; compiling the same code twice with a
certain compiler yielded different binaries. Apparently the compiler
wrote the build date or something like that into the binary. When debug
information is stored in object files this test may also fail for the
wrong reasons. 

-- 
Peter van Merkerk
peter.van.merkerk(at)dse.nl

Relevant Pages

  • Re: #include optimization
    ... The source files have an ... Do a binary compare against the original object file. ... certain compiler yielded different binaries. ...
    (comp.lang.c)
  • Re: #include optimization
    ... Do a binary compare against the original object file. ... > certain compiler yielded different binaries. ... Why did you snip the last sentence or two from my paragraph, ...
    (comp.lang.c)
  • Re: #include optimization
    ... Do a binary compare against the original object file. ... > certain compiler yielded different binaries. ... Why did you snip the last sentence or two from my paragraph, ...
    (comp.lang.cpp)
  • Re: Help! simple compile question
    ... That would depend on what compiler you use, ... sub1 calls sub2 and sub3. ... and sub3 to end up in the same object file. ... the compiled result from multiple source files in a single file, ...
    (comp.lang.fortran)
  • Re: Help! simple compile question
    ... That would depend on what compiler you use, ... sub1 calls sub2 and sub3. ... and sub3 to end up in the same object file. ... the compiled result from multiple source files in a single file, ...
    (comp.lang.fortran)