forrest@orion.sybase.com (Jon Forrest) (02/17/90)
As a proud user of TC2.0 I'm looking forward to TC3.0. What
I'm not looking forward to is a combination C/C++ compiler.
I'm concerned that such a compiler would be bigger and probably
slower than a C-only compiler. In other words, I want
the best, smallest, fastest C compiler Borland can
make. Although I'm not interested in C++ I know that many other
people are and that's why Borland should include 2 compilers
in TC3.0, a C only compiler and a C++ compiler that presumably
will also compile C.
----
Anything you read here is my opinion and in no way represents Sybase, Inc.
Jon Forrest WB6EDM
forrest@sybase.com
{pacbell,sun,{uunet,ucbvax}!mtxinu}!sybase!forrest
415-596-3422elund@pro-graphics.cts.com (Eric Lund) (02/20/90)
> I'm concerned that such a compiler would be bigger and probably > slower than a C-only compiler. In other words, I want > the best, smallest, fastest C compiler Borland can > make. Although I'm not interested in C++ I know that many other > people are and that's why Borland should include 2 compilers > in TC3.0, a C only compiler and a C++ compiler that presumably > will also compile C. Borland's C compiler is currently the fastest (in compile times) on the market. I, for one, am interested in learning C++. However, I agree with your concern over loss of speed. I have faith in Borland they will produce an efficient compiler, and integrate the two well. I don't know if it's necessary to separate the programs, although it may be a viable alternative to slow compilation. We'll just have to wait and see. Eric ProLine: elund@pro-graphics UUCP: ...crash!pro-graphics!elund ARPA/DDN: pro-graphics!elund@nosc.mil Internet: elund@pro-graphics.cts.com
bcw@rti.UUCP (Bruce Wright) (02/21/90)
In article <1590@crash.cts.com>, elund@pro-graphics.cts.com (Eric Lund) writes: > > I'm concerned that such a compiler would be bigger and probably > > slower than a C-only compiler. In other words, I want > > the best, smallest, fastest C compiler Borland can > > make. Although I'm not interested in C++ I know that many other > > people are and that's why Borland should include 2 compilers > > in TC3.0, a C only compiler and a C++ compiler that presumably > > will also compile C. > > Borland's C compiler is currently the fastest (in compile times) on the > market. I, for one, am interested in learning C++. However, I agree with > your concern over loss of speed. I have faith in Borland they will produce > an efficient compiler, and integrate the two well. I don't know anything about C++ (haven't had time to look at it), so I'm speaking from partial ignorance. But what interests me is why everyone seems to think that a compiler that accepts both languages _must_ be slower even when compiling a program using just C. Obviously you can (at the cost of significant memory) have a compiler switch which compiles one language or the other, calling the appropriate semantic analysis routine; the difference in speed shouldn't be noticeable, except for the extra amount of time to load the other analysis routine from disk. If the languages are closely related, which I gather C and C++ are, a single semantic analysis routine might be able to handle programs written for both languages. The major reason I can think of for the compiler to be noticeably slower in this case would be if the C++ language requires a greater computational complexity in the parsing and semantic analysis routines. (For example, when Ada was first introduced, nobody knew any algorithms for doing a semantic analysis that ran in less time than O(N**3), where N is the number of terminals. This is caused by Ada's overloading of operators and identifiers; most languages require only O(N) time. It is now known that algorithms exist which can analyze Ada in O(N) time, but this is not guaranteed for all languages). Obviously there might be a significant _run-time_ hit if a combined compiler had to do a lot of run-time interpretation (say because the C++ language allowed manipulation of the program source text at run time, although there are often ways to greatly reduce the burden of having to interpret the code from scratch every time). Or in this sort of case there might be a possibility of maintaining the original run-time speed if analysis indicated that only C language constructs were used, but this _could_ increase compilation time. A lot of compilers can be thought of as an enormous loop of the form: while (!eof) do { switch () { ... } } where (modulo the amount of time to load the extra code from disk) you can add lots of additional constructs without making much of a difference in compilation speed. The exceptions are languages like Ada (above) which may require a lot of backtracking in order to do the parse or the semantic analysis. (it's true that a compiler back end often does operate with backtracking but presumably the back end would be pretty similar to that of a C only compiler ... or at least that portion of the back end that would be used in the compilation of a program only using C constructs). Is C++ really harder to parse than Ada? Or are the concerns more about run-time efficiency than about compilation efficiency (and why would C++ be so bad)? Or are people mostly just worried about the disk space (which I can certainly sympathize with)? As I said, I don't know anything particular about C++ besides things I've seen on the net and the trade rags. Could someone enlighten me? Bruce C. Wright
forrest@orion.sybase.com (Jon Forrest) (02/22/90)
> >I don't know anything about C++ (haven't had time to look at it), >so I'm speaking from partial ignorance. But what interests me is why >everyone seems to think that a compiler that accepts both languages >_must_ be slower even when compiling a program using just C. [... lots of stuff edited out] Your reply pretty much answers your question, especially if you figure that Turbo C is targeted at 8088 class machines. Maybe a combination C/C++ compiler won't be much slower that a C only compiler (maybe) but it will certainly be bigger. On MSDOS big is bad. On VM systems big isn't all that important. ---- Anything you read here is my opinion and in no way represents Sybase, Inc. Jon Forrest WB6EDM forrest@sybase.com {pacbell,sun,{uunet,ucbvax}!mtxinu}!sybase!forrest 415-596-3422
elund@pro-graphics.cts.com (Eric Lund) (02/24/90)
> Is C++ really harder to parse than Ada? Or are the concerns more > about run-time efficiency than about compilation efficiency (and why > would C++ be so bad)? Or are people mostly just worried about the > disk space (which I can certainly sympathize with)? > > As I said, I don't know anything particular about C++ besides things > I've seen on the net and the trade rags. Could someone enlighten me? A good article on C++ from a C perspective was in a recent Doctor Dobb's Journal. I believe it was the January issue. You are probably right (or at least that was my hope) that the similar constructs between C and C++ would allow the two compilers to run almost as one, but it is the overhead we are worried about. True, the program could be split into two, but hopefully that won't be necessary. (Or rather, I hope they can have both forms.) I think the most truthful concern is, we don't know what to expect from Borland! What kind of package are we going to get? What should we worry about ... Eric. ProLine: elund@pro-graphics UUCP: ...crash!pro-graphics!elund ARPA/DDN: pro-graphics!elund@nosc.mil Internet: elund@pro-graphics.cts.com
cs4g6ag@maccs.dcss.mcmaster.ca (Stephen M. Dunn) (02/27/90)
I was under the impression that C++ could be implemented as a
preprocessor that converted it into standard C, and a regular C
compiler (and, presumably, a library of C++-specific functions).
Chances are I'm wrong, but ...
--
Stephen M. Dunn cs4g6ag@maccs.dcss.mcmaster.ca
<std_disclaimer.h> = "\nI'm only an undergraduate!!!\n";
****************************************************************************
I Think I'm Going Bald - Caress of Steel, Rushfrotz@drivax.UUCP (Frotz) (03/01/90)
Has anyone heard anything about VROOM? It is some kind of Overlay manager that they (Borland) use in paradox. Rumor has it that it might be a part of Turbo C 3.0. Also, does anyone have any comparisons or timings? (I doubt it at this early stage, but you never know.) Email will not be summarized if requested. --Frotz @Digital Research, Incorporated amdahl!drivax!frotz 70 Garden Court, B15 (408) 649-3896 Monterey, California 93940 Ask for John Fa'atuai
webb@uhccux.uhcc.hawaii.edu (Thomas Webb) (03/02/90)
In article <QMNF54T@drivax.UUCP> frotz@drivax.UUCP writes: >Has anyone heard anything about VROOM? It is some kind of Overlay >manager that they (Borland) use in paradox. Rumor has it that it >might be a part of Turbo C 3.0. Also, does anyone have any >comparisons or timings? (I doubt it at this early stage, but you >never know.) > >Email will not be summarized if requested. ^^^ Please _do_ summarize. Well, I recall seeing some mention of VROOM in the Paradox docs, but I don't think they said much more then you already know; ie. it's an overlay manager of some kind. On the other hand, you can ask Borland directly about this by contacting Larry Kraft on CIS at 76703.764@compuserve.com. This is the official connect point for Borland information and tech. support from usenet. On a related note, Borland has just released the 'Paradox Engine' which is a C library that allows easy integration of C applications with Paradox--or so it is claimed. A tp version is claimed to be on the way too. Hope this helps. -tom ps My only realtionship with Borland is as a customer, just in case that's important to you. -- =============================================================================== webb@uhccux.uhcc.Hawaii.edu "The first duty in life is to assume a pose. What the second is, no one has yet discovered." -Oscar Wilde
coy@ssc-vax.UUCP (Stephen B Coy) (03/03/90)
In article <QMNF54T@drivax.UUCP>, frotz@drivax.UUCP (Frotz) writes: > Has anyone heard anything about VROOM? It is some kind of Overlay > manager that they (Borland) use in paradox. Rumor has it that it > might be a part of Turbo C 3.0. Also, does anyone have any > comparisons or timings? (I doubt it at this early stage, but you > never know.) Check out the winter catalog from Programmer's Connection. It contains an article describing VROOM and how it works. It sounds great but there was no mention of ever seeing it outside of Borland. > --Frotz @Digital Research, Incorporated amdahl!drivax!frotz > 70 Garden Court, B15 (408) 649-3896 > Monterey, California 93940 Ask for John Fa'atuai Stephen Coy uw-beaver!ssc-vax!coy