Questions about porting a large engine from Windows to Linux
Author
I am getting ready to port a large scientific simulation engine from Windows (developed in Visual C++ 2005) to my linux box. I have a couple questions that I have had trouble finding answers to via google:
- Is GNU g++ as ISO Compliant as MS Visual C++? I do a lot of lifting with the STL in the engine, so this is a big issue. I spent a lot of time to make sure that the entire code base is ISO compliant so that hopefully this problem wouldn't grow too large.
- How can I configure MSVC++ to give me errors/warnings for code that won't port?
I've been learning how to use Linux (Ubuntu 7 for me) for the last few weeks, and I'm just getting acquainted with using g++ in the terminal, creating makefiles, editing with vim, etc. Any other pointers for porting large projects would be greatly appreciated.
Quote:Original post by Sagar_Indurkhya
- Is GNU g++ as ISO Compliant as MS Visual C++? I do a lot of lifting with the STL in the engine, so this is a big issue. I spent a lot of time to make sure that the entire code base is ISO compliant so that hopefully this problem wouldn't grow too large.
They are about equally compliant, but when it comes to implementation-defined behavior like the size of primitive types they might differ. They might also differ in what parts of standard C++ they don't support.
Quote:- How can I configure MSVC++ to give me errors/warnings for code that won't port?
In "Project Settings -> C/C++ -> Language" there is an item called "Disable language extensions". If you set that to "Yes" it will reject programs depending on VC++-specific features. I'm not sure how helpful it will be, but it might point out some problems you missed.
Quote:- Is GNU g++ as ISO Compliant as MS Visual C++? I do a lot of lifting with the STL in the engine, so this is a big issue. I spent a lot of time to make sure that the entire code base is ISO compliant so that hopefully this problem wouldn't grow too large.
In my experience, gcc/g++ is more lenient when it comes to STL than MSVC, if anything. You can, for example, perform destructive operations on a list while iterating through with an iterator without reassigning that iterator and still have a functioning program (results in runtime error for MSVC - behaviour is undefined in the C++ standard).
Keep in mind that MSVC is a little more lenient than g++ with regards to template expansion. I've had a set of templates compile without a single warning in MSVC and had g++ throw errors everywhere on the same code.
Having been once, where you are now, I have a tangential piece of advice: ditch vi and download nano, No sense in purposefully doing things the hard way.
Quote:Original post by erissian
ditch vi and download nano, No sense in purposefully doing things the hard way.
um.. I would disagree and say it the other way around. ( He said vim not vi btw) Vim has syntax highlighting and auto-complete (and from my experience nano doesn't). But that is a personal perferance depending on person to person
But if we want to do things the "easy" way, I would recommend using a "real" IDE (such as Kdevelop).
Author
Turns out I was just dumb.
I have one file, main.cpp, and a bunch of header files. Because I'm lazy, I made everything inline in every class definition.
When I tried to compile, I would type:
g++ main.cpp Cell.h Reaction.h ... CellSpace.h -o PLGRNSE
which gave me a bunch of errors.
Then I tried:
g++ main.cpp -o PLGRNSE
bam everything worked! It's nice to know that all the time I spent trying to write portable code in the spring worked out!
I'm learning vim very slowly, mainly because I don't know many key bindings/commands, and I get frustrated trying to program when the editor is the limiting factor! However I'm getting better at it everyday. Eventually I'll move onto Emacs and get good at them both.
I have one file, main.cpp, and a bunch of header files. Because I'm lazy, I made everything inline in every class definition.
When I tried to compile, I would type:
g++ main.cpp Cell.h Reaction.h ... CellSpace.h -o PLGRNSE
which gave me a bunch of errors.
Then I tried:
g++ main.cpp -o PLGRNSE
bam everything worked! It's nice to know that all the time I spent trying to write portable code in the spring worked out!
I'm learning vim very slowly, mainly because I don't know many key bindings/commands, and I get frustrated trying to program when the editor is the limiting factor! However I'm getting better at it everyday. Eventually I'll move onto Emacs and get good at them both.
Quote:Original post by Sagar_Indurkhya
I'm learning vim very slowly, mainly because I don't know many key bindings/commands, and I get frustrated trying to program when the editor is the limiting factor! However I'm getting better at it everyday. Eventually I'll move onto Emacs and get good at them both.
Unless you want to "just because its fun" there is no reason to learn Emacs if you know Vim, on the other hand it might be better to start with emacs instead of vim because it has an easier learning curve for new users.
Other options would be gedit with some nice plugins (no learning curve and works ok) or KDevelop, code::blocks, eclipse etc. (Personally I prefer vim over emacs, and seldom use any full IDEs other than what I make with vim and console windows, but its all down to personal experience).
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
