boost::algorithm::split design rational question
Hello, When we look at the following declaration : template<typename SequenceSequenceT, typename RangeT, typename PredicateT> SequenceSequenceT& split(SequenceSequenceT & Result, RangeT & Input, PredicateT Pred, token_compress_mode_type eCompress = token_compress_off); Anyone knows why split() takes the input type by reference and not by const reference ? The current design prevents, say, passing a temporary string to split which is imho something not convenient. I'd want to be able to do code like : string input = "/foo/bar"; vector<string> tokens; split(tokens, input.substr(1), token_compress_off); Thank you for your answers. Philippe
Of course the code : split(tokens, input.substr(1), token_compress_off); Should look like : split(tokens, input.substr(1), is_any_of("/"), token_compress_on); Philippe
Hi, There are reasons for it. One of them is the posibility to store result in reference-like container. Example: vector<iterator_range<string::iterator> > tokens; split(tokens, input, token_comress_off); This way you can have a split without copying overhead. I consider this functionality interesting enough to make the interface to be like it is now. Regards, Pavol Philippe Vaucher wrote:
Of course the code :
split(tokens, input.substr(1), token_compress_off);
Should look like :
split(tokens, input.substr(1), is_any_of("/"), token_compress_on);
Philippe _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Pavol Droba wrote:
Hi,
There are reasons for it.
One of them is the posibility to store result in reference-like container.
Example: vector<iterator_range<string::iterator> > tokens; split(tokens, input, token_comress_off);
This way you can have a split without copying overhead. I consider this functionality interesting enough to make the interface to be like it is now.
No overhead is good, but there might be a different way to achieve it: split( tokens, make_iterator_range(input), ... ); We could even get away with changing split(), but letting make_iterator_range() return a const iterator_range<T> (Erics suggestion). But OTOT, that would disallow a call to mutable functions afterwards. We could also add make_const_iterator_range(). Anyway, I do think the current behavior can be suprising at first and that those who want efficiency should do the extra work (at least in C++03). -Thorsten
participants (3)
-
Pavol Droba -
Philippe Vaucher -
Thorsten Ottosen