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 !
-
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 an
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 se
> 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
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 (N
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 " errors in
> src/FDM/ExternalNet/ on Solaris,
The typed
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 " errors in
src/FDM/ExternalNet/ on Solaris,
Martin.
--
Unix _IS_ user friendly - it's
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 thr
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 started
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 ol
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. T
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Frederic Bouvier schrieb:
> simgear\nasal\string.c(200) : warning C4244: 'function' : conversion
> from 'double' to 'int', possible loss of data
> simgear\nasal\string.c(261) : warning C4244: 'function' : conversion
> from 'double' to 'int', possible l
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 are
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 abou
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 K&R
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
e: [Flightgear-devel]
Big Nasal Changes
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 websi
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
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
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 see
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 not
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 :
http://www.dotnet247.com/247reference/m
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
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 j
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
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 sim
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 th
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 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 featu
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 tha
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 -000
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 planne
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 th
33 matches
Mail list logo
