How to write portable code in c++?

Question

What are the things that I should keep in mind to write portable code? Since I\'m a c++ beginner, I want to practice it since beginning.

Thanks.

Answer 1

Use STL types when possible. Be careful of using system dependent types and APIs. For example don't use types like UINT, and DWORD on Windows.

You can use a library like boost to make it easier for you to write portable code. If you need a GUI consider using a cross platform toolkit like Qt.

Sometimes you will need to write platform specific code, and in those cases you can do something like this:

#ifdef _WIN32
#include <windows.h>
#else
#include <unistd.h>
#endif

Answer 2

Write command-line programs to begin with. When you're ready, find a cross-platform windowing toolkit such as Qt.

If you're interested in writing multilingual code, use a third-party unicode library such as ICU rather than relying on platform-specific libraries.

Answer 3

Others said it before, but here is my view on it:

1) Do you need C++? It's not the best language for writing portable code because it's close to the bare metal. Java, Python, Perl, PHP or Javascript might be better for you.

2) If you need C++, don't try to write completely portable code, it's almost impossible anyway. Instead, decide early which platforms you want to support. For example: Linux, MacOS X, Windows

3) Make sure you test your code on all selected platforms continously. Don't just build on Windows and expect to just compile a Linux version 'when it's done'. Compile on all platforms daily and make sure you keep testing them for problems.

Answer 4

What are the things that I should keep in mind to write portable code?

1. Keep several compilers nearby, test code regularly on target platforms. If you're doing cross-platform software for windows windows/linux , keep around mingw, visual studio express (i.e. "microsoft compiler"), and a linux installation with g++ (or use virtual machine). Even if your code is perfect, compiler might have some kind of unexpected quirk. For example, certain versions of ms compiler have a limit on sizes of string constants, which gcc doesn't have.
2. Do not rely on sizes of standard types. For example, on msvc sizeof(wchar_t) is 2 bytes. On linux installation it can be 4 bytes. Use sizeof (if you need it), or try to avoid having to use size of any type in your code. And you should not assume that pointer is 4 bytes large (passing user data pointer into api call scenario) - it will be 8 bytes on 64 bit.
3. Do not use compiler-specific pragmas, macros and extensions. For example, avoid "#pragma once".
4. Do not use extensions to standard library (provided by compiler developer). This more applicable to C library functions, though. For example, MS compiler provides multiple "safe" (like strcpy_s) versions of standard C-style routines. Which, of course, won't be available on other platforms.
5. Be very careful if you decide to use C-style routines (like sprintf) in C++ code. (I know that it is supposed to be a bad practice, but in some scenarios this is useful) They have slightly different implementations, extensions, and different number of parameters. For example, sprintf may have different additional formats that are implemented differently on different platforms. For example, last time I checked "%S" behaves differently on msvc and gcc in vswprintf routine.
6. Do not rely on compiler-specific data types, like __int32. It is very likely that you'll need some kind of type that is guaranteed to be 4 bytes long (or something like that) - use typedef combined with conditional compilation ("#ifdef WIN32"). OR use types provided by cross-platform library. For example, SDL provides types like Uint8, Qt 4 has quint32, etc. This is pretty common practice.
7. Avoid direct OS calls. Use standard functions for accessing files.
8. When you have to use OS-specific calls, use conditional compilation (#ifdef WIN32, etc)
9. Try to use same build system on all platforms. There is no MSBuild on linux. Use gnumake, cmake, scons or qmake. While in some of those systems you will have to code in flags for different compiler, it will be possible to use same script everywhere. FOr example, it works nicely with SConstructs. And maintaining one building script for all platforms may be easier than synchronizing changes across different build systems.
10. For all operations that require interaction with operating system (Gui, file manipulation), use cross-platform libraries. Qt is a good choice.

Answer 5

a good idea is to use POSIX system calls. that way you don't have to deal with different ways of creating threads or using mutexes and signals.

the problem is that Windows is not exactly POSIX compliant, but there are libraries that implement certain POSIX features, like this one: [1]: http://sourceware.org/pthreads-win32/

Answer 6

Keep platform-specific code separate from reusable code, preferably in a different file but at least in a different function. If you start having #if WIN32 and #if CYGWIN and #if BSD all over the place you'll have a maintenance nightmare.

Then, compile on at least two different platforms early and often. Typical choices are Visual C++ on Windows and gcc on Linux. Since neither the system libraries nor the compiler is shared, you'll catch non-portable code before it becomes deeply entrenched in your design.