reduce compilation times?

[Tom St Denis]

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