ANSI and GNU regarding compatibility

[Peng Yu]

Hi,

ANSI and GNU C are different in some delicate aspects (I'm not sure
about C++). For example, M_PI is not in ANSI C but in GNU C.

Of course, to make my program most portable, I should go for ANSI. But
since ANSI lacks some convenient facilities, such as M_PI just
mentioned, I would like to use GNU C.

Now, the question is if a platform has ANSI C, what is the chance it
does not have GNU C? What is the chance that a GNU C can not be
installed at all? If in most platforms that have both ANSI C and GNU
C. Then I should just use GNU C.

I'm wonder what the general case is.

Thanks,
Peng

[Lucas V. Hartmann]

Have you included <math.hor <cmath>, which is where M_PI should be
defined? Sometimes the most common header files are built-into the
compiler to speed up compilation, so gcc might accept M_PI even
without the header file included. I am pretty certain that M_PI is
standard, as even older C compilers (e.g. Borland Turbo C) supported
it.

On Jul 15, 12:47*am, Peng Yu <[e-mail]:

Hi,

ANSI and GNU C are different in some delicate aspects (I'm not sure
about C++). For example, M_PI is not in ANSI C but in GNU C.

Of course, to make my program most portable, I should go for ANSI. But
since ANSI lacks some convenient facilities, such as M_PI just
mentioned, I would like to use GNU C.

Now, the question is if a platform has ANSI C, what is the chance it
does not have GNU C? What is the chance that a GNU C can not be
installed at all? If in most platforms that have both ANSI C and GNU
C. Then I should just use GNU C.

I'm wonder what the general case is.

Thanks,
Peng

[James Kanze]

On Jul 15, 8:20 am, "Lucas V. Hartmann" <[e-mail]>
wrote:

Have you included <math.hor <cmath>, which is where M_PI
should be defined?

M_PI should not be defined in <math.hnor in <cmathfor a
standard compliant compiler. The C and C++ standards forbid it.
(But the Posix standard requires it. If, and only if,
_POSIX_C_SOURCE is defined.)

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[=?UTF-8?B?RXJpayBXaWtzdHLDtm0=?=]

On 2008-07-15 05:47, Peng Yu wrote:

Hi,

ANSI and GNU C are different in some delicate aspects (I'm not sure
about C++). For example, M_PI is not in ANSI C but in GNU C.

Of course, to make my program most portable, I should go for ANSI. But
since ANSI lacks some convenient facilities, such as M_PI just
mentioned, I would like to use GNU C.

Now, the question is if a platform has ANSI C, what is the chance it
does not have GNU C? What is the chance that a GNU C can not be
installed at all? If in most platforms that have both ANSI C and GNU
C. Then I should just use GNU C.

If ANSI C is not enough go to the next best thing: POSIX (which, among
other things is where M_PI comes from). All UNIX/Linux systems that I
know of are more or less POSIX compatible and many C and C++ compilers
includes support for POSIX features as well. Building in compiler
dependencies in your code is a bad idea unless you really have to.

--
Erik Wikström

[Peng Yu]

On Jul 15, 5:03 am, Erik Wikström <[e-mail]:

On 2008-07-15 05:47, Peng Yu wrote:

Hi,

ANSI and GNU C are different in some delicate aspects (I'm not sure
about C++). For example, M_PI is not in ANSI C but in GNU C.

Of course, to make my program most portable, I should go for ANSI. But
since ANSI lacks some convenient facilities, such as M_PI just
mentioned, I would like to use GNU C.

Now, the question is if a platform has ANSI C, what is the chance it
does not have GNU C? What is the chance that a GNU C can not be
installed at all? If in most platforms that have both ANSI C and GNU
C. Then I should just use GNU C.

If ANSI C is not enough go to the next best thing: POSIX (which, among
other things is where M_PI comes from). All UNIX/Linux systems that I
know of are more or less POSIX compatible and many C and C++ compilers
includes support for POSIX features as well. Building in compiler
dependencies in your code is a bad idea unless you really have to.

I would like my g++ compiler following POSIX. There is an options -
ansi to make it ANSI compatible. Is there an options to make g++ POSIX
compatible? Or g++ is already POSIX compatible without an option?

Thanks,
Peng

[=?UTF-8?B?RXJpayBXaWtzdHLDtm0=?=]

On 2008-07-15 19:05, Peng Yu wrote:

On Jul 15, 5:03 am, Erik Wikström <[e-mail]:

>On 2008-07-15 05:47, Peng Yu wrote:

Hi,

ANSI and GNU C are different in some delicate aspects (I'm not sure
about C++). For example, M_PI is not in ANSI C but in GNU C.

Of course, to make my program most portable, I should go for ANSI. But
since ANSI lacks some convenient facilities, such as M_PI just
mentioned, I would like to use GNU C.

Now, the question is if a platform has ANSI C, what is the chance it
does not have GNU C? What is the chance that a GNU C can not be
installed at all? If in most platforms that have both ANSI C and GNU
C. Then I should just use GNU C.

If ANSI C is not enough go to the next best thing: POSIX (which, among
other things is where M_PI comes from). All UNIX/Linux systems that I
know of are more or less POSIX compatible and many C and C++ compilers
includes support for POSIX features as well. Building in compiler
dependencies in your code is a bad idea unless you really have to.

I would like my g++ compiler following POSIX. There is an options -
ansi to make it ANSI compatible. Is there an options to make g++ POSIX
compatible? Or g++ is already POSIX compatible without an option?

To my knowledge POSIX does not make any changes or additions to the C
language it only adds a number of library functions, so the compiler
have nothing to do with it.

--
Erik Wikström

[gpderetta]

On Jul 16, 11:15*am, Erik Wikström <[e-mail]:

On 2008-07-15 19:05, Peng Yu wrote:

On Jul 15, 5:03 am, Erik Wikström <[e-mail]:

On 2008-07-15 05:47, Peng Yu wrote:

Hi,

ANSI and GNU C are different in some delicate aspects (I'm not sure
about C++). For example, M_PI is not in ANSI C but in GNU C.

Of course, to make my program most portable, I should go for ANSI. But
since ANSI lacks some convenient facilities, such as M_PI just
mentioned, I would like to use GNU C.

Now, the question is if a platform has ANSI C, what is the chance it
does not have GNU C? What is the chance that a GNU C can not be
installed at all? If in most platforms that have both ANSI C and GNU
C. Then I should just use GNU C.

If ANSI C is not enough go to the next best thing: POSIX (which, among
other things is where M_PI comes from). All UNIX/Linux systems that I
know of are more or less POSIX compatible and many C and C++ compilers
includes support for POSIX features as well. Building in compiler
dependencies in your code is a bad idea unless you really have to.

I would like my g++ compiler following POSIX. There is an options -
ansi to make it ANSI compatible. Is there an options to make g++ POSIX
compatible? Or g++ is already POSIX compatible without an option?

To my knowledge POSIX does not make any changes or additions to the C
language it only adds a number of library functions, so the compiler
have nothing to do with it.

Every posix C compiler is also an ANSI C compiler, but not viceversa.

Posix does add extra requirements to the C language. For example
threading requires support from the compiler; CHAR_BIT must be 8 and a
posix system must also support a compiling environment were int is at
least 32 bits. IIRC it also requires that all pointers have the same
size (including function pointers).

HTH,

--
gpd