Writing Cross Platform Code?
Author
Ok so im going to sound dumb now, if i dont usally already.
How do i go about writing cross platform code?
The target platforms are Linux and Windows and i dont really know what to look out for in terms of incompatibility between the two.
Any ideas?
ace
Basically you have the system layer. The difference is Win32 and POSIX. Windows has a Posix environment (SFU) but it's not standard on windows.
So you got file system, network, gui, etc etc differences to begin with.
Look for libraries that help with your problem.
GUIs - wxWindow, Qt, GTK.
Games - SDL is the best bet.
Network - HawkNL
Boost has a lot of libraries for cross-platform, like a filesystem, threads, etc.
NOTE: it certainly doesn't trivialize it, it is not easy. You can have alot of problems simply between different Linuxes and Unixes too ;-)
So you got file system, network, gui, etc etc differences to begin with.
Look for libraries that help with your problem.
GUIs - wxWindow, Qt, GTK.
Games - SDL is the best bet.
Network - HawkNL
Boost has a lot of libraries for cross-platform, like a filesystem, threads, etc.
NOTE: it certainly doesn't trivialize it, it is not easy. You can have alot of problems simply between different Linuxes and Unixes too ;-)
A good place to start would be using cross platform libraries. I have developed my game using SDL, and took care not to use any OS specific code. While the entire development was done on Windows, I managed to get it to work on Mac OS X in less than an hour. The linux port was equally straight forward.
Author
Another Q
Is writing a windows/linux background process any different to writing a console app?
ace
Is writing a windows/linux background process any different to writing a console app?
ace
Quote:Original post by ace_lovegrove
Another Q
Is writing a windows/linux background process any different to writing a console app?
ace
Define 'back ground process'
Service? Yes,on Win32 it is much different. Unix uses Daemons.
A console loop? No, probably not very. Using threads? Yes, POSIX vs Win32.
Unix traditionally favored forks over threads and is a good thing imho.
Writing cross platform code is actually relatively easy if you're periodically compiling and testing your developing project on both systems. Basically, standard C++ compiles everywhere. If you need something platform specific (like dealing with files, memory, etc.) prefer to use the C++ library to native functions. If what you're seeking isn't in the C++ library, take a look at boost and some other third party libs.
If you absolutely need to write platform specific code, abstract it away behind a common interface. Avoid using #ifdef to select pieces of code to compile, use the build system instead (just write win32_blah.cpp, linux_blah.cpp and include appropriate files in appropriate systems into the build process on each system).
That's pretty much it. What else would you like to know?
If you absolutely need to write platform specific code, abstract it away behind a common interface. Avoid using #ifdef to select pieces of code to compile, use the build system instead (just write win32_blah.cpp, linux_blah.cpp and include appropriate files in appropriate systems into the build process on each system).
That's pretty much it. What else would you like to know?
Quote:Original post by Name_Unknown
Unix traditionally favored forks over threads and is a good thing imho.
There are benefits and drawbacks with each approach. Forking gives you a higher degree of protection (if one 'thread' crashes the rest of your app is still up and running) but makes communication and synchronization harder (and a little slower). Which approach to pick really depends on what you're doing.
There are differences in the non-standard STL parts (I'm thinking specifically of hash_map now), which tripped me up to start with. Well, for one thing the windows port doesn't hash at all, and in the linux port it's under a different namespace (__gnu_cxx) and uses "hash" instead of "hash_compare" like in windows (IIRC).
Take a look at the code to evoInvaders 0.1. It's pretty simple but runs on both Windows machines and the Dreamcast. Posting to Linux would be trivial.
The way I've done it is to create a generic interface to the various system-dependant components (System Texture, Graphics, Input and Sound) and provided Win32 and Dreamcast implementations of these. When compiling for your platform, you only compile the *_WIN or *_DC versions, the rest of the code is non-platform-specific and is compiled normally. This code is in C, but for C++ you'd define an abstract interface class and implement it for each platform.
It is actually pretty simple, but it forces you to think about platform specifc code in advance.
The way I've done it is to create a generic interface to the various system-dependant components (System Texture, Graphics, Input and Sound) and provided Win32 and Dreamcast implementations of these. When compiling for your platform, you only compile the *_WIN or *_DC versions, the rest of the code is non-platform-specific and is compiled normally. This code is in C, but for C++ you'd define an abstract interface class and implement it for each platform.
It is actually pretty simple, but it forces you to think about platform specifc code in advance.
Author
Quote:Original post by Name_UnknownQuote:Original post by ace_lovegrove
Another Q
Is writing a windows/linux background process any different to writing a console app?
ace
Define 'back ground process'
Service? Yes,on Win32 it is much different. Unix uses Daemons.
A console loop? No, probably not very. Using threads? Yes, POSIX vs Win32.
Unix traditionally favored forks over threads and is a good thing imho.
Thanks for the reply, but can you expand on that please. And yes i did mean Service, sorry.
ace
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
