[boost-lists][string algo] C++0x string algo.
Hello. I'm using c++0x-enabled c++0x compiler. I was going to use this piece of code: typedef vector< string > split_vector_type; split_vector_type svec; split(svec, str, is_any_of(":")); for c++0x, I shouldn't need to define a typedef to take advantage of that. I think it would be more idiomatic (and way easier to do) to use something like this: auto splitrange = split(str, is_any_of(":")); So I would like to know if it's possible to map split to a range result by default (not a vector, maybe). And it could also be used with a vector if you put it explicitly: auto splitvec = split<vector<string>>(str, ....); I think the whole library should be readapted to return by value. I've spent some time figuring how to use the library because of the out parameters in the arguments. Can anyone tell me if there is any plan to change this? Or if it should be possible? Thanks in advance.
Germán Diago wrote:
Hello. I'm using c++0x-enabled c++0x compiler.
I was going to use this piece of code:
typedef vector< string > split_vector_type; split_vector_type svec;
split(svec, str, is_any_of(":"));
for c++0x, I shouldn't need to define a typedef to take advantage of that. I think it would be more idiomatic (and way easier to do) to use something like this:
auto splitrange = split(str, is_any_of(":"));
So I would like to know if it's possible to map split to a range result by default (not a vector, maybe). And it could also be used with a vector if you put it explicitly:
auto splitvec = split<vector<string>>(str, ....);
I think the whole library should be readapted to return by value. I've spent some time figuring how to use the library because of the out parameters in the arguments.
Can anyone tell me if there is any plan to change this?
There is none.
Or if it should be possible?
It's possible, yes. But that means the splitting would be done lazily as you iterate the returned range. I have the basic utilities needed to adapt all StringAlgo algorithms to behave that way (well, I have a framework for lazy segmentation and transformation or ranges) if there is interest. I wouldn't find it ok for split to return a vector<string> since I like to be kept in control of how I store my elements, and there is no control without taking the container as an argument or using the method I just mentioned.
Or if it should be possible?
It's possible, yes. But that means the splitting would be done lazily as you iterate the returned range. I have the basic utilities needed to adapt all StringAlgo algorithms to behave that way (well, I have a framework for lazy segmentation and transformation or ranges) if there is interest.
I wouldn't find it ok for split to return a vector<string> since I like to be kept in control of how I store my elements, and there is no control without taking the container as an argument or using the method I just mentioned.
There are more changes that can be made to the interface in view of C++0x, especially move-semantics. I suggest that we create that interface in a new namespace e.g. boost::cpp0x::algorithm. -Thorsten
Thorsten Ottosen wrote:
There are more changes that can be made to the interface in view of C++0x, especially move-semantics.
I suggest that we create that interface in a new namespace e.g. boost::cpp0x::algorithm.
What does move semantics, or even C++0x, bring that is new with regards to string algorithms? That means you can return by value without causing a copy, but that was already true anyway due to NRVO.
Mathias Gaunard skrev:
Thorsten Ottosen wrote:
There are more changes that can be made to the interface in view of C++0x, especially move-semantics.
I suggest that we create that interface in a new namespace e.g. boost::cpp0x::algorithm.
What does move semantics, or even C++0x, bring that is new with regards to string algorithms?
That means you can return by value without causing a copy, but that was already true anyway due to NRVO.
Well, now it is guaranteed, it it does seem to have affected the interface. Further, we should be able to take advantage of rvalue arguments. -Thorsten
I wouldn't find it ok for split to return a vector<string> since I like to be kept in control of how I store my elements, and there is no control without taking the container as an argument or using the method I just mentioned.
I would like to be able to use it like this: split(str, predseparators); Which returns a range. I think this is possible. You always return a range, and if you want to store it, you can copy the returned range to a vector<string>, for example. So it would be quite realistic (I think) to adapt split so that returns always ranges and if you want a copy, make a explicit copy in the code: auto r = split(str, predseparators); vector<string> vec(r.begin(), r.end());
Germán Diago skrev:
I wouldn't find it ok for split to return a vector<string> since I like to be kept in control of how I store my elements, and there is no control without taking the container as an argument or using the method I just mentioned.
I would like to be able to use it like this:
split(str, predseparators);
Which returns a range. I think this is possible. You always return a range, and if you want to store it, you can copy the returned range to a vector<string>, for example. So it would be quite realistic (I think) to adapt split so that returns always ranges and if you want a copy, make a explicit copy in the code:
auto r = split(str, predseparators);
vector<string> vec(r.begin(), r.end());
Right. And we also want to be able to say for( const auto& r : split(str,...) ) ... so you are right that ranges are the way to go. -Thorsten
Germán Diago wrote:
I wouldn't find it ok for split to return a vector<string> since I like to be kept in control of how I store my elements, and there is no control without taking the container as an argument or using the method I just mentioned.
I would like to be able to use it like this:
split(str, predseparators);
Which returns a range. I think this is possible. You always return a range, and if you want to store it, you can copy the returned range to a vector<string>, for example. So it would be quite realistic (I think) to adapt split so that returns always ranges and if you want a copy, make a explicit copy in the code:
auto r = split(str, predseparators);
vector<string> vec(r.begin(), r.end());
Which is the mechanism I offered, i.e. lazy evaluation with range adapters.
Rob Riggs wrote:
On 01/17/2010 05:10 PM, Mathias Gaunard wrote:
Germ�n Diago wrote:
auto r = split(str, predseparators);
vector<string> vec(r.begin(), r.end());
Which is the mechanism I offered, i.e. lazy evaluation with range adapters.
I would love to see this added.
I think getting it added is another problem. This is more a rewrite of StringAlgo than a simple extension. I might be better to try out the system as StringAlgo2 first.
Hi, On 18. 1. 2010 13:58, Mathias Gaunard wrote:
Rob Riggs wrote:
On 01/17/2010 05:10 PM, Mathias Gaunard wrote:
Germ�n Diago wrote:
auto r = split(str, predseparators);
vector<string> vec(r.begin(), r.end());
Which is the mechanism I offered, i.e. lazy evaluation with range adapters.
I would love to see this added.
I think getting it added is another problem. This is more a rewrite of StringAlgo than a simple extension.
I might be better to try out the system as StringAlgo2 first.
I'd like to add few points here (as an author) if I might :). First of all, I'm all for any improvements that may come from C++0x, but I would realy like to keep the library working with the (not so) old compilers. So the new functionality should be kept separate. Now to the actual improvements. *auto* and return values might really come handy, but there are not so many places where they can really be used. Apart from split I don't see much improvement they could bring. Lazy evaluation is already part of the library's philosophy, so it might just require soma adapters here and there. Internaly the split is handled by find iterators, and it is possible to define the result as a pair of those. Just check the implementation of boost::algorithm::iter_split. *auto* might come realy handy here though. If some sort of lazy evaluation framework can use this, it might only be beneficial. But I'm not sure if it is not a little bit out of scope of this library. Anyway these are just my quick thoughts, I didn't considered any change in these directions yet. If somebody is willing to experiment, I can offer my assistance. Best Regards, Pavol.
participants (5)
-
Germán Diago -
Mathias Gaunard -
Pavol Droba -
Rob Riggs -
Thorsten Ottosen