Boost logo

Boost :

From: Jeff Garland (jeff_at_[hidden])
Date: 2006-07-05 09:23:44

David Abrahams wrote:
> Jeff Garland <jeff_at_[hidden]> writes:
>> David Abrahams wrote:
>>> Jeff Garland <jeff_at_[hidden]> writes:
>>>> 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.
>>> Try "python -c help(str)"
>> Looks like I'm still missing a couple functions ;-)
> And by the same measure, you have some extras (no regexps in python
> strings).

True, but for my work I need regex and I've cited other languages where it is

>>>> There are plenty of counter examples: Perl,
>>> Not sure that's a good example if you're going for readability; Plus,
>>> it has special operators that help (and could in principle be
>>> implemented as free functions).
>> I thought the c++ was pretty readable. As for free functions, I'm
>> not opposed, but so far I haven't seen a proposal that makes the
>> code clearer to my eye.
> Well, Shunsuke Sogame's proposed interface (which echoes some work
> Eric Niebler has already done) works pretty well. I don't think that
> concatenating string operations with '.' is vastly better than using
> '|', and the former comes with some attendant disadvantages that have
> been detailed elsewhere in this thread.

I guess I have yet to be convinced of the supposed disadvantages.
super_string is just as extensible as basic_string. I can still take
advantage of Sunsuke's code. But, I think there was actually some agreement
that if we surveyed programmers more would understand form #1 without reading
the docs then #2.

   1) s.replace_all(s2, s3)
   2) replace_all(out(s1), in(s2), in(s3));

Don't get me wrong, I think the new range interface is a major usability
advance -- well at least for unix programmers. He actually threw me off a bit
with this example:

  std::string dst(...)
  range_copy(rng|to_upper|to_lower|to_upper, dst);

which didn't make sense (apparently it was a joke). Still, I'm pretty sure in
a code reading contest more programmers would understand this:


as obviously ridiculous code.

>>>> Java, Javascript, and Ruby that build regex directly into the
>>>> library/language.
>>> Whoa there. Python builds regex directly into the library too. That
>>> doesn't mean it should be part of the string.
>>> python -c "import sre;help(sre)"
>> I wasn't trying to suggest that Python didn't support regex.
> Didn't think you were; you seem to be missing my point, which is that
> there are lots of ways to get the functionality into the library. It
> doesn't necessarily have to be directly attached to the string class.

No, I got it, but I don't know what to do with it. Python chose to leave it
out of the string class -- Java chose to provide a simplified interface(just
to be clear, there's a Pattern class in JAVA that works with string). In Perl
it's helped along by language features, but it's essentially built-in using
operators. So it's a mixed bag as far as how people have chosen to build
these functions. Overall though, I didn't see the motivation for leaving Regex
out if I'm going to add other functions to the string type. There's no user
cost if they don't use Regex other then processing of a few extra includes on
compile. So my take is that it's confusing to introduce a new string type and
then make half the functions free functions. And some of the regex functions
are 3 parameter case discussed above.

>>>> 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.
>>> I agree with the idea in principle; I just want to scrutinize its
>>> execution a bit before we all buy into it as proposed ;-)
>> How does that phrase'll be a cold summer day in Az (a balmy
>> 105 now) before we 'all' agree ;-)
> Seems like you're deflecting rather than engaging, which is
> disappointing. There are lots of important questions here; I'm glad
> you proposed this interface and thereby raised them. I just wish we
> could have a more complete exploration of the solution space, which --
> especially where C++ is concerned -- is still largely uncharted.

I think I've been plenty engaged. And we can explore the solutions all we
want. It's just a fact that there's some group of people that will never
agree with me.


Boost list run by bdawes at, gregod at, cpdaniel at, john at