This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
RE: reduce compilation times?
- From: "Duft Markus" <Markus dot Duft at salomon dot at>
- To: "Fabian Cenedese" <Cenedese at indel dot ch>, <gcc-help at gcc dot gnu dot org>
- Date: Wed, 28 Nov 2007 14:18:11 +0100
- Subject: RE: reduce compilation times?
Hi!
Fabian Cenedese <> wrote:
>>> Splitting C files is different to splitting C++ files or splitting
>>> Java files, Fortran, Ada, ObjC, ....
>>
>> In the case of C++, you can just put each method of a class in a
>> separate .C file. Provided they all include a .H file which defines
>> the class prototype it's ok.
>
> The problem may not be the .cpp but the .h files. If I add a new
> member
> or method all files of this class need to be rebuilt. With the
> independent functions in C this may be easier to do. But still, if
> everything is rebuilt then it doesn't matter how many files you
> spread your code over.
>
> Of course from maintenance point of view splitting files is good
> though
> I maybe wouldn't go down to function level, more like class level.
> Otherwise the bad overview in the file is just transferred to the
> project level.
+1 ;o) Exactly how i think about it. I personally have a project with
approximately 30K lines, where each .cpp file contains exactly one class
(and it's internal-only stuff...). The project is perfectly
maintainable, further splitting into more files would only make it more
*unmaintainable*, since i would spend my time searching things... ;o)
And as Fabian sayd, in C++ the header files are the problem. It's even
fater to have a class in one C++ file as opposed to having multiple
files, because (with dependency tracking ebnabled) each of the files
including the header (which would be all of those file, right?) will be
rebuilt anyway.
BTW: has gcc a mechanism to determine, wether a change in a header file
affects a particular .cpp file? Microsoft has... They skip every file
where no affecting changes are detected...
Cheers, Markus
>
> bye Fabi
--
5. Dezember 2007
Salomon Automation am Schweizer Forum fur Logistik, Lausanne, CH
Salomon Automation GmbH - Friesachstrasse 15 - A-8114 Friesach bei Graz
Sitz der Gesellschaft: Friesach bei Graz
UID-NR:ATU28654300 - Firmenbuchnummer: 49324 K
Firmenbuchgericht: Landesgericht fur Zivilrechtssachen Graz