dcsimg

Eric Schnoebelen Archive

Living the Dynamic Life of Plg-Ins
Many C and C++ applications use a plug-in or modular architecture to add features dynamically. Unlike monolithic applications, where all features are compiled into a single executable, modular applications typically have a central engine and a set of complementary feature libraries. Each library -- usually called a plug-in or a module -- implements a unique feature. When that specific feature is needed, the engine simply loads the module on demand, and calls the module to do the work.
Finding and Defining Features
In September, we discussed the significant advantages of re-implementing desired, but less common functions: if you use a feature of your local operating system, but discover it doesn't exist on other platforms, write your own implementation, and make that code a part of your distribution.
Building Portable Build Systems
Last month, we talked about writing portable code and focused on how to use feature test macros, coding standards, and emulation of uncommon functions to make porting even easier. This month, we'll talk about portable build systems -- tools you can use to easily build that portable code on a variety of target platforms.
Writing Portable Code
Everyone professes to write portable code, but few programmers actually manage to do it. In most cases, so-called portable code comes out littered with #ifs or #ifdefs (or worse, nested #ifs and #ifdefs), rendering the code illegible and obfuscated. Sadly, the lion's share of many porting efforts is spent trying to figure out which lines of code are actually being compiled and executed. This wastes time and energy, and can be downright frustrating.