jack@cca.CCA.COM (Jack Orenstein) (06/16/88)
I know this has been discussed, but I didn't need the information at the time. Is there a C++ compiler or preprocessor for the Amiga? Who produces it and how much does it cost? I'd actually prefer a preprocessor so that I can look at the generated C code to understand some of the C++ semantics, and to have access to Manx SDB. Jack Orenstein This is not a disclaimer.
lishka@uwslh.UUCP (Fish-Guts) (06/18/88)
In article <29559@cca.CCA.COM> jack@cca.CCA.COM (Jack Orenstein) writes: > >I know this has been discussed, but I didn't need the information at the time. > >Is there a C++ compiler or preprocessor for the Amiga? Who produces it >and how much does it cost? I'd actually prefer a preprocessor so that I >can look at the generated C code to understand some of the C++ semantics, >and to have access to Manx SDB. I was one of the people interested in this info before. The answers to your questions are (as I understand them): -Lattice's C++ Compiler 1) Has been advertised in an Amiga magazine (I haven't seen the ad myself); 2) Will be around $500 (whew!); 3) Will indeed be a preprocessor, because you will need Lattice's C compiler to use the C++ compiler. -Free Software Foundation (i.e. Richard Stallman) C++ Compiler 1) Is still a beta version (last I heard); 2) Does *NOT* produce C code...it compiles directly to assembly language, one of which is 68000 code; 3) Is freely distrubutable (although you may need to pay distribution charges). So, you can either pay around $700 for Lattice's product (C++[~$500] & C[~$200?] compiler purchased together) or try porting the FSF C++ compiler (not a minor task). If you have the money, you may want to consider Lattice's offer. If you have the time and expertise, you may want to consider FSF's package. Personally, I think Lattice is asking a bit much for the C++ compiler, as C++ is nice but is still a superset of C...anything you can do with a C++ compiler you can pretty much do with a C compiler. But it would be nice to have C++.... >Jack Orenstein -Chris -- ---- ---- Chris Lishka Wisconsin State Lab of Hygiene (608)262-1617 lishka@uwslh.uucp OR lishka%uwslh.uucp@cs.wisc.edu OR ...!{rutgers | ucbvax | ihnp4 | ...}!uwvax!uwslh!lishka ---- ---- "...Just because someone is shy and gets straight A's does not mean they won't put wads of gum in your arm pits." - Lynda Barry, "Ernie Pook's Commeek: Gum of Mystery"
stergios@athsys.uucp (Stergios Marinopoulos) (06/18/88)
In article <29559@cca.CCA.COM> jack@cca.CCA.COM (Jack Orenstein) writes: > I know this has been discussed, but I didn't need the information at the time. > > Is there a C++ compiler or preprocessor for the Amiga? Who produces it > and how much does it cost? I'd actually prefer a preprocessor so that I > can look at the generated C code to understand some of the C++ semantics, > and to have access to Manx SDB. > > Jack Orenstein > > > This is not a disclaimer. Yes, there was a little discussion on C++ before. It is a translator. But dont get your hopes up because of "this" (pun intended). A few concerns which I have voiced previously regarding C++ translators are included below. I never received any feedback on them before so here they are again. Well, actually thats not entirely true. I have received some feedback from a "Language" company about my comments. To bad they dont write compilers for the amiga. Its kinda funny that one heck of a potential competitor for lattice thought it important enough to write back regarding a letter not even directly addressed to them. When will the amiga market mature??? // C++ issues. I beleive mwm@violet.berkeley.edu has already mentioned that Lattice's C++ will be a translator and not a compiler. What I would like to know is if Lattice is basing this translator on AT&T's, *much* like the designer C++ Programming System from Glockenspiel Ltd., Dublin Ireland. Then if so could someone in the know address the following issues? * how does Lattice solve the "post linker linker" problem? - does it go into the executable and patch it with a linked list of all static objects and execute them before entering main?. * related to the above: If you do peform this ugly hack are you going to get it right or mess it up (like AT&T and therefore glockenspiel did) so bad that static global objects cannot be depended on! * again related to the above: will lattice *GUARANTEE* only *ONE* vtable per class per executable? If not then just throw out the possibility of having large programs developed. You would be supprised how easy it is for executables to grow over 1 meg without this option! * again related to the above: What about virtual destructors? Are you going to get them right? Please, please say yes. * what extensions will lattice support? - multiple inheritance? can live with out but would be a big win for true object oriented programming. - accept "old style" c function definitions? *this is a must* - interface to "old style" c libraries. * document the naming convention for overloaded and virtual functions. This is a must for debugging. Not that AT&T documented it. It would just be nice to have in a product you pay $$ for and make your living with! * How about debugging? Are you going to support a C++ debuugger? I could live with a regular dbx style debugger that has alias commands. Dont even bother giving a machine level debugger by itself. Could a Lattice representative please comment on the above? stergios marinopoulos XPert XPorts sun!athsys!cyclopes!stergios
dmg@ssc-vax.UUCP (David Geary) (06/19/88)
In article <29559@cca.CCA.COM>, jack@cca.CCA.COM (Jack Orenstein) writes: > > I know this has been discussed, but I didn't need the information at the time. > > Is there a C++ compiler or preprocessor for the Amiga? Who produces it > and how much does it cost? I'd actually prefer a preprocessor so that I > can look at the generated C code to understand some of the C++ semantics, > and to have access to Manx SDB. > > Jack Orenstein > Lattice will release a version of C++ for the Amiga "this summer". I called Lattice (again ;-) ) last week, to ask about it, and they do not have a sales sheet on it yet, but expect it to cost around $500.00. I believe that includes the Lattice 4.?0 compiler. It is a preprocessor that produces C code for the C compiler. I was also told that a symbolic debugger for C++ is in the works. David Geary -- *********************************************************** * David Geary, Boeing Aerospace Co., Seattle, WA * * I disclaim all disclaimers.... * ***********************************************************
pete@violet.berkeley.edu (Pete Goodeve) (10/26/88)
I was one of those who jumped in and bought Lattice C++ at Ami-Expo for the
"bargain" price of $250. Having immersed myself intensively in it for a
couple of weeks, I think it's about time to pass on my impressions.
Most important, I guess, is that it seems to perform as advertised. I was
mightily pleased that my early attempts to create some classes and matching
test programs all seemed to run first time [once I'd gotten past all those
pesky error messages, naturally]. I haven't noticed any bugs in the
compiler yet (though it does seem rather more prone to "knock on" errors --
those hordes of spurious reports that follow a genuine mistake -- than
regular Lattice C).
On the other hand, it IS a bit of a pig. They recommend 1.5 Meg and a hard
disk. (I have extra memory rather than the hard disk, and that seems to be
reasonably good.) It has two precompile passes before the compiler proper
(Lattice 4.1 at the moment) gets it, so no way is it going to be
particularly speedy.
As one illustration of its hoggish nature, take the two versions of "Hello
World" in the examples directory: the first just uses a C++ "stream" for
output rather than printf, the second opens a window to display the text.
The stream version source is 89 bytes long: it generates an intermediate C
file of nearly 6K... the executable is 14K! On the other hand, the
executable of the window version is only 900 bytes longer than that, and in
general more complex programs have more rational sizes. Obviously there's
quite a bit of fixed overhead for things like the stream library.
By far the most impressive thing about this implementation is that ALL the
Exec and Intuition structures are now OBJECTS, with associated methods to
manipulate them. For example, I was able to enclose the "Hello World" in
the window with an ellipse by adding three statements (one to compute its
size, one to position it, and one to draw it) -- and again it worked first
time, except that I got the ellipse positioned wrong.
On the flip side, I have one MAJOR nit to pick. There is NO way that I can
find to redirect the error messages anywhere but the console! Trying a
standard CLI ">" in the cc command has absolutely no effect, and there is
no switch option to select an error file. You have to have a ready finger
on the space bar to catch the early messages. Add in the knock-on effect I
mentioned, and it becomes a real pain.
+ + +
The package contains two disks (compiler+libs and includes+examples), a
manual (with more than the occasional omission and error, but reasonable)
and a textbook "An Introduction to Object Oriented Programming and C++" by
Wiener and Pinson.
Given that I was able to read the text all the way through without
gibbering in frustration at any point, I guess I have to rate it as pretty
good. It also doesn't seem to be too hard to find a particular bit of
information that you need. They did manage to make it a little harder to
read than it should have been by printing identifiers in the same font as
the rest of the text; as they had chosen nice meaningful names for these,
sentences could get rather confusing. Also I've reached the conclusion
that it's not a complete description of all the C++ features. Luckily I
had Stroustrup's article in IEEE software handy to clear up some points; I
probably will have to get his book for the final word.
The examples included on the disk look interesting, but to be truthful I
haven't played with them yet. I'm always more interested in trying out
experiments of my own. I have noticed though that the comments in the
examples are in the conventional C programming style -- largely missing...
+ + +
All in all I find C++ itself a real pleasure. At the very least, with
things like overloading of operators, anonymous unions, reference
parameters, and so on, it is a large step beyond vanilla C. Its "Object
Oriented" features -- classes and so on -- are very powerful additions
which seem easy to use. I do have one important quibble about this aspect,
though, which I'll return to in a moment. And I did have an unexpected
adventure or two along the way.
As an exploratory mission, I thought I would implement a true "string" type
(i.e. "class") -- one that manages its own storage dynamically. [I'm sure
that someone must have done this already, but my cursory search of the
handy literature didn't turn one up, so I went ahead anyway.] The goal is
a class such that you can say:
string s1, s2;
s1 = "some text";
s2 = "..more text";
s1 = s2;
s1 += "...append this"
/* ... and so on */
and each time you change the contents of a string it will allocate new
storage and discard the old automatically. I won't go into the details.
Suffice to say that it all went together very easily.
I got surprised by one feature of C++ here, which in fact could be a
potentially serious Ooh-Nasty. What happened was that my first string
assignment test (s1 = "a string";) worked perfectly, but I stopped
congratulating myself when I found that I had forgotten to actually define
the "=" operator in my string class!! Basically it seems that the
"constructor" you define for a class will also by default be used as a cast
function in an assignment to that class. This meant that storage for the
string was being allocated properly; on the other hand the corresponding
"destructor" ISN'T invoked on any data that might happen to be already in
the string, so THAT block would be cast adrift, never to be recovered.
Ouch.
My big gripe, though, is that C++ makes a big deal about its "Object
Orientation" and "Data Hiding", but to my way of thinking it doesn't really
meet those qualifications very well. I'm probably more of a "Data Hider"
than an "Object Lover", so I was looking forward to creating classes where
I could wall off the implementation from the user modules. The reason is
not just to hide my bad code, but so that I could CHANGE the representation
if I wanted to WITHOUT having to recompile all the user modules, as long as
I didn't modify the public interface of the class. For example, one might
want to change a "stack" class from an array storage implementation to a
linked list, leaving the "push()" and "pop()" etc. the same. Actually a
couple of remarks in the references suggest one should be able to do this,
but I made a quick check and the Guru gave me his True Word immediately:
You CANNOT change the private section of a class and expect it to run with
the old user modules.
In fact, I can't see how it could be otherwise. The only indication of how
much storage a class needs, for instance, is in its definition, so wherever
a module invokes a "new" operation for the class it must have the complete
information in the header file. You would need to actually store the
information in the executable file somewhere -- and how would you know
which information to store if not all the headers were the same? Maybe
some other implementation has solved this somehow, but as the Lattice
version comes straight from AT&T I doubt it.
Oh well. It ain't perfect, but it's getting there. What I like the most
is that it provides all these neat features without being dogmatic about it
(a true descendant of C...). You can write code for your program at
whatever level seems appropriate. There is one other language that I would
even more like to see on the Amiga [POP-11, if you must know], but until
that comes along, I think C++ may keep me pretty satisfied.
-- Pete --
... and, yes -- the list price ($500) SHOULD be lower.jcrotinger@ssibbs.UUCP (James Crotinger) (10/28/88)
In article <16021@agate.BERKELEY.EDU>, pete@violet.berkeley.edu (Pete Goodeve) writes: > By far the most impressive thing about this implementation is that ALL the > Exec and Intuition structures are now OBJECTS, with associated methods to > manipulate them. This is nice but is not done as well as it could have been. Most of the data in the structures is not hidden. This does make it more nearly compatible with existing C code, but if you were starting from scratch in C++ you'd probably hide all that data and write accessor functions to access it. > On the flip side, I have one MAJOR nit to pick. There is NO way that I can > find to redirect the error messages anywhere but the console! Yes, they output the error messages, etc, to stderr, which cannot be redirected from the CLI. Tim said he'd try to change this in the next release. > information that you need. They did manage to make it a little harder to > read than it should have been by printing identifiers in the same font as > the rest of the text; as they had chosen nice meaningful names for these, > sentences could get rather confusing. This does get confusing. A nice typewriter font for identifiers would definitely make it easier to follow. > that it's not a complete description of all the C++ features. Luckily I > had Stroustrup's article in IEEE software handy to clear up some points; I > probably will have to get his book for the final word. Note that Stroustrups book is somewhat out of date. A few things (like protected) have been added that aren't in the book. The book describes C++ as implemented in CFRONT 1.0. The newest version is 1.2 with 2.0 due out Real Soon Now (2.0 will have multiple inheritance). The Lattice CFRONT says that it is 1.1a. I don't know what the differences are between 1.1a and 1.2. > As an exploratory mission, I thought I would implement a true "string" type > (i.e. "class") -- one that manages its own storage dynamically. [I'm sure > that someone must have done this already, but my cursory search of the > handy literature didn't turn one up, so I went ahead anyway.] Stroustrup does this in his book. > > My big gripe, though, is that C++ makes a big deal about its "Object > Orientation" and "Data Hiding", but to my way of thinking it doesn't really > meet those qualifications very well. I'm probably more of a "Data Hider" > than an "Object Lover", so I was looking forward to creating classes where > I could wall off the implementation from the user modules. The reason is > not just to hide my bad code, but so that I could CHANGE the representation > if I wanted to WITHOUT having to recompile all the user modules, as long as > I didn't modify the public interface of the class. For example, one might > want to change a "stack" class from an array storage implementation to a > linked list, leaving the "push()" and "pop()" etc. the same. Actually a > couple of remarks in the references suggest one should be able to do this, > but I made a quick check and the Guru gave me his True Word immediately: > You CANNOT change the private section of a class and expect it to run with > the old user modules. > > In fact, I can't see how it could be otherwise. The only indication of how > much storage a class needs, for instance, is in its definition, so wherever > a module invokes a "new" operation for the class it must have the complete > information in the header file. You would need to actually store the > information in the executable file somewhere -- and how would you know > which information to store if not all the headers were the same? Maybe > some other implementation has solved this somehow, but as the Lattice > version comes straight from AT&T I doubt it. Right, user modules have to be recompiled with the new headers. You may be able to get around this with 2.0 as it allows you to overload the new operator. Even so, the data IS hidden in that the user doesn't have to be aware of how the private section is implemented, and he certainly has no direct access to the private section, but he does have to compile with an up to date header file. > -- Pete -- > > ... and, yes -- the list price ($500) SHOULD be lower. Definitely. For a limited time, registered Lattice C 4.0 owners can upgrade for $300. Also, fortunately for me, they have a 50% educational discount (only applies to new packages, not upgrades). But even at $250-$300 I doubt it'll revolutionize the way most Amigans compute. BTW, Tim Holloway mentioned on BIX that he wants to make the next release a real compiler, as opposed to a translator. That would definitely help. Currently it takes about 2 minutes to compile and link Hello.cp on my 3 Meg A1000 w/hard drive. -- Jim Crotinger crotinger%mit.mfenet@nmfecc.arpa
pete@violet.berkeley.edu (Pete Goodeve) (10/30/88)
Responding to Jim Crotinger's reply <32@ssibbs.UUCP> to my original posting: > > By far the most impressive thing about this implementation is that ALL the > > Exec and Intuition structures are now OBJECTS, with associated methods to > > manipulate them. > > This is nice but is not done as well as it could have been. Most of the > data in the structures is not hidden. This does make it more nearly > compatible with existing C code, but if you were starting from scratch > in C++ you'd probably hide all that data and write accessor functions to > access it. I'm not entirely convinced of this yet. Accessor functions mean a lot of overhead, and in the majority of situations I don't think you need to be paranoid about the user messing where he shouldn't. At least as long as the structures remain fixed, and the way the Kernel is currently designed, we can probably be fairly sure that they will. (Too many things would break if they didn't.) Now what WOULD be nice would be an ability to specify members to be publicly 'const' -- they would then be WRITTEN to only by suitably friendly accessor functions. As I said in the last posting, I like "Data Hiding", but only where it allows you to build a truly pnambic system, where you can implement things however you like on the "backside" of the interface without bothering the user at all, and C++ doesn't quite meet this spec. [Mm..mm? Oh -- "PNAMBIC" ... "Pay No Attention to that Man BehInd the Curtain..."] > Note that Stroustrups book is somewhat out of date. A few things (like > protected) have been added that aren't in the book. The book describes > C++ as implemented in CFRONT 1.0. The newest version is 1.2 with 2.0 due > out Real Soon Now (2.0 will have multiple inheritance). The Lattice CFRONT > says that it is 1.1a. I don't know what the differences are between 1.1a > and 1.2. This is going to be one problem with C++ ... keeping up with an evolving language. I suspect I'll be hanging around comp.lang.c++ quite a bit from now on. In fact I've already run into some nasties that sparked a long posting to that group. My initial enthusiasm got tempered quite a bit by those findings. (They're too detailed to even think of cross posting.) > BTW, Tim Holloway mentioned on BIX that he wants to make the next > release a real compiler, as opposed to a translator. That would definitely > help. [.....] Yeah. It will also eliminate the hefty licence fee Lattice has to pay AT&T for cfront, so it SHOULD be one way of bringing the price down... > > Jim Crotinger > crotinger%mit.mfenet@nmfecc.arpa -- Pete --
pds@quintus.uucp (Peter Schachte) (11/02/88)
In article <16220@agate.BERKELEY.EDU> pete@violet.berkeley.edu (Pete Goodeve) writes: About Lattice C++: >> > ALL the Exec and Intuition structures are now OBJECTS, with associated >> > methods to manipulate them. >> if you were starting from scratch in C++ you'd probably hide all that >> data and write accessor functions to access it. >I'm not entirely convinced of this yet. Accessor functions mean a lot of >overhead Couldn't you get around this by making the accessors macros? As I recall, Stroustroup's (sp???) book has several examples of this sort of thing. So you get clean, safe, and efficient code. What more could you ask for? Pnews fodder to stretch the posting -Peter Schachte "Clean water? I'm for clean water." pds@quintus.uucp -George Bush ..!sun!quintus!pds
bader+@andrew.cmu.edu (Miles Bader) (11/03/88)
pds@quintus.uucp (Peter Schachte) writes: > In article <16220@agate.BERKELEY.EDU> pete@violet.berkeley.edu (Pete Goodeve) write\ > s: > About Lattice C++: > >> > ALL the Exec and Intuition structures are now OBJECTS, with associated > >> > methods to manipulate them. > >> if you were starting from scratch in C++ you'd probably hide all that > >> data and write accessor functions to access it. > >I'm not entirely convinced of this yet. Accessor functions mean a lot of > >overhead > > Couldn't you get around this by making the accessors macros? As I > recall, Stroustroup's (sp???) book has several examples of this sort of > thing. So you get clean, safe, and efficient code. What more could > you ask for? Absolutely. When in doubt, I always provide access macros, rather than have clients (people using my "object") access my data structures. You can also inline functions in c++. I also think you can put the entire body of short functions in the class declaration, in which case they should get automagically inlined. In any case, there's no reason to allow access to internal structure. Disallowing access makes for MUCH easier future changes! -Miles
jac@ssibbs.UUCP (James Crotinger) (11/04/88)
In article <614@quintus.UUCP>, pds@quintus.uucp (Peter Schachte) writes: > Couldn't you get around this by making the accessors macros? As I > recall, Stroustroup's (sp???) book has several examples of this sort of > thing. So you get clean, safe, and efficient code. What more could > you ask for? > The correct term is 'inline function' and this is a prime example of why they are there. You can make the data private and then provide an inline accessor function to read it, write it, etc. This is a very good practice. The combination of inline functions and function/operator overloading make it possible for user defined data types to be as easy to use and as efficient as the regular data types. Some good applications are given in Stroustrup's book, like the complex data type and the vector/ matrix data types. The catch is that as the number of accessor functions, etc. increase, the compile time and the amount of memory required also increases, and it already takes 1.5 Megs to run. Tim said that the memory constraint and compatibility problems were the main reason he didn't do a more object oriented version of the system routines. You can always do it yourself, of course, by deriving your own classes from his. He has a couple of examples of window classes that are derived in this manner. > -Peter Schachte "Clean water? I'm for clean water." Jim -- Jim Crotinger crotinger%mit.mfenet@nmfecc.arpa
klm@wang7.UUCP (Kevin L. McBride) (01/24/89)
Ok, so like Lettuce now has a ridiculously priced (IMHO) C++ compiler. Does anybody know if Manx has any plans to make a similar (and hopefully more reasonably priced) offering? If they were to offer it to owners of the Developer package for, lets say, under $150, I might bite. $400 for Lattice is absurd (IMHO) considering I can buy a commercial port of cfront to my 386 Unix machine for half that price. I would love to have C++ on my Amiga and am willing to pay a reasonable price for it. Guess I'll have to wait a while. -- Kevin McBride Another // | Also: Wang Laboratories Proud // | President, brewmeister, chief taster Desktop Image Systems \\ // Amiga | McBeer Brewery, Nashua, NH ...!ima!wang7!klm \X/ owner | ...!ima!wang7!gozer!klm
daveh@cbmvax.UUCP (Dave Haynie) (01/27/89)
in article <2653@wang7.UUCP>, klm@wang7.UUCP (Kevin L. McBride) says: > Keywords: Manx > Ok, so like Lettuce now has a ridiculously priced (IMHO) C++ compiler. > $400 for Lattice is absurd (IMHO) considering I can buy a commercial port > of cfront to my 386 Unix machine for half that price. Well, you get what you pay for. A compiler that produces inferior 8088 code (at least, the vast majority of MS-DOS compilers aren't producing native '386 code) is certainly worth less than a compiler that can produce real 32 bit code. And of course, there's the volume issue. There are undoubtedly more folks using these PClone toys who'd like to use C++ than folks on the Amiga, at least in real numbers if not percentage-wise. Which is a shame, since there's really nothing in the PC that would lend itself to a good C++ object model, while most of the Amiga OS was practically built for C++. The other thing that tends to lower costs is competition, and there are several C++ translators and one compiler for the PC, while there's only one for the Amiga. It's not the cost of the compiler that bothers me (especially if you get it though the special upgrade deal with Lattice, though I'm not sure that's still on), but the cost of the 68020 board you need to make the cc->ccp->cfront->LC1->LC2->BLINK compilation process go quickly l^). I hope that Manx or someone else produces a C++ compiler -- the competition between the two C compilers for the Amiga has resulted in two excellent compilers, both of which started out pretty weak. Same thing happened in the Modula 2 arena. C++ is currently my language of choice for applications programs, and I'd like it to follow the same improvement paths. > I would love to have C++ on my Amiga and am willing to pay a reasonable > price for it. Guess I'll have to wait a while. > Kevin McBride Another // | Also: > Wang Laboratories Proud // | President, brewmeister, chief taster > Desktop Image Systems \\ // Amiga | McBeer Brewery, Nashua, NH > ...!ima!wang7!klm \X/ owner | ...!ima!wang7!gozer!klm -- Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy Amiga -- It's not just a job, it's an obsession
jac@ssibbs.UUCP (James Crotinger) (01/27/89)
In article <2653@wang7.UUCP>, klm@wang7.UUCP (Kevin L. McBride) writes: > Ok, so like Lettuce now has a ridiculously priced (IMHO) C++ compiler. > > Does anybody know if Manx has any plans to make a similar (and hopefully > more reasonably priced) offering? > Tim Holloway was originally working on both a Manx and Lattice version. However his marketing deal with Lattice apparently precludes the possibility of his selling a Manx version, so someone else will have to do it. > > $400 for Lattice is absurd (IMHO) considering I can buy a commercial port > of cfront to my 386 Unix machine for half that price. > Unless they've changed it since I bought it, the list price is $500. I doubt anyone could make money in the Amiga market selling C++ for what the PC versions sell for--AT&T charges a licence fee of $2000 + $50 per copy sold. The $50 royalty really hurts. However I believe that if they develop a native compiler, they won't have to pay the royalty. > I would love to have C++ on my Amiga and am willing to pay a reasonable > price for it. Guess I'll have to wait a while. > You could always go back to college--Lattice has a 50% discount for college students (& staff??). I'd have never been able to afford it without that. Jim -- Jim Crotinger crotinger%mit.mfenet@nmfecc.arpa
jmarvin@oracle.com (10/16/90)
> jte@sai.UUCP (John Evans) writes; >Subject: C++ Available for Amiga. >Just got a newsletter from Comeau Computing. They say they have C++ >version 2.1 availiable for the Amiga. They do not mention which >operating system they support or any other details. Here is their >address and phone number if anyone wants to contact them. > >Comeau Computing >91-34 120th St >Richmond Hill, NY 11418 > >Contact: Marge Behrens >(718) 945-0009 This number is not in service. If this is real, I'ld like to buy it! ******************************************************************* * Nhoj Nivram * * email: jmarvin@oracle.com * * "Reality is a Harsh Mistress..." * *******************************************************************
sk2x+@andrew.cmu.edu (Sun Kun Kim) (10/16/90)
There is a C++ package available from a more RELIABLE source than Comeau
Computing. Lattice/SAS has one out and it's been out for about 6 months
now. Looking at Lattice C I have, they should have done an equally
impressive version of C++ for the Amiga.
Sun...
**********************************************************************
Carnegie Mellon University sk2x+@andrew.cmu.edu
(C)1990, Totally Cool People Society of America.
a non-profit organization formed to protect the lives of the innocent
against weird, barbaric, and grotesque UNCool(C) people in the world.
"Anything I say or do could be used against YOU" - Yours Truly.
Publisher of the Totally Cool People Society's bi-weekly Top Ten List.
**********************************************************************
(Sig file v.2.2a)jer@stbimbo.UUCP (John Ramspott) (10/17/90)
In article <1990Oct16.005807.6839@oracle.com> jmarvin@oracle.com () writes: > >> jte@sai.UUCP (John Evans) writes; >>Subject: C++ Available for Amiga. >>Just got a newsletter from Comeau Computing. They say they have C++... >>Comeau Computing >>91-34 120th St >>Richmond Hill, NY 11418 >>Contact: Marge Behrens >>(718) 945-0009 >This number is not in service. >If this is real, I'ld like to buy it! > Yes, it is real enough. Their product is available on many platforms, including several UNIX boxes, MS-DOS, and other machines. I called and they sent me their literature. The enclosed product reviews excerpted from magazines sound very encouraging. The price is a very reasonable $250, and requires the Lattice C (now SAS/C). They expect to be shipping by the end of the month. Sounds very promising to me. Just too bad SAS didn't do this themselves, but enough waiting. I'll still get use out of their nice C compiler, and play with Comeau's rather widely available 2.1 C++. I hope lots of people buy it so that they will continue to support the Amiga version. Personally, I think their are enough innovative programmers out in the Amiga community to support a solid C++. If I had the time and money to pay AT&T, I would have done it myself eventually. Disclaimer: I have not seen it. Just chatted with the lady who answered the phone and read the literature they sent me. >******************************************************************* >* Nhoj Nivram * >* email: jmarvin@oracle.com * >* "Reality is a Harsh Mistress..." * >******************************************************************* --John E. Ramspott
jte@sai.UUCP (John Evans) (10/17/90)
In article <Mb6lAye00awA4_w0s9@andrew.cmu.edu>, sk2x+@andrew.cmu.edu (Sun Kun Kim) writes: > There is a C++ package available from a more RELIABLE source than Comeau > Computing. Lattice/SAS has one out and it's been out for about 6 months > now. Looking at Lattice C I have, they should have done an equally > impressive version of C++ for the Amiga. > > Sun... I can't complain about the standard lattice C compiler, but I believe their C++ is AT&T version 1.2. This is quite an old version! AT&T has since released 2.0 and 2.1. We have been using the 2.0 version for over a year now, and are now using 2.1! (386 unix version). This does not show me that Lattice is really supporting the C++ enviroment. -- Schmidt Associates Inc. John T. Evans 2865 Sunrise Blvd. jte@sai.UUCP Rancho Cordova CA. UUCP: ...uunet!sai!jte
jdege@ (Jeff Dege) (10/18/90)
In article <206@sai.UUCP> jte@sai.UUCP (John Evans) writes: >In article <Mb6lAye00awA4_w0s9@andrew.cmu.edu>, sk2x+@andrew.cmu.edu (Sun Kun Kim) writes: >> There is a C++ package available from a more RELIABLE source than Comeau >> Computing. Lattice/SAS has one out and it's been out for about 6 months >> now. Looking at Lattice C I have, they should have done an equally >> impressive version of C++ for the Amiga. > >I can't complain about the standard lattice C compiler, but I believe their >C++ is AT&T version 1.2. This is quite an old version! AT&T has >since released 2.0 and 2.1. We have been using the 2.0 version for over a >year now, and are now using 2.1! (386 unix version). This does not show me >that Lattice is really supporting the C++ enviroment. Lattice didn't develop Lattice C++, they contracted it out. Now that they are out of Amigadom, the status of that package is up in the air. SAS is handling the C compiler, but they haven't taken over the C++ cfront. According to posts on Bix, SAS is in the process of developing a natice C++ compiler (version 2.1 or better), but that won't be ready for release for quite some time. Personally, I'm wondering if it wasn't Comeau that developed C++ for Lattice. It would explain their sudden appearance in the Amiga market. I can see them working on a 2.1 for Lattice, finding SAS isn't interested, then deciding to market it on their own. This is, of course, unfounded speculation on my part, so if anybody takes it as fact, it is their own problem... ---------------- 12B->21B
Rick_R_Kitts@cup.portal.com (10/21/90)
No it wasn't Comeau that did the Lattice cfront, although the name of the company that did it escapes me at the moment (I think it started) with an 'M'. Comeau appearance on the Amiga market is not at all sudden. I had bugged Mr. Comeau about doing an Amiga port many moons ago, before I realized what a kludge language C++ is. He had told me that it was something they had been thinking of for quite some time, and they would do one as soon as they had the resources. I guess they found the resources :-). ---Rick