[libstdc++-v3 parallel mode] lack of __gnu_parallel::copy and inconvenience of transform overload

[Johannes Singler]

Paolo Carlini wrote:
> Hi,
>> While using __gnu_parallel, I could not guess nor find the reason not
>> to have a __gnu_parallel::copy, which should be embarrassingly
>> parallel for random iterators. I settled for __gnu_parallel::transform
>> using an identity Op, which brings me to my second question/remark :
>> given that the overload of std:transform (for 1 or 2 input sequences)
>> interferes with the additional optional parameter for __gnu_parallel::
>> algorithms, would it be possible to provide
>> __gnu_parallel::transform1(...,__gnu_parallel::_Parallelism ) and
>> __gnu_parallel::transform2(...,__gnu_parallel::_Parallelism ) to allow
>> an easy selection of the parallelism of the transform algorithms over
>> 1 and 2 input sequences ?

Hmm, is there no way to solve this ambiguity otherwise?  Are you using
the version from trunk?

> Johannes, what do you think? Are you already aware of this kind of
> request? Should we add it to libstdc++/38875?

That's a good idea.  However, I cannot promise too much speedup for an
operation that (normally) does nothing else than accessing memory.

-- Johannes