Re: [boost] Interest in super string class?

From: Gennaro Prota (gennaro_prota_at_[hidden])
Date: 2006-07-05 10:09:17

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 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
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.

>[...]
>
>>>>> 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.

>  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.

>  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.

>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.

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.

--
[ Gennaro Prota, C++ developer for hire ]
[    resume:  available on request      ]