sho@pur-phy (Sho Kuwamoto) (08/02/89)
I don't think I've seen the answers to these yet... 1) I know 4.0 isn't (and wasn't supposed to be) a full implementation of Cfront 2.0. Is exact compatibility planned? Or is this not so high on the priority list? (I'd like to see overloading and multiple inheritance, for one...) 2) Why was a new class library made to handle Mac stuff? On one hand, I am excited at the prospect, because MacApp could stand a good rewrite (have never used it, just seen it, so I could be wrong). In either case, I'm sure improvements could be made. However, MacApp *does* seem to be a very stable product, with a lot of error checking, and Apple seems committed to updating it as the System software evolves. There is some comfort in using such a de facto standard. Are there any plans for MacApp support? If (when, more like) I learn to use this class library, I will be stuck with one compiler, and it may be the case that there will be a greater lag time between the introduction of new toolbox calls and new classes. (not to be nasty. Just a thought.) 3) I bought 3.0 the same month it came out, and *still* haven't turned in the registration form. Is this going to cause any problems? Should I just send it in along with a check for $69? -Sho -- sho@risc.com <<-- flies in his eyes.
siegel@endor.harvard.edu (Rich Siegel) (08/02/89)
In article <2394@pur-phy> sho@newton.physics.purdue.edu.UUCP (Sho Kuwamoto) writes: >I don't think I've seen the answers to these yet... > >1) I know 4.0 isn't (and wasn't supposed to be) a full implementation >of Cfront 2.0. Is exact compatibility planned? Or is this not so As usual, I can't comment on future versions or unannounced products... >2) Why was a new class library made to handle Mac stuff? On one hand, [also wants MacApp support] As far as I know, MacApp doesn't exist for use with C++, and it will be a while before there is a class library from Apple that works with C++. The THINK Class Library is just as robust as MacApp is, but has the advantages of being much easier to learn, and it also incurs less code overhead in an application. We're hoping that it will become the de facto standard for C class libraries, just as THINK C is the de facto standard for C compilers. >3) I bought 3.0 the same month it came out, and *still* haven't turned >in the registration form. Is this going to cause any problems? >Should I just send it in along with a check for $69? Since you didn't register, you won't get the letter, but you can still pay the upgrade fee and get the upgrade. --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 ~~~~~~~~~~~~~~~
dgold@apple.com (David Goldsmith) (08/03/89)
In article <2346@husc6.harvard.edu> siegel@endor.harvard.edu (Rich Siegel) writes: > As far as I know, MacApp doesn't exist for use with C++, and > it will be a while before there is a class library from Apple that > works with C++. This isn't quite true. MacApp 2.0b9, available now through APDA, is compatible with MPW C++. The problem is not MacApp; the problem is that MPW C++ is not available yet. There are C++ MacApp programs running inside of Apple. In fact, the ViewEdit program which comes with MacApp has been converted to C++ (though I don't know if the version that shipped with MacApp 2.0b9 is the C++ or the original Pascal version). You should be able to do MacApp programming in C++ as soon as C++ is available. Now that AT&T has release CFront 2.0, that shouldn't be much longer (though making a prediction would be a bad idea, as it would almost certainly turn out wrong). David Goldsmith Apple Computer, Inc. AppleLink: GOLDSMITH1 BIX: dgoldsmith 20525 Mariani Avenue, MS: 77A UUCP: {nsc,dual,sun,voder,ucbvax!mtxinu}!apple!dgold Cupertino, CA 95014 CSNET: dgold@apple.com
granteri@pnet51.cts.com (Grant Erickson) (08/04/89)
Is it not also true the NEW Finder was written in C++???
Grant Erickson
._________________________________________________________.
| UUCP: {rosevax, crash, orator}!orbit!pnet51!granteri |
| ARPA: crash!orbit!pnet51!granteri@nosc.mil |
| INET: granteri@pnet51.cts.com |
|---------------------------------------------------------|
| In order to be intelligent, one must first be insane... |
!_________________________________________________________!hankin@sauron.osf.org (Scott Hankin) (08/22/89)
The following does not reflect on my opinion of Symantec at all. My dealings with them in the past have always been positive. However... I sent in my upgrade two days after I received it. Calling Symantec not only did not result in my being informed of my option to order over the phone, but the representitive was seemingly unable to look up my registration number over the phone. I was told to send in my disk if I couldn't find my registration number. The next day, the messages started appearing on the net about how I could not only order over the phone, but get 2nd day air service as well (I had already sent in my letter). Shortly thereafter, I started to read reviews from people who had received their copy. It's been nearly a month since I sent in my letter. Am I alone? Has anyone on the east coast who upgraded the slow, boring way received their copy yet? Should I be worried? Scott Hankin Open Software Foundation 11 Cambridge Center Cambridge, MA 02142 (617) 621-8815 PS: I am, admittedly, a product of MacConnection next day service. Patience has never been a virtue of mine when it came to new toys. I know the UPS drivers by their first names.
hankin@sauron.osf.org (Scott Hankin) (08/23/89)
I want to take this opportunity to commend Symantec on their responsiveness. They are obviously trying hard to achieve customer satisfaction, often going that extra mile to please the customer. Case in point: yesterday I submitted an item to this newsgroup lamenting the lack of delivery of THINK C 4.0. When I arrived home last evening, it was waiting on my doorstep. What service! Consider what must have happened. A Symantec representative must have read my submission and taken it upon themselves to rectify the situation. As they are in California and I am in New Hampshire, the rep must have realized that even Federal Express would not arrive until the next day. But they had an unhappy customer, and tomorrow just was not good enough. Dispatching a bonded courier by jet, they flew to New Hampshire, drove to my residence, and placed my upgrade on my front porch. Clear, direct action, producing a satisfying solution to the difficulty. While they could have delivered the upgrade to my office (my article did contain my work address), they rightly felt that the unobtrusive approach was the best. Clearly, this is a company which recognizes the value of customer service. We should applaud their efforts in making sure the customer comes first. Scott Hankin (hankin@osf.org) Open Software Foundation 11 Cambridge Center Cambridge, MA 02142 (617) 621-8815
mec@mtfmi.att.com (M.CONNICK) (08/23/89)
In article <535@paperboy.OSF.ORG> hankin@sauron.osf.org (Scott Hankin) writes: >Am I alone? Has anyone on the east coast who upgraded the slow, boring way >received their copy yet? Should I be worried? I mailed upgrade form along with a personal check around the 3rd of August. Symantec shipped Think C 4.0 to me on the 10th via UPS ground. It arrived yesterday, the 22nd. So I'd imagine you'll be receiving yours anyday now. UPS ground appears to be very slooooooowww! Actually I was VERY pleased at how fast Symantec shipped. They apparently do NOT wait for personal checks to clear, which is a very considerate and trusting policy. ----------------------------------------------------- Michael Connick att!mtfmi!mec 201-957-3057 AT&T Bell Labs MT 3F-113 (Dept. 79153)
tro@hx.lcs.mit.edu (Sean Trowbridge) (08/24/89)
In article <535@paperboy.OSF.ORG> hankin@sauron.osf.org (Scott Hankin) writes: > Am I alone? Has anyone on the east coast who upgraded the slow, boring way > received their copy yet? Should I be worried? I have been waiting, twiddling my thumbs, for the new upgrade which "has to come tommorrow, because I've read about so many people getting theirs so fast." And still I wait..... Sean Trowbridge MIT Lab for Computer Science. tro@hx.lcs.mit.edu Disclaimer: I'm just FNORD! a student, I don't know nothin'.
macgyver@banana.cis.ohio-state.edu (wilson m liaw) (08/25/89)
In article <1SYMmN#4k8NyD=daemon@mintaka> tro@hx.lcs.mit.edu (Sean Trowbridge) writes: >I have been waiting, twiddling my thumbs, for the new upgrade which "has >to come tommorrow, because I've read about so many people getting theirs >so fast." And still I wait..... Well, I got my upgrade yesterday. And guess what, I have two Disk 1, one Disk 3, one Disk 4, but no Disk 2. Oh well, no ANSI library for now, and no Think Class Library Demo and Starter Project either... Mac -=- Wilson Mac Liaw $ Two sure ways to tell a sexy male; Internet : macgyver@cis.ohio-state.edu $ the first is, he has a bad memory. CompuServe : 71310,1653 $ I forget the second :) GEnie : W.Liaw $
mkg@lzsc.ATT.COM (Marsh Gosnell) (08/25/89)
If you call to inquire about your order and are told it can't be found, it might not be "lost in the mail". I ordered my upgrade on 8/2 and called customer service a week ago and was told that they couldn't find my upgrade order in their database. I called them back the next day to double check before issuing a stop-payment and found out from different customer service rep that the only orders in the database were FILLED orders and there was a large stack of yet-to-be-entered orders. She found my order in that stack and said it would be entered and filled the next day (that was a week ago). I called today and was told that it shipped yesterday. Grumble, grumble. I am especially annoyed that the upgrade letter did not mention that you could upgrade at Macworld. Marsh Gosnell
jpd00964@uxa.cso.uiuc.edu (08/26/89)
I called, told them I was thinking of demoing Think C 4.0 at the next MUG, and paid for second day air ($2.50 extra), and received it in less than a week. That seemed a bit slow to me, but I am used to next day from MacConnection and two days from Direct Micro. After hearing other people, I think I am lucky now. Michael Rutman
jpd00964@uxa.cso.uiuc.edu (08/26/89)
Received my Think C 4.0 upgrade today and am going through it. I must say, I started out ordering out of obligation, not because I like C++ (I am an Objective-C addict). However, Symantic did some very good things. First, They appear to have included the commands this and inherited: These are equivelant to the self and super of Objective C which most C++ books seem to ignore. The Waite Group's does not mention the inherited: and mention this only in passing. A pity, because this is where the power really is. Second, The libraries are very well done. It is about time someone made the Mac programmable by everyone, not just someone dedicated to 6 months of banging their heads on the walls. Third, and the main reason why I like the product: THEY GIVE THEIR SOURCE CODE AWAY. That's right, I have complete documented source code for their entire library. That is what will make this a standard in my mind. A person would have to be crazy to pass up this oportunity. Even on the NeXT (which runs Objective C), I do not have source code. Anyway, here is a real important question to me: Are there different standards for C++? It seems Stroustrup and Waite group have different ideas, and Symantic seems to be running something quite different than either of those. Is it my imagination, or are there at least three standards? Michael Rutman
marti@ethz.UUCP (Robert Marti) (08/28/89)
In article <227700036@uxa.cso.uiuc.edu>, jpd00964@uxa.cso.uiuc.edu writes: > First, [Symantec] appear to have included the commands this and inherited: > These are equivalent to the self and super of Objective C which most C++ > books seem to ignore. How very interesting. If this is true, THINK C 4.0 is neither a superset of C++ 2.0 (which their deliberatly ambiguous claim of upward compatibility suggested to some people) *nor* a subset of C++ 2.0: In C++, the equivalent of super in Smalltalk (and probably Objective-C) is achieved by explicitly naming the superclass whose method (member function) is to be invoked using the scope resolution operator ::. --Bob "I hate marketing hype" Marti -- Robert Marti Phone: +41 1 256 52 36 Institut fur Informationssysteme ETH-Zentrum CSNET/ARPA: marti%inf.ethz.ch@relay.cs.net CH-8092 Zurich, Switzerland UUCP: ...uunet!mcvax!ethz!marti
mce@tc.fluke.COM (Brian McElhinney) (08/29/89)
In article <227700036@uxa.cso.uiuc.edu> jpd00964@uxa.cso.uiuc.edu writes: >Are there different standards for C++? It seems Stroustrup and Waite group >have different ideas, and Symantic seems to be running something quite >different than either of those. Is it my imagination, or are there at least >three standards? There is only one C++, the one defined by Stroustrup. THINK C is not C++ at all, and Symantec's claims to the contrary only hurt the product by confusing the issue. THINK C is ANSI C with object-oriented structures (similar to C++ structures, but far different from C++ classes). >The Waite Group's does not mention the inherited: and mention this only in >passing. I'm not sure what the "Waite Group" is or what they are describing, but there is no "inherited" keyword in C++ (it is a TC-ism). One of my (many) complaints about C++ is that you have to explictly name the super class in order to invoke it's methods. The syntax is "superclassname::method()". The best book I have seen on C++ is "C++ PRIMER" by Stanley Lippman. Brian McElhinney mce@tc.fluke.com
lsr@Apple.COM (Larry Rosenstein) (08/29/89)
In article <10710@fluke.COM> mce@tc.fluke.COM (Brian McElhinney) writes: > is no "inherited" keyword in C++ (it is a TC-ism). One of my (many) > complaints about C++ is that you have to explictly name the super class in > order to invoke it's methods. The syntax is "superclassname::method()". When we (Apple) tried to define a subset of C++ that matched Object Pascal, this was one of the things we asked Stroustrup about. The problem with using INHERITED as a keyword is that with multiple inheritance you may have multiple superclasses. I guess he didn't want to add another keyword that could only be used in the signel inheritance case (you would need to explicitly name the superclass in the multiple inheritance case anyway). In a sense, there are 4 dialects "C++-like languages". AT&T has both version 1.2 and 2.0 of C++, which are the "standards" (2.0 adds a bunch of language features, including multiple inheritance). There's GNU g++, which based on news articles I've read, has a few different features and C++, and there's minimal C++ (the language I mentioned above, which I assume is implemented by TC 4.0). Larry Rosenstein, Apple Computer, Inc. Object Specialist Internet: lsr@Apple.com UUCP: {nsc, sun}!apple!lsr AppleLink: Rosenstein1
joe@gistdev.UUCP (Joe Brownlee) (08/30/89)
I thought I'd throw in my $.02 about THINK C 4.0, which I got about a week ago.
As has been stated many times here, it is not C++, but it is certainly a useful
subset of C++. The class library is impressive on the surface; when I really
get a chance to dig into it, I have a feeling I will be even more impressed.
I was a little upset about another $69 upgrade charge, but I have to admit,
the changes seem to be well worth it. And, oh -- my upgrade came in about a
week to 10 days by standard carrier, so I have no complaints about that.
One complaint I do have is about TC 4.0's ANSI compatibility, though. I am
really just a hobbyist Mac programmer, since my main area I work in is UNIX.
One of the things I have liked about LSC was the ability to bring UNIX work
home, and be able compile to run it reasonably under LSC on the Mac. I think
that some of the omissions of from ANSI in TC 4.0 will be a problem for me in
trying to continue to do this.
Now, I don't expect the world in a first release, and I understand that ASNI
C is not chisled in stone yet. The thing that bothered me was the statement
in the manual (in the differences from previous versions section) that the ANSI
features that were omitted were either fundamental changes (i.e. too hard) or
unusual features which aren't that useful. OK, I suppose I can live without
trigraphs and such, but the implication from the statement in the manual is that
we shouldn't be looking for a true ANSI compiler out of Symantec in the future.
That would be a shame, because I like THINK C, and I want to continue to use it.
I particularly was disappointed to see the omission of the keywords "const"
and "signed". And I _really_ think it was a mistake not to reserve them --
that is, if you plan ANSI compliance in the future. Sure, someone said earlier
you can #define them yourself, but that's not the point. This once again
implies that they are not planned for future versions.
I won't go into a list of what is or isn't ANSI compliant in TC 4.0, but suffice
it to say that there are features there that are not just obscure things nobody
uses. Full ANSI compatibility is _very_ important to me, and anyone else who
works with C on a number of diverse platforms (though I guess I can't _really_
speak for "anyone else" :-). I hope that the disclaimer in the manual just
conveyed the wrong impression to me.
But -- just to repeat -- I am very impressed with TC 4.0, and though full C++
support would be nice, its subset of C++ is fine with me. I will use objects,
though I will probably #define "class" for portability. That one would have
been nice in the compiler, too, but I understand the reluctance to add any
new keywords very well, since my work involves development of a training 4GL.
Joe Brownlee | Captain, please -- not in front of the Klingons.
GIST, Inc. | -- Mr. Spock, Star Trek V
1800 Woodfield Dr. | Pay attention to what I say, and you might start a trend.
Savoy, IL 61874 | ARPANET: joe%gistdev@uxc.cso.uiuc.edu
(217) 352-1165 | UUCP : {uunet,pur-ee,convex}!gistdev!joesiegel@endor.harvard.edu (Rich Siegel) (08/30/89)
In article <581@gistdev.UUCP> joe@gistdev.UUCP (Joe Brownlee) writes: > >One of the things I have liked about LSC was the ability to bring UNIX work >home, and be able compile to run it reasonably under LSC on the Mac. I think >that some of the omissions of from ANSI in TC 4.0 will be a problem for me in >trying to continue to do this. I'm impressed. THINK C 3.0 was much less ANSI-conformant than THINK C 4.0 is, and you were able to port ANSI programs to it? >C is not chisled in stone yet. The thing that bothered me was the statement >in the manual (in the differences from previous versions section) that the ANSI >features that were omitted were either fundamental changes (i.e. too hard) or >trigraphs and such, but the implication from the statement in the manual is that >we shouldn't be looking for a true ANSI compiler out of Symantec in the future. Trying to draw conclusions from the reasoning behind design decisions is a losing proposition, in my opinion. UNLESS the manual says "we will never ever in a million years come out with a full ANSI compiler", you're misleading a lot of people (including yourself) by drawing this conclusion. "We didn't do it in this version because it required fundamental changes" IS NOT THE SAME as "we will never do it". A specific example: "const" and "volatile" can be considered to be directives to the code generator or optimizer; "const" means "this data element will never change", and "volatile" means "this data element is subject to change without notice due to external forces" (e.g. at interrupt time). To fully take advantage of these directives, fairly extensive changes to the code generator would be required, and there wasn't time to do this for the 4.0 release. Again, I would advise against drawing long-term conclusions from statements where nothing lends weight to those conclusions... R. ~~~~~~~~~~~~~~~ Rich Siegel Staff Software Developer Symantec Corporation, Language Products Group Internet: siegel@endor.harvard.edu UUCP: ..harvard!endor!siegel "There is no personal problem which cannot be solved by sufficient application of high explosives." ~~~~~~~~~~~~~~~
joe@gistdev.UUCP (Joe Brownlee) (08/31/89)
In article <2532@husc6.harvard.edu> siegel@endor.UUCP (Rich Siegel) writes: >In article <581@gistdev.UUCP> joe@gistdev.UUCP (Joe Brownlee(me)) writes: >>One of the things I have liked about LSC was the ability to bring UNIX work >>home, and be able compile to run it reasonably under LSC on the Mac. I think >>that some of the omissions of from ANSI in TC 4.0 will be a problem for me in >>trying to continue to do this. > > I'm impressed. THINK C 3.0 was much less ANSI-conformant than THINK C >4.0 is, and you were able to port ANSI programs to it? OK, I didn't say _exactly_ what I meant. What I meant is that I have taken UNIX C programs to LSC 3.0. We are, and have been, moving our UNIX C work to ANSI conformant compilers (and our MS-DOS work, too, for that matter), so the ANSI compatibility issue has recently become important. We do actually have to keep our code in both ANSI and non-ANSI forms for different platforms at the moment, but we are in the process of moving away from non-ANSI compilers. > Trying to draw conclusions from the reasoning behind design decisions >is a losing proposition, in my opinion. UNLESS the manual says "we will never >ever in a million years come out with a full ANSI compiler", you're misleading >a lot of people (including yourself) by drawing this conclusion. "We didn't >do it in this version because it required fundamental changes" IS NOT THE SAME >as "we will never do it". OK, that makes me feel better about this. I certainly did not mean my original posting to be a "flame" on Symantec, but I felt (I think justified) concern based on what the manual had to say. As I stated in my original posting, I work on the development of a 4GL, and I understand trying to walk the line between telling users your expected future direction (especially regarding potentially incompatible changes), and not comitting to specific features which will be added. I simply hope that full ANSI conformance will be offered at some future time (and that I won't have to pay mega-$ for it :-). I _do_ want to repeat that I am very happy with TC 4.0, especially in the Mac-only-code area, and I hope that you guys keep up the good work, Rich. Thanks for the response. >~~~~~~~~~~~~~~~ > Rich Siegel > Staff Software Developer > Symantec Corporation, Language Products Group > Internet: siegel@endor.harvard.edu > UUCP: ..harvard!endor!siegel >~~~~~~~~~~~~~~~ Joe Brownlee | Captain, please -- not in front of the Klingons. GIST, Inc. | -- Mr. Spock, Star Trek V 1800 Woodfield Dr. | Pay attention to what I say, and you might start a trend. Savoy, IL 61874 | ARPANET: joe%gistdev@uxc.cso.uiuc.edu (217) 352-1165 | UUCP : {uunet,pur-ee,convex}!gistdev!joe