
Marc Mutz wrote:
On Sunday 02 July 2006 03:03, Jeff Garland wrote:
super_string s(" (456789) [123] 2006-10-01 abcdef "); s.to_upper(); cout << s << endl;
s.trim(); //lop of the whitespace on both sides cout << s << endl;
I really like this proposal, but have a minor point to add: IMHO, value classes should have much fewer mutating (non-const) (member) functions. The above two examples are a very good example. to_upper() should be const and return the string converted to uppercase, instead of performing the operation on 'this'. Similarly, trim() should be trim_med_() and return a trimmed copy of 'this'. This makes it much easier to work with such classes. Qt4's QString has gone a long way towards this style of interface, but still has a lot of annoying exceptions that make me mad most every day.
Well, I went about 50% of the way on this. You'll notice that for some things there are non-modifying variations. basic_super_string trim_copy() const; basic_super_string trim_left_copy() const; basic_super_string trim_right_copy() const; basic_super_string to_lower_copy() const; basic_super_string to_upper_copy() const; I just got tired and didn't add all the variations for replace_xxx. Of course that makes the interface even fatter :-)
The usual argument against is performance, and I agree performance is important for a general-purpose string class. But what is often overlooked is that the prefer-const-to-mutable-methods-style interface allows many more optimisations than the classical style, if the implementor is willing to go down the expression template path: s = s.replace('&',"&").replace('<',"<).replace('\'','''); can be made to execute a lot faster if replace is const than if it is not, b/c it forces the return value of replace() to be evaluated.
I'm no expert in expression templates, but I don't think '.' can be overloaded -- how can ET do anything here?
Maybe I'm talking common wisdom here, it's just something that I found annoying in my everyday work and wanted to share. Feel free to ignore :)
I'll add replace_*_copy versions in the next rev... Jeff