[string_algo] new flavour of xxx_copy algorithms
Hi.
Many algorithms in the string-algo library have 3 versions (I'll take
to_upper as an example):
1. In-place modification which takes a SequenceT by ref:
template<typename MutableCollectionT>
void to_upper(MutableCollectionT &);
2. Copy version which takes a SequenceT by const ref, and returns SequenceT:
template<typename SequenceT>
SequenceT to_upper_copy(const SequenceT &);
3. Copy version which takes a const ref CollectionT and an
OutputIteratorT and the OutputIteratorT after using it:
template
Hi Yuval Saturday, April 2, 2005, 11:44:31 PM, you wrote:
Hi.
Many algorithms in the string-algo library have 3 versions (I'll take to_upper as an example): 1. In-place modification which takes a SequenceT by ref: template<typename MutableCollectionT> void to_upper(MutableCollectionT &); 2. Copy version which takes a SequenceT by const ref, and returns SequenceT: template<typename SequenceT> SequenceT to_upper_copy(const SequenceT &); 3. Copy version which takes a const ref CollectionT and an OutputIteratorT and the OutputIteratorT after using it: template
OutputIteratorT to_upper_copy(OutputIteratorT, const CollectionT &)
I believe there's room for another version - something that takes a const ref CollectionT, and returns a copy in a SequenceT:
template
SequenceT to_upper_copy(const CollectionT &);
The benefits are ease of use combined with performance. IMO, a common scenario is to perform a copy algorithm on a char* string, and returning it as a std::string. Such a thing would be easily done with the proposed extension as:
std::string str = to_upper_copystd::string("something");
As it is now, I either have to make additional copy (if I use the in-place modification version or the SequenceT copy version), or handle the std::string size my self (if I use the OutputIteratorT version). The new version will allow me to do it elegantly and efficiently. The problem is that it probably can't be an overload of to_upper_copy because it has the same number of arguments as one of the existing overloads, so it will have to have a different name :-(
You have pinpointed an important topic. The use-case you have shown is indeed important. However I don't think, that the approach you have suggested is a viable solution. StringAlgo library is already overbloated with different overrides. I'm think about something different. The chaining of _copy algorithms curretly means a lot of unnecessary copying. Part of it can be removed using expression templates. And I have some ideas how it can also provide the functionality you have requested. Unfortunately, these ideas are currently only it the consideration phase, so I cannot say whey they will be incorporated. In the mean time, I would suggest you to convert char* to std::string and then perform in-place transformation. Thanks, Pavol
Pavol Droba wrote:
I'm think about something different. The chaining of _copy algorithms curretly means a lot of unnecessary copying. Part of it can be removed using expression templates. And I have some ideas how it can also provide the functionality you have requested.
Unfortunately, these ideas are currently only it the consideration phase, so I cannot say whey they will be incorporated.
Looking forward to it! Yuval
participants (2)
-
Pavol Droba
-
Yuval Ronen