[PATCH] D36089: [ELF] - Replace parallelForEach with ranged form.

David Blaikie via llvm-commits llvm-commits at lists.llvm.org
Thu Aug 3 11:40:01 PDT 2017


On Wed, Aug 2, 2017 at 4:09 PM Rafael Avila de Espindola <
rafael.espindola at gmail.com> wrote:

> David Blaikie <dblaikie at gmail.com> writes:
>
> > Oh, huh, yeah - right you are (I was rather hoping that "T&" would
> derive T
> > as "const U" when passed a temporary, but as you've pointed out, it
> > doesn't).
> >
> > Yeah, I'd be in favor of what you've done then - passing T&& so
> temporaries
> > or locals can be passed by reference without undue copying in either
> case.
>
> Sorry, what copying?
>

If "const T&" is used, then users can't pass mutable data - which seems
like a reasonable thing users of a parallel API might want (I want to do a
parellel mutation of data - like if I have a vector of vectors and want to
reduce the subvectors in some way - replace them with a single-element
vector containing the sum of the elements of the original vector)

If "T" is used, then they can mutate data, but would've had to copy it
first, which probably defeats the point (since then the side effects get
thrown away at the end)

But sure - if you want to restrict the use of the API to non-mutating cases
for now, it's your/LLD's code. But it seems like a reasonable
implementation to use T&& thus allowing mutation or non-mutation (same as a
normal for loop, or std::for_each, etc) without waiting for the specific
use case.

Up to you,
- Dave


>
> Since this is an algorithm and not an adapter, no copying is necessary,
> right? If that is the case I think it is probably better to use "const
> T&".
>
> Cheers,
> Rafael
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170803/11bf6a5a/attachment.html>


More information about the llvm-commits mailing list