Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > ANSI and GNU regarding compatibility

Reply
Thread Tools

ANSI and GNU regarding compatibility

 
 
Peng Yu
Guest
Posts: n/a
 
      07-15-2008
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
 
Reply With Quote
 
 
 
 
Lucas V. Hartmann
Guest
Posts: n/a
 
      07-15-2008
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 <(E-Mail Removed)> 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


 
Reply With Quote
 
 
 
 
James Kanze
Guest
Posts: n/a
 
      07-15-2008
On Jul 15, 8:20 am, "Lucas V. Hartmann" <(E-Mail Removed)>
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:(E-Mail Removed)
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
 
Reply With Quote
 
Erik Wikstr├Âm
Guest
Posts: n/a
 
      07-15-2008
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
 
Reply With Quote
 
Peng Yu
Guest
Posts: n/a
 
      07-15-2008
On Jul 15, 5:03 am, Erik Wikstr÷m <(E-Mail Removed)> 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
 
Reply With Quote
 
Erik Wikstr├Âm
Guest
Posts: n/a
 
      07-16-2008
On 2008-07-15 19:05, Peng Yu wrote:
> On Jul 15, 5:03 am, Erik Wikstr├Âm <(E-Mail Removed)> 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
 
Reply With Quote
 
gpderetta
Guest
Posts: n/a
 
      07-16-2008
On Jul 16, 11:15*am, Erik Wikstr÷m <(E-Mail Removed)> wrote:
> On 2008-07-15 19:05, Peng Yu wrote:
>
>
>
> > On Jul 15, 5:03 am, Erik Wikstr÷m <(E-Mail Removed)> 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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Are there statistics packages in ANSI C and/or ANSI C++? lbrtchx@gmail.com C Programming 11 04-28-2008 03:00 AM
Are there statistics packages in ANSI C and/or ANSI C++? lbrtchx@gmail.com C++ 1 04-24-2008 06:44 PM
Re: Any non-GNU compilers? sick of GNU copylefts Markus Elfring C++ 2 02-23-2005 10:24 PM
R e: 1 day gnu, whole life gnu? Peter Java 17 01-13-2005 03:32 PM
1 day gnu, whole life gnu? Peter Java 3 01-10-2005 02:26 PM



Advertisments