To sum up - the aim of the preceding exercise was to check my past assumptions. Rather than use the standard C++ string classes, I have for a number of years chosen to use a very thin wrapper class, with buffer allocation off a free-list. At the end the measurements show performance is indeed better than the standard C++ string classes, with one minor surprise.

The minor surprise was that the x86 string instructions are no longer optimal (at least on an AMD Athlon CPU). There are two alternates - either write inlined C++ code to perform the equivalent operation (better with small strings), or use the C library string functions (better with large strings). To force the use of string functions rather than string intrinsics in optimized code, you need to present the following pragma to the Microsoft C++ compiler.

#pragma function(strcpy,strcat)

Other than the use of the pragma, it looks as though the existing string classes in my applications do not need to be changed.

Building a better string class - prior exercises

Notions that go into choosing a string class in this form include…

  • The string class is meant to be a thin, efficient wrapper around conventional NUL-terminated C strings.
  • The string class is safer than C strings as the common operations that can lead to overflow (strcpy() and strcat()) upsize the string buffer as needed.
  • This is not an attempt hide or completely encapsulate C strings.
  • This is not a re-invention of C strings.
  • Constant strings are passed as “const char*” - to which the string class readily converts.
  • The string class is not meant to be so general as to suit every application in existance, and is not meant for inclusion in a library. Rather you would simply take the base version and add any functions needed.
  • The string class is optimal for strings of “usual” size (less than 256 characters).

The end result is small, efficient, and easy to adapt as needed. Suits my purpose at least :).