[cfe-dev] Transforming push_back(T(args, ...)) into emplace_back(args)

[mats petersson via cfe-dev]

Not sure if this is "change clang itself" or "make clang do this
transform".

On the "change clang itself to use emplace_back, the general principle is
that you should use push_back whenever "feasible", and emplace_back if
there is a specific reason to use that - for example non-copyable objects,
or very large objects that take significant to copy construct.

If it's "make clang do this", I think it would be interesting to see if
this can be detected and converted and how much improvement that gives for
average cases - and if there are cases where it's detrimental? Some
benchmarks to show the difference would be nice.

--
Mats



On 29 April 2016 at 16:19, David Blaikie via cfe-dev <cfe-dev at lists.llvm.org
> wrote:

> Transformation as in clang-tidy? Or as in optimization in Clang? I doubt
> the latter, but could imagine the former. I'm not sure if it's a
> universally preferred transformation, though (but that's one of the
> benefits of clang-tidy, it doesn't have to be)
>
> On Thu, Apr 28, 2016 at 7:00 PM, Vedant Kumar via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>
>> Hi all,
>>
>> It's common to see code which does this:
>>
>>   (1) V.push_back(T(args, ...));
>>
>> When it could do this instead:
>>
>>   (2) V.emplace_back(args, ...);
>>
>> IIUC, the copy constructor for T is never called in case (2).
>>
>> Would it be possible/worthwhile/correctness-preserving to perform this
>> transformation in clang? Based on a cursory grep it doesn't seem like we do
>> this today, but I could've missed something.
>>
>> thanks
>> vedant
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160429/fa26e4a8/attachment.html>