Chapter 4 Portability
4.1 Introduction
Many people consider a piece of software to be portable if it can be built with different brand names of compiler on different operating systems. I think that is an overly narrow view of portability. In my opinion, the portability of software is increased if the software refrains from using the most recently introduced features of a programming language, because that means the software is portable to both new and older versions of a programming language.
4.2 Compatibility with Old Compilers
During the 15 years I spent working in the professional services department of a software vendor, I visited many companies who were slow to upgrade software that they were using. An example of how slow some companies are to upgrade is provided by Microsoft. Microsoft released version 6.0 of the Visual Studio C++ compiler in 1998. In 2010, some developers are still using that version of the compiler, despite the fact that Microsoft have brought out five major newer releases in the intervening 12 years.
When implementing Config4Cpp and Config4J, I decided to avoid using relatively new language features whenever possible. By “relatively new”, I mean less than 5 or 10 years old. My intention is that Config4Cpp and Config4J can be used not just with the latest versions of compilers, but with older compilers too.
For Config4J, this means that annotations, generics and enumerations (all introduced in Java 5) have been avoided. I also decided to avoid using the assert keyword (introduced in Java 1.4); instead I wrote the Util.assertion() operation to provide similar functionality.
For Config4Cpp, I have been happy to use exceptions, namespaces, and single inheritance, but I avoided static_cast<>, multiple inheritance, template types and the standard C++ library (instead I rely only on the standard C library). Further discussion of this is given in the Config4* C++ API Guide.
4.3 Platform-specific Issues
In general, portability of Java code is better than portability of C++ code. This has resulted in Config4J containing very little platform-dependent code. In fact, the only non-trivial platform-dependent code is in the implementation of getenv() in the ConfigurationImpl class. You can find a discussion of this in comments in the code.
In Config4Cpp, I have encapsulated platform-specific code in the files platform.h and platform.cpp. Interested readers should look at the comments in those files to see the approach taken to dealing with platform-specific issues.