<table><tr><td style="">aaronpuchert added a comment.
</td><a style="text-decoration: none; padding: 4px 8px; margin: 0 8px 8px; float: right; color: #464C5C; font-weight: bold; border-radius: 3px; background-color: #F7F7F9; background-image: linear-gradient(to bottom,#fff,#f1f0f1); display: inline-block; border: 1px solid rgba(71,87,120,.2);" href="https://phabricator.kde.org/D9236" rel="noreferrer">View Revision</a></tr></table><br /><div><div><blockquote style="border-left: 3px solid #8C98B8;
          color: #6B748C;
          font-style: italic;
          margin: 4px 0 12px 0;
          padding: 8px 12px;
          background-color: #F8F9FC;">
<div style="font-style: normal;
          padding-bottom: 4px;">In <a href="https://phabricator.kde.org/D9236#177787" style="background-color: #e7e7e7;
          border-color: #e7e7e7;
          border-radius: 3px;
          padding: 0 4px;
          font-weight: bold;
          color: black;text-decoration: none;" rel="noreferrer">D9236#177787</a>, <a href="https://phabricator.kde.org/p/kossebau/" style="
              border-color: #f1f7ff;
              color: #19558d;
              background-color: #f1f7ff;
                border: 1px solid transparent;
                border-radius: 3px;
                font-weight: bold;
                padding: 0 4px;" rel="noreferrer">@kossebau</a> wrote:</div>
<div style="margin: 0;
          padding: 0;
          border: 0;
          color: rgb(107, 116, 140);"><p>I still have to complete my C++11 classes sadly. In my naive mind I would have hoped something like this would be possible, in general:</p>

<div class="remarkup-code-block" style="margin: 12px 0;" data-code-lang="text" data-sigil="remarkup-code-block"><pre class="remarkup-code" style="font: 11px/15px "Menlo", "Consolas", "Monaco", monospace; padding: 12px; margin: 0; background: rgba(71, 87, 120, 0.08);">alloc heap memory for list items
for each item
    default constructor item on heap
    setup item on heap</pre></div>

<p>I would not see any principal need to prepare the item on the stack. Is there? Why would C++11 still prefer a move operator, instead of going directly for the final memory destination?</p></div>
</blockquote>

<p>You are completely right, I would just advise against going through the vector twice, as you'd do with <tt style="background: #ebebeb; font-size: 13px;">resize()</tt>. So if you still use <tt style="background: #ebebeb; font-size: 13px;">reserve()</tt>, then add single elements and initialize them that's fine.</p>

<blockquote style="border-left: 3px solid #a7b5bf; color: #464c5c; font-style: italic; margin: 4px 0 12px 0; padding: 4px 12px; background-color: #f8f9fc;"><p>With QVector it seems there is some practical need for a separate item instance only because the API does not have any hooks for some iterator-based filling, any item construction is hardcoded to the default constructor (Edit: besides the <tt style="background: #ebebeb; font-size: 13px;">append()</tt> logic which does copy/move constructor, which though does not gain us something for avoiding the temp copy on the stack). One could imagine some <tt style="background: #ebebeb; font-size: 13px;">fill(int count, functor constructor)</tt> or some <tt style="background: #ebebeb; font-size: 13px;">T& appendNew()</tt>. But it isn't there after all the years, despite list filling from a loop surely being a common need. Would that be an anti-pattern for some reason?</p></blockquote>

<p>STL's <tt style="background: #ebebeb; font-size: 13px;">std::vector</tt> has <a href="http://en.cppreference.com/w/cpp/container/vector/emplace_back" class="remarkup-link" target="_blank" rel="noreferrer">emplace_back</a> that constructs a new vector element in place. Sadly <tt style="background: #ebebeb; font-size: 13px;">QVector</tt> doesn't have it yet, and I've seen Qt developers <a href="https://stackoverflow.com/a/5863014" class="remarkup-link" target="_blank" rel="noreferrer">express their doubts</a> it's going to happen soon.</p>

