lib files are NOT usable across different OSs. even calls that are non system api calls in the "standard" library are implemented different on different OSs. obj files will link to OS specific code no matter what you do. recompiling on each OS is not difficult and should be as simple as just running the compiler.

here is an example of OS independet code, but requires OS dependent libraries.
int *a = new int();
delete int();

each compiler handles allocation differently. so that right there modifies how the code is generated. ussually new used on a struct call malloc() then the ctor which inits everything in the object. delete calls the dtor then free().

malloc is implemneted different on different systems, heck some OSs use different calling conventions (ie pass parms on teh stack, pass them using registers, caller should clean up parms, the function deals with cleaning up the parms, etc), as well as simply handling memory allocation differently. there is VERY little code that you can write that is truly 100% not relient on the OS.

there is no such thing as an OS independent compiler as you think. since the compiler compiles whatever it is given using the libraries it has avialible which are OS dependent. you can change the libraies and even the target platform (ie cpu) with some compilers.

question. does your OBJ file contain ANY OS code (ie use printf, basically an io call) or use anything that deals with memory? if so the opcodes compiled into the OBJ file will not run since it will fail to find the functions (ie not linked with the libraries, and different OSs handle dynamic libraries differently if they are even supported) or they are linked staticly in which you have OS specific code with in your OBJ file (the actually asm code to create blocks of memory is different in each OS, since OSs can map interrupt functions in any way they wish). dont try this. do things correctly and cross compile your code using proper dlls/o or libs/a. dont hack things using OBJ files. you will find its MUCH more work to ensure yoru code will run correctly and even more work to get arounf the limitations you will face because of yoru choices.

compiling ocde is not so difficult that it requires such a difficult workaround.

Eli Gottlieb, you say you found code to "parse" exe files. i assume this is only fo the pe format (ie win32). linux and other OSs use different mehods of storage AND initilization of exes.

what are you trying to create? a math library that works in linux and windows? you seem to be confised on some things. try explaining better what your are trying to do. i think you really just want to compile the code on a single platform, but have it work on mulitple platforms. this can work, it requires installing mulitple compilers and libraries for the platforms you wish to use, and compiling your binary for each platform.

Were these tests using the optimisations that everyone was talking about earlier, and in what context are you talking about here? Graphics programming, general etc. Very vague statement.

quote:Original post by Magmai Kai Holmlor
In all the performance test I''ve looked at, MSVC was often about twice as fast as gcc. The price of portability?

quote:Original post by Magmai Kai Holmlor
In all the performance test I''ve looked at, MSVC was often about twice as fast as gcc.

Can you show us some of these tests you are refering to? In this article (which was primarily meant to compare Java and C/C++), (an old version of) GCC outperforms MSVC (MSVC 6 Enterprise) in 3 out of 5 tests, so I don''t think that they are so unequal as what you claim.

quote:Original post by Magmai Kai Holmlor
In all the performance test I''ve looked at, MSVC was often about twice as fast as gcc.

..and Intel C/C++ Compiler twice as fast as MSVC.

quote:Original post by Null and Void
In this article (which was primarily meant to compare Java and C/C++), (an old version of) GCC outperforms MSVC (MSVC 6 Enterprise) in 3 out of 5 tests, so I don''t think that they are so unequal as what you claim.

And by all accounts, the new GCC 3.1 produces even better code still. (At the expense of slower compile times, however.)



[ MSVC Fixes | STL | SDL | Game AI | Sockets | C++ Faq Lite | Boost | Asking Questions | Organising code files ]

quote:Original post by Kylotan
And by all accounts, the new GCC 3.1 produces even better code still. (At the expense of slower compile times, however.)

That''s been my experience with GCC 3.x . That''s why I made sure to add "an old version" to that post.

Looking at that Java/C comparison article, the setups aren''t really comparable. The GCC setup is set to do a lot more aggressive optimization...The MSVC setup, for example, is generally isn''t biasing its optimizations towards Pentium Pro and above as it would if one used the /G6 option... The gcc setup, on the other hand, clearly is set up to bias towards ppro and above.

Anyway, gcc isn''t that bad. Not bad enough that you have to worry too much about its performance, especially as you can use it for free, which is a big plus. However, in my experience, having used both quite extensively (up to their current release versions) MSVC++ (especially V7/.Net, but V6 too) produces consistently faster code when it comes to real world C++. As far as straight C goes, they might be closer and gcc might even beat it in some cases..Dunno, haven''t programmed straight C code in years. But for C++ code using templates and other langage features, I''d pick MSVC++ over gcc any day (though they both still have problem areas when it comes to the dark corners of the C++ standard).


In any case, if performance is what you care about over price, you''ll want the Intel compiler (mentioned previously) which is even better yet, or Codeplay''s vectorizing compiler (doesn''t support C++ under Windows yet though...supposed to have a version that would in May but its delayed). Both of those beat MSVC++, but if you value your sanity you''ll still buy a copy of VC++ for the slick IDE and debugger (debug builds in MSVC++ so you get the edit & continue and other rather nice debug functionality, release builds in the performance compiler of your choice...the two mentioned both support Visual Studio IDE integration).

quote:Original post by gmcbay
Looking at that Java/C comparison article, the setups aren''t really comparable. The GCC setup is set to do a lot more aggressive optimization...The MSVC setup, for example, is generally isn''t biasing its optimizations towards Pentium Pro and above as it would if one used the /G6 option... The gcc setup, on the other hand, clearly is set up to bias towards ppro and above.

Yes, I''d like to see the test done again with every compiler set to optimize for the current system. If anyone would like to come up with some code to duplicate the tests run under than article, maybe that could be done (I don''t see any download link for the source code in the article).

quote:Original post by gmcbay
Both of those beat MSVC++, but if you value your sanity you''ll still buy a copy of VC++ for the slick IDE and debugger...

When it comes to my sanity, I''d have to say that MSVC (6, at least, the only version I own) has caused me many more problems when it comes to standard compliance than Borland (5.5) or GCC (any version that I''ve used) .