Program portability

Question

How to make sure that my program will be fully portable?

Answer 1

Avoid platform-specific libraries.

Answer 2

Avoid using platform specific libraries. If you can implement desired functionality using the STL and BOOST only, go ahead.

Answer 3

Develop on the most restrictive compilation environment. Use the smallest set of features from C++. Split the platform-dependent portions of code into separate files. Develop a configuration (make) environment for each platform, as part of the software package.

Answer 4

Unit test it, on each platform, during development

Answer 5

Making sure to only use libraries that actually exist on all target platforms would be a good start.

Answer 6

1. Test

This is a necessary but not a sufficient condition for doing anything properly. To test portability, you'll want multiple platforms and compilers.

2. Write to the standard, not to your development platform.

This means, only do something if the standard says you can do it. Only expect a particular result if the standard says you can expect it. Only use a library or API if the standard says it exists. The standard is available here (among other places):

http://openassist.googlecode.com/files/C%2B%2B%20Standard%20-%20ANSI%20ISO%20IEC%2014882%202003.pdf

It helps if you assume that:

• CHAR_BIT is equal to 9.
• sizeof(int) is equal to 5 and int is a 37 bit type. Or a 16 bit type.
• the basic character set is EBCDIC.
• The epoc began in 1721.
• time_t is double

And so on. By which I don't mean, write code that relies on those things to be true, I mean write code that will work if they are, and will also work on a sane implementation.

3. Use the most restrictive and pedantic compiler options you can find,

This is the only practical way to give yourself a reasonable chance of achieving (1).

4. Understand that "real compilers" fail to implement the standard correctly or fully, and make some concessions to this fact.

Theoretically, there's nothing non-portable about a C++ program that uses export. If it's a perfectly good C++ program in every other respect, then it will work on any conforming C++ compiler. But hardly anyone uses a conforming C++ compiler, so there's a de facto common subset of C++ that you'll want to stick to.

5. Understand that the C++ standard provides quite a restricted programming environment

Certain things are not portable in standard C++, such as drawing graphics on a screen, since standard C++ has no graphics or GUI API. So there is no such thing as a "fully portable" GUI program written in C++. So you may or may not need to revise your goal, depending what your program is supposed to do.

If your program requires something that simply cannot be done entirely within standard C++, then you can make your program easier to port by encapsulating that behaviour within an interface which you think should be implementable on all platforms you care about. Then set about implementing it for each one. This doesn't result in a "fully portable" program, though, since to me that means a program which you can compile and run unchanged on any conforming C++ implementation. A program which can be ported to most platforms with a C++ compiler, probably, assuming they have a screen and a mouse, with some bespoke programming work, isn't the same thing.

All this can be taken too far, of course. You will probably actually want to assume that CHAR_BIT is 8 (reading files is madness otherwise), and perhaps even rely on a GUI framework like Qt. But you did say, "fully portable", and one of the main things you need to do to write portable programs is usually to work out how far you're willing to compromise on "fully".

6. Assert what you assume

At compile-time if you can, or runtime otherwise, ensure that if your program requires int to be at least 32 bits (or whatever), then it will fail noisily when it isn't. OK, so comprehensive test coverage would catch cases where your arithmetic silently overflows and gives the wrong answer, but it's hard to write truly comprehensive tests, and anyway the tests might make the same non-portable errors as the code, or some poor sucker who has downloaded your code might not run them all properly.

When you use libraries, you are effectively doing this automatically. You'll #include some header, and if the library isn't available that will fail immediately. At least, you hope it will - it's conceivable that some other implementation could have a header of the same name which does something radically or subtly different. Radical differences usually result in compilation failures, for subtle differences you can test for preprocessor symbols to identify implementations.