The C++ Promise

C++ has been around for a long time... C has been around even longer. Indeed, in a time when changes in Java and .NET can make you feel like you need to "rewrite it or die", many C and C++ users like to boast that they have been using their programs for decades without change. I sure do.

Unfortunately, while we might be quick to boast about how static the C / C++ language can be, in 30 years some changes must take place. After all, when C was created decades ago, most of corporate America was still programming on punch cards! (You can't even find that stuff on eBay!)

Unfortunately, whenever you look for code over the Internet, you see a lot of source that pre-dates the C++ standardization efforts. Just go to your favorite search engine and look for popular legacy #include directives (like stdio.h, strstrea.h, or iostream.h) to see how prevalent the legacy is. Too many!

Fortunately, the vast majority of the changes to the language have taken place so as to preserve the lion's share of your source code investment. I find that most of the time all I have to do is to change a simple #include directive to port 99.99% my source code to a new compiler or operating system... But I tweak and re-compile my code a lot - if you have never heard of X3J11, then your mileage might vary.

When converting from bad habits and / or earlier versions of C/ C++, there are basically two types of header changes to be aware of. The first is the header conversions recommended when converting from C to modern C++. The second set involves detecting vendor-specific and / or pre-standardization conventions. Most of these were in force well before the modern C++ (ISO/IEC 14882:2003) standard.

When upgrading C programs to C++, the modern standard requires you to change headers like <ctype.h> to <cctype>. The following table lists the ones to be aware of.

The next set of conventions requires you to modernize legacy stream, STL, and other obsolete header files. If you find yourself relying upon a growing set of relatively esoteric pre-processor definitions (like Borland's _USE_OLD_RW_STL), then it is time for a change!

Depending upon the age of your compiler, the list or obsolete header files can grow. For Windows, Unix, Mac OS/X, and Linux users however, they need to be aware of the following header changes.

Finally, lest we forget, when detecting the second type of changes that you also usually need to add a "using namespace std" statement. Failure to have this clause appear at the proper place in your code will cause your upgraded C++ programs to stop compiling. For this reason, when porting code, the first rule of sanity is to start small, and to always keep a pre-conversion source code backup handy!

In general, note that no standard legacy (system bracketed) header files should use the ".h" suffix these days. Moreover, many conversion developers also need to be aware that older 8.3 DOS naming conventions (like using <strstrea.h> rather than <strstream>) are also in pester. A lot to keep in mind!

So when it came time to (grudgingly) port my millions of lines of C and C++ code to modern C++ usage, the task was discouraging enough for me to create a tool (affectionately known as a "neat odd job") to do it for me. This tool worked so well that I wrote this article and made it a part of my open source stdnoj project. (A project that, come to think of it, itself started out as a code modernization effort - the goal was to put the more useful classes that I share between projects under a common namespace.)

This NOJ was called HeaderConvert. (The source code is part of the sharenoj projects.) It was designed to help you begin the process of converting both your old and new C++ files. Feel free to download and use it in the spirit of the GPL.

(Note that if you do not have Microsoft Visual C++ 6, then unless you can read a COFF binary to link to the stdnoj_sl.lib therein, that you will also need to download my "stdnoj" project at sourceforge.net. After unzipping the stdnoj.zip project, just set your path to include the stdnoj folder, #define UNIX, WIN32, or DOS, and add every .cpp file in the stdnoj/NOJ folder to your project.)

After automatically converting about 15% of my .h, .cpp, and .hpp files, I discovered that only a surprisingly a few areas needed to be changed manually. In general, most of the manual changes were related to improved stream usage and dropping some sporadically used Microsoftisims (like using odd things like ios::nocreate, or headers called <strstrea.h>.)

Indeed, because of the way I manage the reuse, after the automatic conversion I was able to get the majority of my 6 commercial products updated in less than a day or three. Better still, since both my POSIX and WIN32 projects once again share the same set of headers, platform independence is more easily guaranteed... at least in my "unmanaged" code ... (but tackling that wonderful .NET goddess using C++ is another story)!

About the Author

R. A. Nagy is an independent trainer, author, lecturer, and consultant. He has served as a Principal at both Borland Software and Informix Corporation. With over six (6) commercial and shareware applications to his credit, his training and other wares are actively hawked at Soft9000.com.

In his spare time (he says it has been known to happen), he enjoys running from hurricanes and a relatively carb-free life when canoeing and kayaking in the great Florida outdoors.