ross@unc.cs.unc.edu (Judy Ross) (02/02/89)
I am currently in search of c++ for the Macintosh. I have heard that one product is available from OASYS. Has anyone had any experience with their c++ or with their company in general that can help us decide whether or not we should go for their product? Thanks, Judy Ross ross@compsci.unc.edu (919)962 - 1789 ******************************************************************************
shebanow@Apple.COM (Andrew Shebanow) (02/02/89)
Apple is working on a version of C++ that runs under the Macintosh
Programmer's Workshop (MPW). It is currently undergoing some
limited alpha testing. Beta versions will be available from
APDA sometime within the next 1-2 months.
I believe that OASYS's C++ only runs under Apple's UNIX system.
It is a vanilla C++, without any of the Mac extensions that
our C++ will have (support for SANE floating point, ability to
call pascal routines, etc).
Andrew Shebanow, Futurist, Developer Technical Support, Apple Computer, Inc.
------------------------------------------------------------------------------
INTERNET: shebanow@apple.com
UUCP: {decwrl, hoptoad, nsc, sun, amdahl}!apple!shebanowross@fillmore.cs.unc.edu (Judy Ross) (02/03/89)
In article <6482@thorin.cs.unc.edu>, ross@unc.cs.unc.edu (Judy Ross) writes: > ...in search of c++ for the Macintosh. I have heard that > one product is available from OASYS. Has anyone had any experience... ? > > Thanks, > Judy Ross > ross@compsci.unc.edu ^^^^^^^^^^^^^^^^^^^^ Sorry, that should be : ross@cs.unc.edu > (919)962 - 1789
mce@tc.fluke.COM (Brian McElhinney) (07/13/89)
According to the 7/10/89 PCWEEK, Glockenspiel will be releasing CommonView and a C++ compiler for the Macintosh "by the first week of December". CommonView is a generic application, along the lines of MacApp (implements windows, scrollbars, etc). The major difference is that your CommonView program can be "easily" (and legally) ported to other platforms. Can anyone contrast it with MacApp? This brings the list of Macintosh C++ vaporware to three: Apple (available in beta Real Soon Now, but under slooow MPW), Symantec/THINK (who knows when, but presumably it will be fast), and now Glockenspiel (also runs under MPW?). ObjectWorks (by ParcPlace) is being ported to "other platforms", and the Macintosh seems like an obvious candidate. Then again, at $2495 they might not get much business! Brian McElhinney mce@tc.fluke.com
ech@cbnewsk.ATT.COM (ned.horvath) (07/19/89)
From article <9598@fluke.COM>, by mce@tc.fluke.COM (Brian McElhinney): ... > This brings the list of Macintosh C++ vaporware to three: Apple (available in > beta Real Soon Now, but under slooow MPW), Symantec/THINK (who knows when, but > presumably it will be fast), and now Glockenspiel (also runs under MPW?). That is not entirely accurate (where's Rich?): Symantec/THINK has stated that they intend to support some kind of O-O C extension someday. They did demo a prerelease "Object C" at January MacWorld. It ISN'T C++, and it ISN'T announced. Thus the term "vaporware" is unfair to Think. Of course, holding your breath for a Think product could be unfair, too... I'd be interested in some details about the Glockenspiel product. One of the uglier aspects of the announced MPW C++ is that you won't be able to mix the handle-based Object Pascal class library -- including MacApp -- with the pointer-based C++ class library (both will be supported, but they will not be able to inherit from each other). If the Glockenspiel app shell is integrated smoothly with the C++ 2.0 library, it will have clear advantages. Also, the full power of MPW C++ will be available ONLY in applications: method dispatching will use global variables, which the brain-damaged MPW linker STILL insists must be A5-relative. =Ned Horvath=
isle@eleazar.dartmouth.edu (Ken Hancock) (07/20/89)
[Stuff about various C++'s available deleted...] Actually, according to Symantech's rep at Boston Computer Society's meeting a few weeks ago, LSC 4.0 is due out later this fall. The bad news is it will only support partial implementation of C++. We'll have to wait for LSC 5.0 for full C++ implementation I guess. Ken Ken Hancock '90 | BITNET/UUCP/ Personal Computing Ctr Consultant | INTERNET: isle@eleazar.dartmouth.edu -----------------------------------+---------------------------------------- DISCLAIMER? I don't get paid enough to worry about disclaimers.
tim@hoptoad.uucp (Tim Maroney) (07/20/89)
In article <654@cbnewsk.ATT.COM> ech@cbnewsk.ATT.COM (ned.horvath) writes: >Also, the full power of MPW C++ will be available ONLY in applications: >method dispatching will use global variables, which the brain-damaged >MPW linker STILL insists must be A5-relative. So? You can write your own A5 management in code resources under MPW. I've done this -- it's pretty easy. The only thing I couldn't manage was initialization to non-zero values (and if I'd spent a few days on it, I'm sure I could have cracked that too -- it just didn't seem very important). It's not as easy as under Lightspeed C, granted, but it's hardly as close to impossible as you're saying. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "I am convinced that cross-posting is an evil Satanic plot." -- Eugene Miya on soc.net-people, misc.headlines, misc.kids, misc.misc, news.misc, and soc.misc
siegel@endor.harvard.edu (Rich Siegel) (07/21/89)
In article <14505@dartvax.Dartmouth.EDU> isle@eleazar.dartmouth.edu (Ken Hancock) writes: >Actually, according to Symantech's rep at Boston Computer >Society's meeting a few weeks ago, LSC 4.0 is due out later 1) The "Symantec rep" was Michael Kahl, the principal author of LightspeedC. 2) A press release announcing version 4.0 went out yesterday (see my posting on comp.sys.mac, which contains the full text of that press release). According to the release, THINK C 4.0 will ship in about three weeks. >this fall. The bad news is it will only support partial >implementation of C++. We'll have to wait for LSC 5.0 >for full C++ implementation I guess. I would suggest that you investigate what is offered before passing it up; TC 4.0 offers the chief feature of C++: object orientation. And it does so in a fashion which avoids much of the confusion of C++, since the extension set is small enough to make learning the language easy. But hey, that's just this man's opinion... --Rich ~~~~~~~~~~~~~~~ Rich Siegel Staff Software Developer Symantec Corporation, Language Products Group Internet: siegel@endor.harvard.edu UUCP: ..harvard!endor!siegel "When it comes to my health, I think of my body as a temple - or at least a moderately well-managed Presbyterian youth center." - Emo Phillips ~~~~~~~~~~~~~~~
jpd00964@uxa.cso.uiuc.edu (07/24/89)
> TC 4.0 offers the chief feature of C++: object orientation
To bad they did not go with Objective C instead. A much better language.
Michael Rutman
Softmedhammersslammers1@oxy.edu (David J. Harr) (07/24/89)
Rich Siegel says:
>TC 4.0 offers the chief feature of C++: object orientation.
Now for the $64 dollar question: does TC 4.0 offer documentation explaining
how to use these extensions? TP offers exactly one paragraph on the object
oriented features of the language (can you say "minimalist documentation"?)
That is my major complaint about what is otherwise a fine product. If TC 4.0
is no better, I will probably pass on the upgrade, because it will do me no
good.
David Harr --- Sorry, no .sig yet, I used all my brain-dead ideas abovesiegel@endor.harvard.edu (Rich Siegel) (07/25/89)
In article <44174@tiger.oxy.edu> hammersslammers1@oxy.edu (David J. Harr) writes: >Now for the $64 dollar question: does TC 4.0 offer documentation explaining >how to use these extensions? TP offers exactly one paragraph on the object The documentation has chapters on the use of objects in general, and additional material on describing the use of TCL (the class library). The next revision of the THINK Pascal manual will have similar content. --Rich ~~~~~~~~~~~~~~~ Rich Siegel Staff Software Developer Symantec Corporation, Language Products Group Internet: siegel@endor.harvard.edu UUCP: ..harvard!endor!siegel "When it comes to my health, I think of my body as a temple - or at least a moderately well-managed Presbyterian youth center." - Emo Phillips ~~~~~~~~~~~~~~~
ech@cbnewsk.ATT.COM (ned.horvath) (07/25/89)
Earlier, I wrote: >Also, the full power of MPW C++ will be available ONLY in applications: >method dispatching will use global variables, which the brain-damaged >MPW linker STILL insists must be A5-relative. From article <8060@hoptoad.uucp>, by tim@hoptoad.uucp (Tim Maroney): > So? You can write your own A5 management in code resources under MPW. > I've done this -- it's pretty easy. The only thing I couldn't manage > was initialization to non-zero values (and if I'd spent a few days > on it, I'm sure I could have cracked that too -- it just didn't seem > very important). It's not as easy as under Lightspeed C, granted, > but it's hardly as close to impossible as you're saying. Shucks, Tim, I wrote that part of the Aztec linker, including nonzero initialization. But when you are talking C++, you ARE talking about nonzero initialization, and running new() overloads as part of that initialization. And when you are talking about method-dispatch tables, you are talking about data initialized from information provided only by the compiler and effectively usable by the linker alone. Yes, I suppose I could ask the MPW linker to create a symbol table, and I suppose I could write a "post-linker" to put that information into a resource where my DA's open could find it, and I suppose I might even be able to track changes in Apple's C++ and MPW naming conventions and object-file symbol conventions for my own personal use. Or I suppose I could write my own linker to do it "right." Perhaps you could, too. So I'll rephrase my original statement, thus: unless you are a Maroney- class guru, and you are prepared to do one shitload of work, you aren't going to be using virtual methods in non-applications any time soon. =Ned Horvath=
siegel@endor.harvard.edu (Rich Siegel) (07/25/89)
In article <669@cbnewsk.ATT.COM> ech@cbnewsk.ATT.COM (ned.horvath) writes: > >So I'll rephrase my original statement, thus: unless you are a Maroney- >class guru, and you are prepared to do one shitload of work, you aren't >going to be using virtual methods in non-applications any time soon. I guess Mike Kahl is a Maroney-class :-) guru, then, because THINK C 4.0 lets you write *anything* using Object C. Applications, DA's, drivers, cdevs, inits, whatever. And non-applications can consist of multiple segments. --Rich ~~~~~~~~~~~~~~~ Rich Siegel Staff Software Developer Symantec Corporation, Language Products Group Internet: siegel@endor.harvard.edu UUCP: ..harvard!endor!siegel "When it comes to my health, I think of my body as a temple - or at least a moderately well-managed Presbyterian youth center." - Emo Phillips ~~~~~~~~~~~~~~~
mnkonar@manyjars.SRC.Honeywell.COM (Murat N. Konar) (07/25/89)
In article <227700015@uxa.cso.uiuc.edu> jpd00964@uxa.cso.uiuc.edu writes: > >To bad they did not go with Objective C instead. A much better language. True enough for applications I suppose. But I wonder if Objective C could do WDEFs, CDEFs (ie. stand alone code) and still take advantage of object orientedness (can C++?). Also, and probably more important, Objective C is a proprietary product of Stepstone, Inc. and they charge in the neighborhood of $2500 for the Sun version of Objective C. So even if THINK could get Stepstone to allow an Objective C clone for the Mac, it is likely that it would be mondo expensivo. ____________________________________________________________________ Have a day. :^| Murat N. Konar Honeywell Systems & Research Center, Camden, MN mnkonar@SRC.honeywell.com (internet) {umn-cs,ems,bthpyd}!srcsip!mnkonar(UUCP)
falken@apple.com (Dave Falkenburg) (07/26/89)
In article <2271@husc6.harvard.edu> siegel@endor.harvard.edu (Rich Siegel) writes: > >how to use these extensions? TP offers exactly one paragraph on the object > > The documentation has chapters on the use of objects in general, > and additional material on describing the use of TCL (the class library). Just one little obnoxious question: is the "Object C" in your product a subset of C++ in SYNTAX as well as features? I only ask because I'd like to know if I can take THINK C sources and later recompile them under a full C++ 2.0 system later... -dave falkenburg apple computer, inc. dislaimer: my opinions are my own and not always those of my employer
siegel@endor.harvard.edu (Rich Siegel) (07/26/89)
In article <3098@internal.Apple.COM> falken@apple.com (Dave Falkenburg) writes: > >Just one little obnoxious question: is the "Object C" in your product a >subset of C++ in SYNTAX as well as features? I only ask because I'd like Yes. R. ~~~~~~~~~~~~~~~ Rich Siegel Staff Software Developer Symantec Corporation, Language Products Group Internet: siegel@endor.harvard.edu UUCP: ..harvard!endor!siegel "When it comes to my health, I think of my body as a temple - or at least a moderately well-managed Presbyterian youth center." - Emo Phillips ~~~~~~~~~~~~~~~
tim@hoptoad.uucp (Tim Maroney) (07/27/89)
In article <669@cbnewsk.ATT.COM> ech@cbnewsk.ATT.COM (ned.horvath) writes: >Shucks, Tim, I wrote that part of the Aztec linker, including nonzero >initialization. But when you are talking C++, you ARE talking about >nonzero initialization, and running new() overloads as part of that >initialization. And when you are talking about method-dispatch tables, >you are talking about data initialized from information provided only >by the compiler and effectively usable by the linker alone. I haven't been keeping up with Stroustrup's work lately, and the closest I've ever been to a C++ system was a technical manual, so I don't know whether you're right or not. What is all this initialization used for? The last time I looked, you couldn't use function pointers as initializers in MPW C because they aren't compile-time constants. Method dispatch tables have to be initialized explicitly at run-time if they point to functions. Will the MPW C++ system put out function offset tables or something for initialization? >Yes, I suppose I could ask the MPW linker to create a symbol table, and I >suppose I could write a "post-linker" to put that information into a >resource where my DA's open could find it, and I suppose I might >even be able to track changes in Apple's C++ and MPW naming conventions >and object-file symbol conventions for my own personal use. Or I suppose >I could write my own linker to do it "right." Perhaps you could, too. Assuming that you do need non-zero initialization, then it shouldn't be as hard as this. The linker already puts out tables describing extern initialization in a resource; these tables are traversed by a routine in the C run-time library. There are probably a few tricks involved in putting these pieces together for non-application code resources, but I doubt it would be more than a few days to figure it out -- and once once person figures it out, anyone can use their solution. I didn't bother because I generally prefer my externs and statics to be initialized to zero regardless.... >So I'll rephrase my original statement, thus: unless you are a Maroney- >class guru, and you are prepared to do one shitload of work, you aren't >going to be using virtual methods in non-applications any time soon. That's so sweet. But like I said, I really don't believe it's all that much work for anyone but the first person. It would be nice if Apple would just provide the solution themselves, but they do provide the pieces, anyway. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "Satanic is merely the name they give to the behavior of those who would disrupt the orderly way in which men want to live." -- Gabrielle, THE VAMPIRE LESTAT, Anne Rice
jpd00964@uxa.cso.uiuc.edu (07/28/89)
> Objective C is a proprietary product > of Stepstone, Inc. and they charge in the neighborhood of $2500 for > the Sun version of Objective C Strange. I got mine free with my NeXT machine. I'm sure they have different prices for different machines. After all, it is really only a SmallTalk pre-processor for a standard C processor with some small runtime routines thrown in. Michael Rutman Softmed
awd@dbase.UUCP (Alastair Dallas) (07/29/89)
Rich Siegel says he posted the full text of a press release regarding THINK C 4.0. I have to believe him; who would lie about a thing like that? :-) However, I can't find it at our site and I would be very, very interested. Also, I read this group and comp.sys.mac fairly regularly, so I'm pretty sure there was some kind of transmission loss. Anyway, Rich, please repost (or send email if you're sure everyone but me got the original). Thanks in advance. /alastair/
hiebert@mdivax1.uucp (Graeme Hiebert) (07/31/89)
In article <180@dbase.UUCP> awd@dbase.UUCP (Alastair Dallas) writes: > > Rich Siegel says he posted the full text of a press release regarding > THINK C 4.0. I have to believe him; who would lie about a thing like that? :-) > However, I can't find it at our site and I would be very, very interested. > Also, I read this group and comp.sys.mac fairly regularly, so I'm pretty > sure there was some kind of transmission loss. > > Anyway, Rich, please repost (or send email if you're sure everyone but me > got the original). Thanks in advance. > > /alastair/ I don't think we ever got it at this site either. -g -- "I didn't sleep well last night. This girl kept knocking on my hotel room door. After awhile, I had to get up and let her out." -Henny Youngman Graeme Hiebert (hiebert@mdivax1.uucp, ...{uunet,ubc-cs}!van-bc!mdivax1!hiebert)
ech@cbnewsk.ATT.COM (ned.horvath) (08/05/89)
Earlier, I wrote: >So I'll rephrase my original statement, thus: unless you are a Maroney- >class guru, and you are prepared to do one shitload of work, you aren't >going to be using virtual methods in non-applications any time soon. From article <2278@husc6.harvard.edu>, by siegel@endor.harvard.edu (Rich Siegel): > I guess Mike Kahl is a Maroney-class :-) guru, then, because THINK > C 4.0 lets you write *anything* using Object C. Applications, DA's, > drivers, cdevs, inits, whatever. And non-applications can consist of > multiple segments. Gees, Rich, read the WHOLE article, willya?? My point was with respect to the forthcoming MPW C++ (please note the MPW, a product of a company not yet owned by Symantec). And my point was precisely that Apple is the only major compiler supplier that doesn't provide adequate runtime support for non-apps. There's no excuse for this shortcoming, particularly in view of all of Apple's "become object-oriented or die!" hype. It is right and proper for Kahl to provide such support; it is inappropriate for customers of MPW to have to roll their own. =Ned=
jasons@frosty.CNA.TEK.COM (Jason Scheck) (08/05/89)
I just got my Think C 4.0 upgrade notice, and found it to be somewhat confusing. I quote the last two lines of one of the paragraphs in the letter. > The object extensions inTHINK C are similar to Object Pascal as defined > by Apple Computer. The syntax is based on C++, and is upwardly > compatible with C++. The last sentence gets me. From what has been set on this newsgroup, Think C doesn't support operator overloading, among other C++ features. So how is it that its _syntax_ is compatible with C++, without having its features. For instance, if I give it the text: class A { public: ... A& operator=(int); ... }; which is syntax accepted by cfront, how can Think C accept it without supporting operator overloading. Was some marketing person at Symantec somewhat overzealous? Jason Scheck jasons@tekred.CNA.TEK.COM
siegel@endor.harvard.edu (Rich Siegel) (08/05/89)
In article <4400@tekred.CNA.TEK.COM> jasons@frosty.CNA.TEK.COM (Jason Scheck) writes: >I just got my Think C 4.0 upgrade notice, and found it to be somewhat >confusing. I quote the last two lines of one of the paragraphs in the >letter. > >> by Apple Computer. The syntax is based on C++, and is upwardly >> compatible with C++. > >The last sentence gets me. From what has been set on this newsgroup, >Think C doesn't support operator overloading, among other C++ >features. So how is it that its _syntax_ is compatible with C++, >without having its features. For instance, if I give it the text: You're misinterpreting, I think. "Upward compatible" means that if you write a program in THINK C, you'll be able to compile with a C++ compiler, not that you can compile C++ programs with THINK C. --Rich ~~~~~~~~~~~~~~~ Rich Siegel Staff Software Developer Symantec Corporation, Language Products Group Internet: siegel@endor.harvard.edu UUCP: ..harvard!endor!siegel "When it comes to my health, I think of my body as a temple - or at least a moderately well-managed Presbyterian youth center." - Emo Phillips ~~~~~~~~~~~~~~~
awd@dbase.UUCP (Alastair Dallas) (08/08/89)
In article <4400@tekred.CNA.TEK.COM>, jasons@frosty.CNA.TEK.COM (Jason Scheck) writes: > I just got my Think C 4.0 upgrade notice, and found it to be somewhat > confusing. I quote the last two lines of one of the paragraphs in the > letter. > > > The object extensions inTHINK C are similar to Object Pascal as defined > > by Apple Computer. The syntax is based on C++, and is upwardly > > compatible with C++. > > The last sentence gets me... > > Jason Scheck > jasons@tekred.CNA.TEK.COM Your problem is that you think that "upwardly compatible" means that THINK C will compile C++ programs. What it really means is that AT&T C++ will be able to compile programs you write in THINK C. I got my notice last week, too, a few hours after I called Symantec to complain that I hadn't received it. Symantec let me order by phone with my Visa, and for $2.50 extra, they'll ship it UPS Blue! Hope this information benefits anyone out there who is as anxious as I am for 4.0. /alastair/
lsmith@apollo.HP.COM (Lawrence C. Smith) (08/09/89)
In article <4400@tekred.CNA.TEK.COM> jasons@frosty.CNA.TEK.COM (Jason Scheck) writes: >I just got my Think C 4.0 upgrade notice, and found it to be somewhat >confusing. I quote the last two lines of one of the paragraphs in the >letter. > >> The object extensions inTHINK C are similar to Object Pascal as defined >> by Apple Computer. The syntax is based on C++, and is upwardly >> compatible with C++. > >The last sentence gets me. From what has been set on this newsgroup, >Think C doesn't support operator overloading, among other C++ >features. So how is it that its _syntax_ is compatible with C++, >without having its features. For instance, if I give it the text: > > class A > { > public: > ... > A& operator=(int); > ... > }; > >which is syntax accepted by cfront, how can Think C accept it without >supporting operator overloading. Was some marketing person at Symantec >somewhat overzealous? > >Jason Scheck >jasons@tekred.CNA.TEK.COM Obviously, it can't. "Upwardly compatible" is a polite marketspeak way of saying the product in question is a "strict subset". That means, whenever both THINK C 4.0 and C++ have a feature in common, THINK C will accept the same syntax. Since both have objects, we can therefore presume that: class A { public long foobar(); } will be accepted by THINK C just as C++ accepts it. However, where they do not have features in common, no syntax is acceptable, your example fragment would be rejected. The promise of compatibility is important, though. Programs can be developed on THINK C and they *will* port to C++. However, C++ programs will *not* port to THINK C until more C++ features are added. The promise means that as the new features are added, they will be added in C++-compatible syntax. Someday, THINK C will therefore be C++-compliant. This is all perfectly standard English, Jason. Symantic hasn't made *any* wild claims. -- Larry Smith lsmith@apollo1.UUCP or {mit-eddie,yale,uw-beaver}!apollo!lsmith
jpd00964@uxa.cso.uiuc.edu (08/09/89)
> Upward compatible" means that > if you write a program in THINK C, you'll be able to compile with a C++ > compiler, not that you can compile C++ programs with THINK C. Whoopie. I should hope that you can provide that. After all, standard C should be compilable under C++. Michael Rutman Softmed jpd00964@uxa.cso.uiuc.edu