I was told there is only one kind of C++ in Linux. I was surprised and looked at man gcc and direct that person to the section headed:
Options Controlling C Dialect
The following options control the dialect of C (or languages derived from C, such as C++, Objective-C and Objective-C++) that the compiler accepts:
-ansi In C mode, support all ISO C90 programs. In C++ mode, remove GNU extensions that conflict with ISO C++.
This is what I was in referance to. I wonder what C Dialect Windows uses?
Hi,
On Sunday 2 September 2007 9:21:40 pm Karl Larsen wrote:
I was told there is only one kind of C++ in Linux. I was surprisedand looked at man gcc and direct that person to the section headed:
I suspect am I that person, so I guess I should consider myself directed ;)
Options Controlling C Dialect The following options control the dialect of C (or languages derived from C, such as C++, Objective-C and Objective-C++) that thecompiler accepts:
-ansi In C mode, support all ISO C90 programs. In C++ mode, removeGNU extensions that conflict with ISO C++.
This is what I was in referance to. I wonder what C Dialect Windowsuses?
This is different to what you original said, to quote "Do recall that there are many basic types of C++ and you need to let them know which to use"
i.e. you are suggesting there are different types of "C++" - As far as I am considered this in incorrect.
C, C++, Objective-C and Objective-C++ are all *different" languages in themselves. They may share some common heritage in C or C++, but they are not the same language in a strict sense.
( Its the same as American English being very similar to English (British), but not being the same, far from it ;) )
Chris
Karl Larsen wrote:
I was told there is only one kind of C++ in Linux. I was surprised and looked at man gcc and direct that person to the section headed:
Options Controlling C Dialect
The following options control the dialect of C (or languages derived from C, such as C++, Objective-C and Objective-C++) that the compiler accepts:
Unfortunately only one of these is C++[1][2]. By dialect they mean the standard used for each one. In C mode that means whether to support the C90 or C99 standards and whether gnu and other extensions to the language should be supported. Which can have interesting effects on the availability of GNU or Posix functions like getopt. The C++ mode will do the equivalent for that language.
-ansi In C mode, support all ISO C90 programs. In C++ mode, remove GNU extensions that conflict with ISO C++.This is what I was in referance to. I wonder what C Dialect Windows uses?
MS own dialect. They tend to choose (particularly with C++) what bits to support and what not to and like all other compiler vendors will provide their own extensions. Further support varies between the different versions. Visual C++ 6 was notorious for some bits of its C++ support, though many of these were later patched.
I can only really speak about C, not C++, but in both MS and GCC compilers support for the latest version of the C99 standard is not complete (N.B. that some parts will require support in the underlying library, glibc for GNU). Some parts of the standard are implemented as extensions.
The best way to stay safe in terms of portability is to stick to the published standard and run your compiler in conforming mode, but often confounding factors will make this difficult.
[1] Attempts to treat C++ as a superset of C eventually lead to pain. [2] Objective-C++? I'd like some of whatever they're having please.
Ian Malone wrote:
Karl Larsen wrote:
I was told there is only one kind of C++ in Linux. I was surprised and looked at man gcc and direct that person to the section headed:
Options Controlling C Dialect
The following options control the dialect of C (or languagesderived from C, such as C++, Objective-C and Objective-C++) that the compiler accepts:
Unfortunately only one of these is C++[1][2]. By dialect they mean the standard used for each one. In C mode that means whether to support the C90 or C99 standards and whether gnu and other extensions to the language should be supported. Which can have interesting effects on the availability of GNU or Posix functions like getopt. The C++ mode will do the equivalent for that language.
-ansi In C mode, support all ISO C90 programs. In C++ mode,remove GNU extensions that conflict with ISO C++.
This is what I was in referance to. I wonder what C Dialect Windows uses?
MS own dialect. They tend to choose (particularly with C++) what bits to support and what not to and like all other compiler vendors will provide their own extensions. Further support varies between the different versions. Visual C++ 6 was notorious for some bits of its C++ support, though many of these were later patched.
I can only really speak about C, not C++, but in both MS and GCC compilers support for the latest version of the C99 standard is not complete (N.B. that some parts will require support in the underlying library, glibc for GNU). Some parts of the standard are implemented as extensions.
The best way to stay safe in terms of portability is to stick to the published standard and run your compiler in conforming mode, but often confounding factors will make this difficult.
[1] Attempts to treat C++ as a superset of C eventually lead to pain. [2] Objective-C++? I'd like some of whatever they're having please.
When I was MUCH younger and using an old Fortran because that was what we had, I learned about the subtle changes you can make by a simple change. I tried to compile some of my old code on the Linux Fortran 97 and they would all error out. I fixed them and it was not too hard. Around 1970 I got interested in C. I still have books of that vintage and was amazed that Unix was made with C. At that time I think ANCI C was in style.
On Sun, 2007-09-02 at 15:26 -0600, Karl Larsen wrote:
When I was MUCH younger and using an old Fortran because that waswhat we had, I learned about the subtle changes you can make by a simple change. I tried to compile some of my old code on the Linux Fortran 97 and they would all error out. I fixed them and it was not too hard. Around 1970 I got interested in C. I still have books of that vintage and was amazed that Unix was made with C. At that time I think ANCI C was in style.
That would have been the dialect known as "K&R C"--the language described in the original edition of Kernighan and Ritchie's book.
I believe the ANSI C (later ISO C) standard was adopted in the early '90s. It added function prototypes and standardized the library, among other changes.
There is now a new C standard (nicknamed "C99"), which includes some additional features. Most compilers haven't fully implemented this version yet.
The best references for comparison of the various C versions are the various editions of the Harbison and Steele book. At least the 4th edition also has a good discussion of the relationship between C and C++ and how to write code that is as close as possible to portable between the two languages.
Matthew Saltzman wrote:
On Sun, 2007-09-02 at 15:26 -0600, Karl Larsen wrote:
When I was MUCH younger and using an old Fortran because that waswhat we had, I learned about the subtle changes you can make by a simple change. I tried to compile some of my old code on the Linux Fortran 97 and they would all error out. I fixed them and it was not too hard. Around 1970 I got interested in C. I still have books of that vintage and was amazed that Unix was made with C. At that time I think ANCI C was in style.
That would have been the dialect known as "K&R C"--the language described in the original edition of Kernighan and Ritchie's book.
I believe the ANSI C (later ISO C) standard was adopted in the early '90s. It added function prototypes and standardized the library, among other changes.
There is now a new C standard (nicknamed "C99"), which includes some additional features. Most compilers haven't fully implemented this version yet.
The best references for comparison of the various C versions are the various editions of the Harbison and Steele book. At least the 4th edition also has a good discussion of the relationship between C and C++ and how to write code that is as close as possible to portable between the two languages.
You have it right Matt. I recall it was K&R C at first and there were few libraries you could include. It was much later ANSI-C showed up and it was much nicer. I never got real interested in C++ because I never used it to make a living.
-
Chris Jones -
Ian Malone -
Karl Larsen -
Matthew Saltzman