<table><tr><td style="">zzag 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/D23918">View Revision</a></tr></table><br /><div><div><blockquote style="border-left: 3px solid #a7b5bf; color: #464c5c; font-style: italic; margin: 4px 0 12px 0; padding: 4px 12px; background-color: #f8f9fc;"><p>You need to provide sources for such generic statements.</p></blockquote>

<p>Sorry to disappoint you but that's an unwritten rule in C++ community. The main reason why one should avoid inheriting qvector or std::vector has something to do with destructors. More specifically, neither one of those container types has virtual destructor. However, you could fix that with private inheritance, which will look very ugly! From design perspective if you want to transform a container you have to use an algorithm rather than inherit from the container type and add a method, i.e. don't go against STL design. It somewhat relates to composition over inheritance [1].</p>

<p>Let's talk about Outputs class specifically. The main problem with it is that it adds only a constructor and nothing more. In the end we have a class without anything new to offer than its base class [QVector<AbstractOutput *>]. The worst thing is that we have yet another container type to deal with. The correct solution is to use a helper function to perform conversions between QVector<Base> and QVector<Derived> rather than using new container type.</p>

<p>[1] <a href="https://en.wikipedia.org/wiki/Composition_over_inheritance" class="remarkup-link" target="_blank" rel="noreferrer">https://en.wikipedia.org/wiki/Composition_over_inheritance</a></p></div></div><br /><div><strong>INLINE COMMENTS</strong><div><div style="margin: 6px 0 12px 0;"><div style="border: 1px solid #C7CCD9; border-radius: 3px;"><div style="padding: 0; background: #F7F7F7; border-color: #e3e4e8; border-style: solid; border-width: 0 0 1px 0; margin: 0;"><div style="color: #74777d; background: #eff2f4; padding: 6px 8px; overflow: hidden;"><a style="float: right; text-decoration: none;" href="https://phabricator.kde.org/D23918#inline-135287">View Inline</a><span style="color: #4b4d51; font-weight: bold;">romangg</span> wrote in <span style="color: #4b4d51; font-weight: bold;">utils.h:240</span></div>
<div style="margin: 8px 0; padding: 0 12px; color: #74777D;"><p style="padding: 0; margin: 8px;">For simple data types according to Qt docs resize is faster. It's a micro-optimization, but since the outputs are queried often maybe it's worth it. I assume we could use template specialization for <tt style="background: #ebebeb; font-size: 13px;">AbstractOutput*</tt> as <tt style="background: #ebebeb; font-size: 13px;">To</tt> type, or just use no template at all? Although having a templated qvector_cast is nice.</p></div></div>
<div style="margin: 8px 0; padding: 0 12px;"><p style="padding: 0; margin: 8px;">We could use std::enable_if or std::enable_if_t to specialize pointer types, however I don't think this level of complexity worth the trouble. We want to copy primitive and complex types.</p>

<p style="padding: 0; margin: 8px;">Append method costs only an if statement and an integer increment operation. We can stick with the current solution unless benchmarks show that we need to make concrete assumptions about internal implementation of qvector.</p></div></div></div></div></div><br /><div><strong>REPOSITORY</strong><div><div>R108 KWin</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D23918">https://phabricator.kde.org/D23918</a></div></div><br /><div><strong>To: </strong>zzag, KWin<br /><strong>Cc: </strong>romangg, davidedmundson, alexeymin, kwin, LeGast00n, The-Feren-OS-Dev, sbergeron, jraleigh, fbampaloukas, GB_2, mkulinski, ragreen, jackyalcine, Pitel, iodelay, crozbo, bwowk, ZrenBot, ngraham, himcesjf, lesliezhai, ali-mohamed, hardening, jensreuterberg, abetts, sebas, apol, mart<br /></div>