This is the mail archive of the 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?

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:

#include "ctmp.H"

  cout << "hello world" << endl;

#include "ctmp.H"

  cout << "goodbye world" << endl;

#include <iostream>
using namespace std;

class ctmp {
public: 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.


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