From: Jeff Garland (jeff_at_[hidden])
Date: 2006-07-02 14:51:32
David Abrahams wrote:
> Jeff Garland <jeff_at_[hidden]> writes:
>
>> I've been working on a little project where I've had to doing lots of string
>> processing, so I decided to put together a string type that wraps up
>> boost.regex and boost.string_algo into a string type. I also remember a
>> discussion in the LWG about whether the various string algorithms should be
>> built in or not -- well consider this a test -- personally I find it easier
>> built into the string than as standalone functions.
>
> I appreciate the convenience of such an interface, I really do, but
> doesn't this design just compound the "fat interface" problems that
> std::string already has?
Yes, that's partially the point :-) I understand std::string is too big for
some. Sadly the members it has make it hard to do the things I tend to do with
strings most often with strings. The fact is, if you look around at the
languages people are using most for string processing, they offer just as many
features as super_string and then some. Somehow, programmers are managing to
deal with this. I'd buy more into the fat interface being a problem if
something in the string class went beyond string processing, but it doesn't.
String processing is a big complex domain -- whole languages have been
optimized for it -- it needs a lot of functions to cover the domain and make
easy to read code. Any way you slice it the current basic_string is inferior
to what most modern languages offer.
Needless to say, I understand all about stl, free functions, their power, etc,
etc. But the big thing this misses is that having a single type that unifies
the string processing interface means there's a single set of documentation to
start figuring out how to do a string manipulation. I don't have to wade thru
50 pages of string_algorithms, 50 pages of regex docs and so on -- there's
hundreds of functions to deal with strings there. Not to mention the
templatization factor in the docs of these libraries which mostly detracts
from me figuring out how to process the string. If I'm a Boost novice much of
this great a useful string processing capability might be lost in so many
other libraries.
The other thing that gets me is the readability of code. With a built-in
function, it's one less parameter to remember when calling these functions.
It seems trivial, but I believe the code is ultimately easier to understand.
Simple example:
std::string s1("foo");
std::string s2("bar);
std::string s3("foo");
//The next line makes me go read the docs again, every time
replace_all(s1,s2,s3); //which string is modified exactly?
or
s1.replace_all(s2, s3); //obvious which string is modified here
I understand this flies against the current established C++ wisdom, but that's
part of the reason I've done it. After thinking about it, I think the
'wisdom' is wrong. Usability and readability has been lost -- my code is
harder to understand. I expect that super_string has little chance of ever
making it to Boost because it is goes too radically against some of these
deeply held beliefs. That said, I think there's a group of folks out there
that agree with me and are afraid to speak up. Now they can at least download
it from the vault -- but maybe they'll speak up -- we'll see. In any case,
it's up to individuals to decide download and use super_string, or continue
using their inferior string class ;-)
> Even Python's string, which has a *lot* built in, doesn't try to
> handle the regex stuff directly.
There are plenty of counter examples: Perl, Java, Javascript, and Ruby that
build regex directly into the library/language. It's very powerful and useful
in my experience. And, of course, super_string doesn't take away anything,
just makes these powerful tools more accessible and easier to use.
Jeff