This month, as promised, I'm continuing to flesh out the C++ matrix class. But first, I want to talk about the value of reusable code and how it's supported by the Microsoft compiler called Visual C++ Express. Regular readers may remember how highly I praised this compiler, because of its ease of use and all its neat features.

Since then, I've had a few problems. This is by no means to suggest that I'm reverting back to my former, anti-Microsoft stance. Although I've been doing C++ for a long time, I'm a total newbie to this compiler and perfectly willing to accept that my problems are results of pilot error. However, having loaded up with books on the order of Microsoft Visual C++ for Dummies and having contacted folks in the developers' community and Internet forums, without much success, I'm still having the problems. In the future, I hope to establish a dialog with folks at Microsoft who can set me straight. In the meantime, I'd like to share my experiences with you. See what you think.

One of the big selling points of object-oriented design and development has always been that it encourages software reuse. If we design our C++ classes carefully, we should be able to generate software packages that can be used again and again, in new projects, without modifications. I stress that last phrase, because you're not really reusing software if you have to modify it for the next application. My incentive to develop classes for vector and matrix operations comes directly from this notion of reuse.

I can't resist reporting that I had my own version of software reuse, going on in the 1960s and 1970s. The "libraries" for my software were two sections of my desk drawer; one containing the source code (on IBM punched cards) for reusable functions, the other, object decks. Reusing those functions was as easy as lifting the object decks out of the drawer. The incentive to not recode was strong.

I should also note in passing that none of the software methodologies, from top-down design to the latest UML-based methods, are very effective in defining candidates for reuse. The reason is simple: you don't get those candidates from any single project-development effort. What you get from such an effort is the specifications for software needed for that particular project. As a ridiculous example, you might find several places in a given project that a vector addition is needed, but none with vector subtraction. A strict application of formal methods would never lead to a vector subtraction function.

By definition, reusable software is software that's used on multiple projects. You identify candidates for reuse by asking "will I ever need to use this function again?" In the end, the answer comes much more from the experience and foresight of the human designer than from any formal method.