You are hereHome / Development / Building A Better C++ String Class?
Building A Better C++ String Class?
Preston L. Bannister tries to build a better C++ string class than provided by the C++ standard libraries (found through Christopher Baus). However, I think he will fail, since he's too much involved in low level things, rather then design.
Preston states that
I seldom use the C++ string classes supplied with the standard libraries, out of a belief that (for my purposes) that I can easily do better, building on bits of history and experience. Considerations that go into building a simple and highly efficient C++ string class include the following.
- The standard <string .h> supplied C string functions are highly optimized (as described in a previous post).
- Heap operations are best avoided (where practical) in long running applications. Use of a free list is very effective when the application has a cyclic workload (as most do).
- Use of C++ inline class methods allows both readable code and most effective use of the optimizer.
I actually wonder why he's so negative about the standard C++ string class, and what makes him belief the standard implementation isn't highly efficient. Let's take a look at the Visual C++ implementation, for example. Doesn't it fullfill, what Preston considers?
- It uses calls to the supplied C string functions, which turn out to perform very well on Windows machines, as he himself figured out.
- It avoids unnecessary heap allocation by implementing copy-on-write, allocating in blocks and similiar tricks.
- Since it is a template class, all functions are inlined.
Remarkably, the string class gains perfomance by changing the point of view from low level operations like memory copying to the actual usage. Take for example the copy-on-write strategy (Scott Meyers wrote about it in "More Effective C++", Rule 29). This is a true performance boost, since you avoid memory beeing copied on each assignment or copy construction operation. And have in mind that each function returning a string class implicitly invokes the copy constructor. In other words: This is a very common use case for a string class.
Figuring out the best way to copy an array of chars is simple. But designing a string class is much more than this: It is about avoiding copying whereever possible, too. And I doubt if the string class Preston is to come up with, will be look too much different from the current standard implementation in the end.
I agree. Definitely NIH Syndrome. I pointed this out because this is example of how low level optimizations can back fire, not because I think it is a good idea to reimplement the string class. Although most people seem to agree that the standard string class is missing a lot of functionality.
Indeed the string class is missing quite a lot. Always wondered why, actually. Everyone I know - including me - is customizing it by adding convenient functions like replace(const string& what, const string& with), trim(), toLower() etc.
In fact, Herb sutter thinks (in http://www.gotw.ca/gotw/084.htm) it has far too many members...
I think writing your own string class must be a project everyone has done. In fact I've written my own called "The Better String Library" which is relevant to your points above:
1. "The Better String Library" *outperforms* standard C string library functions, std::string and MFC's CString class on a variety of the most common string manipulation tasks (often by massive margins). This has been confirmed by benchmarking on multiple CPUs, operating systems and compilers.
2. Avoiding unnecessary heap allocations is a misdirected effort. ("copy-on-write" is hard to make thread safe, and certainly cannot be done without impacting performance). It only helps in the most marginal cases while adding to the overhead of mainline code.
3. Inlining is usually only necessary and/or beneficial (performance-wise) for trivial accessor functions, while adding to the footprint of your code (since code paths are redundantly generated.) The best answer is just to use the standard "inline" declaration on methods where it is appropriate.
For the evidence I invite you to look at all the data here:
http://bstring.sf.net/features.html
You can even download the benchmarks for yourself from the examples.
But of course, this all ignores the far more important question about string manipulation in todays security and cost conscious programming environment:
A. How safe is the string manipulation with respect to buffer overflows?
B. How easy is the library to use and understand?
C. How portable is the library?
D. Is the library well documented?
E. Is the library well tested?
F. Is the library being actively maintained?
You can check the Better String library against any of these criteria, and you will find it hard to beat with *any* alternative.