gft_robert@gsbacd.uchicago.edu (08/15/90)
---- This is basically just a repost of my earlier msg. I got only two responses, one of which was asking me to forward any info I got. So, in the thought that my subject line might have been too vague, I repost. Basically I just wanted to know if someone wanting to learn C++ has any reason to purchase MPW C++ over THINK C's C+-. I'm familiar with major differences between the two environments and I'm mainly curious about whether the syntax differences between C++ and C+- are sufficient enough to warrant purchasing MPW's C++ if you're really trying to learn C++. Any info much appreciated! Robert ============================================================================ = gft_robert@gsbacd.uchicago.edu * generic disclaimer: * "It's more fun to = = * all my opinions are * compute" = = * mine * -Kraftwerk = ============================================================================
perry@key.COM (Perry The Cynic) (08/18/90)
In article <1990Aug15.165548.25740@midway.uchicago.edu> gft_robert@gsbacd.uchicago.edu writes: > ---- > This is basically just a repost of my earlier msg. I got only two responses, > one of which was asking me to forward any info I got. So, in the thought that > my subject line might have been too vague, I repost. > > Basically I just wanted to know if someone wanting to learn C++ has any reason > to purchase MPW C++ over THINK C's C+-. I'm familiar with major differences > between the two environments and I'm mainly curious about whether the syntax > differences between C++ and C+- are sufficient enough to warrant purchasing > MPW's C++ if you're really trying to learn C++. > > Any info much appreciated! > > Robert Well, if you want to learn C++, then the main reason why you shouldn't use THINK C is that it isn't. C++, that is. They claim that it is a "subset". What they presumably mean is that THINK C code is valid C++ code. That seems true as far as it goes, but it says little about THINK C's abilities. After all, most ANSI C code is valid C++, too. The people at Symantec have decided that they want to make their own object- oriented C. That's fine by me. Just don't think that their product is anywhere near real C++. In fact, they seem to like that state of affairs. I remember sending mail to a Symantec guy on the net when their "Object C" came out, and receiving a rather nasty reply telling me to "stop whining for C++". Since then I've seen several postings from their side telling us that C++ is filthy and unclean, and Object C is so much better. I can't tell whether that is marketing rationale or a true religious belief on their part. Anyway, I can't see any kind of commitment to full, standard C++ on Symantec's part. (If I'm wrong, I'm sure somebody will tell me. Peacefully, please. :-) Even if they magically turn THINK C (n+1) into a full C++ compiler, they will hardly rewrite their object library, so it will remain stuck in the Object Pascal frame of mind. For the record, here are a few highlights of what isn't in Symantec's Object C: Non-heap class objects (at all), C++-style creators and destructors(!!), operators and function overloading (including asignment and copy operators!), references and const types; and of course the advanced stuff like multiple inheritance and operator new is Totally Out. MPW C++ is advertised as fully C++ 2.x. I can't confirm it, since I don't have it. My C++ development happens under MS-DOS, where Borland can deliver a $100 ANSI C/C++ 2.0 compiler system without requiring 4MB of RAM. Sort of like a THINK C environment with MPW capabilities... too bad it doesn't run on the Mac. -- perry Standard disclaimer: Nobody mentioned pays me anything. In fact, I paid Borland and Symantec for their products, and Apple for my Mac... -- -------------------------------------------------------------------------- Perry The Cynic (Peter Kiehtreiber) perry@arkon.key.com ** What good signature isn't taken yet? ** {amdahl,sgi,pacbell}!key!perry
siegel@endor.harvard.edu (Rich Siegel) (08/19/90)
In article <2054@key.COM> perry@arkon.key.COM (Perry The Cynic) writes: > >The people at Symantec have decided that they want to make their own object- >oriented C. That's fine by me. Just don't think that their product is anywhere 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++. >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. R. ~~~~~~~~~~~~~~~ Rich Siegel Staff Software Developer Symantec Corporation, Language Products Group Internet: siegel@endor.harvard.edu UUCP: ..harvard!endor!siegel "Who could sleep when there's a hunk with no clothes on wandering around at five in the morning, knocking over furniture?" ~~~~~~~~~~~~~~~
vladimir@prosper.Eng.Sun.COM (Vladimir G. Ivanovic) (08/20/90)
I'm curious, why doesn't Symantec declare that they're working on C++? As a user, I'm about to buy MPW C++ because they haven't announced. I'm certainly not going to buy THINK C++ after my investment in MPW C++ unless THINK C++ really blows MPW C++ away, which is unlikely. -- VLadimir, just puzzled by seemingly irrational behavior. -- -- Vladimir Vladimir G. Ivanovic vladimir@prosper.Eng.Sun.COM Sun Microsystems, Inc. or (415) 336-2315 vivanovic@Sun.COM
Chris.Parson@f54.n382.z1.FIDONET.ORG (Chris Parson) (08/22/90)
Rich,
I like Think C 4.0, but I wish there were more examples of using
it. Are any books out now or coming out that you know of that expound
on the object oriented aspects of 4.0?
Chris Parson
--
Chris Parson via cmhGate - Net 226 fido<=>uucp gateway Col, OH
UUCP: ...!osu-cis!n8emr!cmhgate!382!54!Chris.Parson
INET: Chris.Parson@f54.n382.z1.FIDONET.ORGperry@key.COM (Perry The Cynic) (08/23/90)
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
lsr@Apple.COM (Larry Rosenstein) (08/23/90)
In article <2070@key.COM> perry@arkon.key.COM (Perry The Cynic) writes: > >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 official name is Minimal C++. That was the basic idea. It provided an intermediate target for developers who wanted to support MacApp but didn't want to support full C++. (Also, I'm not sure what the state of C++ was at the time this spec was written.) >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. The explicit Init call has the advantage that initialization is separated from allocation. In the current version of C++ it is more difficult to recover from a failed constructor. As far as virtual overhead goes, C++ requires that the programmer make a decision about virtual/non-virtual for each member function. The programmer has to decide up front whether a user of the class would want to override a function. In Object Pascal (don't know about THINK Pascal/C), this optimization is made in the linker, based on how the class is used. If the function isn't overridden then there is no virtual dispatching overhead. -- Larry Rosenstein, Object Specialist Apple Computer, Inc. 20525 Mariani Ave, MS 46-B Cupertino, CA 95014 AppleLink:Rosenstein1 domain:lsr@Apple.COM UUCP:{sun,voder,nsc,decwrl}!apple!lsr
siegel@endor.uucp (Rich Siegel) (08/23/90)
> >As far as virtual overhead goes, C++ requires that the programmer make a >decision about virtual/non-virtual for each member function. The programmer >has to decide up front whether a user of the class would want to override a >function. In Object Pascal (don't know about THINK Pascal/C), this >optimization is made in the linker, based on how the class is used. If the >function isn't overridden then there is no virtual dispatching overhead. Just to fill in the gap - both THINK C and THINK Pascal will optimize monomorphic methods to avoid method dispatches. R. ~~~~~~~~~~~~~~~ Rich Siegel Staff Software Developer Symantec Corporation, Language Products Group
perry@key.COM (Perry The Cynic) (08/24/90)
In article <9896@goofy.Apple.COM> lsr@Apple.COM (Larry Rosenstein) writes: > As far as virtual overhead goes, C++ requires that the programmer make a > decision about virtual/non-virtual for each member function. The programmer > has to decide up front whether a user of the class would want to override a > function. In Object Pascal (don't know about THINK Pascal/C), this > optimization is made in the linker, based on how the class is used. If the > function isn't overridden then there is no virtual dispatching overhead. The problem is not (so much) member call dispatch overhead. The problem is the notion that every *class* necessarily needs virtual dispatching in the first place. One of the great things about C++ is that I can make encapsulated types that are *not* meant to be heap nodes. I can create class boundedInt { ... private: int value; }; with no virtual members at all, and the compiler will happily lay it out as an int with no storage overhead. Together with inline access functions I can implement a notion of bounded integer with a low enough overhead to use in place of unbounded ints. I would not try that if all my boundedInt's would take 4 bytes more (for a virtual table pointer), or if I had to make Init calls for all those integers in my program(!). Note that boundedInt's follow a *value* concept, NOT a *reference* concept. This whole idea does of course not fit with Object Pascal, where an object is inherently heap based and reference-oriented (in the SmallTalk sense). C++ classes are meant (IMHO) to implement "abstract data types", which is a true superset of "OOP objects". Note that in C++ you are still free to separate allocation and construction if you so choose. Just use a separately named constructor function. On the other hand, you can provide implicit initialization where appropriate. In my experience, the ability to *force* initialization during creation eliminates many coding problems, esp. in multi-person projects. Unfortunately, Symantec's Object C is like Object Pascal, *not* like C++, in this respect. -- perry -- -------------------------------------------------------------------------- Perry The Cynic (Peter Kiehtreiber) perry@arkon.key.com ** What good signature isn't taken yet? ** {amdahl,sgi,pacbell}!key!perry