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
