Duft Markus wrote:
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)
This is where automated tools come in handy. In my projects, I have
scripts that pick up source files and insert them into the makefile(s).
So with very little fuss I can add new files (either new functionality
or new split up code).
It really depends on the size of the class whether factoring makes sense
or not. but if you have heaps of 3000+ line long functions, I suspect
you spend enough time searching through them as is.
When I was working on DB2 and scouring their often 6000+ line files
looking for why GCC 4.whatever.beta wasn't working as hot as it could,
it wasn't exactly a lot of fun.
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...
Can't a makefile do that?
file.o: file.H file.C
Yes that works fine with GNU Make
-bash-3.1$ make
make: `ctmp1.o' is up to date.
-bash-3.1$ touch ctmp.H
-bash-3.1$ make
g++ -c -o ctmp1.o ctmp1.C
-bash-3.1$ cat Makefile
ctmp1.o: ctmp.H ctmp1.C
It's almost like, if you engineer your builds correctly, these are
"non-issues."
I don't want to make this personal, but honestly, if you're going to try
and give out advice, at least know what you are talking about. There
are actual proper ways to do things that reduce errors, increase
productivity, etc, etc.
Tom
