Inheritance-free polymorphism

Question

The X: I have a collection of unrelated container-like objects (vector, maps, trees,...) handling objects of different unrelated types. The lifetime of the objects in these containers is shared between some subsets of them. I have an object in charge of their synchronization. The simplest implementation of a synchronization class that I can think of would be to have a vector of BaseContainerLike pointers, where BaseContainerLike would be a class implementing a common interface for all of the container-like objects that I want to manage. But not all of them are container like. They could be used as container like, but making them inherit from a common base class feels very weird and I'm scared that it will couple my design very strongly.

So I've created a ContainerLikeInterface class like this:

struct ContainerLikeInterface {
template<T>
ContainerLikeInterface(T& t) 
 : create([](int i){ return t->create(i); }),    // this is just an example
   delete([](int i){ return t->delete(i); }) {}

std::function<void(int)> create;
std::function<void(int)> delete;
};

template<class T>
ContainerLikeInterface make_containerLikeInterface(T& t) {
  return ContainerLikeInterface(t);
}

This allows me to trivially create a vector of interfaces in a non-intrusive way (I can just partially specialize the constructor for different types). My code using this approach is slightly faster than when using inheritance, but it requires slightly more memory and longer compile times (but I don't prioritize compile times). I don't know however if this approach will scale well with my project. And I've read some articles about value-semantics in which people prefer to transfer the object ownership to the interface, so I have the following questions:

• What are the pros/cons of this approach?
• Is this going to give me some problems in the long term?
• Should I use inheritance instead?
• Should I implement this in a different way?
• Should I use a library instead? (boost::TypeErasure, adobe::poly, or pyrtsa/poly)

Answer 1

Your interface slightly resembles the interface system that is made in Rust object system. Classic VMT-based interfaces have a pointer to an object which holds a pointer to a VMT. Yours have 2 pointers: one to an object and another to a method table. It [almost] always looks to have more power than virtual functions with disadvantages you already mentioned (memory usage etc.) As for the speed, std::function uses standard allocator to keep a pointer to t. If you call ContainerLikeInterface constructor a lot, it may cause some perfomance decrease because it needs at least one allocation per std::function in your interface and you could write your own for this.

Answer 2

Your basic idea (do not require inheritance) is good. I would recommend using Adobe.Poly instead. When you use 1 std::function per single operation you have N sort-of virtual table (pointers), plus potentially N heap allocations (depending if SBO (Small Buffer Optimization) can be applied or not).

You are also very likely to get into object life-time management problems. In your implementation you assume that the real object lives longer than the "interface". Sooner or later you will get it wrong. This is why I would encourage a value-semantic approach. Adobe.Poly gives you that.

With Adobe.Poly you only get one vtable (pointer). It also implements SBO: potentially not a single allocation.

I would not necessarily go with Boost.TypeErasure. It requires learning another "language" for specifying interfaces, which exploits lots of meta programming, and as of today it does not implement SBO.

Adobe.Poly is not well documented. See this post for examples of how you use it. Also, see this paper on how it is implemented.

Answer 3

You are essentially creating a proxy object with ContainerLikeInterface interface with a pointer or reference to some T.

There is a way to avoid creating the proxy, while still using the standard containers which can not derive ContainerLikeInterface. It is probably called Mix-in design patter and with perfect forwarding in C++11 it would look like:

#include <vector>

struct IContainerLikeInterface
{
    virtual void create(int) = 0;
    virtual void erase(int) = 0;
};

template<class T>
struct ContainerLikeInterface : T, IContainerLikeInterface
{
    template<class... Args>
    ContainerLikeInterface(Args&& ...args) 
        : T(std::forward<Args>(args)...)
    {}

    // implement IContainerLikeInterface
    void create(int) override;
    void erase(int) override;
};

int main() {
    ContainerLikeInterface<std::vector<int> > v(10);
    v.size();
}

However, it is intrusive because all declarations of containers in question, like std::vector<int>, have to be changed into ContainerLikeInterface<std::vector<int> >. The usage stays the same though, because ContainerLikeInterface<T> is-a T.