Right now I've decided to focus on redesigning my personal code library. My library has grown over the last few years in a piecemeal fashion as I find a useful bit in a project I'm doing and decide to dump it somewhere so that I don't have to redo it later. About a year ago, I started putting it into a single namespace and started naming all the headers .cow instead of .h. The basic reason for that is that when using Visual Studio .NET IDE, the tabs for the text editing area are labled with the file name being edited. A lot of my code library are glue classes to work with existing headers. So my classes for cctype function wrappers would go in cctype.cow, and then I could easily tell the difference between cctype.cow and cctype just from the tab. Using cctype.h wouldn't be happy because then at first glance I might think I had ctype.h open.

Quote:
I think I'll abuse the quote tag as a "Tip" box. For Visual Studio 7.1, if you want to apply syntax highlighting and all that goods stuff to files with a different extension you can add a registry entry like this to your system:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\7.1\Languages\File Extensions\.cow]
@="{B2F072B0-ABC1-11D0-9D62-00C04FD9DFD9}"

The UUID specifies C++. C# and VB.NET can be enabled using different UUIDs. Poke around in the registry if you want to find out exactly what to use.

In any case, at this point I've decided to rework much of my personal library. This is for a couple of reasons.

1. Compile times. A lot of template code and classes with their guts hanging out (so to speak). A prime example is my binary stream header, which is a wonder of orthogonality able to accept all sorts of different template parameters to customize behaviour and all that jazz. Of course, I never use it for anything other than char streams with the default char_traits class. So time to cut out the cruft. I'll probably leave the original implementation intact, but I'll put up a few design firewalls to handle the more common cases.
   
2. Runtime performance. I'm assert() happy. I admit it. Pre conditions, post conditions, class invariants, random logic checks, I'll assert() on all of it. And then some. This all goes away in a release build, but enough asserts will still make a debug build run unacceptably slowly. Therefore in the rework, I'll start add priority levels to my asserts.
   
3. Testability. Almost all of my code library has had test cases written, run, passed, and the promptly lost. Not a big deal for a class wrapper around std::toupper(), but a different story for things like container classes or algorithms. This time around I'll be embedding a testing framework with the library itself.
   

I guess that pretty much covers the basics. Tommorrow I'll explain some of the scaffolding I'll be using for achieve these goals.