- Individual Compilers
- Individual Platforms
- Platform Idiosyncrasies
- Wrapping Up
Individual Platforms
After you deal with the idiosyncrasies introduced by individual compilers, you have to look at the issues introduced from platform to platform. There are libraries of functions out there that specifically contain instructions for 32-bit Windows implementations, others for Macs, and still more for UNIX variants. These functions extend the ANSI standards to provide access to operating systemspecific information and hardware, and are ultimately impossible to avoid.
For example, to create a dialog box on a Mac in C and C++, you need a different function library than you would need to create the same dialog box under Windows or Linux. To make your code as portable as possibleso you don't have to make changes based on the platform on which you're compilingyou create a single function, perhaps called MyCreateDialogBox(). Then you have this function choose the appropriate platform-specific code to use underneath. This technique is referred to as abstraction.
This term brings to mind the topic of abstraction layerscode structures that isolate your higher-level design from the nitty-gritty details of lower-level implementation. For excellent examples of existing abstraction layers, you need look no further than Microsoft's DirectX and the X Window System under UNIX. These two constructs provide a high-level interface for programmers to use, while freeing them from the need to know precisely what hardware the user has under the hood.
For example, every graphics card has its own specific instruction for drawing a line on the screen. What a nightmare, having to build separate functions for each of these cards! Instead, both DirectX and the X Window System offer their own abstraction functions for the purpose. You just call the function DrawLine(), in the case of DirectX, and let DirectX or the X Window System worry about turning that instruction into hardware-specific code.
It doesn't take much thinking to see how much time and frustration abstraction saves, as programmers are freed to focus on application logic rather than building repetitive sets of instructions based on individual hardware components. To return to the generic MyCreateDialogBox() function mentioned earlier, this function's logic might look like the following:
MyCreateDialogBox(...) { if (this is a Windows machine) { call the Windows library CreateDialog() function; } else if (this is a Mac) { call the Mac library's dialog creation function; } else if (this is a UNIX box) { call the X Window System's dialog creation function; } }
With this function in place, you're now free to worry about the program's next logic component.