jnh@ecemwl.ncsu.edu (Joseph N. Hall) (10/17/89)
Well, I got my copy of C++ 3.1B1 yesterday, and my first impression was
that it is _impressively_ slow. I compiled the TESample program, broken
into four files, on a Mac Plus and it took, oh, 10 or 15 minutes. There
are only about 2000 lines of .cp code there, mind you!
However, a little inspection revealed that the example includes just about
every .h file it can get its hands on. The TESample program was broken
up into 4 parts to illustrate a kind of one-class-one-file approach to
OOP. This means, of course, that all of these header files are processed
4 times by cfront ...
Cfront isn't too sluggish when compiling "normal" C++ code, except that
including <stream.h> produces another pretty good endurance test.
Naturally, there is no #pragma load for cfront. Not only do you have to
include _more_ headers with cfront, you can't pre-compile them, and they
are processed more slowly by cfront than by c, THEN they have to be
processed by C, and they STILL can't be pre-compiled. The result, if you're
used to working with a lot of little files (I prefer 500-1000 lines max),
is a "sloth" demon. I plan to get over my squeamishness toward longer
source files very quickly.
Cfront and C include special "gibberish" switches (-z3) that produce
and read (respectively) special non-TEXT output; these aren't documented but
are used in the CPlus script. The result, when there's an error that isn't
caught by cfront but which is caught by C, is something like:
#
#
# ?
### Error 123 xxxxxxxxx
#-------------------------------------------------------------
File "test.cp"; Find *!49:$!1; Open "{Target}"
#-------------------------------------------------------------
... which isn't the most intuitive error message possible. If you select
the error message and hit ENTER, as usual, though, you are magically
transported to the approximate location of the source of the error in the
original source file. Weird, but you get used to it.
In any event, the biggest "con" of MPW C++ is that it is slo-o-ow and that
the slo-o-ow-ness is difficult to work around. The "pro," of course, is that
it IS C++, and is an up-to-date AT&T C++ v.2.0 which will probably be well
supported in the future.
I wish I could see the amount of candy bars and coffee consumed by the
System 7.0 writers while they waited on CFront ...
v v sssss|| joseph hall || 4116 Brewster Drive
v v s s || jnh@ecemwl.ncsu.edu (Internet) || Raleigh, NC 27606
v sss || SP Software/CAD Tool Developer, Mac Hacker and Keyboardist
-----------|| Disclaimer: NCSU may not share my views, but is welcome to.dorourke@polyslo.CalPoly.EDU (David M. O'Rourke) (10/17/89)
jnh@ecemwl.UUCP (Joseph N. Hall) writes: > [talks about slow C++ on a Macintosh Plus > >I wish I could see the amount of candy bars and coffee consumed by the >System 7.0 writers while they waited on CFront ... I'm sure the system software people are developing on something faster than a Mac Plus... :-) { and maybe even something faster that a IIci, maybe, perhaps, please.. :-) :-) } But that still doesn't excuse the lack of pre-compiled headers. -- \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\|///////////////////////////////////////// David M. O'Rourke____________________|_____________dorourke@polyslo.calpoly.edu | Graduating in March of 1990, with a BS in Computer Science & need a Job. | |_____________________________________________________________________________|
chuq@Apple.COM (Chuq Von Rospach) (10/17/89)
> I'm sure the system software people are developing on something faster >than a Mac Plus... :-) Most people around here seem to have Mac II's. Some have IIx's, but when you're selling every machine you can make of a model, you generally don't allocate them internally unless you need to -- and Mac II's work just fine. >{ and maybe even something faster that a IIci, >maybe, perhaps, please.. :-) :-) } faster? of course. Just wait until you see the new 37.6MHz Apple III/GS.... chuq (oops. shouldn't have said that...) -- Chuq Von Rospach <+> Editor,OtherRealms <+> Member SFWA/ASFA chuq@apple.com <+> CI$: 73317,635 <+> [This is myself speaking] Anyone who thinks that the argument over {sci,rec}.fishies is about group names doesn't understand the system.
jnh@ecemwl.ncsu.edu (Joseph N. Hall) (10/18/89)
In article <1989Oct17.161431.18416@polyslo.CalPoly.EDU> dorourke@polyslo.CalPoly.EDU (David M. O'Rourke) writes: >jnh@ecemwl.UUCP (Joseph N. Hall) writes: >> [talks about slow C++ on a Macintosh Plus >> >>I wish I could see the amount of candy bars and coffee consumed by the >>System 7.0 writers while they waited on CFront ... > > I'm sure the system software people are developing on something faster >than a Mac Plus... :-) { and maybe even something faster that a IIci, >maybe, perhaps, please.. :-) :-) } > Silly me; I neglected to mention running it on the IIcx, too. I wouldn't describe it as speedy there, either. I haven't tried compiling with the MacApp headers (since I don't have MacApp it would just be for kicks) but I anticipate that this is probably too strenuous an exercise for a Mac Plus, even with 4 MB. > But that still doesn't excuse the lack of pre-compiled headers. >-- Well, I can see how this is kind of a tricky issue since you have to deal with "precompiling" C++ source, i.e., dumping and loading the gobbledygook that CFront needs. I doubt that you could ever use a precompiled header on the subsequent pass with the C compiler, but maybe there is some trick that could be useful. Since C++ headers tend to be longer and more difficult to compile than normal C headers, a dump/load feature would really be useful. Difficult, though. (Another problem would be whether it will be incorporated by AT&T or Apple.) Personally, I think this would be easier for a pure C++ compiler like G++. Speaking of which, has anyone got G++ running under A/UX yet? Sure, I know this is heresy ... v v sssss|| joseph hall || 4116 Brewster Drive v v s s || jnh@ecemwl.ncsu.edu (Internet) || Raleigh, NC 27606 v sss || SP Software/CAD Tool Developer, Mac Hacker and Keyboardist -----------|| Disclaimer: NCSU may not share my views, but is welcome to.
lsr@Apple.COM (Larry Rosenstein) (10/18/89)
In article <4208@ncsuvx.ncsu.edu> jnh@ecemwl.ncsu.edu (Joseph N. Hall) writes: > up into 4 parts to illustrate a kind of one-class-one-file approach to > OOP. This means, of course, that all of these header files are processed > 4 times by cfront ... One trick that people use is to make a "master" .c file that includes the normal .c files (each containing 1 class). In the cases where you know that you are going to compile a 4 classes, you are better off compiling the master .c file and parsing the headers only once. > Naturally, there is no #pragma load for cfront. Not only do you have to > include _more_ headers with cfront, you can't pre-compile them, and they > are processed more slowly by cfront than by c, THEN they have to be > processed by C, and they STILL can't be pre-compiled. The headers are only processed by CFront. The output of CFront is C code with all the headers & macros expanded. #pragma dump/load is high on the list of enhancements for CFront. As you said, it isn't a trivial addition. I don't know if this will be in C+ 3.1 final. (As a C++ user, I hope so.) > Cfront and C include special "gibberish" switches (-z3) that produce > and read (respectively) special non-TEXT output; these aren't documented This is a performance improvement. CFront outputs a token stream which is directly read by the C compiler. This avoid having to re-parse the output from CFront. You can ask to see the generated C code with the -c option to CPlus. > are used in the CPlus script. The result, when there's an error that isn't > caught by cfront but which is caught by C, is something like: Any error that is reported by the C compiler is a bug in CFront, no question about it. CFront is supposed to catch all the program syntax errors, so you should never see errors reported by the C compiler. Larry Rosenstein, Apple Computer, Inc. Object Specialist Internet: lsr@Apple.com UUCP: {nsc, sun}!apple!lsr AppleLink: Rosenstein1
jnh@ecemwl.ncsu.edu (Joseph N. Hall) (10/18/89)
In article <4801@internal.Apple.COM> lsr@Apple.COM (Larry Rosenstein) writes: >Any error that is reported by the C compiler is a bug in CFront, no >question about it. CFront is supposed to catch all the program syntax >errors, so you should never see errors reported by the C compiler. (If you're still there!) Then this is the shortest amount of time it's ever taken me to find a compiler bug ... about 2 hours. The actual error message was: # ? ### Error 213 Field name expected ---------------------------------------------------------------- File "test.cp"; Find *!743:$!1; Open "{Target}" #--------------------------------------------------------------- I had a class which had overloaded methods named X() and X(int arg), respectively, used in the Smalltalk sense (obj.X() returns the value of member x and obj.X(arg) sets member x to arg), and was doing something like this: objPtr->X instead of objPtr->X() It was perfectly repeatable, and maybe I'll try out the Outside Bug Reporter now that (as a sort of beta tester) I'm actually allowed/encouraged to use it. v v sssss|| joseph hall || 4116 Brewster Drive v v s s || jnh@ecemwl.ncsu.edu (Internet) || Raleigh, NC 27606 v sss || SP Software/CAD Tool Developer, Mac Hacker and Keyboardist -----------|| Disclaimer: NCSU may not share my views, but is welcome to.