Non-Virtual Polymorphism in C++

Question

I have developed the following code in an attempt to implement non-virtual polymorphism:

#include <functional>
#include <iostream>
namespace{
    using std::function;
    class base {
    protected:
        using signiture =void(void);
        using func_t = function<signiture>;
        ~base(){}
    public:
        func_t bar;//std::function object to a function of type "signature"
    };
}
template <typename implementation>
class foo:public base {
public:
    foo(implementation* instance){
        bar = func_t(std::bind(&implementation::bar_implementation,instance));
//binds a function of name "bar_implementation" from class implementation to the std::function object
//binds to object "instance"
    }
};
typedef base foo_base;

class testcase:public foo<testcase> {
public:
    friend class foo;//allows implementations to be protected or private
    testcase():foo(this){}//sends instance to the constructor of the base class in order to enable binding
protected:
    void bar_implementation(void){
        std::cout<<"Hello"<<std::endl;
    }
};
class testcase2:public foo<testcase2> {
public:
    friend class foo;//allows implementations to be protected or private
    testcase2():foo(this){}
protected:
    void bar_implementation(void){
        std::cout<<"World!"<<std::endl;
    }
};


int main(int argc, const char * argv[]) {
    testcase t;
    testcase2 t2;

    foo_base* b = &t;
    foo_base* b2 = &t2;
    b->bar();
    b2->bar();
    return 0;
}

In reality this code is spread out over a few files...

I would like to know if anything in my code can be considered bad-practice,undefined behavior or otherwise undesirable in some manor? A Live Example

Any thoughts on this pattern as a replacement for virtual inheritance and the design are appreciated.

Let me know if i can clarify anything.

EDIT: I am asking this question as an attempt to determine if there are any reasons why a design like this would be a suitable way to implement non virtual polymorphism and if it is not, why is that?

Answer 1

Your code is an interesting approach. It's a nice proof of concept but it has a major flaw: it doesn't manage inheritance consistently !

The problem : class inheritance

Suppose I want to create a class testcase22 which inherits from testcase2, but has its own implementation of bar().

Alternative 1: if I define it naively by inheriting from testcase2, it will use the bar_implementation of testcase2:

    class testcase22:public testcase2  {
    public:
        testcase22() {}   // naive contructor
    protected:
        void bar_implementation(void){    // will not be used
            std::cout<<"Great!"<<std::endl;
        }
    };

Alternative 2: If I try to use your constructor pattern, it won't work because of a compiling error. Because the type deduction will use foo<testcase2>, which is not a direct base class of testcase22 and can hence not be used in the mem-initializer list:

    class testcase22:public testcase2  {
    public:
        friend class foo;//allows implementations to be protected or private
        testcase22():foo(this){}   // !!!!! causes compile error
    protected:
        void bar_implementation(void){
            std::cout<<"Great!"<<std::endl;
        }
    };

Alternative 3: if I'd use foo explicitly, it would not work because foo os not either a valid base type initializer.

Alternative 4: if I'd try to use multiple inheritance, I'd be confronted to ambiguous base class

    class testcase22:public testcase2, public foo<testcase22> {
    public:
        friend class foo;//allows implementations to be protected or private
        testcase22():foo(this){}
    protected:
        void bar_implementation(void){
            std::cout<<"Great!"<<std::endl;
        }
    };

This could be solved by defining foo inheriting virtually from base:

    class foo:public virtual base { ... };

Then it would compile, but it still would use the bar_implementation of testcase2 instead of that from testcase22. By the way, even if it would have worked, the virtual base would prevent possibility of using multiple inheritance with your class family.

Conclusion

Your nice construct works, but only with a single level of simple inheritance.

This is a major constraint. Especially when considering that the benefit of polymorphism is to manage natural hierarchies making best use of the inheritance relationships.

Your pattern is also relatively complex to use in comparison with easy to use virtual functions. What will your code look like with several polymorphic functions, some of them even overloaded ?

The goals you intend to achieve with your pattern is not clear, but honestly, I wouldn't go for this approach for real life projects that have to be maintained over several years. But this is my own subjective opinion of course.