
Gennaro Prota wrote:
On Wed, 05 Jul 2006 06:23:44 -0700, Jeff Garland <jeff@crystalclearsoftware.com> wrote:
David Abrahams wrote:
Jeff Garland <jeff@crystalclearsoftware.com> 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