<p>What I was trying to say is that compilers have a lot of freedom with local variables - they might not ever be written to actual memory, sometimes not even into registers. The only requirement imposed is that the observed behavior is not allowed to change. This is why debugging optimized code can be so hard. Eliminating copies of local variables may not actually improve performance.</p>

<p>But even if the compiler is not able to optimize out copies, all that stuff is still happening in the L1 cache. Drastic performance degradation usually happens when there is too much data and stuff gets evicted to main memory. Hence it's preferable to do everything in one pass.</p>

<blockquote style="border-left: 3px solid #a7b5bf; color: #464c5c; font-style: italic; margin: 4px 0 12px 0; padding: 4px 12px; background-color: #f8f9fc;"><p>No real clue yet about move operators, but how does it spare us here any constructor and deconstructor calls? And with the QType-sub-datastructures being implicitly-shared usually, does the move operator make a difference when it comes to unneeded temporary allocations?</p></blockquote>

<p>The benefit for implicitly-shared data types might be small, but I think not all types are. So maybe I should clarify that moves might not always be cheaper than copies (for simple data types they do the same), but sometimes there is a considerable benefit, usually when types own (meaning it's not shared) a chunk of data on the heap.</p>

<blockquote style="border-left: 3px solid #8C98B8;
          color: #6B748C;
          font-style: italic;
          margin: 4px 0 12px 0;
          padding: 8px 12px;
          background-color: #F8F9FC;">
<div style="font-style: normal;
          padding-bottom: 4px;">In <a href="https://phabricator.kde.org/D9236#177745" style="background-color: #e7e7e7;
          border-color: #e7e7e7;
          border-radius: 3px;
          padding: 0 4px;
          font-weight: bold;
          color: black;text-decoration: none;" rel="noreferrer">D9236#177745</a>, <a href="https://phabricator.kde.org/p/aaronpuchert/" style="
              border-color: #f1f7ff;
              color: #19558d;
              background-color: #f1f7ff;
                border: 1px solid transparent;
                border-radius: 3px;
                font-weight: bold;
                padding: 0 4px;" rel="noreferrer">@aaronpuchert</a> wrote:</div>
<div style="margin: 0;
          padding: 0;
          border: 0;
          color: rgb(107, 116, 140);"><p>By the way, it's usually a good idea to have vector elements nothrow-move constructible. This can be checked with</p>

<div class="remarkup-code-block" style="margin: 12px 0;" data-code-lang="cpp" data-sigil="remarkup-code-block"><pre class="remarkup-code" style="font: 11px/15px "Menlo", "Consolas", "Monaco", monospace; padding: 12px; margin: 0; background: rgba(71, 87, 120, 0.08);"><span style="color: #aa4000">static_assert</span><span class="p">(</span><span class="n">std</span><span style="color: #aa2211">::</span><span class="n">is_nothrow_move_constructible</span><span style="color: #aa2211"><</span><span class="n">Type</span><span style="color: #aa2211">>::</span><span class="n">value</span><span class="p">,</span> <span style="color: #766510">"..."</span><span class="p">);</span></pre></div>

<p>for a <tt style="background: #ebebeb; font-size: 13px;">QVector<T></tt>. This doesn't always seem to be the case. Maybe I'll have a look what can be done there.</p></div>
</blockquote>

<p><a href="https://stackoverflow.com/a/5863014" class="remarkup-link" target="_blank" rel="noreferrer">Well</a>, "QVector still doesn't move elements on reallocations."</p></div></div><br /><div><strong>REPOSITORY</strong><div><div>R32 KDevelop</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D9236" rel="noreferrer">https://phabricator.kde.org/D9236</a></div></div><br /><div><strong>To: </strong>kossebau, KDevelop<br /><strong>Cc: </strong>aaronpuchert, brauch, kdevelop-devel<br /></div>