25.3. Working with Other String Classes

So far we've seen how the concatenator can be used with your own string class by implementing your operator +() overloads in terms of the fast_string_concatenator<>. In this guise, there are no problems of any kind, and it all simply works.

However, you might also wish to use the concatenator with other string classes, in which case there are several issues of which you need to be aware.

25.3.1 Incorporation into Standard Libraries

In order to ensure that the concatenator would be compatible with standard library implementations (see section 25.6), I hacked it into the standard library headers of all the compilers tested. Although it's not possible to include them on the CD for copyright reasons, I can assure you that it was simple and easy to do, and there were no surprises.

25.3.2 Incorporation into Modifiable Extant Classes

The concatenation operators of extant string classes can be "upgraded" simply and safely by replacing the existing operators with equivalent versions incorporating the concatenator. If your organization has its own string classes, then you will be able to upgrade them and the only effect to any client code, once it's recompiled, will be that it will run faster: that's not something you often get to say in software engineering!

To test this out, I've done it to several existing string classes from different libraries, including MFC's CString and STLSoft's basic_simple_string.

25.3.3 Interoperation with Nonmodifiable Classes

This is where things get a little tricky. If you're using a third-party library, such as MFC's CString, you should not alter the headers that accompany the library. Any future update of the library will overwrite your changes. Even worse, some libraries, such as MFC, come in part in binary format, so any changes to the headers will not be reflected in the binary part of the library. At best you're going to get a crash in testing. Don't do it!

But we like the concatenation optimization, and we want to use it with third-party libraries. So what do we do?

If the string class you're interested in does not provide its own operators, then your task is comparatively easy. You can either define the new operators within the global namespace, which is appropriate on an application level, or within your own namespace if you'll be using these operators with your own libraries. Of course, if the string class comes in a third-party namespace, then you could define the operators in that namespace. To do that, however, you must have missed the "Namespaces Dos and Don'ts: 101" as it's a very foolish thing to add things into namespaces that you're not responsible for; conflicting things can be placed in that namespace at any time by the authors of the libraries.

If the string class comes with its own operators, you're in stickier waters. If it's a template class, then you can define your own operators for specific instantiations of the string template. In other words, if the string is tp_string, you can define your own operators for tp_string<char>, or tp_string<wchar_t>, or whatever, since a compiler can unambiguously select a nontemplate function over a template one. If it's not a template class, you're stuck. Even if you write your own concatenator-returning overloads in a "nearer" namespace, Koenig lookup (see sections 6.2 and 20.7) will ensure that the compiler can see multiple equivalent operators, and it will rightly fail to compile. For this we need concatenation seeding.