Bob.Stout@p6.f506.n106.z1.fidonet.org (Bob Stout) (11/03/90)
their educational discount program. It has a great IDE and the best source level debugger on the market. ZTC++ compiles faster, though, and produces better (often dramatically better) code - for a price. No clear-cut answers, you have to decide where the trade-offs are to be. Oh, BTW, ZTC++ can work with the MS Windows SDK to produce Windows app's right out of the box and offers extra-cost support for OS/2, SCO Unix 386, and the Phar Lap DOS extender (Rational Systems DOS extender support is standard). TC++ is DOS only for the time being - look for TC++ to support Windows next spring.
sean@ms.uky.edu (Sean Casey) (11/06/90)
No need to buy a C++ compiler. Get gnu g++. It's free of charge. Sean -- *** Sean Casey <sean@s.ms.uky.edu> *** ``Aaaaaa!'' -James Brown
fmbutt@mrbt.sw.stratus.com (Farooq Butt) (11/14/90)
In article <sean.657840642@s.ms.uky.edu> sean@ms.uky.edu (Sean Casey) writes: >No need to buy a C++ compiler. Get gnu g++. It's free of charge. I keep hearing that g++ is below AT&T rev level 2.0. Is that true ? If so is multiple inheritance supported ? -fmb -- Hi-Tech Disclaimer: NOTHING in the above article has any relationship to reality. If any reality correspondences are found, please notify me IMMEDIATELY. Any threats or abuse of any kind is purely unintentional. My employer is not liable.
jbuck@galileo.berkeley.edu (Joe Buck) (11/14/90)
In article <3072@lectroid.sw.stratus.com>, fmbutt@mrbt.sw.stratus.com (Farooq Butt) writes: |> In article <sean.657840642@s.ms.uky.edu> sean@ms.uky.edu (Sean Casey) writes: |> >No need to buy a C++ compiler. Get gnu g++. It's free of charge. |> |> I keep hearing that g++ is below AT&T rev level 2.0. Is that true ? |> If so is multiple inheritance supported ? Not true; g++ v1.37.1 is about the same distance from satisfying E&S as cfront 2.0 is; multiple inheritance is supported and I am currently using MH with g++. However, libg++ includes a streams package corresponding to AT&T 1.2; it doesn't have "iostream.h". (cfront is AT&T's C++ 2.0 compiler). To be fair, most of the bugs in 1.37.1 seem related to multiple inheritance and virtual base classes; some of these crash the compiler. But the bug list for g++ isn't substantially longer than the bug list for cfront. -- Joe Buck jbuck@galileo.berkeley.edu {uunet,ucbvax}!galileo.berkeley.edu!jbuck
leech@cezanne.cs.unc.edu (Jonathan Leech) (11/14/90)
In article <39546@ucbvax.BERKELEY.EDU>, jbuck@galileo.berkeley.edu (Joe Buck) writes: |>In article <3072@lectroid.sw.stratus.com>, fmbutt@mrbt.sw.stratus.com (Farooq Butt) writes: |>|> I keep hearing that g++ is below AT&T rev level 2.0. Is that true ? |>|> If so is multiple inheritance supported ? |>Not true; g++ v1.37.1 is about the same distance from satisfying |>E&S as cfront 2.0 is; multiple inheritance is supported and I am |>currently using MH with g++. However, libg++ includes a streams |>package corresponding to AT&T 1.2; it doesn't have "iostream.h". |>(cfront is AT&T's C++ 2.0 compiler). You can quibble over terminology, but the fact is that lack of the iostream package makes G++ useless for many applications, such as mine. In terms of portability, the standard library is part of the language.
jbuck@galileo.berkeley.edu (Joe Buck) (11/14/90)
In article <17523@thorin.cs.unc.edu>, leech@cezanne.cs.unc.edu (Jonathan Leech) writes: |> You can quibble over terminology, but the fact is that lack of the |> iostream package makes G++ useless for many applications, such as mine. In |> terms of portability, the standard library is part of the language. But there is no "standard library". You can call what you got from AT&T "standard" if you wish, but each vendor (including those who port cfront to different architectures) puts a different set of capabilities in their "standard library". There are things in libg++ that AT&T doesn't supply, similarly for all the others. Most of iostream's functionality is supported by stream, in any case. -- Joe Buck jbuck@galileo.berkeley.edu {uunet,ucbvax}!galileo.berkeley.edu!jbuck
glenn@huxley.huxley.bitstream.com (Glenn P. Parker) (11/14/90)
In article <17523@thorin.cs.unc.edu> leech@cezanne.cs.unc.edu, (Jonathan Leech) writes: > You can quibble over terminology, but the fact is that lack of the > iostream package makes G++ useless for many applications, such as mine. In > terms of portability, the standard library is part of the language. Perhaps you should consider rephrasing your first sentence to say: "The lack of the iostream package makes G++ useless for many _existing_ applications that were written assuming it's presence." Since the original query was from someone who has not written a single line of C++ code yet, this hardly seems like a prohibitive constraint. Personally, I don't use the iostreams library, even though it comes with my compiler. In the absence of an ANSI standard, asserting that any C++ compiler is "useless" because it lacks a library provided by one vendor is simply short-sighted (and rather bigoted, IMHO). -- Glenn P. Parker glenn@bitstream.com Bitstream, Inc. uunet!huxley!glenn 215 First Street BIX: parker Cambridge, MA 02142-1270
vaughan@mcc.com (Paul Vaughan) (11/15/90)
From: leech@cezanne.cs.unc.edu (Jonathan Leech) You can quibble over terminology, but the fact is that lack of the iostream package makes G++ useless for many applications, such as mine. In terms of portability, the standard library is part of the language. No, but it is an interesting way of locking in customers. Fortunately, I don't believe AT&T intends to use it that way. I'd heard that AT&T had made or intends to make their library (or parts of it) available as a separate product. Can anyone confirm/deny that? Also, since I'm quoting out of context, I want to make sure that people are aware that g++ has two (at least) streams packages available (one in libg++, another from InterViews), both of which are similar to the AT&T streams package that came with their 1.2 release. I'm not aware of an AT&T streams 2.0 lookalike from any other vendor who didn't get it from AT&T. I don't know if g++ can compile AT&T's streams 2.0 package without difficulty, but it does support MI. The two compilers are not object-code compatible. Paul Vaughan, MCC CAD Program | ARPA: vaughan@mcc.com | Phone: [512] 338-3639 Box 200195, Austin, TX 78720 | UUCP: ...!cs.utexas.edu!milano!cadillac!vaughan
leech@threonine.cs.unc.edu (Jonathan Leech) (11/15/90)
In article <13154@cadillac.CAD.MCC.COM>, vaughan@mcc.com (Paul Vaughan) writes: |> From: leech@cezanne.cs.unc.edu (Jonathan Leech) |> You can quibble over terminology, but the fact is that lack of the |> iostream package makes G++ useless for many applications, such as mine. In |> terms of portability, the standard library is part of the language. |>No, but it is an interesting way of locking in customers. If G++ did not support multiple inheritance, would you also consider that an 'interesting way of locking in customers' on AT&T's part as well?
rfg@NCD.COM (Ron Guilmette) (11/16/90)
In article <3072@lectroid.sw.stratus.com> fmbutt@mrbt.sw.stratus.com (Farooq Butt) writes: >In article <sean.657840642@s.ms.uky.edu> sean@ms.uky.edu (Sean Casey) writes: >>No need to buy a C++ compiler. Get gnu g++. It's free of charge. > >I keep hearing that g++ is below AT&T rev level 2.0. Is that true ? In my opinion, that is not an accurate characterization. I think that it would be fair to say that g++ is to the left of cfront, but not necessarily below it. >If so is multiple inheritance supported ? Give or take a bug or two here and there, yes. -- // Ron Guilmette - C++ Entomologist // Internet: rfg@ncd.com uucp: ...uunet!lupine!rfg // Motto: If it sticks, force it. If it breaks, it needed replacing anyway.
rfg@NCD.COM (Ron Guilmette) (11/16/90)
In article <39546@ucbvax.BERKELEY.EDU> jbuck@galileo.berkeley.edu (Joe Buck) writes: +In article <3072@lectroid.sw.stratus.com>, fmbutt@mrbt.sw.stratus.com (Farooq Butt) writes: +Not true; g++ v1.37.1 is about the same distance from satisfying +E&S as cfront 2.0 is; I'd be very interested in knowing what measurment tools were used to derive this answer. I don't disagree with the answer (necessarily). I just would like to know how people think that they can make any sort of meaningful `distance' measurements between a language specification and a given implementation. +To be fair, most of the bugs in 1.37.1 seem related to multiple +inheritance and virtual base classes; some of these crash the +compiler. But the bug list for g++ isn't substantially longer than +the bug list for cfront. For the bug lists that I have, this is true. I believe that ratio was about 1.2/1 in favor of cfront 2.0, but then cfront 2.1 widened the gap a bit more (perhaps to 1.2/0.8). Anyway, please don't take take those numbers a meaning anything in particular. These are just the bugs I stumbled upon in each of these two products on dark nights when the power was out and I had no flashlight. The number of things that I stumble upon (and by the way... I was drinking at the time :-) are no indication of anything whatsoever. Even if they were, you would still need to factor in the *significance* and/or *severity* of each bug. Who cares if there is a bug in an implementation in some dark corner where no sane (and sober) programmer ever goes? Most of the bugs that I have found were found in just such places. -- // Ron Guilmette - C++ Entomologist // Internet: rfg@ncd.com uucp: ...uunet!lupine!rfg // Motto: If it sticks, force it. If it breaks, it needed replacing anyway.
rfg@NCD.COM (Ron Guilmette) (11/16/90)
In article <13154@cadillac.CAD.MCC.COM> vaughan@mcc.com (Paul Vaughan) writes: >I'd heard that AT&T had made or intends to make their library (or parts of >it) available as a separate product. Can anyone confirm/deny that? I can confirm that when I spoke with the AT&T product manager for cfront at the USENIX C++ Conference last April, he stated that he *was* going to make the library code that comes with cfront into a separate product so that if you had a brand X C++ compiler (or translator) you could just buy a licence for the AT&T libraries and *not* also be forced to pay for cfront itself. Better still, he said that his target price for the library was $<minimal>. He mentioned a number for <minimal> but I'd rather let AT&T tell you what number they ended up choosing. Anyway, since that was last April, I imagine that by now, AT&T is either doing it, or has decided never to do it. AT&T Software sales is at 1-800-828-UNIX. Be prepared to have somebody who speaks South Carolinian standing by on your end to interpret. :-) -- // Ron Guilmette - C++ Entomologist // Internet: rfg@ncd.com uucp: ...uunet!lupine!rfg // Motto: If it sticks, force it. If it breaks, it needed replacing anyway.
leech@homer.cs.unc.edu (Jonathan Leech) (11/17/90)
In article <2711@lupine.NCD.COM> rfg@NCD.COM (Ron Guilmette) writes: >In article <13154@cadillac.CAD.MCC.COM> vaughan@mcc.com (Paul Vaughan) writes: >>I'd heard that AT&T had made or intends to make their library (or parts of >>it) available as a separate product. Can anyone confirm/deny that? >Better still, he said that his target price for the library was $<minimal>. >He mentioned a number for <minimal> but I'd rather let AT&T tell you what >number they ended up choosing. I'm not AT&T, but I just called them: 2.0 library source: $2000/first cpu (commercial) $300 (academic) 1.0 library extension source: $5000/first cpu (commercial) $1000 (academic) -- Jon Leech (leech@cs.unc.edu) __@/ ``Even by the 22nd century, no way had yet been discovered of keeping elderly and conservative scientists from occupying crucial administrative positions. Indeed, it was doubted if the problem ever would be solved.'' - Arthur Clarke, _Rendezvous with Rama_
dlw@odi.com (Dan Weinreb) (11/17/90)
In article <2711@lupine.NCD.COM> rfg@NCD.COM (Ron Guilmette) writes:
Anyway, since that was last April, I imagine that by now, AT&T is either
doing it, or has decided never to do it.
Not necessary. AT&T is a large company with complex internal
organization. It can be slow sometimes. (I don't know anything about
this particular issue; this is just a general comment.)jimad@microsoft.UUCP (Jim ADCOCK) (11/20/90)
In article <17523@thorin.cs.unc.edu> leech@cezanne.cs.unc.edu (Jonathan Leech) writes: > You can quibble over terminology, but the fact is that lack of the >iostream package makes G++ useless for many applications, such as mine. In >terms of portability, the standard library is part of the language. regards ANSI-fication "standards" -- I believe the libraries group of the standardization committee is working to identify a simplified version of iostreams to become the "standard." What this is exactly, is not yet finalized, I believe. It sounds like the intent is to make stdio call freely intermixable with streams calls, so maybe one would do best for today to stick to the simpler functionality of [io]/streams, and use stdio for more complicated functionality. --Thus making it more likely that your software will work with the future ANSI library standards -- when they emerge.