Andy Ross wrote:
More practically, this site seems to have good info, albeit not always
complete:
http://predef.sourceforge.net/
Good enough for me ;-)
Thanks,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
Andy Ross wrote:
- #elif defined( _MSC_VER ) || defined(__MINGW32__)
+ #elif defined( _MSC_VER ) || defined(__MINGW32__) || defined(__solaris__)
Can anyone give me a hint on how to determine the defines that are
set by the compiler itself ?
Martin.
--
Unix _IS_ user friendly - it's just
Martin Spott wrote:
Can anyone give me a hint on how to determine the defines that are
set by the compiler itself ?
With a gcc variant, you can do something like:
echo | gcc -E -dM -
This is kinda fun, you can watch how the built-in defines changes as
you vary the optimization switches and
From: Curtis L. Olson
Frederic Bouvier wrote:
I am not here to endorse Microsoft choices, but I see little point to use C
syntax when C++ is available and is the language of choice for the overall
FlightGear project. However, the link below should clarify Microsoft point of
view :
Andy Ross wrote
Vivian Meazza wrote:
It won't compile under Cygwin using gcc either. Fails with:
NasalSys.cxx:292: error: invalid conversion from `naRef (*)(Context*,
naRef,
int, naRef*)' to `naRef (*)(Context*, naRef)'
You forgot to update your SimGear, or have an old one still
Andy Ross wrote:
Basically: please be constructive. Singing about SGI's wonderful Unix
or flaming GCC for failing to warn about correct (!) code isn't
improving Nasal or FlightGear.
Excuse me? You started accusing other compilers about not being standard
compliant and now I am the one who
Erik Hofman wrote:
When I start FlightGear I get the following list of errors on IRIX
(big-Endian) (Linux doesn't have this problem):
This looks like the GC is cleaning up objects incorrectly. On the
assumption that this is an endianness issue: Is this for a 32 or 64
bit target (Nasal has
Andy Ross wrote:
Can anyone else on a big endian system (Mac, Sparc) see the same or
similar problem?
I would do if I could - I'm still busy with digging through Port me!
Platforms that don't have stdint.h errors in
src/FDM/ExternalNet/ on Solaris,
Martin.
--
Unix _IS_ user friendly -
Martin Spott wrote:
Andy Ross wrote:
Can anyone else on a big endian system (Mac, Sparc) see the same
or a similar problem?
I would do if I could - I'm still busy with digging through Port
me! Platforms that don't have stdint.h errors in
src/FDM/ExternalNet/ on Solaris,
The
Andy Ross wrote:
Erik Hofman wrote:
When I start FlightGear I get the following list of errors on IRIX
(big-Endian) (Linux doesn't have this problem):
This looks like the GC is cleaning up objects incorrectly. On the
assumption that this is an endianness issue: Is this for a 32 or 64
bit target
Selon Andy Ross [EMAIL PROTECTED]:
I wrote:
4. I have a warning on a non standard extension used on
naRef array[];
This one is new, but I honestly thought it was a standard C89 feature.
Can you post the warning? Or is there a #pragma I can use to turn it
off?
I just looked it
Selon Andy Ross:
Please try again, this time in C, and let me know the error you are
seeing. I strongly suspect you've been fooled by a much simpler
issue.
OK, I backed out all my changes and restart the compilation. I found where it is
not C : you don't always declare local variables at the
Frederic Bouvier schreef:
OK, I backed out all my changes and restart the compilation. I found where it is
not C : you don't always declare local variables at the beginning of functions
but you have the C++ habit to declare them as you need them. So the change
below are needed and they are much
Frederic Bouvier wrote:
I found where it is not C : you don't always declare local
variables at the beginning of functions but you have the C++
habit to declare them as you need them.
... which is a well-established feature of the (now 6-year-old!)
C99 standard. It's not a C++ thing. And GCC
Andy Ross wrote:
Sigh. I guess six years isn't enough for SGI and Microsoft. Has
anyone had a chance to try the Sun compiler, which (I think) is
the only other one we use.
I use GCC-3.4.2 on Sun because I didn't manage to get a different one,
Martin.
--
Unix _IS_ user friendly - it's
Selon Andy Ross:
Frederic Bouvier wrote:
I found where it is not C : you don't always declare local
variables at the beginning of functions but you have the C++
habit to declare them as you need them.
... which is a well-established feature of the (now 6-year-old!)
C99 standard. It's
Frederic Bouvier wrote:
I am not here to endorse Microsoft choices, but I see little point to use C
syntax when C++ is available and is the language of choice for the overall
FlightGear project. However, the link below should clarify Microsoft point of
view :
I am still using VC++ 6.0 from 98 myself. I have been thinking of
upgrading to either 2003 or 2005 but hesitant to do so until I find out
whether I can still code the same way as I do now in those
environments. I did some reading on the MS website last night and it
seemed to imply that I do
Selon Terry Reinert:
I am still using VC++ 6.0 from 98 myself. I have been thinking of
upgrading to either 2003 or 2005 but hesitant to do so until I find out
whether I can still code the same way as I do now in those environments.
I did some reading on the MS website last night and it seemed
Andy Ross wrote:
Erik Hofman wrote:
The same problem happened for MIPSpro.
Sigh. I guess six years isn't enough for SGI and Microsoft. Has
anyone had a chance to try the Sun compiler, which (I think) is
the only other one we use.
It is, in fact MIPSpro supported c99 before gcc did, but you need
Erik Hofman wrote:
It is, in fact MIPSpro supported c99 before gcc did, but you need a
compiler option to enable it which is the only valid way to enable
it. Just face it, gcc behaved bad (again).
I don't follow the logic. If that were the true, then the only
valid result of running a C
ven though the development
environment is nicer than VC6.
Hope this helps you at least somewhat.
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Terry
ReinertSent: Tuesday, April 19, 2005 8:25 AMTo:
FlightGear developers discussionsSubject: Re: [Flightgear-devel]
Andy Ross wrote:
I don't follow the logic. If that were the true, then the only
valid result of running a C compiler would be a pre-struct KR
thing, no? :)
You don't bother to turn on a switch to enable structs or function
prototypes, you just expect them to be there. Similarly you didn't
need
Erik Hofman wrote:
It's quite simple, SGI has the zero warning compiling philosophy; No
build will be shipped if it generates a warning. It has gained them
the reputation of being one of the most stable UNIX variants
available.
Now I'm even more confused. What warning are you talking about?
Andy Ross wrote :
Erik Hofman wrote:
It's quite simple, SGI has the zero warning compiling philosophy; No
build will be shipped if it generates a warning. It has gained them
the reputation of being one of the most stable UNIX variants
available.
Now I'm even more confused. What warning
Andy Ross wrote:
Frederic Bouvier wrote:
2. MSVC use file extensions to choose the right language to
compile. So in misc.c the syntax of C not C++ apply. This file
should definitively be named misc.cxx, like lib.c should be lib.cxx.
Definitely not. I promise you that it's a C file.
Vivian Meazza wrote:
It won't compile under Cygwin using gcc either. Fails with:
NasalSys.cxx:292: error: invalid conversion from `naRef (*)(Context*, naRef,
int, naRef*)' to `naRef (*)(Context*, naRef)'
You forgot to update your SimGear, or have an old one still
installed somewhere. The
OK, I *finally* got the last of the (known) bugs fixed over the
weekend, so it's time to make a new Nasal release. Enough has changed
(all the advertised features are now present and working) that I think
this will be a 1.0 release.
I'm not finished doing the documentation and website work for
I wrote:
Here's a quick overview of the changes (or at least all of the ones
I can remember at the moment):
Yup, forgot one:
The C syntax for conditional expressions (A ? B : C) now works in
Nasal like you expect. This is 100% identical to writing
if(A){B}else{C}, and I had originally planned
Andy Ross a écrit :
Scream really loudly if something breaks and you want this patch reverted.
I don't really want to see this patch reverted, but here is my first
experience with MSVC.
1. empty struct member ( ;; ) seems to be disallowed. So I changed :
--- data.h18 Apr 2005 19:48:47
Frederic Bouvier wrote:
2. MSVC use file extensions to choose the right language to
compile. So in misc.c the syntax of C not C++ apply. This file
should definitively be named misc.cxx, like lib.c should be lib.cxx.
Definitely not. I promise you that it's a C file. The only C99
feature that
I wrote:
4. I have a warning on a non standard extension used on
naRef array[];
This one is new, but I honestly thought it was a standard C89 feature.
Can you post the warning? Or is there a #pragma I can use to turn it
off?
I just looked it up. This one is actually a C99 feature, not
32 matches
Mail list logo
