Lessons of the xstring class Implementation

I believe the existing standard library string class exhibits undesirable and improper behavior when passed a constant value 0 as an initializer. Perhaps the standard library will be corrected to prevent this problem eventually, and in many languages, we would have no choice but to wait for the library correction. However, we are fortunate that in the case of C++, we can fix this problem in the process of defining an extended xstring class, without losing any of the benefits of the existing std::string class. So this is a fine example of using object-oriented design to make use of a lot of existing code (in the standard library) while adding appropriate and necessary features for our own purposes.

One More Design Decision Regarding the xstring class

I should mention one more design decision that I have had to make in the process of creating this new class: whether to change the behavior of >> when reading data into an xstring, so that it would read an entire line rather than only up to the first blank. That was very tempting, as it would have simplified the example programs quite a bit, making them easier to write and understand. So why have I not done this?

Because it would change the interface of the new class from the standard library string class interface, thus making it impossible to switch from one to the other of these classes as necessary without changing the input operations in your programs. Even though I believe that the decision of the standard library designers was incorrect in this case, the drawbacks of changing the interface are significant enough that I have reluctantly decided to stay with the original behavior of the input operator. This means that you won't have another learning curve when you have to use the standard library string class in future programs you write.

Susan had a couple of questions about defining this new class:

Susan: Why did you call this new class xstring? Why not just call it string?

Steve: Because that would be very confusing to people accustomed to using the standard string class. It's a really bad idea to define classes whose names clash with names of classes in the standard library. One exception is when we're just showing how we might implement a standard library class, as in the case of the string class earlier in the book.