Re: [Boost-users] [string_algo] new flavour of xxx_copy algorithms

From: Pavol Droba (droba_at_[hidden])
Date: 2005-04-03 04:46:43

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<typename OutputIteratorT, typename CollectionT>
>     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<typename SequenceT, typename CollectionT>
> 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_copy<std::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