如何将模板派生类的方法提取到非模板基类中

Question

I want using polymorphism in C++, I am try to extract method shows in all derived class into base class.

For example:

I have two class, HouseA and HouseB , they are template class. And they are derived from base class BaseHouse .

class BaseHouse
{
public:
    //other thing
private:
};

template <typename Type>
class HouseA : public BaseHouse
{
public:
    HouseA(Type object_input) : object(object_input)
    {
    }
    // other thing about HouseA
    Type &getObject()
    {
        std::cout << "this is House A" << std::endl;
        return object;
    }

private:
    Type object;
};

template <typename Type>
class HouseB : public BaseHouse
{
public:
    HouseB(Type object_input) : object(object_input)
    {
    }
    // other thing about HouseB
    Type &getObject()
    {
        std::cout << "this is House B" << std::endl;
        return object;
    }

private:
    Type object;
};

Bacause of polymorphism, we using base class's pointer to access derivated class object. When I need to call method defined in derivated class, I am always transfer base class pointer into derivated class pointer:

int main()
{
    HouseA<int> house_a(5);
    int x = house_a.getObject();

    BaseHouse *base_ptr = &house_a;

    // suppose after some complicate calculate calculation
    // we only have the base class pointer can access derivated class object

    HouseA<int> *ptr_a = (HouseA<int> *)base_ptr; //transfer base class pointer into derivated class pointer
    ptr_a->getObject();
    return 0;
}

But the derived class HouseA and HouseB both have the method getObject .

So I want to extract template derived class's method into non-template base class.

For some reason, we suppose that the base class BaseHouse can not be template class.

Is there any way I can do that?

Thanks in advance.

Answer 1

If the signature of the derived member depends on the template arguments (as your getObject does on Type) the member cannot be extracted into a non-template base. At least not without removing the ability of the member's signature to vary based on template arguments.

Answer 2

Maybe not exactly a classical Visitor, but...

Okay, the basic idea is we have to somehow capture and encapsulate templated processing into a single entity ready-to-use in a run-time polymorphic construct.

Let's start with a simple class hierarchy:

struct Consumer;

struct Base {
    virtual void giveObject(Consumer const &) const = 0;
    virtual ~Base() = default;
};

struct Derived1: Base {
    Derived1(int x): x(x) {}
    void giveObject(Consumer const &c) const override {
        c(x);
    }
private:
    int x;
};

struct Derived2: Base {
    Derived2(double y): y(y) {}
    void giveObject(Consumer const &c) const override {
        c(y);
    }
private:
    double y;
};

So far, it is very simple: the Base class has a pure virtual method that accepts an object of type Consumer and a concrete implementation of this method is expected to expose to Consumer the relevant part of the internal state of its particular implementor (which is a subtype of Base ). In other words, we have taken that 'virtual template' idiom and hid it inside the Consumer . Ok, what could it possibly be?

First option, if you know in advance at compile-time (at source code-time, more exactly) what it could possibly do, ie there's only one algorithm of consumption per each object type, and the set of types is fixed, it is quite straightforward:

struct Consumer {
    void consume(int x) const { std::cout << x << " is an int.\n"; }
    void consume(double y) const { std::cout << y << " is a double.\n"; }
    template<typename T> void consume(T t) const {
        std::cout << "Default implementation called for an unknown type.\n";
    }
};

etc.

More elaborate implementation would allow run-time construction of a templated entity. How is that even possible?

Alexandrescu in his "Modern C++ Design" uses typeid to store particular type handlers in a single data structure. In a brief, this could be something like:

struct Handler {
    virtual ~Handler() = default; // now it's an empty polymorphic base
};

template<typename T> struct RealHandler: Handler {
    RealHandler(std::function<void(T)> f): f(std::move(f)) {}
    void handle(T x) {
        f(x);
    }
private:
    std::function<void(T)> f;
};

#include <map>
#include <type_info>
#include <functional>

struct Consumer {
    template<typename T> void consume(T t) const {
        auto f{knownHandlers.find(typeid(t))};
        if(f != knownHandlers.end()) {
            RealHandler<T> const &rh{
                dynamic_cast<RealHandler<T> const &>(*f->second)};
            rh.handle(t);
        }
        else {
            // default implementation for unregistered types here
        }
    }
    template<typename T> Consumer &register(std::function<void(T)> f) {
        knownHandlers[typeid(T)] = std::make_unique<RealHandler<T>>(std::move(f));
    }
private:
    std::map<std::type_info, std::unique_ptr<Handler>> knownHandlers;
};

Haven't actually tested it, as I don't like typeids and other RTTI much. What I have quickly tested is another solution that requires neither maps nor typeinfo to store handlers in a templated manner. Still it uses a small trick, like how can we possibly pass, keep and retrieve information of an arbitrary type with the same call.

struct Consumer {
    Consumer() {}
    template<typename T> void consume(T t) const {
        auto f{setSlot<T>()};
        if(f) f(t);
        else {
            // default implementation for an unset slot
            std::cout << t / 2 << '\n';
        }
    }
    template<typename T>
    std::function<void(T)> &setSlot(
            std::function<void(T)> f = std::function<void(T)>{}) const
    {
        static std::function<void(T)> slot;
        if(f) { // setter
            slot = std::move(f);
        }
        return slot;
    }
};

Here, setSlot() is used to store a handler for a particular type: when called with a non-empty argument, it stores that argument; and then returns its currently kept value. With Consumer so defined, the class hierarchy from above works as:

int main() {
    Consumer c;
    c.setSlot<int>([](int x){ std::cout << x << " is an int!\n"; });
    Base const &b1{Derived1{42}};
    Base const &b2{Derived2{3.14}};
    b1.giveObject(c);
    b2.giveObject(c);
}

Output:

42 is an int!
1.57

In the first line we see a message printed by a custom int handler; in the second line, a default message is printed for the double type, as no custom handler for double was installed.

One obvious drawback of this implementation is that handlers are stored in static variables thus all Consumer s share the same handlers for all types, so Consumer here is actually a monostate. At least, you can change implementations for types at run-time, unlike if you had fixed Consumers of the very first approach. The maps-of-typeids approach from above shouldn't have this drawback, in exchange for some performance cost.