Does static polymorphism make sense for implementing an interface?

孤者浪人 提交于 2019-11-29 10:52:21

Checking Interface.

Dynamic polymorphism does force the child to respect the interface.

Static polymorphism does NOT force the child to respect the interface (until you really call the function), So, if you don't provide useful method, you may use directly Impl.

class InvalidImpl {}; // Doesn't respect interface.
void bar()
{
    InvalidImpl invalid;

    // this compiles, as not "expected" since InvalidImpl doesn't respect Interface.
    CRTP_Interface<InvalidImpl> crtp_invalid; 

#if 0 // Any lines of following compile as expected.
    invalid.Foo();
    crtp_invalid.Foo();
#endif
}

You have a 3rd way using traits to check that a class verify an Interface:

#include <cstdint>
#include <type_traits>

// Helper macro to create traits class to know if class has a member method
#define HAS_MEM_FUNC(name, Prototype, func)                             \
    template<typename U>                                                \
    struct name {                                                       \
        typedef std::uint8_t yes;                                       \
        typedef std::uint16_t no;                                       \
        template <typename T, T> struct type_check;                     \
        template <typename T = U>                                       \
        static yes &chk(type_check<Prototype, &T::func> *);             \
        template <typename > static no &chk(...);                       \
        static constexpr bool value = sizeof(chk<U>(0)) == sizeof(yes); \
    }

// Create traits has_Foo.
HAS_MEM_FUNC(has_Foo, void (T::*)(), Foo);

// Aggregate all requirements for Interface
template <typename T>
struct check_Interface :
    std::integral_constant<bool, has_Foo<T>::value /* && has_otherMethod<T>::value */>
{};

// Helper macros to assert if class does respect interface or not.
#define CHECK_INTERFACE(T) static_assert(check_Interface<T>::value, #T " doesn't respect the interface")
#define CHECK_NOT_INTERFACE(T) static_assert(!check_Interface<T>::value, #T " does respect the interface")

Lets test it:

class Interface {
public:
    virtual void Foo() = 0;
};

class Child_Impl final : public Interface {
public:
    void Foo() override {};
};

#if 0 // Following doesn't compile as expected.
class Child_InvalidImpl final : public Interface {};
#endif

template <class I>
class CRTP_Interface : public I
{
public:
    void Foo() { I::Foo(); } // not actually needed
};

class Impl { public: void Foo(); }; // Do respect interface.
class InvalidImpl {};               // Doesn't respect interface.

CHECK_INTERFACE(Interface);
CHECK_INTERFACE(Child_Impl);
CHECK_INTERFACE(Impl);
CHECK_INTERFACE(CRTP_Interface<Impl>);

CHECK_NOT_INTERFACE(InvalidImpl);
CHECK_INTERFACE(CRTP_Interface<InvalidImpl>); // CRTP_Interface<T> _HAS_ Foo (which cannot be invoked)

Performance

With Dynamic Polymorphism, you may pay for virtual call. You may reduce some virtual call by adding final as class Child final : public Interface.

So compiler may optimize code like:

void bar(Child& child) { child.Foo(); } // may call Child::Foo not virtually.

but it can't do any magic (assuming bar not inlined) with:

void bar(Interface& child) { child.Foo(); } // have to virtual call Foo.

Now, assume that in your interface you have:

void Interface::Bar() { /* some code */ Foo(); }

we are in the second case where we have to virtual call Foo.

Static polymorphism solves that by:

template<class Derived>
void Interface<Derived>::Bar() { /* some code */ static_cast<Derived*>(this)->Foo(); }

Whether it makes sense to use static polymorphism depends on how you use the class.

Virtual functions introduce a level of indirection. Virtual functions allow calling a method in the derived class using a pointer or reference to an object of the base class (which is common to all derived classes).

Static polimorphism does not use a common base class. Each derived class uses it's own base class. These base classes are often created from a common class template. Nevertheless, they are different classes. This leads to such things that e.g. pointers or references to such objects cannot be stored in a common container.

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!