reduce compilation times?

Tom St Denis tstdenis@ellipticsemi.com
Wed Nov 28 13:17:00 GMT 2007


J.C. Pizarro wrote:
>> This is so blatantly false ... I don't know about fortran/ada/obj, but
>> for C++ and Java you can trivially factor your code.
>>     
>
> It's not false, you get wrong.
>   

I don't want to make this personal, so I apologize for the tone in my 
other reply.

>> 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.
>>     
>
> I'm not sure if GCC C++ does it.
>   
Yes, it does.  Consider:

ctmp1.C
#include "ctmp.H"

ctmp::ctmp(void)
{
   cout << "hello world" << endl;
}

ctmp2.C
#include "ctmp.H"

ctmp::~ctmp(void)
{
   cout << "goodbye world" << endl;
}

ctmp.H
#include <iostream>
using namespace std;

class ctmp {
   public: 
      ctmp(void);
      ~ctmp(void);
};

Both .C files compile just fine.

>> In the case of Java, you can break up a large task into classes which
>> handle separate functions of the program.  For example, a compiler may
>> have an I/O class, a lexer class, a parser class, an interface for
>> optimizations, and various implementations of the interface, etc, etc.
>> Hell, most colleges teach things like the MVC model when doing GUI Java
>> apps which, last I checked, is a way to refactor one large program into
>> separate tasks.
>>     
>
> We've talking to split files (e.g. 1 file per 1 function or per 1 method),
> not to separate tasks or factor tasks.
>
> Java can't split many methods of a class to many files,
> only 1 file per 1 class, not 1 file per method.
>   

Refactoring doesn't strictly mean one function per file.  That's the 
ideal [in most cases].  Refactoring simply means breaking a large task 
into smaller re-useable components.  For example, suppose you had a Java 
program made up of 10 classes, and each class you manually coded up a 
[say] GZIP decompressor, wouldn't it make more sense to split that off 
into it's own class?  That's re-factoring.

In an ideal application (as opposed to library), your "main" class 
should be fairly trivial pawning off all the hard work to a set of 
classes which handle all the individual aspects of the program.

This is reflected well in how glade designs GTK+ applications in C.  
Basically you end up with a C file which constructs and maintains the 
GUI, the code there should just be calling library functions to do the 
heavy work.

Tom



More information about the Gcc-help mailing list