title: What is the proper way to use mix-ins in C++ to fulfill interface contracts?
body: <p>I apologize in advance for the highly specific example.</p>
  <p>Let's say I have an &quot;interface&quot; (purely abstract class) <code>Drawable</code> which requires an implementation of <code>virtual void draw()</code>, as well as <code>virtual float compute_z()</code>. Let's say <code>draw()</code> is supposed to draw some object on the screen, and let's say <code>compute_z()</code> is supposed to return a depth for the purposes of allowing a rendering engine to order draw commands (e.g. for early z rejection / reducing overdraw).</p>
  <p>Let's say I also have a very common implementation of the <code>draw()</code> function, which is simply to store a texture and draw a quad on the screen, mapping the quad's vertices to the texture's vertices, and let's say I expose that common implementation through a mix-in class called <code>SpriteMixin</code>.</p>
  <p>Let's say I also have a very common implementation of the <code>compute_z()</code> function which simply returns some static value (static in the sense that it does not change, rather than in one of the many other senses of the term), and I expose it through a mix-in class called <code>StaticZComputerMixin</code>.</p>
  <p>Now let's say I want to create an object called <code>StaticSprite</code> which inherits the <code>Drawable</code> interface and implements the two functions through the two mixins.</p>
  <p>Lastly, let's say that I <em>sometimes</em> want to be able to use these mixins <em>without</em> inheriting the entire <code>Drawable</code> interface. That is, it might be useful to be able to render a simple quad texture via a <code>SpriteMixin</code>, but not necessarily have to be able to compute a depth (or vice versa). Yet, at <em>other</em> times, I <em>do</em> want to inherit the whole interface, and in fact implement it via these mix-ins.</p>
  <p>I believe have found <em>one</em> relatively simple solution. In particular, I believe that in order to use these mix-ins to fulfill the interface, they must inherit from the interface. However, since I don't <em>always</em> want to inherit from the interface, I have to use a little bit of template trickery. I am hesitant though; since there are two mixins, I have to use multiple virtual inheritance to &quot;delegate the implementations to the sister mixin classes&quot;, as described <a href="https://isocpp.org/wiki/faq/multiple-inheritance#mi-delegate-to-sister" rel="nofollow noreferrer">here</a>:</p>
  <pre><code>class Drawable {
  public:
      virtual void draw() = 0;
      virtual float compute_z() = 0;
  };
  
  template&lt;typename base&gt;
  class SpriteMixin : public virtual base {
  private:
      texture t;
  public:
      SpriteMixin(texture t) : t(t) {}
  
      void draw() {
          // Draw t here...
      }
  };
  
  template&lt;typename base&gt;
  class StaticZComputerMixin : public virtual base {
  private:
      float z;
  public:
      StaticZComputerMixin(float z) : z(z) {}
  
      float compute_z() {
          return this-&gt;z;
      }
  };
  
  class StaticSprite : public SpriteMixin&lt;Drawable&gt;, public StaticZComputerMixin&lt;Drawable&gt; {
  public:
      StaticSprite(texture t, float z)
          : SpriteMixin&lt;Drawable&gt;(t), StaticZComputerMixin&lt;Drawable&gt;(z){}
  };
  </code></pre>
  <p>Of course, if I wanted to <em>not</em> inherit the entire <code>Drawable</code> interface, I could do some basic additional template magic (like full template specialization) to support that.</p>
  <p>I don't believe that there's necessarily something <em>wrong</em> with this. As far as I'm aware, such &quot;sister delegations&quot; are one of the motivating purposes of virtual inheritance. However, I've also heard that virtual inheritance is a &quot;hacky&quot; solution to the diamond problem (and this is essentially the diamond problem).</p>
  <p>Is there a more proper solution to this problem?</p>
  <p><strong>Edit:</strong></p>
  <p>I now realize that I could also reverse the inheritance tree, i.e. I could have a templated <code>SpriteMixin</code> inherit from a templated <code>StaticZComputerMixin</code> which inherits from a <code>StaticSprite</code> which inherits from <code>Drawable</code>. However, this would require something like variadic expansion of template parameters to properly pass all of the constructor arguments up the hierarchy (sort of like <code>std::vector::emplace()</code>), since in this case you would have to be able to specify the parents of the mix-ins in a templated way, and those parents might have constructor parameters. From my understanding, these are the two most common mixin implementations in c++, as described <a href="https://www.fluentcpp.com/2017/12/12/mixin-classes-yang-crtp/" rel="nofollow noreferrer">here</a> (my former solution corresponds to the CRTP-minded solution). However, as Wikipedia states, &quot;a mixin is a class that contains methods for use by other classes without having to be the parent class of those other classes&quot;, which suggests that the CRTP solution isn't <em>technically</em> a mixin implementation.</p>
  <p>Is there a preferred solution?</p>