Re: [boost] Boost super_string
Fyi all, here is just a few queries that I ran thru Google regarding std::string and some of the things that developers are looking for frequently. http://groups.google.co.nz/groups/search?hl=en&q=c%2B%2B+std+string+mfc http://groups.google.co.nz/groups/search?hl=en&q=c%2B%2B+std+string+qt http://groups.google.co.nz/groups/search?hl=en&q=c%2B%2B+std+string+uppercase http://groups.google.co.nz/groups/search?hl=en&q=c%2B%2B+std+string+lowercase http://groups.google.co.nz/groups/search?hl=en&q=c%2B%2B+std+string+trim http://groups.google.co.nz/groups/search?hl=en&q=c%2B%2B+std+string+format http://groups.google.co.nz/groups/search?hl=en&q=c%2B%2B+std+string+replace http://groups.google.co.nz/groups/search?hl=en&q=c%2B%2B+std+string+remove http://groups.google.co.nz/groups/search?hl=en&q=c%2B%2B+std+string+regex We all know that Boost is made up of high quality and technically challenging libraries but how would it hurt having something like super_string as part of it? Something like this might? not ever make it into Standard C++ (because of all the politics involved?) but why should it be stopped from being part of Boost? Is this why Java, C#, MFC, ATL etc. just so much used by a lot of programmers, string classes with required functionality offered right out of the box? I am sure Jeff would be happy to improve the interface based on feedback (which we can see he has already done so quite well in the past with his other work and also this one) and his response his also great. Why should something like trimming, uppercasing, lowercasing should be so hard in C++. I think its good enough to have this kind of basic high level wrapper around string_algo, regex, format etc. Plus it integrates well with existing code and std::basic_string. Jeff has seemed to explain these rationals quite well in his documentation for this library. See: http://www.crystalclearsoftware.com/libraries/super_string/index.html Overall I think this library will be a good addition to Boost because it has some of the most wanted features of strings. I am sure that having it as part of Boost would be of interest to a lot of developers because they will know it is likely to be portable, definately well tested and available from a single source. The thing is that if you don't want to use it then dont, but atleast these string functionalities should be available with ease for all including novices and experianced programmers. Something like super_string in Boost could be received quite well by the boosters community and could increase popularity of Boost even between novice and experianced developers. We should be attracting people to C++ NOT distracting. Thanks Shams
shams <shams <at> orcon.net.nz> writes:
The thing is that if you don't want to use it then dont, but atleast these string functionalities should be available with ease for all including novices and experianced programmers. Something like super_string in Boost could be received quite well by the boosters community and could increase popularity of Boost even between novice and experianced developers.
What if a module need to use some super_string functions. If it then takes a super_string as argument, all modules using this library need to include headers for regex and string_algo and all their dependencies. The alternative is to take the argument as basic_string and then copy it into a superstring to do the processing.
Why should something like trimming, uppercasing, lowercasing should be so hard in C++.
Why is boost::super_string ss(s) ss.trim() easier than boost::trim(s) Many other langages (specially entry-level like VB) only have free functions for string processing. I agree that the string_algo library is a bit difficult to get into but solving that with a new library isn't the right way. Why not a string_algo wiki where users can add their own real-world examples of how you do things with it.
Martin Adrian wrote:
shams <shams <at> orcon.net.nz> writes:
The thing is that if you don't want to use it then dont, but atleast these string functionalities should be available with ease for all including novices and experianced programmers. Something like super_string in Boost could be received quite well by the boosters community and could increase popularity of Boost even between novice and experianced developers.
What if a module need to use some super_string functions. If it then takes a super_string as argument, all modules using this library need to include headers for regex and string_algo and all their dependencies.
Yep. But it's all template so if you don't use regex you don't have to link it.
The alternative is to take the argument as basic_string and then copy it into a superstring to do the processing.
Yes, it will run the basic_string copy constructor in this case.
Why should something like trimming, uppercasing, lowercasing should be so hard in C++.
Why is
boost::super_string ss(s) ss.trim()
easier than
boost::trim(s)
It isn't -- except which header do you include again? And you have to remember that half the functions you might use are free functions while the other half are member functions. We had a long discussion of this in the summer. In short, for me, it's having all the functions in one place. The signature for more advanced regex functions are much simpler with super_string. Many people don't even realize what's already in Boost (see other discussion in this thread). Also see: http://www.crystalclearsoftware.com/libraries/super_string/index.html#decisi... Most of this started for me when I had to write some string code and Java -- it was nice to not have to run around to 3 places to see string function docs. I *know* C++ is just as powerful as Java, but there's a big mental impedance (even for me) in C++ because you have to look at 4 libraries (regex, format, lexical_cast, string_algo) to do what Java String and super_string do in one place. I find I'm doing these things together, so I find it's *slow* to be jumping around to find the docs, examples, etc.
Many other langages (specially entry-level like VB) only have free functions for string processing.
Sure.
I agree that the string_algo library is a bit difficult to get into but solving that with a new library isn't the right way.
Why not a string_algo wiki where users can add their own real-world examples of how you do things with it.
We've had a Boost user wiki for 5 years so frankly I'm not holding my breath. Plus I don't *really* care about examples, the string_algo docs are plenty good for me. I care about the code that I write. I'm satisfied that with super_string I can write cleaner, clearer string manipulation code -- readable by c++ novices. http://www.crystalclearsoftware.com/libraries/super_string/index.html#code_e... Jeff
Jeff Garland <jeff <at> crystalclearsoftware.com> writes:
Why is
boost::super_string ss(s) ss.trim()
easier than
boost::trim(s)
It isn't -- except which header do you include again?
Agree, but we don't need a super_string class to solve that. A new header "boost/all_string_related_stuff.hpp" would be just as good.
And you have to remember that half the functions you might use are free functions while the other half are member functions.
Agree, but that is not unique for strings or even C++. Is "sort" and "find" member or free functions? At one point there was a proposal to allow both syntaxes in future C++. Don't know what happened to it. An alternative solution would be to add a few more string_algo functions like substr, find_* and all functions would be free just like in VB (begin, end, size is already available via range)
all the functions in one place. The signature for more advanced regex functions are much simpler with super_string. Many people don't even realize what's already in Boost (see other discussion in this thread).
But they will realize that super_string is available? I agree that string functionality is scattered into severeal places with maybe hard to find documentation but still don't understand why a new type is better than combining and unifying the documentation? (except that most of us programmers prefer to write code instead of documentation) Why stop at super_string? Next step is collosal_super_string which combines super_string with spirit, asio and sql.
On 10/13/06, Martin Adrian <adrianm@touchdown.se> wrote:
I agree that string functionality is scattered into severeal places with maybe hard to find documentation but still don't understand why a new type is better than combining and unifying the documentation? (except that most of us programmers prefer to write code instead of documentation)
</lurk> I may very well be speaking out of turn here, and I apologize to Jeff and anyone else if I inadvertantly step on toes. It is my impression that Jeff wanted a string class that he could use for all of his string needs, and when he had something that functioned basically for that purpose he offered it to Boost or any other interested parties. So a new string type is better because it helps one developer, Jeff, do his job more efficiently. Now in the future he just has to include something like "super_string.hpp" and then can get access to whatever he needs. He doesn't have to scratch his head and try to remember which string algorithm header to include for a particular piece of functionality or anything like that. Anyways, that's my take of the situation. I have every intention of grabbing super_string just as soon as I need to do any sort of heavy (or light, for that matter) string lifting. Back to my dark corner now. <lurk> Jeremy
On 10/13/06, Martin Adrian <adrianm@touchdown.se> wrote:
shams <shams <at> orcon.net.nz> writes:
Why is
boost::super_string ss(s) ss.trim()
easier than
boost::trim(s)
I don't want to speak for Jeff, but I think the intention was not to replace the free functions, but rather to use them in the super_string implementation and expose them through member functions. So to your question, one could answer, "It might not be easier for you. If that is the case you are free to use string_algo, or regex, or format." The free functions definitely still have a place. For instance, the string_algo library can accept iterator_ranges, whereas the super_string could only operate on iterators within its own underlying string (forgive me if I'm mistaken, Jeff). I think super_string could co-exist with the other Boost string manipulation libraries quite happily. --Michael
On 10/13/06, Martin Adrian <adrianm@touchdown.se> wrote:
I agree that the string_algo library is a bit difficult to get into but solving that with a new library isn't the right way.
String_algo is also almost completely broken on CVS-HEAD and has been so for some time now: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/algorit... -- Caleb Epstein
"Caleb Epstein" <caleb.epstein@gmail.com> wrote
On 10/13/06, Martin Adrian <adrianm@touchdown.se> wrote:
I agree that the string_algo library is a bit difficult to get into but solving that with a new library isn't the right way.
String_algo is also almost completely broken on CVS-HEAD and has been so for some time now:
http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/algorit...
Not a good excuse for making a new library, especially if it relies on the broken one :) Regards, Arkadiy
Caleb Epstein <caleb.epstein <at> gmail.com> writes:
String_algo is also almost completely broken on CVS-HEAD and has been so for some time now:
And your point is? To me it means that super_string is also broken just like date_time and all other libraries depending on string_algo. And if you trace it back you'll see that string_algo is broken because the range library was updated in a non-compatibale way last spring.
On 10/13/06, Martin Adrian <adrianm@touchdown.se> wrote:
Caleb Epstein <caleb.epstein <at> gmail.com> writes:
String_algo is also almost completely broken on CVS-HEAD and has been so for some time now:
And your point is? To me it means that super_string is also broken just like date_time and all other libraries depending on string_algo.
My point is that string_algo is currently broken, no more than that.
And if you trace it back you'll see that string_algo is broken because the range library was updated in a non-compatibale way last spring.
And noone has bothered to fix the follow-on effects in all this time? Doesn't anyone care? -- Caleb Epstein
Caleb Epstein wrote:
On 10/13/06, Martin Adrian <adrianm@touchdown.se> wrote:
I agree that the string_algo library is a bit difficult to get into but solving that with a new library isn't the right way.
String_algo is also almost completely broken on CVS-HEAD and has been so for some time now:
http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/algorit...
I'm here to be blamed for this. The status is not actualy as bad as it seems. Only the char-literals support is broken. So everything works fine with std::string. This is due to changes in range library. Due to some personal matters (mostly related to my fristborn :) ), I had only a little time to spare. But situation is getting better, so I will get back to string_algo soon. Regards, Pavol
On 10/13/06, Pavol Droba <droba@topmail.sk> wrote:
Due to some personal matters (mostly related to my fristborn :) ), I had
Congrats!
only a little time to spare. But situation is getting better, so I will get back to string_algo soon.
I'm glad you're aware of the problem. I wasn't sure anyone else had noticed. -- Caleb Epstein
Caleb Epstein wrote:
On 10/13/06, Pavol Droba <droba@topmail.sk> wrote:
Due to some personal matters (mostly related to my fristborn :) ), I had
Congrats!
only a little time to spare. But situation is getting better, so I will get back to string_algo soon.
I'm glad you're aware of the problem. I wasn't sure anyone else had noticed.
I can asure you, that I'm very well aware of the problem. But since 1.34 is still not out and I had time problems, I was working on more urgent matters (like proposal for C++ commitee). Regards, Pavol.
participants (9)
-
Arkadiy Vertleyb -
Caleb Epstein -
Jeff Garland -
Jeremy Day -
loufoque -
Martin Adrian -
Michael Fawcett -
Pavol Droba -
shams