Program portability

Question

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

Answer 1

Your question:

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

cannot be answered satisfyingly. You cannot, in any real-world application, make sure it's portable. You can only prove your expectation by accurate tests of the application on the target platform, as has been already proposed here by Lou Franco.

In the process of developing and testing in parallel on different platforms or environments, every one of us finds his bag of tricks and explores his share of pitfalls. You said in one comment you work on a Windows system. This is fine. Try to get your program working with the Visual Studio compiler (and environment). Then, install CygWin with the GCC 4.x compiler suite. Install the Netbeans IDE & C++ Environment and create a project based on the same sources. Netbeans will use the Cygwin GCC 4.x. If your compiled program works with both toolchains, you mastered probably about 90% of the real-world portability hurdles.

Regards

rbo

Answer 2

This is less a direct answer to the question, than an answer in the light of other answers.

You need to balance a requirement for absolute portability against the expectations of platform users - there are different basic HCI/HIG guidelines for Windows, OS X, KDE and Gnome, and none of the portable GUI toolkits will automatically produce the right results in each (some allow you to apply different layouts, which is a start).

The inbetween approach is to have a pure portable core with multiple native GUIs.

It's not necessary (there is a lot of software that succeeds despite ignoring conventions) but it is a trade-off that needs to be considered - in particular if there is an existing strong native application.

Answer 3

Continuous integration on all target platforms.

Answer 4

It is impossible. What happens when I write my operating system that has a weird C compiler?

That said, to be portable, you need to:

• Avoid Win32
• Avoid POSIX (which is annoying... You may want to just use Cygwin to provide Windows support)
• Avoid any platform specific library. This usually limits you in graphics to wxWindows, GTK, and QT.
• TEST. Make sure it works.
• Don't assume anything. Windows is weird and uses \r\n, so be careful about that.
• I think Visual C++ on windows gives you warnings about "unsafe c functions" and asks you to use the "safe ones", which are not standard. Don't fall for Microsoft's attempt to monopolize your program.

Some things will help:

• Autoconf will allow any decent system (ie one that includes a shell) to detect common portability issues and set up the correct headers
• Cmake can do this as well, but only on platforms that Cmake itself is available on

Answer 5

Know the platforms that you intend to ship for. If some platform convention contradicts the standard, ignore the standard. I'm serious about that. For example, if you use the standard std::ifstream constructor, which takes a char* argument, you won't be able to open any files with Unicode filenames on Windows—you must use the nonstandard wchar_t* overload there. The functionality lost by not being able to open files that are allowed and legal on the platform severely outweighs the portability gained by using only what the standard knows; in the end, it's the functionality that matters, not the adherence to a particular standard.

Answer 6

• Make it standards compliant. At least a common subset of the standard that is implemented by vendors on all platforms you intend to deploy your application on.

• Factor out platform specific portions from platform-independent ones. Typically, the lowest layer or two should deal with the platform.

• Keep abreast with changes of:

  • Platform/OS APIs
  • Tool chains
  • Language features

• Test, Deploy. Rinse and repeat.