Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!newstop!sun!amdahl!key!perry
From: perry@key.COM (Perry The Cynic)
Newsgroups: comp.sys.mac.programmer
Subject: Re: MPW C++ vs. THINK C 4.0
Message-ID: <2070@key.COM>
Date: 22 Aug 90 19:10:06 GMT
References: <1990Aug15.165548.25740@midway.uchicago.edu> <2054@key.COM> <3947@husc6.harvard.edu>
Reply-To: perry@arkon.key.COM (Perry The Cynic)
Organization: Key Computer Laboratories, Fremont
Lines: 46

In article <3947@husc6.harvard.edu> siegel@endor.UUCP (Rich Siegel) writes:
> The object-oriented extensions in THINK C 4.0 are based
> on a specification which came from Apple; this spec defines a langauge
> called "C+-" or "Minimal C++"; "Object C" is also an apt name, because
> the extensions in the language are analogous to the extensions in
> Object Pascal over standard [sic] MPW Pascal. The extensions themselves
> are largely syntax-compatible with C++.

I didn't know that Apple actually perpetrated this "C+-" idea. Ah well.
Yes, "Object C" feels for all the world like an "Object Pascal" programmer's
idea on how to extend C. I can see how it got conceived; maybe they just
wanted an objectified C that could easily interface to MacApp. (And then they
turned around and implemented full C++...)

The extensions are indeed ("largely") syntax-compatible with C++. The problem
is that full C++ requires (well, allows) different programming paradigms that
won't work with C+- (e.g., reliance on implicit creators/destructors/copy
operators, and treating class types "just like" built-in types).
And yes, I know you think that's unclean. I happen to like it.

> >Non-heap class objects (at all), C++-style creators and destructors(!!),
> 
> 	In fact, THINK C 4.0 does support the definition and instantiation
> of 'direct' classes, in which the programmer is completely responsible for
> allocation and deallocation of instances of such a class. This means that
> an instance of a direct class can reside in the heap, on the stack, in
> global space, or wherever the programmer wishes to place it.

... as long as I don't mind making an explicit "here's this storage area
that I want to make into an object, please" call for every non-heap *instance*
of such a class. The compiler does not call a constructor, nor construct the
virtual table pointer automatically; but then the notion of implicit
construction and destruction doesn't exist in C+- at all. Making an Init call
for each object-typed field of a struct object I'm creating is not my idea of
fun. Besides, it's error prone. Besides, it always has virtual overhead.
Besides...

Once again, I don't want to slam Symantec or THINK C. It's a nice (almost)
ANSI C environment. It's just that personally, I want to work in genuine C++,
and I don't see any such commitment out of Symantec. You just want something
different, for whatever reasons.
  -- perry
-- 
--------------------------------------------------------------------------
Perry The Cynic (Peter Kiehtreiber)		       perry@arkon.key.com
** What good signature isn't taken yet? **  {amdahl,sgi,pacbell}!key!perry