
Thorsten Ottosen wrote:
Jeff Garland wrote:
It doesn't stop being easier to use -- it's the same every day. Your implicit implication is that later on I'm going to find a bunch of extra functions that I can't perform with super_string. True enough. At that point I either add it to super_string or write it using the functional interface. No big deal.
My implicit implication was that soon you'll feel comfortable with the free-standing functions.
Not likely, I've used free functions for years, but I'm going to the dark side now ;-) Anyway, I've already responded to this point in detail elsewhere. I agree, btw, that it can be done cleanly without a string type, but then you're going to need language support to do it well.
In php, there is not a single member functions in a string, and all string processing is done with free-standing functions. In general I find strings in php easy to work with:
http://www.php.net/manual/en/ref.strings.php http://dk2.php.net/manual/en/ref.regex.php
I've written code in PHP as well. It has the advantage over C++ in that it doesn't have templates to distract in the documentation. But overall, I think PHP string handling is a mess...sorry.
Not a good idea IMO.
We disagree, obviously, and that's fine. Just to save some time, I'm pretty sure it's impossible to convince me that range or something else is going to solve my set of issues.
Probably not. I did not have that I mind. I think some extensions to range will make stuff like regexes easier, but it would give you "one ^^^^^^ place for all string processing".
Sorry -- do you mean 'wouldn't give'?
I'll just point out, that some of this was a result of recent brushes of mine with other languages. I've been doing some coding lately in, gasp, Java and Javascript. As a diehard C++ developer, it ticks me off that I can sit down with the manual for these languages and in 15 minutes whip up some fancy string parsing code using regular expressions, etc. It's all very nice and neat. Go to the string reference page -- see the list of functions and boom, you're in business. So it gets me thinking, why is it that C++ makes this so hard? Well, std::string isn't as capable as Java's string. Of course, C++ (with Boost) has all of the same capabilities, but it takes a truckload of documentation and a masters degree to figure it all out. And then it's a pain in the neck to use and read the code. This is my attempt to rectify that.
If the problem is bad documentation/tutorials, then I think we should fix that instead.
Nope, that's not really the problem.
For Java, many many people have been paid to write the documentation,
That's sad, a lot of it is pretty lousy as far as I'm concerned.
whereas for boost, we have to do it our spare-time. It's pretty good most of the time anyway.
I don't really have a problem with the documentation. I think each of the various docs are good by themselves. But as I mentioned before the functions are spread across a number of libraries. And, of course, the reference documentation has to be written in a totally generic fashion. Just take regex_replace as a case in point: template <class OutputIterator, class BidirectionalIterator, class traits, class charT> OutputIterator regex_replace(OutputIterator out, BidirectionalIterator first, BidirectionalIterator last, const basic_regex<charT, traits>& e, const basic_string<charT>& fmt, match_flag_type flags = match_default); template <class traits, class charT> basic_string<charT> regex_replace(const basic_string<charT>& s, const basic_regex<charT, traits>& e, const basic_string<charT>& fmt, match_flag_type flags = match_default); My first reaction when I read this is, wow, interesting, but how do I use it? It's hard for even an experienced guy like me to see the forest from the template tree's here. So I scroll down to the example and start reading the example code. Ok, now I see it and I can go back, consume it, ponder more...then realize, ok I guess it's the second signature because I'm using an std::string...now I can go write some code. (Of course, I normally don't do it like this because I go and look up some regex code I've already written). Now lets compare JavaString.replaceAll (short description) String replaceAll(String regex, String replacement) Replaces each substring of this string that matches the given regular expression with the given replacement. Wow, ok I don't need to see the example code, I can write code now. I might need to read more about the regex string rules, but no biggie they follow expected conventions. After 2 minutes I'm testing code. Of course, JavaString.replaceAll is just lame compared to what regex can do. But, you know, it covers most of what I use for typical day to day string processing. It's clean, easy, fast -- I can focus on other parts of my app rather than the template parameters for the string function. Now lets examine the hastily created *pre-alpha* super_string docs: template<class char_type> void basic_super_string< char_type >::replace_all_regex( const base_string_type & match_regex, const base_string_type & replace_format) Replace the all instance of the match_string with the replace_format. super_string s("(abc)3333()(456789) [123] (1) (cde)"); //replace parens around digits with #--the digits--# s.replace_all_regex("\\(([0-9]+)\\)", "#--$1--#"); //s == "(abc)3333()#--456789--# [123] #--1--# (cde)" Right from the start there's only one signature and only one template parameter to document -- char_type is pretty easy to understand, doesn't even really require explanation -- but really the docs would be nicer without that distraction. The context is string processing, so I don't have to worry about explaining the regex function can work on vector<char> or whatever sequence I want. I've ditched a couple parameters of function parameters -- always going for the regex defaults. So super_string is more like JavaString -- very limited compared to full up regex or string_algo, but it's easier to document and use for common cases. Jeff