jeffb.bbs@shark.cs.fau.edu (Jeffrey Boser) (02/13/91)
with all the postings complaining about THINK C not being C++, i have a few questions: 1) my think C manual says it is upwards compatable with c++, meaning think C is lacking something in c++. what exactly is it lacking? 2) from previous conflicts of similar nature (some people think that their way of doing something is the only way), such decisions are usually based on ignorance. (usually, not always. remember attitudes about the mac when it first came out?) why is c++ so important that it precludes all alternatives? and does it have anything to do with 1? 3) if the state of the art (in mac programming) moves toward that, what will be the consequences? remember, the toolbox is based on a pascal library. c is not a good initial language for the mac. thanks in advance for any replys. .....Jeff jeffb.bbs.@shark.cs.fau.edu
marc@Apple.COM (Mark Dawson) (02/13/91)
In article <cwmaX1w163w@shark.cs.fau.edu> jeffb.bbs@shark.cs.fau.edu (Jeffrey Boser) writes: >with all the postings complaining about THINK C not being C++, >i have a few questions: > >1) my think C manual says it is upwards compatable with c++, meaning > think C is lacking something in c++. what exactly is it lacking? C++ supports o data abstraction the data needed by that code is local to that code; if you want access to that data, you have to ask the code ("object") to get it for you) o inheritance you can derive a new user-defined type from an old one and make changes only where you need them--in theory this makes for easier code reuse) o polymorphism the actual creating of a new user-defined type that can inherit (or not) properties of the old type, plus add something. For example, you could have a type "oval" that draws an oval. Using polymorphism, you could derive a sub-type called "circle" that uses (inherits) all of "oval"'s drawing routines, but defines that the x & y axises (sp?) are the same. o Function overloading Allows you to define a function that takes different types--you could define x(double y) AND x(int y)...you would write two routines && the compiler would route the call to the correct routine, depending on the passed parameter. o Operator overloading Allows you to redefine how an operator works with a type--for example, if you used operator overloading when defining a Str255, you could do: x = x + "hello world" + "\phello world II"; it would concatenate both strings (using function overloading to concatenate first a C string and then a Pascal string. These are all used in the "object-oriented" concept. Obviously, this power allows you to write even worse code than in C; it can also help you write better (easier to read) code. > >2) from previous conflicts of similar nature (some people think that their > way of doing something is the only way), such decisions are usually > based on ignorance. (usually, not always. remember attitudes about > the mac when it first came out?) why is c++ so important that it > precludes all alternatives? and does it have anything to do with 1? > I assume this relates to Apple converting its MacApp over to C++. At the MacApp conference last week Apple (note that I work at Apple, but in these instances, I'm a 3rd party developer just like a lot of you) gave some reasons: (1) A lot of corporate development houses are very standards-oriented. They wish to use object-oriented languages and the only commercial standards are Smalltalk and C++. It sounded like it was getting hit with a "toy language on a toy computer" argument. Apple wanted to convince more programmers to develop; to do so I got the impression that they felt that they needed to start using a commercially standard langauge. (2) Apple's internal development is very quickly going to C++ (it was mentioned that the sys 7.0 finder was written in C++); the MacApp team didn't want to be constantly porting code that they'd like to use from C++ to Object Pascal, plus they'd like to take advantage (when they can) of some of the large body of C++ objects/classes that are available (they mentioned stuff like sorting routines). So it boils down to that Apple feels it needs to provide its next generation support in a more commercial language, C++. They feel that the development community (the whole one--MSDOS, Unix, etc world) is moving towards using C++ as its standard, so its in Apple's interest to provide support for it. Its not that C++ is better, its just more commercial && its hoped that it will attract more cross-developers (this could make it easier for Mac programs to be ported to other platforms, but since the Mac only holds 10-15% of the market, Apple is gambling that it'll see more programs moving the other way). _ >3) if the state of the art (in mac programming) moves toward that, what > will be the consequences? remember, the toolbox is based on a pascal > library. c is not a good initial language for the mac. > By using C++, you can actually make very Pascal-like calls to the toolbox, plus as readable code (examples taken from Object Pascal-C++ conversion talk at the conference ---- Pascal ----- PROCEDURE TView.Resize (width, height:VCoordinates); BEGIN IF (fSize.h <> width) | (fSize.v <> height) THEN SetVPt(delta,width-fSize.h,height-fSize.v); fSize.h := width; fSize.v := height; END; PROCEDURE foo(**); BEGIN saveIt : PenState; GetPenState(saveIt); SetPenState(saveIt); END; ----- C++ ------- pascal void TView::Resize(VCoordinate width,VCoordinate height) { VPoint pt {width, height}; if (fSize != pt) delta = pt = fSize; fSize = pt; } pascal void GetPenState (PenState &pnState); pascal void SetPenState (const Penstate &pnState); void foo() { PenState saveIt; GetPenState(saveIt); SetPenState(saveIt); } ---- So, you can see that C++ can allow you to more easily code toolbox routines; you don't have to worry about when to use C's '&' (address of) operator. Hope this helps, Mark -- --------------------------------- Mark Dawson Service Diagnostic Engineering AppleLink: Dawson.M Apple says what it says; I say what I say. We're different ---------------------------------
siegel@endor.uucp (Rich Siegel) (02/14/91)
In article <49114@apple.Apple.COM> marc@Apple.COM (Mark Dawson) writes: >>1) my think C manual says it is upwards compatable with c++, meaning >> think C is lacking something in c++. what exactly is it lacking? >C++ supports > o data abstraction the data needed by that code is local to that > code; if you want access to that data, you have to ask > the code ("object") to get it for you) > o inheritance you can derive a new user-defined type from an old one > and make changes only where you need them--in theory this > makes for easier code reuse) > o polymorphism the actual creating of a new user-defined type that can > inherit (or not) properties of the old type, plus add > something. For example, you could have a type "oval" > that draws an oval. Using polymorphism, you could derive > a sub-type called "circle" that uses (inherits) all of > "oval"'s drawing routines, but defines that the x & y > axises (sp?) are the same. Actually, THINK C does support all three of these things; you can write your own methods to abstract the instance variables of an object. What THINK C does not provide is compiler-enforced abstraction through the use of keywords such as "private", "protected", and "friend". THINK C supports the Object Pascal model of inheritance, that is, a class can inherit its characteristics from only one superclass. C++ supports multiple inheritance, in which a class can derive its characteristics from more than one superclass. In your description, you've confused inheritance and polymorphism; in fact, both of the things you describe (inheriting characteristics from an ancester class and overriding the inherited behavior) are features of the inheritance model. Polymorphism means that you can have to disjoint types of object which both have a message of the same name, but the name means different things for each class. Consider: TYPE Shape = object procedure Draw; end; Square = object (Shape) sideLength : Integer; procedure Draw; Override; end; Oval = object(Shape) majorAxis : Integer; minorAxis : Integer; procedure Draw; Override; end; The "Draw" message has different meaning to an Oval object than it has to the "Square" object. R. Rich Siegel Symantec Languages Group Internet: siegel@endor.harvard.edu "I was just trying to be subtle. That's my job, isn't it?"
mce@tc.fluke.COM (Brian McElhinney) (02/14/91)
jeffb.bbs@shark.cs.fau.edu (Jeffrey Boser) writes: >1) my think C manual says it is upwards compatable with c++, meaning > think C is lacking something in c++. what exactly is it lacking? For starters, THINK C lacks classes, constructors, destructors, operator overloading, inline functions, non-virtual methods, friends, and user-defined conversion rules. And more. IMHO the only significant C++ feature THINK C has is inheritance of structures. Very different than C++ classes. Comparing THINK C to C++ is like comparing prostitutes and nuns: both are women, but you would be disappointed if you expected one and got the other. >2) from previous conflicts of similar nature (some people think that their > way of doing something is the only way), such decisions are usually > based on ignorance. (usually, not always. remember attitudes about > the mac when it first came out?) why is c++ so important that it > precludes all alternatives? and does it have anything to do with 1? Usage of C++ is, according to some, doubling every year. That rapid growth means lots of reusable classes, and lots of different compilers for lots of different machines. Why invest your effort in a single-vendor language that is only available on one platform? >3) if the state of the art (in mac programming) moves toward that, what > will be the consequences? remember, the toolbox is based on a pascal > library. c is not a good initial language for the mac. The most important, long-range consequence, is that it will be easier to port Mac software to other machines. Which could in turn convince Apple that it is a software company. Nah. Wishful thinking. If you want to develop object oriented software, C++ is the safest choice at the moment. So it has become popular, which makes it even safer. I abhor some of the compromises in C++, but it is here to stay. Brian McElhinney "The two most common things in the universe are mce@tc.fluke.com hydrogen and stupidity." --Harlan Ellison
jspencer@p510.f22.n282.z1.mmug.edgar.mn.org (Jim Spencer) (02/16/91)
Rich Siegel writes in a message to All >>1) my think C manual says it is upwards compatable with c++, meaning >> think C is lacking something in c++. what exactly is it lacking? >C++ supports > o data abstraction the data needed by that code is local to that > code; if you want access to that data, you have to ask > the code ("object") to get it for you) >... RS> Actually, THINK C does support all three of these things; you RS> can write your own methods to abstract the instance variables RS> of an object. What THINK C does not provide is compiler-enforced RS> abstraction through the use of keywords such as "private", "protected", RS> and "friend". There's a couple of other C++ features that probably more directly relate to data abstraction than the data hiding you describe. C++ provides for operator and function overloading, i.e. it permits you to cause both operators and functions to work in new ways based on the type of the data being operated on or passed to the function. Thus if you are creating an abstract data type of type "complex" you can define a function which will describe what, say the '+' operator will do when it adds two complex numb ers and/or a complex number and an integer. Similarly, you can have two different functions named foo: foo(int); foo(double); and the correct function of the data type passed will be called. There are a few other things that Think C doesn't support that C++ does: - double slash comments - default arguments - constructors and destructors - the virtual keywords (effectively all Think C member functions are declared virtual. I think but am not sure that Think C does not support inline functions. -- Jim Spencer (jspencer@mmug.edgar.mn.org) UUCP: ...jhereg!tcnet!vware!edgar!mmug!jspencer FidoNet: 1:282/22.510 --
paul@u02.svl.cdc.com (Paul Kohlmiller) (02/19/91)
jeffb.bbs@shark.cs.fau.edu (Jeffrey Boser) writes: >1) my think C manual says it is upwards compatable with c++, meaning > think C is lacking something in c++. what exactly is it lacking? >2) from previous conflicts of similar nature (some people think that their > way of doing something is the only way), such decisions are usually > based on ignorance. (usually, not always. remember attitudes about > the mac when it first came out?) why is c++ so important that it > precludes all alternatives? and does it have anything to do with 1? I think Think C is missing the keywords class and friend and the notions that these keywords represent (someone who know C++ better than I should explain whatever it is I just said). At this particular moment in time, C++ is perhaps the most portable language around. C comes in many different flavors and when the world (and THINK C) is completely ANSI then this might change. So if you want to port some code to the Mac it would be nice to be able to port C++ code. The PC folks have Turbo C++ which also supports ANSI C. It is the lack of a similar product that really gripes those of us who want to use C++ on a Mac but who don't want to do the whole MPW thing. >3) if the state of the art (in mac programming) moves toward that, what > will be the consequences? remember, the toolbox is based on a pascal > library. c is not a good initial language for the mac. You're absolutely right. But more and more code is being written in C++ and MacApp can handle either Object Pascal or C++. Now, which of those two languagesis more portable? -- // Paul H. Kohlmiller // "Cybers, Macs and Mips" // // Control Data Corporation // Internet: paul@robin.svl.cdc.com // // All comments are strictly // America Online: Paul CDC // // my own. // Compuserve: 71170,2064 //
oster@well.sf.ca.us (David Phillip Oster) (02/19/91)
In article <1991Feb14.004044.6847@tc.fluke.COM> mce@tc.fluke.COM (Brian McElhinney) writes: >Usage of C++ is, according to some, doubling every year. That rapid growth >means lots of reusable classes, and lots of different compilers for lots of >different machines. What reusable classes are available? Where? From whom? How much? -- -- David Phillip Oster - At least the government doesn't make death worse. -- oster@well.sf.ca.us = {backbone}!well!oster
mce@tc.fluke.COM (Brian McElhinney) (02/20/91)
oster@well.sf.ca.us (David Phillip Oster) writes: >In article <1991Feb14.004044.6847@tc.fluke.COM> mce@tc.fluke.COM (Brian McElhinney) writes: >>Usage of C++ is, according to some, doubling every year. That rapid growth >>means lots of reusable classes, and lots of different compilers for lots of >>different machines. >What reusable classes are available? >Where? >From whom? >How much? You misunderstood. C++ is a *very* young language. It is entering the *beginning* of its useful life, not the middle or end (whereas C is in its middle age, and Object Pascal is forever young, doomed as it is to a niche existence). At present, most C++ classes are spread like folk tales, on an individual basis. Not the best quality. However, there are some "real" C++ classes available. I've not had time to research production-quality classes, but I've briefly looked at the GNU g++ library (forest approach), and the software from Gorlen, et al, (tree approach). When the Booch Components Library is out (later this year?) it will go to the top of the list. Because they have the most incentive, the largest and most productive concentration of reusable software will *always* be proprietary to individual companies. They have the advantage in that 1) such software is very close at hand, 2) its pedigree -- defect reports, test history, authors -- is well known, and 3) the company is almost certainly developing similar follow-on products. But somehow I think you have a hidden agenda here. Don't like C++, perhaps? Don't blame you. But sniping at the perceived availability of reusable classes is not going to make it go away. Brian McElhinney "If always without desire, one can observe marvels; if mce@tc.fluke.com always desireous, one sees merest traces." Lao-Tzu