What is the proper way to use mix-ins in C++ to fulfill interface contracts?

Question

I apologize in advance for the highly specific example.

Let's say I have an "interface" (purely abstract class) Drawable which requires an implementation of virtual void draw(), as well as virtual float compute_z(). Let's say draw() is supposed to draw some object on the screen, and let's say compute_z() 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).

Let's say I also have a very common implementation of the draw() 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 SpriteMixin.

Let's say I also have a very common implementation of the compute_z() 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 StaticZComputerMixin.

Now let's say I want to create an object called StaticSprite which inherits the Drawable interface and implements the two functions through the two mixins.

Lastly, let's say that I sometimes want to be able to use these mixins without inheriting the entire Drawable interface. That is, it might be useful to be able to render a simple quad texture via a SpriteMixin, but not necessarily have to be able to compute a depth (or vice versa). Yet, at other times, I do want to inherit the whole interface, and in fact implement it via these mix-ins.

I believe have found one 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 always 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 "delegate the implementations to the sister mixin classes", as described here:

class Drawable {
public:
    virtual void draw() = 0;
    virtual float compute_z() = 0;
};

template<typename base>
class SpriteMixin : public virtual base {
private:
    texture t;
public:
    SpriteMixin(texture t) : t(t) {}

    void draw() {
        // Draw t here...
    }
};

template<typename base>
class StaticZComputerMixin : public virtual base {
private:
    float z;
public:
    StaticZComputerMixin(float z) : z(z) {}

    float compute_z() {
        return this->z;
    }
};

class StaticSprite : public SpriteMixin<Drawable>, public StaticZComputerMixin<Drawable> {
public:
    StaticSprite(texture t, float z)
        : SpriteMixin<Drawable>(t), StaticZComputerMixin<Drawable>(z){}
};

Of course, if I wanted to not inherit the entire Drawable interface, I could do some basic additional template magic (like full template specialization) to support that.

I don't believe that there's necessarily something wrong with this. As far as I'm aware, such "sister delegations" are one of the motivating purposes of virtual inheritance. However, I've also heard that virtual inheritance is a "hacky" solution to the diamond problem (and this is essentially the diamond problem).

Is there a more proper solution to this problem?

Edit:

I now realize that I could also reverse the inheritance tree, i.e. I could have a templated SpriteMixin inherit from a templated StaticZComputerMixin which inherits from a StaticSprite which inherits from Drawable. 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 std::vector::emplace()), 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 here (my former solution corresponds to the CRTP-minded solution). However, as Wikipedia states, "a mixin is a class that contains methods for use by other classes without having to be the parent class of those other classes", which suggests that the CRTP solution isn't technically a mixin implementation.

Is there a preferred solution?

Answer 1

I'm not sure if this solves your problem entirely, but how about splitting up Drawable into two separate interfaces, like this?

class IDrawable {
public:
    virtual void draw() = 0;
};

class IComputeZable {
public:
    virtual float compute_z() = 0;
};

class StaticZ : public IComputeZable
{
public:
    StaticZ(float z) : _z(z) {}

    virtual float compute_z() {return _z;}

private:
    const float _z;
};

class SpriteDrawable : public IDrawable {
public:
    SpriteDrawable(texture t) : _t(t) {}

    virtual void draw() {drawTexture(_t);}

private:
    texture _t;
};

class StaticZSpriteDrawable : public StaticZ, public SpriteDrawable
{
public:
   StaticZSpriteDrawable(float z, texture t) : StaticZ(z), SpriteDrawable(t) {}
};

That way any class-type can implement IDrawable/compute_z() or IComputeZable/draw(), or both, as it sees fit.