SuperString v2 in the vault
Thanks all for the discussion/suggestions on the first version. As usual Boosters have very helpful suggestions. I've uploaded version 2 of super_string to the vault and put an improved set of documentation online: http://www.crystalclearsoftware.com/libraries/super_string/index.html Vault location: http://tinyurl.com/dbcye Probably the biggest thing in this version is an immutable version using the proposed boost::const_string. http://www.crystalclearsoftware.com/libraries/super_string/classbasic__const... After using it a bit, it seems to me that the immutable approach is likely viable for most applications. To see the impact, I wrote a little performance test. On mutating operations const_super_string is clearly slower. The benefit on non-mutating operations is minimal. However, this version is probably not as optimized as possible and it under emphasizes allocation, so I expect in actual practice the mutable version may better than these tests demonstrate. Your mileage may vary. 10 trials 500000 iterations/trial const append test --> total elapsed: 00:00:25.071687 mutable append test --> total elapsed: 00:00:21.904486 10 trials 1000000 iterations/trial const trim test --> total elapsed: 00:00:14.977803 mutable trim test --> total elapsed: 00:00:11.693688 10 trials 100000 iterations/trial const contains regex test --> total elapsed: 00:00:27.044718 mutable contains regex test --> total elapsed: 00:00:27.633608 10 trials 100000 iterations/trial const split regex test --> total elapsed: 00:00:16.517079 mutable split regex test --> total elapsed: 00:00:17.582708 Other notable changes in this version: * Make modification functions chainable -- thanks Mark Mutz * Add append_file function -- Thx to suggestion by Pavel Vozenilek super_string data; data.append_file("data1.txt").append_file(data2.txt); * Type conversion with user supplied stringstream std::ostringstream ss; s.setprecision( super_string s; ss << std::setprecision(3); double dbl = 1.987654321; int i = 1000; s.append(dbl, i, i, " stuff", dbl, ss); //s == "1.99 1000 1000 1.99 stuff 1.99" //ss -- has been modified * Add boost.format capabilities -- Thx to suggestion by Pavel Vozenilek super_string s; double d = 1.123456789; int i = 1000; s.append_formatted(d, i , d, i, "a string", "%-7.2f %-7d %-7.2f %-7d %s"); //s == "1.12 1000 1.12 1000 a string" * Removed all const _copy overloads in mutable string to reduce the api size. * Add additional template overloads to support multi-append cases like double double d = 1.54; int i = 25; s.append("double: ", d, " is ", i); Currently up to 5 parameters Enjoy, Jeff
Jeff Garland wrote:
After using it a bit, it seems to me that the immutable approach is likely viable for most applications. To see the impact, I wrote a little performance test. On mutating operations const_super_string is clearly slower. The benefit on non-mutating operations is minimal. However, this version is probably not as optimized as possible and it under emphasizes allocation, so I expect in actual practice the mutable version may better than these tests demonstrate. Your mileage may vary.
There's another strategy that's not done in the tests: immutable strings returning lazily evaluated views (ala Fusion). I bet ya, such a strategy will leave both versions in the dust (especially on compound operations, which BTW you don't currently have), but I'll avoid making claims for now. I intend to look into this when I get some time. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
I find your improvements over string class interface very valuable. Is there any hope to incorporate these changes directly into basic_string in the future C++ standard? I mean it's fine we now have super_string class but the fact we have two string classes for the same thing is confusig. And if super_string is superset and better than std::string why not replace it? Tomas "Jeff Garland" <jeff@crystalclearsoftware.com> píse v diskusním príspevku news:44B194C1.8080903@crystalclearsoftware.com...
Thanks all for the discussion/suggestions on the first version. As usual Boosters have very helpful suggestions. I've uploaded version 2 of super_string to the vault and put an improved set of documentation online:
http://www.crystalclearsoftware.com/libraries/super_string/index.html
Vault location:
Probably the biggest thing in this version is an immutable version using the proposed boost::const_string.
http://www.crystalclearsoftware.com/libraries/super_string/classbasic__const...
After using it a bit, it seems to me that the immutable approach is likely viable for most applications. To see the impact, I wrote a little performance test. On mutating operations const_super_string is clearly slower. The benefit on non-mutating operations is minimal. However, this version is probably not as optimized as possible and it under emphasizes allocation, so I expect in actual practice the mutable version may better than these tests demonstrate. Your mileage may vary.
10 trials 500000 iterations/trial const append test --> total elapsed: 00:00:25.071687 mutable append test --> total elapsed: 00:00:21.904486
10 trials 1000000 iterations/trial const trim test --> total elapsed: 00:00:14.977803 mutable trim test --> total elapsed: 00:00:11.693688
10 trials 100000 iterations/trial const contains regex test --> total elapsed: 00:00:27.044718 mutable contains regex test --> total elapsed: 00:00:27.633608
10 trials 100000 iterations/trial const split regex test --> total elapsed: 00:00:16.517079 mutable split regex test --> total elapsed: 00:00:17.582708
Other notable changes in this version:
* Make modification functions chainable -- thanks Mark Mutz * Add append_file function -- Thx to suggestion by Pavel Vozenilek
super_string data; data.append_file("data1.txt").append_file(data2.txt);
* Type conversion with user supplied stringstream
std::ostringstream ss; s.setprecision( super_string s; ss << std::setprecision(3); double dbl = 1.987654321; int i = 1000; s.append(dbl, i, i, " stuff", dbl, ss); //s == "1.99 1000 1000 1.99 stuff 1.99" //ss -- has been modified
* Add boost.format capabilities -- Thx to suggestion by Pavel Vozenilek
super_string s; double d = 1.123456789; int i = 1000; s.append_formatted(d, i , d, i, "a string", "%-7.2f %-7d %-7.2f %-7d %s"); //s == "1.12 1000 1.12 1000 a string"
* Removed all const _copy overloads in mutable string to reduce the api size. * Add additional template overloads to support multi-append cases like double
double d = 1.54; int i = 25; s.append("double: ", d, " is ", i); Currently up to 5 parameters
Enjoy,
Jeff _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 7/11/06, Tomas <pecholt@sin.cvut.cz> wrote:
I find your improvements over string class interface very valuable. Is there any hope to incorporate these changes directly into basic_string in the future C++ standard? I mean it's fine we now have super_string class but the fact we have two string classes for the same thing is confusig. And if super_string is superset and better than std::string why not replace it?
My problem there is that it's only solving a problem (assuming for now that there is one) in one place instead of doing something more general that could later solve it in other places. If foo(bar,a,b) could always be written as bar.foo(a,b) and algorithms taking an iterator range also accepted just a container (and returned a container instead of using an output iterator (range?), if applicable), would a super_string still be needed? ~ Scott McMurray
Tomas wrote:
I find your improvements over string class interface very valuable. Is there any hope to incorporate these changes directly into basic_string in the future C++ standard?
Faint, I'd say. If you've been following the reaction, you'll know that this is a tough area to get agreement. I don't know if there's enough support to get it included in Boost and if you can't get the library into Boost it doesn't bode well for the committee.
I mean it's fine we now have super_string class but the fact we have two string classes for the same thing is confusig. And if super_string is superset and better than std::string why not replace it?
Even if you could get agreement that super_string is better than string, someone has to write a paper for the committee suggesting this. Many of the string algorithms that super_string uses have been proposed for TR2, but I'm not sure where they stand. I put super_string out there because it's useful to me and I thought it would be useful to have a discussion about it. I don't have time to write a paper to propose it to the committee, but if someone wanted to do that I'd be fine with it. But beware, there's a good chance it's a waste of time. Jeff
Hi Jeff, If simplicity is really the goal, then may I suggest the following: 1. remove the last template parameter (simply derive the types from boost::detail::super_string). 2. rename the type boost::string and boost::wstring (an adjective like super don't sound very good IMO) -Thorsten
Thorsten Ottosen wrote:
Hi Jeff,
If simplicity is really the goal, then may I suggest the following:
1. remove the last template parameter (simply derive the types from boost::detail::super_string).
I suppose, but that might scare someone off from doing: template<class char_type> really_super_string : public super_string<char_type> which is a perfectly valid way to add in a few more pet algorithms in a consistent fashion.
2. rename the type boost::string and boost::wstring (an adjective like super don't sound very good IMO)
That scares me a little. Someone that happens to do a using namespace std; and using namespace boost would wind up with errors. I'm willing to entertain other names, but I'd like to avoid the conflict here. Jeff
Jeff Garland wrote:
Thorsten Ottosen wrote:
Hi Jeff,
If simplicity is really the goal, then may I suggest the following:
1. remove the last template parameter (simply derive the types from boost::detail::super_string).
I suppose, but that might scare someone off from doing:
template<class char_type> really_super_string : public super_string<char_type>
which is a perfectly valid way to add in a few more pet algorithms in a consistent fashion.
You can expose boost::basic_string too if you want. But if you really want simplicity and good error messages, you should get rid of the template parameter.
2. rename the type boost::string and boost::wstring (an adjective like super don't sound very good IMO)
That scares me a little. Someone that happens to do a using namespace std; and using namespace boost would wind up with errors. I'm willing to entertain other names, but I'd like to avoid the conflict here.
People should learn to use qualified calls. Anyway, the error would be purely a compile-time error, so what's the problem? -Thorsten
participants (6)
-
Andy Little -
Jeff Garland -
Joel de Guzman -
me22 -
Thorsten Ottosen -
Tomas