This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: reduce compilation times?


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.

That's no different than in C where you change a struct, union, or enum (or other macros).


But most of your re-compiles will be after changing code not definitions or prototypes. And even if it didn't save compile time [which it will] it still makes code more maintainable.

As I said in my first post on the subject, there is no "hard set" rule about when to refactor. If your class has 3 methods and is 75 lines of code, it's probably better to have it all organized in one unit/file. But if your class has 15 methods, and requires 1500 lines of code, you're probably better off refactoring it.

Libraries are different from applications in this sense. In a library, it usually makes sense to factor at the function level as you get a better chance to smart link (as well as the other development benefits). This doesn't strictly apply to C++ I suppose (well it may if nothing calls a method), but it definitely does to C.

Tom


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]