On 02/24/2015 12:32 PM, Bjoern Michaelsen wrote:
On Tue, Feb 24, 2015 at 08:13:56AM +0100, Stephan Bergmann wrote:
Rather than allowing to move out of the temporary pair, better avoid
its creation in the first place:
for(auto const & aEntry : vInit)
Eh, true. But actually, I wanted both: Iterating over the pairs in the
initializer list by reference and still using the move-ctor from there.
You can't move out of an initializer_list (it only offers const access
to its elements).
That use of std::move is actually a pessimization, as it prevents RVO.
How so? The RVO would be to do the ::std::move(). So this is just making that
(needlessly) explicit, isnt it? At least that is what I read from
http://stackoverflow.com/questions/17473753/c11-return-value-optimization-or-move
No; see e.g. Item 25 of Meyers' "Effective Modern C++" for details. (In
short, RVO only applies if what's returned is a local object, not a
reference to a local object. While a compiler would be required to
internally do the equivalent of adding the std::move if it decided
against applying RVO in the no-explicit-std::move version, the
explicit-std::move version prevents it from applying RVO.)
"And check out Scott Meyers' helpful 'Effective Modern C++,'
<http://shop.oreilly.com/product/0636920033707.do>, if only to make you
realize that C++ is still a baroque pile of gotchas."
[<http://lists.freedesktop.org/archives/libreoffice/2014-September/063326.html>]
Context
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.