Re: [Flightgear-devel] Big Nasal Changes
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 ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Big Nasal Changes
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 selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Big Nasal Changes
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 language (g++/gcc). More practically, this site seems to have good info, albeit not always complete: http://predef.sourceforge.net/ Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Big Nasal Changes
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 : http://www.dotnet247.com/247reference/msgs/56/280444.aspx snip Sounds like Microsoft is just trying to be customer oriented... Ah...you mean cu$tomer oriented, right? The closed source democracy: majority rules, money talks. :-) Best regards, Jim ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Big Nasal Changes
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 installed somewhere. The API for extensions has changed with this version, and your compilation is picking up the older version of nasal.h. Quite right - I hadn't rebuilt SimGear correctly, and the compilation was still picking up the older version of nasal.h. I also had a few local difficulties in FlightGear, but all fixed, and everything compiles correctly Thanks for your help. Vivian ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Big Nasal Changes
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 this? Here is a small subset from the IRIX man pages for MIPSpro: The following list summarizes some of the major differences between the GNU cc compiler and the MIPSpro C compiler. The wording gcc allows or g++ allows in the following paragraphs indicates that the GNU compiler is providing more flexible constructs beyond what is allowed in the standard. The MIPSpro compilers adhere more closely to standards requirements. * The gcc compiler allows variadic macros; the MIPSpro 7.4 compilers support these macros in c99 mode. If you have code that uses ellipses (...) as part of a macro definition and you are not compiling with c99, you will need to rewrite the macro. Two possible approaches are to replace the macro with a new variadic function, or to create a family of macros, each taking different (fixed) numbers of arguments. * gcc allows the non-standard __FUNCTION__ and __PRETTY_FUNCTION__ pseudo-macros. These are not true macros, so you must use _GNUC__ to test for them. As of IRIX 6.5.18, the c99 func macro is available, which expands to a function name. * By default gcc allows C++ style double slash (//) comments in C code. To obtain this behavior with the MIPSpro C compilers you must specify the -Xcpluscomm command line option or use c99, which defines a double slash (//) to be a comment. But leave it at this, it might be better to spent our time hunting problems like this one: When I start FlightGear I get the following list of errors on IRIX (bug-Endian) (Linux doesn't have this problem): Nasal runtime error: non-objects have no members at /opt/share/FlightGear/data/Nasal/view.nas, line 24 Nasal runtime error: non-objects have no members at /opt/share/FlightGear/data/Nasal/gui.nas, line 40 Nasal runtime error: non-objects have no members at /opt/share/FlightGear/data/Nasal/autopilot.nas, line 29 Nasal runtime error: non-objects have no members at /opt/share/FlightGear/data/Nasal/controls.nas, line 17 Nasal runtime error: non-objects have no members at /opt/share/FlightGear/data/Nasal/fuel.nas, line 17 After that, every key I press generates this error: Nasal runtime error: no such member at command, line 1 Failed to execute command nasal Do you have any clue where to search for this? Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Big Nasal Changes
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 three structure layouts* for the naRef -- both endiannesses for 32 bit and just one layout for 64 bit)? Can you verify that nothing has broken with the endian detection stuff at the top of nasal.h (building for the wrong layout will mostly work but might produce issues like this), maybe by just deleting everything that isn't part of a NASAL_BIG_ENDIAN_32_BIT block? Can anyone else on a big endian system (Mac, Sparc) see the same or similar problem? Oddly, the structure layout stuff has not changed in this version, so I'm out of ideas as to what might have happened. I'll see if I can find a BE system at work (we have a few old suns running linux) to test on. Andy * At some point I'll start using my laptop in 64 bit mode full time and work more on the 64 bit version; right now it stores 12 bytes per naRef, but it could be shrunk down to 8 by unioning the pointer and the double by setting the NaN bits of the pointer. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Big Nasal Changes
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 - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Big Nasal Changes
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 typedefs in net_crtls.hxx should be correct for Sparc32 too. Have you tried something like this in src/Network/net_ctrls.hxx: - #elif defined( _MSC_VER ) || defined(__MINGW32__) + #elif defined( _MSC_VER ) || defined(__MINGW32__) || defined(__solaris__) You will also need to add the following above that test to make sure the (windows-specific) __int64 type is defined (someone correct me if I'm wrong: long long exists and is 64 bits wide on both sparc32 and sparc64, right?) #ifdef __solaris__ typedef long long __int64 #endif Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Big Nasal Changes
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 (Nasal has three structure layouts* for the naRef -- both endiannesses for 32 bit and just one layout for 64 bit)? Ah, yes now I remember. It's for 32-bit big-endian. Can you verify that nothing has broken with the endian detection stuff at the top of nasal.h (building for the wrong layout will mostly work but might produce issues like this), maybe by just deleting everything that isn't part of a NASAL_BIG_ENDIAN_32_BIT block? This seems to work correctly, it detects it has to define NASAL_BIG_ENDIAN_32_BIT Oddly, the structure layout stuff has not changed in this version, so I'm out of ideas as to what might have happened. I'll see if I can find a BE system at work (we have a few old suns running linux) to test on. It's getting late here so I won't do any testing today but I'll start to look at it tomorrow morning again. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Big Nasal Changes
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 up. This one is actually a C99 feature, not C89. If MSVC (or the SGI or Sun compilers) doesn't support it, I can use a slightly more complicated variant by declaring it as an array of one member and diddling the allocation math. I strongly suspect that it does work, though, since your compiler called it a non-standard* extension and not a parse error. In which case it ought to be sufficient to find the #pragma that disables the warning. * Which is silly, because what is ISO C99 if not a standard? :) This is only a warning. Maybe I am too strict on the warning level. But this is the least of the problem. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Big Nasal Changes
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 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 simpler than yesterday evening ;-) With them the compilation is seamless and the warning on empty arrays disappeared as other C++ oddness ;-) Then change in GC_HEADER is required though. cvs -z4 -q diff -u code.c data.h lib.c misc.c (in directory I:\FlightGear\cvs\SimGear\simgear\nasal\) Index: code.c === RCS file: /var/cvs/SimGear-0.3/SimGear/simgear/nasal/code.c,v retrieving revision 1.8 diff -u -r1.8 code.c --- code.c 18 Apr 2005 19:48:47 - 1.8 +++ code.c 19 Apr 2005 06:18:24 - @@ -107,13 +107,14 @@ static void initGlobals() { +int i; +struct Context* c; globals = (struct Globals*)naAlloc(sizeof(struct Globals)); naBZero(globals, sizeof(struct Globals)); globals-sem = naNewSem(); globals-lock = naNewLock(); -int i; globals-allocCount = 256; // reasonable starting value for(i=0; iNUM_NASAL_TYPES; i++) naGC_init((globals-pools[i]), i); @@ -124,7 +125,7 @@ // Initialize a single context globals-freeContexts = 0; globals-allContexts = 0; -struct Context* c = naNewContext(); +c = naNewContext(); globals-symbols = naNewHash(c); globals-save = naNewVector(c); @@ -140,11 +141,12 @@ struct Context* naNewContext() { int dummy; +struct Context* c; if(globals == 0) initGlobals(); LOCK(); -struct Context* c = globals-freeContexts; +c = globals-freeContexts; if(c) { globals-freeContexts = c-nextFree; c-nextFree = 0; Index: data.h === RCS file: /var/cvs/SimGear-0.3/SimGear/simgear/nasal/data.h,v retrieving revision 1.3 diff -u -r1.3 data.h --- data.h 18 Apr 2005 19:48:47 - 1.3 +++ data.h 19 Apr 2005 06:10:30 - @@ -33,7 +33,7 @@ // implementing objects to pack in 16 bits worth of data for free. #define GC_HEADER \ unsigned char mark; \ -unsigned char type; \ +unsigned char type struct naObj { GC_HEADER; Index: lib.c === RCS file: /var/cvs/SimGear-0.3/SimGear/simgear/nasal/lib.c,v retrieving revision 1.6 diff -u -r1.6 lib.c --- lib.c 18 Apr 2005 19:48:47 - 1.6 +++ lib.c 19 Apr 2005 06:17:09 - @@ -49,8 +49,9 @@ static naRef setsize(naContext c, naRef me, int argc, naRef* args) { +int sz; if(argc 2) return naNil(); -int sz = (int)naNumValue(args[1]).num; +sz = (int)naNumValue(args[1]).num; if(!naIsVector(args[0])) return naNil(); naVec_setsize(args[0], sz); return args[0]; Index: misc.c === RCS file: /var/cvs/SimGear-0.3/SimGear/simgear/nasal/misc.c,v retrieving revision 1.4 diff -u -r1.4 misc.c --- misc.c 18 Apr 2005 19:48:47 - 1.4 +++ misc.c 19 Apr 2005 06:17:09 - @@ -49,10 +49,11 @@ naRef naNew(struct Context* c, int type) { +naRef result; if(c-nfree[type] == 0) c-free[type] = naGC_get(globals-pools[type], OBJ_CACHE_SZ, c-nfree[type]); -naRef result = naObj(type, c-free[type][--c-nfree[type]]); +result = naObj(type, c-free[type][--c-nfree[type]]); naVec_append(c-temps, result); return result; } ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Big Nasal Changes
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 simpler than yesterday evening ;-) With them the compilation is seamless and the warning on empty arrays disappeared as other C++ oddness ;-) Then change in GC_HEADER is required though. The same problem happened for MIPSpro. Since I have a bulk of patches to wade through I have committed this one to get a clean CVS tree. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Big Nasal Changes
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 stopped warning about this (in C mode, under -Wall) several years ago. You need to engage -ansi and disable --std=c99 to see stuff like this. 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. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Big Nasal Changes
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 just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Big Nasal Changes
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 not a C++ thing. And GCC stopped warning about this (in C mode, under -Wall) several years ago. You need to engage -ansi and disable --std=c99 to see stuff like this. 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/msgs/56/280444.aspx Not speaking about the fact that a lot of people are still using the v6 version that was released in 1998. Thanks for committing the patch. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Big Nasal Changes
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/msgs/56/280444.aspx Not speaking about the fact that a lot of people are still using the v6 version that was released in 1998. Thanks for committing the patch. Sounds like Microsoft is just trying to be customer oriented... Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [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 website last night and it seemed to imply that I do not need to program in .NET or the other fancy stuff they implimented but being Microsoft I am leary to believe them. So, anyone out there with VC++ 2003 that could shed some light on this? Will the programs I use now still compile without any modifications under the 2003 / 2005 IDE? Frederic Bouvier wrote: 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 not a "C++" thing. And GCC stopped warning about this (in C mode, under -Wall) several years ago. You need to engage -ansi and disable --std=c99 to see stuff like this. 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/msgs/56/280444.aspx Not speaking about the fact that a lot of people are still using the v6 version that was released in 1998. Thanks for committing the patch. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Big Nasal Changes
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 to imply that I do not need to program in .NET or the other fancy stuff they implimented but being Microsoft I am leary to believe them. So, anyone out there with VC++ 2003 that could shed some light on this? Will the programs I use now still compile without any modifications under the 2003 / 2005 IDE? You still can do traditional C++ with VC++ 7.1 aka .NET 2003. This is called unmanaged code in Microsoft terminology. This version is a lot more compliant to standards C++ wise, but C seems to be locked on ansi with additionnal features that are borrowed to newer specs. If you use C++ templates, you should prefer the last version because VC6 is notoriously buggy in that area. I tried beta 1 of VC++ 2005. I managed to compile FG but the runtime was not happy with / as path separators so FG crashed very early. Beta 2 is out and available for download but I don't had a chance to try it yet. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Big Nasal Changes
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 a compiler option to enable it which is the only valid way to enable it. Just face it, gcc behaved bad (again). Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Big Nasal Changes
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 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 to to enable other non-C89 features like // comments or the empty array declaration. So why isn't MIPSpro behaving badly in *exactly* the same way by supporting these things without requiring a command line extension? I can fix the code to match compiler limitations. But I'm at a loss for why you think it is somehow GCC's fault for generating correct output for correct source code by default... Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Big Nasal Changes
For what this is worth: For work, I build flightgear with some custom modsusing 2003 .NET It builds with pretty much zero code changes. I dohave to munge around with the project files and add a bunch of include paths, lib paths, lib refs,etc. to get a clean build. However, the interesting part of 2003 .NET is the debugger. I have nothing but problems with it. It is just plain not as stable as the VC6 debugger. Constant crashes with large applications like FlightGear. I've been told that this is a install specific thing and that our messed up workstation config is the cause (our network IS/mgmt people are quite inept.) Other people tell me "no, it just sucks like that for any install." So I'm not sure where the truth lies. Probably somewhere in the middle. Many people in our company that are forced to do windows development refuse to upgrade to 2003 .NET even 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] 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 website last night and it seemed to imply that I do not need to program in .NET or the other fancy stuff they implimented but being Microsoft I am leary to believe them. So, anyone out there with VC++ 2003 that could shed some light on this? Will the programs I use now still compile without any modifications under the 2003 / 2005 IDE? Frederic Bouvier wrote: 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 not a "C++" thing. And GCC stopped warning about this (in C mode, under -Wall) several years ago. You need to engage -ansi and disable --std=c99 to see stuff like this. 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/msgs/56/280444.aspx Not speaking about the fact that a lot of people are still using the v6 version that was released in 1998. Thanks for committing the patch. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Big Nasal Changes
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 to to enable other non-C89 features like // comments or the empty array declaration. So why isn't MIPSpro behaving badly in *exactly* the same way by supporting these things without requiring a command line extension? I can fix the code to match compiler limitations. But I'm at a loss for why you think it is somehow GCC's fault for generating correct output for correct source code by default... 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, c89 and c99 are incompatible in that way, you can't compile c89 code without warnings on a c99 compiler, or visa versa. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Big Nasal Changes
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? The one that the SGI compiler does not generate for // comments? The one that gcc does not generate for inline variable declarations? The one that the MSVC compiler generates for empty array members in a struct? If you want me to fix a warning condition in Nasal, I'm happy to. Just point me to where. If you want the GCC people to add a warning, please be more specific (and maybe consider posting to a more appropriate forum). If you actually think the SGI compiler catches all possible errors with its magical warning-fu, then I have a bridge to sell you. :) Seriously, Erik. Think more about the problem. There are no easy answers here; I think you've misunderstood* something. * Example: You seem to think that an inline declaration is a bad thing, and worth warning about. But you seem to be fine with comments that begin with //, a non-C89 feature about which the SGI compiler is silent. Both are useful features, part of C99, and worth supporting, so why does your opinion of the two differ? My guess is it's only because your favorite compiler writers toss a warning for one and not the other. :) 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. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Big Nasal Changes
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 you talking about? The one that the SGI compiler does not generate for // comments? The one that gcc does not generate for inline variable declarations? The one that the MSVC compiler generates for empty array members in a struct? Just a precision and I will stop here : MSVC is not emitting a warning on empty (no size, [] ) array members in C mode, just in C++ mode. The problem with MSVC is the same than with MIPSpro : inline variable definition in C mode and this is an error for it. The other problem I had with recent Nasal code was that a construct like this : struct naObj { unsigned char mark; unsigned char type; ; }; with an empty member ( double ; ) induced by the use of the macro GC_HEADER produce a syntax error. I am not arguing here that MSVC is free of bugs but we have to cope with them, and the situation with VC 7.1 is much better than with older VC 6. FYI, I also have this kind of warnings : 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 loss of data and : simgear\nasal\hash.c(37) : warning C4018: '' : signed/unsigned mismatch simgear\nasal\hash.c(71) : warning C4018: '' : signed/unsigned mismatch simgear\nasal\hash.c(176) : warning C4018: '' : signed/unsigned mismatch simgear\nasal\hash.c(203) : warning C4018: '' : signed/unsigned mismatch I can live with these warning, and they are a bunch in other sections of FG code. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Big Nasal Changes
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. The only C99 feature that gets used is the // comment convention. None of this has changed from the last version, either, and several FlightGear releases have been made against the MSVC compiler. Are you sure you aren't over-diagnosing a simpler error by switching to C++ mode? 3. the word 'namespace' is used as a name of a struct member in naFunc in data.h. 'namespace' is definitively reserved keyword in C++. Yet more evidence that this is not, in fact, C++ code. :) 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? 5. 'delete' is a reserved keyword in C++ ( in lib.c that needs to be compiled with the C++ language ) OK, get this out of your head now. It's not C++, it doesn't compile with a C++ compiler, and it never has. :) 6. can't convert void * to char * without a cast. Hrm... now that I thought definitely *was* part of the C89 standard, otherwise every malloc() invocation needs its own cast. Are you sure this isn't yet another C++ side effect? 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. 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)' I'm afraid that with my limited knowledge I don't think I can offer a tentative solution. Regards, Vivian ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Big Nasal Changes
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 API for extensions has changed with this version, and your compilation is picking up the older version of nasal.h. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Big Nasal Changes
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 not to include it. But honestly, it's just more readable in many cases. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Big Nasal Changes
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 -1.3 +++ data.h18 Apr 2005 21:20:58 - @@ -33,7 +33,7 @@ // implementing objects to pack in 16 bits worth of data for free. #define GC_HEADER \ unsigned char mark; \ -unsigned char type; \ +unsigned char type struct naObj { GC_HEADER; to avoid that. 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. In C, MSVC doesn't seems to like union assignment, but I may be wrong. It's ok in C++, but there is a lot of subsequent problems induced by this change of language. See below : 3. the word 'namespace' is used as a name of a struct member in naFunc in data.h. 'namespace' is definitively reserved keyword in C++. 4. I have a warning on a non standard extension used on naRef array[]; ( empty array in struct ) 5. 'delete' is a reserved keyword in C++ ( in lib.c that needs to be compiled with the C++ language ) 6. can't convert void * to char * without a cast. --- lib.c18 Apr 2005 19:48:47 -1.6 +++ lib.c18 Apr 2005 21:42:18 - @@ -219,7 +219,7 @@ va_list va; int len = 16; while(1) { -buf = naAlloc(len); +buf = (char *)naAlloc(len); va_start(va, f); if(vsnprintf(buf, len, f, va) len) { va_end(va); and it's late here so I can't continue but there is a lot of other messages ( I have the french version of MSVC so the error messages are in french ) -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Big Nasal Changes
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 gets used is the // comment convention. None of this has changed from the last version, either, and several FlightGear releases have been made against the MSVC compiler. Are you sure you aren't over-diagnosing a simpler error by switching to C++ mode? 3. the word 'namespace' is used as a name of a struct member in naFunc in data.h. 'namespace' is definitively reserved keyword in C++. Yet more evidence that this is not, in fact, C++ code. :) 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? 5. 'delete' is a reserved keyword in C++ ( in lib.c that needs to be compiled with the C++ language ) OK, get this out of your head now. It's not C++, it doesn't compile with a C++ compiler, and it never has. :) 6. can't convert void * to char * without a cast. Hrm... now that I thought definitely *was* part of the C89 standard, otherwise every malloc() invocation needs its own cast. Are you sure this isn't yet another C++ side effect? 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. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Big Nasal Changes
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 C89. If MSVC (or the SGI or Sun compilers) doesn't support it, I can use a slightly more complicated variant by declaring it as an array of one member and diddling the allocation math. I strongly suspect that it does work, though, since your compiler called it a non-standard* extension and not a parse error. In which case it ought to be sufficient to find the #pragma that disables the warning. * Which is silly, because what is ISO C99 if not a standard? :) Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d