Let me make a bold statement:
All functions taking a “const String&” parameter as input are bad.
…where String is either your own custom string class, or std::string, whatever. This is bad, of course, because it forces your users to have a String around. If they get the string from an external source (typically as “const char*”) you just forced them to create a temporary String just to call the function (or worse, the temporary will get created without them even noticing). Since you pass it as a const, you will not modify the text and there is no reason to force people using a String. The proper API just takes a “const char*” parameter.
(Yeah, yeah, I know, it ignores Unicode stuff and loses some minor optimizations when the String class caches the length of the text, whatever, you get the idea of the bold statement. And also, any const function in the String class is stupid, as an old classic GOTW entry showed eons ago).
January 7th, 2011 at 9:23 am
I prefer the even bolder statement that most game code should not be using any strings at all!
January 16th, 2011 at 7:39 am
I prefer the even more bold statement that most games shouldnt be written in arcaic languages such as C++ which still define constant strings in terms of pointers(among other things).
(no tempory allocations needed if _everything_ is an immutable System.String)