Path: utzoo!utgpu!water!watmath!clyde!bellcore!faline!ulysses!sfmag!sfsup!shap
From: shap@sfsup.UUCP (J.S.Shapiro)
Newsgroups: comp.sys.mac
Subject: Re: C vs. Pascal for the mac, vs C for MSDOS
Summary: C++
Message-ID: <2759@sfsup.UUCP>
Date: 5 Feb 88 16:02:10 GMT
References: <697@thorin.cs.unc.edu> <2270004@hpmwtla.HP.COM>
Organization: AT&T-IS, Summit N.J. USA
Lines: 48

In article <2270004@hpmwtla.HP.COM>, garyb@hpmwtla.HP.COM (Gary Bringhurst) writes:
> ....  C++ is obviously the language of
> choice for real-world tasks _at this time_.  It addresses efficiency issues
> with inline functions, and typechecking and other protective features via the
> object-oriented extensions.  I heartily endorse the use of C++, until
> something better comes along.
> 
> Gary Bringhurst

At the risk of sounding like advertising, I have just finished a
(non Mac) large application written entirely in C++ (with the 
exception of the C library and another local utility library).
C++, once you warp your head so as to look at it correctly,
is an extremely powerful language, and for many problems, the
conceptions it forces the programmer to think in result in
smaller and faster code.

On the other side of the coin, there are some flaws that Bjarne
Stroustrop acknowledges are not straightforward to fix. Examples:

	Current version lacks an usable exception mechanism
		(setjmp doesn't work in C++ the way it does in C,
		because a stack-allocated object can create heap
		allocated objects in its constructor, and the
		longjump() doesn't let you destroy them properly.)
	
	Improper cleanup of tasks (my opinion - tasks should have
		separate heaps)
		
	Lack of graceful parameterized types. (Unless you use rather
		kludgey specially constructed macros, there is no
		way, for example, to write a generic binary tree
		class [i.e. type of tree-members not encapsulated
		in the definition of the tree] from which you could
		derive classes of specific trees)

In isolation each of these problems is straightforward. In combination
they are hard to solve well.

I think it is a very interesting question whether as PC's become
more powerful, it doesn't become very reasonable to run interpreted
garbage-collecting languages, or at least garbage collecting languages.
For those of you who will object that garbage collection takes time,
you are right, but current real-time garbage collection schemes take
a bit less than 10%, and I am think on a Mac II this might not be
a problem...

Jon