Re: [boost] Interest in super string class?

From: Jeff Garland (jeff_at_[hidden])
Date: 2006-07-05 10:50:41

Gennaro Prota wrote:
> On Wed, 05 Jul 2006 06:23:44 -0700, Jeff Garland
> <jeff_at_[hidden]> wrote:
> 
>> David Abrahams wrote:
>>> Jeff Garland <jeff_at_[hidden]> writes:
>>>
>>>> David Abrahams wrote:
>>>>> [...]
>> True, but for my work I need regex and I've cited other languages where it is 
>> integrated.
> 
> Ok. But is it something for *your* work or a generally usable library?
> ;)

I wrote super_string for my own purposes.  My experience writing 
tools/utilities and other things that process strings (largely in perl) is 
that regex processing is essential for all but the most trivial cases.  I 
posted it because I thought others might find it useful.

>> [...]
>> 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));
> 
> Yes. But call me a stupid, that's not necessarily a disadvantage.
> Programmers should never go without reading docs. If anyone makes a

I won't call you names, but I couldn't disagree more.  I might just be reading 
the code not changing it.  I'm just trying to understand what it does.  Having 
to read the docs is a distraction.

> mistake with (2) because he *supposed* the modified string was
> something he randomly chose, then change the syntax if you like but be
> sure to change the programmer, as well.

It isn't necessarily a mistake.  When I read #2 I just wonder what in() and 
out() mean...it distracts me from the purpose of the code.

>> [...]
>>
>>>>>> There's no user 
>> cost if they don't use Regex other then processing of a few extra includes on 
>> compile.
> 
> That's in a perfect world. On this planet, your library could not
> compile because a compiler bug prevents it to compile the regex
> headers, even if you don't use them.

Regex is in TR1 - it's highly portable.  I have to say, I could really care 
less about people with really bad compilers at this point.

>>  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.
>>
>>>>>> [...]
>>> Seems like you're deflecting rather than engaging, which is
>>> disappointing.
> 
> Indeed.

I'm sorry that you think I'm deflecting -- I'm not.  I believe I've patiently 
explained my reasons.  I don't expect everyone to agree with the trade-offs 
I've made.  Personally I think this sort of deflecting comment that detracts 
from the real discussion -- let's move on.

>>  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.
> 
> Exactly. Discussions here are never to "reject" or "approve" per se;
> they just try to improve and *understand* things before they get
> approved or rejected.

This is just bogus....I never stopped discussing the technical merits of 
anything.  I had low expectations for the proposal because it goes against the 
c++ is 'expert only' and the  'obscure code is better dogma' you've espoused 
and seems to be so commonly held.  But this is going off course again...

>> 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.
> 
> I know how you may feel, believe me. Some time ago I proposed things
> like 0p as null pointer literal, or a new null keyword (the former
> being a palliative for the latter); I suggest typed enums and many
> other things, to always hear one of the same two answers: no new
> keywords, please; no compelling case for making a language change. You
> know what happened to all of these.

Sorry to hear that.  I will say, however, language changes are very hard to 
justify and are very expensive. They impact everyone.  Libraries are easier 
because they are optional -- you don't have to use them.  You're free to 
ignore super_string if you don't like it.

> I personally think your proposal is naturally going to have some (or
> much) opposition but is anyway an idea worth exploring. Just let us
> "digest" it, so to speak, and try your code on the field. Some months
> from now our ideas might be different.

Feel free to digest all you like -- I'm not going anywhere.

Jeff