novak@intvax.UUCP (James L. Novak) (06/09/90)
I apologise if I break any defined protocol re: comp.lang.c--I am a new subscriber. I have many ANSI C modules (developed on a PC) that I want to use on a SPARCstation. I've seen the problem of ANSI C to C translators discussed thoroughly here before--I got in in the middle. My question is: is C++ a superset of ANSI C such that any C++ compiler will take ANSI C and spit out "standard" C (or binary)? I get conflicting answers, especially with regard to linking th code to old C libraries (need to use "externc"). If this is true, can't we just all get C++ compilers? BTW, my SUN rep says V4.1 will include ANSI C--but not till later this fall. Jim Novak Sandia National Labs novak@cs.sandia.gov or novak@intvax.UUCP, whichever happens to be up....
karl@haddock.ima.isc.com (Karl Heuer) (06/11/90)
In article <3547@intvax.UUCP> novak@intvax.UUCP (James L. Novak) writes: >My question is: is C++ a superset of ANSI C such that any C++ >compiler will take ANSI C and spit out "standard" C (or binary)? Not quite. And if it compiles to C code, the result is unmaintainable. >If this is true, can't we just all get C++ compilers? Why not "just" get an ANSI C compiler? That's almost certainly less work than getting a C++ compiler. Karl W. Z. Heuer (karl@ima.ima.isc.com or harvard!ima!karl), The Walking Lint
platt@ndla.UUCP (Daniel E. Platt) (06/11/90)
In article <3547@intvax.UUCP>, novak@intvax.UUCP (James L. Novak) writes: > I apologise if I break any defined protocol re: comp.lang.c--I > am a new subscriber. > > > My question is: is C++ a superset of ANSI C such that any C++ > compiler will take ANSI C and spit out "standard" C (or binary)? POINT 1: I understand that for the most part, there is declaration compatibility except on one point. In ANSI C, a declaration with no arguments: double foo(); is interpreted to mean that foo may have an argument, but that it hasn't been specified to the compiler what the types are. If you want to specify that they function is to take NO arguments in ANSI C, you specify double foo(void); On the other hand, in C++, the specification double foo(); means that foo() has NO arguments (equivalent to 'double foo(void)' in ANSI C). POINT 2: C++ has generally been handled via a preprocessor that produces C code, with the expectation that a 'native' C++ compiler will follow. Some companies have been producing native C++ compilers not dependent on ATT's C++ translator. > I get conflicting answers, especially with regard to linking th > code to old C libraries (need to use "externc"). If you're using the translator based products, there shouldn't be a library incompatibility, since you're using the standard C compiler anyway. If you're using a native C++ compiler, you might have library problems. C++ also has its own libraries to worry about; but if you're not using the C++ standard 'streams.h' IO interface or other such, you probably don't need to worry about all that. > If this is true, can't we just all get C++ compilers? With the added advantages of object oriented programming, I'd tend to agree just on general prinicples. It enhances your options without restricting them. Dan
fischer@iesd.auc.dk (Lars P. Fischer) (06/12/90)
In article <3547@intvax.UUCP> novak@intvax.UUCP (James L. Novak) writes: >I have many ANSI C modules (developed on a PC) that I want to >use on a SPARCstation. I've seen the problem of ANSI C to C >translators discussed thoroughly here before--I got in in the >middle. Get the GNU C compiler (GCC). Works nicely on the SPARCstation and supports ANSI C. It is free software and is available from several FTP sites. prep.ai.mit.edu is one. /Lars -- Lars Fischer, fischer@iesd.auc.dk | NeXT: A disaster looking for a place CS Dept., Univ. of Aalborg, DENMARK. | to happen -- Bill Joy
bms6x@hopper.cs.Virginia.EDU (Brad M. Segal) (07/14/90)
Hi, Does anyone know of a text that describes the differences between ANSI C and C++ 2.0? I'm trying to compile ANSI C headers with a C++ compiler and not getting too far. I'd appreciate any help. Thanks! ------------------------------------------------------------------------------ Brad Segal "So you're having a relationship, University of Virginia with a screwed-up person... Department of Computer Science Welcome to Philadelphia!"
henry@zoo.toronto.edu (Henry Spencer) (07/15/90)
In article <1990Jul13.225712.3433@murdoch.acc.Virginia.EDU> bms6x@hopper.cs.Virginia.EDU (Brad M. Segal) writes: > Does anyone know of a text that describes the differences between >ANSI C and C++ 2.0? I'm trying to compile ANSI C headers with >a C++ compiler and not getting too far. The best book for this is the new Annotated C++ Reference Manual (Ellis and Stroustrup, Addison-Wesley 1990). Be warned that it's expensive. Be warned, also, that it describes the current version of C++, and most compilers don't implement that yet. That last point deserves emphasis: you're going to have to be more precise than "a C++ compiler". C++ has evolved quite a bit since the old Stroustrup book, and various compilers implement slightly different languages. -- NFS: all the nice semantics of MSDOS, | Henry Spencer at U of Toronto Zoology and its performance and security too. | henry@zoo.toronto.edu utzoo!henry
bs@alice.UUCP (Bjarne Stroustrup) (07/17/90)
henry@zoo.toronto.edu (Henry Spencer @ U of Toronto Zoology) writes: > > Does anyone know of a text that describes the differences between > >ANSI C and C++ 2.0? I'm trying to compile ANSI C headers with > >a C++ compiler and not getting too far. > The best book for this is the new Annotated C++ Reference Manual (Ellis > and Stroustrup, Addison-Wesley 1990). Be warned that it's expensive. > Be warned, also, that it describes the current version of C++, and most > compilers don't implement that yet. I'd like to try to prevent a couple of potential (and probably uninented) misconceptions: The ARM has 457 pages and a recommended price of US$37.75. That is, about 8 cents a page and - I think - quite reasonable compared with books of a similar quality and page count. In addition, the ARM is hardcover and printed on nice paper. My personal opinion is that ALL books are too expensive and in particular that the price increase that most books suffer when sold in continental Europa is shocking, but that is a separate issue and that it would be unfair to single out the ARM as particularly expensive. > That last point deserves emphasis: you're going to have to be more > precise than "a C++ compiler". C++ has evolved quite a bit since the > old Stroustrup book, and various compilers implement slightly different > languages. Yes, agreed 100%. However please also note that most C++ compilers currently shipped (AT&T 2.0 and 2.1 ports, Turbo C++, Zortech 2.1, ect.) are actually quite close; the ARM is not simply a paper design for an unimplemented language. The efforts of the C++ standards committee and of its members which includes most C++ compiler purveyers - and currently even most C++ compiler writers - makes further convergence probable. Older, 1.? versions differ to a greater extent. I think it could be argued that the relative differences between 1.? and 2.1 are of the order of the relative differences between Classic C and ANSI C. FYI: Ellis & Stroustrup: The Annotated C++ Reference Manual Addison Wesley, 1990. 450 pages. ISBN 0-201-51459-1 To return to the original question: There shouldn't be problems compiling ANSI C headers with a C++ compiler provided the headers don't rely on the int f(); /* f() accepts all kinds of arguments */ trick. In addition, many `ANSI C' compilers accept `extensions' - such as allowing casts as lvalues - for compatibility with Classic C dialects. Most such `extensions' are errors in C++. The ARM lists the differences between ANSI C and C++.