<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 #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/D23918#531302" style="background-color: #e7e7e7;
          border-color: #e7e7e7;
          border-radius: 3px;
          padding: 0 4px;
          font-weight: bold;
          color: black;text-decoration: none;">D23918#531302</a>, <a href="https://phabricator.kde.org/p/gladhorn/" style="
              border-color: #f1f7ff;
              color: #19558d;
              background-color: #f1f7ff;
                border: 1px solid transparent;
                border-radius: 3px;
                font-weight: bold;
                padding: 0 4px;">@gladhorn</a> wrote:</div>
<div style="margin: 0;
          padding: 0;
          border: 0;
          color: rgb(107, 116, 140);"><p>How would it be to only keep one vector of AbstractOutputs in Platform? Then there is no vector copying. A cast should in my opinion not be a memory intense operation in the first place, but just a change of how types are interpreted.<br />
 In the sub-classes the outputs could then actually be cast as needed (in a convenience function, in case it's more than one or two places). Hopefully this would also reduce code duplication. Of course it only works if there is only one platform in use at a time (I assume that is the case right now already).</p></div>
</blockquote>

<p>Hmm, that might one way to go. Its biggest disadvantage is that we'll have to put a few static_casts here and there as well that Platform would need to have some protected methods to alter private m_outputs field.</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>Going one step further, for the public side of things, I'd prefer to use Output as name, instead of AbstractOutput. That there is a platform specific implementation should not matter for the consumer of the public API.</p></blockquote>

<p>I think Roman just wanted AbstractOutput to be in line with AbstractClient. However, I agree that it's better to drop "Abstract" prefix.</p></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>gladhorn, anthonyfieroni, 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>