From: frenchc AT cadvision DOT com (Calvin French)
Newsgroups: comp.os.msdos.djgpp
Subject: Re: Speed of DJGPP?
Date: 11 Jun 1997 02:06:31 GMT
Organization: Reham Salad
Lines: 24
Message-ID: <5nl177$3o9a@elmo.cadvision.com>
References: <3 DOT 0 DOT 16 DOT 19970610012929 DOT 35c79ee0 AT hem1 DOT passagen DOT se>
NNTP-Posting-Host: ts2ip90.cadvision.com
Mime-Version: 1.0
Content-Type: Text/Plain; charset=US-ASCII
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Precedence: bulk


>Yeah, I can agree with you here, since DJGPP produces very good (read
>great) code, I'm not complaining. It's slower than other compilers during
>compilation, but faster during execution of the compiled program. 
>And making DJGPP incompatible with GCC sounds like a bad idea I guess. So,
>well, we'll all just have to settle with a somewhat slow compiler, that
>produces really fast code, and makes porting of code very easy, and is just
>great. I can settle with that! =)

Since djgpp is my only contact with any gnu-type stuff, I'm just wondering 
about updated versions of gnu c++. Are people somewhere busily working on 
gcc 3.0 (or maybe that's a bit ambitious; I know the c++ working paper isn't 
even exactly standardized yet -- let's say 2.8, or whatever a significan't 
version update would be) or what? I myself can't see exactly why gcc needs 
to use temp files, i.e., why use separate programs at all? With a well 
defined source API which I'm sure the gnu people (whoever and wherever they 
are) are more than capable of, couldn't it all be integrated into one 
program while still maintaining modularity? Command line ("system" calls, 
whatever you want) is just such a brutal excuse for a run-time API, it seems 
(and of course proves) really wasteful to rely on it. I'm not criticizing 
things I don't understand and won't anytime soon probably, I'm just curious.

- Calvin -