Re: #include optimization
From: Peter van Merkerk (merkerk_at_deadspam.com)
Date: 09/30/04
- Next message: CBFalconer: "Re: Compound statements in expressions"
- Previous message: Michael Mair: "Re: attempt at qsort implementation"
- In reply to: CBFalconer: "Re: #include optimization"
- Next in thread: CBFalconer: "Re: #include optimization"
- Reply: CBFalconer: "Re: #include optimization"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Next message: CBFalconer: "Re: Compound statements in expressions"
- Previous message: Michael Mair: "Re: attempt at qsort implementation"
- In reply to: CBFalconer: "Re: #include optimization"
- Next in thread: CBFalconer: "Re: #include optimization"
- Reply: CBFalconer: "Re: #include optimization"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
