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

• learn to use the standard library
• read books (eg. this one)
• when you're experienced, learn to use boost

Answer 3

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 4

For learning, try to avoid books that concentrate on one implementation. In some cases, the introduction or an early chapter will give you some instructions on how to get or use a language implementation; if it mentions more than one implementation you're probably OK.

Get a reference book that's platform-independent. Stroustrup's The C++ Programming Language is a fine reference, although it's not a good book for a beginner to try to learn from. Don't rely on references for a given implementation. MSDN is useful, for example, but its main focus is how to write Windows programs using Visual C++, not how to write programs that will compile and run anywhere.

To write anything really useful, you're going to have to get into nonportable code. Try to get in the habit of separating the user interface code from everything else, since that's where you'll have the least compatibility. The less code you have to change between platforms, the more portable your code is.

Answer 5

The unwary programmer is likely to walk into a whole lot of traps, that we can attempt to categorize. But let me tell you first: as an absolute it's impossible.

The problem is that even standard-conforming code might not be portable because of a particular compiler issue.

Now here are the main categories that I can think off the top of my head.

Compiler extensions

Like for example the use of variables arrays:

void func(int const n)
{
  int array[n];
}

This is not standard, but many compilers support it nonetheless because it's just practical.

Standard libraries extensions

Many standard libraries implementations provide a std::hash_map which never was specified. If you use it in your code, it's not portable.

The modern trend is to stash this stuff into the std::tr1 namespace so that programmers are aware that this is an extension.

Also be aware that many define typedef or macros that are not generic (for example PRETTY_FUNCTION). No macro is specified by the standard, and very few typedef are.

Platform specific

For example, the size and alignment of int or double is not specified in the standard. If you do bit-twiddling and expect it to have 32 bits, you'll be screwed on 64 bits platforms even without changing your compiler.

Platform API

Our programs are meant to be compiled, and they are often meant to interact with the computer they run on:

• for access to the hardware
• for access to the filesystem
• for access to the screen

You need to find cross-platform portable APIs, or roll your own. Check some libraries in the list below.

Libraries

Most well-written libraries are largely portable, just make sure that they support:

• the compilers you are interested in
• the platforms you are interested in

Good libraries involve:

• Apache (the collection of libraries)
• Boost
• Qt (for graphic)
• ICU (for Unicode handling)

The others you need to review... and that takes time.

I don't think there is a perfect answer there. But since perfect portability is not possible you need to decide which compilers and platform you wish to support.

For the platform, you should begin with Windows and one Linux flavor. For the compilers, pick any two (with Comeau if you can afford it).

Answer 6

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 7

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.

Answer 8

OS-independent code is surprisingly hard to do in C++. Consider this trivial example:

#include <iostream>
int main(int argc, char** argv) {
  std::cout << argv[0] << std::endl;
}

That is perfectly valid C++, still it's nonportable because it won't accept Unicode command line arguments on Windows. The correct version for Windows would be:

#include <iostream>
int wmain(int argc, wchar_t** argv) {
  std::wcout << argv[0] << std::endl;
}

Of course that is again nonportable, working only on Windows and being nonstandard. So in fact you cannot even write a portable main() function in C++ without resorting to conditional compilation.

Answer 9

Some guidelines:

1. Keep the business end of the code and the GUI separate.
2. Avoid the use of compiler specific crutches (#pragma, etc.)
3. Use conventional expressions that won't change behavior with compiler/platform instead of cute bit manipulation tricks.
4. If it touches hardware it belongs in a device driver.
5. Use data type headers like types.h (uint32_t, etc.).
6. Use an operating system abstraction layer so you are not calling operating system calls directly.

Sometimes you have to trade off efficiency and performance to gain portability. For example, if your code requires accessing fields out of a buffer you can always cast a packed struct to the buffer pointer. But that is horribly non-portable. So instead you need to use named pointers calculated with offsets -- sometimes with boundary alignment handling code. Not pretty, but portable. Fortunately you can hide a lot of that stuff with judicious use of class interfaces.

Not all code needs to be written that way. If you design your application in a very modular way with well defined boundaries of responsibility then 90-95% of the code can be portable without pain. Then just isolate the 5-10% in a very localized area that would need to be customized for a new platform.

Answer 10

If you can, compile all your code with at least two different compilers.

Answer 11

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 12

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.