Is Portability Still Important?
I suppose it depends on what you mean by “portability.” The ability to take code to other platforms was once a cherished freedom. If another vendor’s hardware was faster, or a new compiler generated better code, you wanted to go there.
Before C things weren’t so easy, of course. Yes, there were standards in place, such as ANSI FORTRAN, but building real-world software systems often required using non-standard features, especially for I/O. Besides, in those days, hardware was large and astronomically pricey, so companies were usually tethered to a single hardware vendor or service provider. Indeed, compilers were developed by the hardware vendors, who had no interest in enabling customers to leave the fold.
The relative affordability of mid-range computers and the attendant proliferation of Unix installations in the 70s and 80s broke the Big Iron shackles and had an influence on the design of C. In the C community, in fact, portability became a way of life. Every seasoned C developer was accustomed to using typedefs and conditional compilation without much conscious effort. It was just the way things were done.
CUJ had its beginnings in the days of online bulletin boards frequented by microcomputer owners who were reaping the benefits of C’s support for portable code. You could dial up the C Users Group server, download C source for your favorite software tool or game, run it through your compiler (very likely not the one the author used), and presto! You were up and running with a new editor (remember MicroEmacs?) or text formatter (nroff, for example). I had the same tool set at work on the Vax as I had at home on my 8086, and the only price I had to pay was to change a #define or two before compiling.
As users came to demand more of their applications, the OS shackles clamped on again, since the most popular requests, graphics and threading, are by nature platform dependent. A small number of cross-platform GUI libraries popped up, but they didn’t last long. POSIX threads gave cross-platform portability to the Unix world, but that’s not as big a world as it used to be. (See Bill Kempf’s excellent article on Boost.Threads in this issue for a threading library that ports to Win32, POSIX, and the MacIntosh.)
And then came Java. By placing support for threads and graphics in the virtual machine, your GUIs and multithreaded applications could go anywhere the JVM could take them. No solution is perfect, of course, and there are those who think that Java’s threading model leaves a lot to be desired, but no matter — much of Java’s appeal is its OS independence.
But that’s not the point, really. Too many of us seem to forget what prompted the portability concept in the first place. It wasn’t just about compiler independence, nor platform independence, as nice as they are. It was about not being dependent upon one particular company, whether it’s their hardware, operating system, or virtual platform. The shackles of monopoly are certainly the most insidious of all. Part of the appeal of C and C++ is that they are non-proprietary. You can be sure that ISO C and C++ will stay that way, and that C++0x will include features, like portable threads, that will aid you in your fight for independence.
Chuck Allison
Senior Editor
cda@freshsources.com