ANSI and GNU regarding compatibility

Discussion in 'C++' started by Peng Yu, Jul 15, 2008.

  1. Peng Yu

    Peng Yu Guest

    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
     
    Peng Yu, Jul 15, 2008
    #1
    1. Advertising

  2. Have you included <math.h> or <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 <> 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.
    >
    > I'm wonder what the general case is.
    >
    > Thanks,
    > Peng
     
    Lucas V. Hartmann, Jul 15, 2008
    #2
    1. Advertising

  3. Peng Yu

    James Kanze Guest

    On Jul 15, 8:20 am, "Lucas V. Hartmann" <>
    wrote:
    > Have you included <math.h> or <cmath>, which is where M_PI
    > should be defined?


    M_PI should not be defined in <math.h> nor in <cmath> for 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:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
     
    James Kanze, Jul 15, 2008
    #3
  4. 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
     
    Erik Wikström, Jul 15, 2008
    #4
  5. Peng Yu

    Peng Yu Guest

    On Jul 15, 5:03 am, Erik Wikström <> wrote:
    > 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
     
    Peng Yu, Jul 15, 2008
    #5
  6. On 2008-07-15 19:05, Peng Yu wrote:
    > On Jul 15, 5:03 am, Erik Wikström <> wrote:
    >> 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
     
    Erik Wikström, Jul 16, 2008
    #6
  7. Peng Yu

    gpderetta Guest

    On Jul 16, 11:15 am, Erik Wikström <> wrote:
    > On 2008-07-15 19:05, Peng Yu wrote:
    >
    >
    >
    > > On Jul 15, 5:03 am, Erik Wikström <> wrote:
    > >> 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
     
    gpderetta, Jul 16, 2008
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Peter

    1 day gnu, whole life gnu?

    Peter, Jan 10, 2005, in forum: Java
    Replies:
    3
    Views:
    358
    John C. Bollinger
    Jan 10, 2005
  2. Peter
    Replies:
    17
    Views:
    629
    Chris Smith
    Jan 13, 2005
  3. Markus Elfring
    Replies:
    2
    Views:
    389
    Markus Elfring
    Feb 23, 2005
  4. Replies:
    1
    Views:
    510
  5. Replies:
    11
    Views:
    1,110
    Keith Thompson
    Apr 28, 2008
Loading...

Share This Page