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

[Rafael Avila de Espindola via llvm-commits]

David Blaikie <dblaikie at gmail.com> writes:

> This becomes more relevant with range adapters rather than range algorithms
> - the trick being that you want to take ownership of the range if it's an
> rvalue (note that T&& isn't an rvalue necessarily - it's a universal
> reference... or someth other terminology. It can refer to an rvalue or an
> lvalue - I can describe all that in more detail if you're not familiar with
> that weird/complex part of C++) otherwise range-for loops like this:
>
> for (auto x : reverse(buildVector()))
>
> break - if buildVector returns a vector by value, and 'reverse' produces a
> range adapter that refers to the vector but doesn't take ownership - then
> the vector will be destroyed after the evaluation of the range-for loops
> initializer expression, leaving the reverse adapting range with a dangling
> reference to the underlying vector. (but on the other hand, when presented
> with a non-rvalue reference, you don't want to unduly copy the contents...
> - so range adapters do dark magic things to correctly copy or not as
> needed... at least range adapters attempting to be safe/highly generic. I
> think some of the range adapters so far in LLVM have these sort of smarts)
>
> I suppose for a range algorithm (as opposed to a range adapter) you
> probably just need to take by T & (and T will be deduced to const U if
> needed).
>
> Taking by T&& and not using std::forward is pretty telling that it's
> probably not needed/intended. And using std::forward more than once, like
> using std::move more than once, is a bit suspect (though I've done it in
> some specific cases).
>
> So if this was a range-algorithm calling through to another range
> algorithm, I might use T&& and std::forward - to pass through the
> mutability/const/rvalueness, etc... - but that's not the case here.
>
> Unless there are counterexamples already in ADT - happy to speculate on
> their design and the consistency/inconsistency with this code.

Thanks a lot for the explanation. Care to add some of it as a comment
STLExtras.h? :-)

Cheers,
Rafael