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
> 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
> 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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk