开发者

Ways to detect whether a C++ virtual function has been redefined in a derived class

开发者 https://www.devze.com 2023-02-05 08:54 出处:网络
In brief: From a C++ base-class pointer which points to an instance of a derived class, how can one determine at run-time whether a non-pure virtual function (with an implementation in the base class)

In brief: From a C++ base-class pointer which points to an instance of a derived class, how can one determine at run-time whether a non-pure virtual function (with an implementation in the base class) has been re-implemented in the derived class?

The context: I am w开发者_C百科riting a C++ library to solve certain classes of mathematical equation. The library provides an Equation class with several virtual functions, which library users use as a base class for the particular equation they wish to solve. The library also provides a Solver class, which takes an Equation * as a constructor parameter. The user then writes code along the lines of:

class MyEquation : public Equation
{ ... } // equation definition here

int main()
{
  MyEquation myEqn;
  Solver solver(&myEqn);
  solver.Solve();
}

If certain combinations of the virtual functions in Equation are not redefined in the derived equation class, certain computationally expensive parts of the algorithm run by the Solver object can be omitted. I would therefore like to know, in the constructor of Solver, which functions have been redefined, and which will instead run the default implementation in Equation.

  • I would like to make this transparent to users of the library so I am not looking for a solution where, for example, the user sets some flags in the constructor of their derived equation specifying which functions have been redefined.

  • One possible solution is for the default implementations of the virtual functions in Equation to set a private flag in the Equation class; the constructor of the Solver class can then clear this flag, run the virtual function, and check the flag value to see whether the implementation in Equation has been called. I would like to avoid this though, because simply setting the flag every time the virtual function is executed slows the algorithm down a good deal (the execution of these virtual functions contributes significantly to the run time of the program, and the default implementations simply return a constant).


You can't check for override of virtual function portably.

You need to bring the knowledge to the Solver, preferably via type as opposed to run-time flag.

One (type-based) way is to check for presence or absence of a interface, via dynamic_cast.

A probably better way is to provide overloads of solve function, in your case the Solver constructor.

Probably better advice could be given if you provided a more concrete description of the problem. It does remind of typical situation where someone (1) needs to solve some problem P, (2) envisions technical approach X as a solution to P, (3) discovers that X doesn't cut it, and (4) asks how to make X work for a vague description of P, or even for some unrelated problem Q. The details of original problem P will often suggest a much better solution than X, and the problems of making X work, irrelevant to solving P.


For future reference, it turns out that GCC provides this extension: http://gcc.gnu.org/onlinedocs/gcc/Bound-member-functions.html which allows checking if a method was overridden with

(void*)(obj.*(&Interface::method)) != (void*)(&Interface::method)

ICC supports this extension officially, clang's docs don't mention it but the code works and even compiles without the warning.

MSVC doesn't support this, though, so there's that.

Also, it appears to not work with methods defined in the header (i.e. inline) in a separate library if you link to a different version of the library where the implementation has changed. If I interpret the standard correctly, this is undefined behaviour (changing the implementation that is) but if the implementation stays the same, then the address should be unique too. So don't do that with inline methods.


After only finding results that link to gcc's PMF extension, I thought there must be a proper way to do so.

I found a solution without any hacks and is at least tested to work on gcc & llvm:

#include <iostream>
#include <typeinfo>

struct A { virtual void Foo() {} };
struct B : public A { void Foo() {} };
struct C : public A { };

int main() {
    std::cout << int(typeid(&A::Foo) == typeid(&A::Foo)) << std::endl;
    std::cout << int(typeid(&A::Foo) == typeid(&B::Foo)) << std::endl;
    std::cout << int(typeid(&A::Foo) == typeid(&C::Foo)) << std::endl;
    return 0;
}

http://ideone.com/xcQOT6

PS: I actually use it in a CEventClient system. So you derive your class from CEventClient and if it overrides an event method it will automatically 'link' the event.


Even though this probably is somehow possible, I would advice not doing it. You are:

  • Violating the OOP principles. If you are given a general class/interface, you should not check for implementation details. This increases dependency between classes and is exactly the opposite of what OOP was designed for.
  • Duplicating code. Considering that you use the constants that would be otherwise returned by the Equation class.
  • Obfuscating code. Many conditions with type checks will make your program look ugly.
  • Probably doing a premature optimization. There is almost no speed difference between executing a virtual function call and a condition. Have you run your profiler to check if it's the virtual functions that are the bottleneck? It is almost never the case in a well designed application/library.


It can't be done the way you're trying. There's no way for the base class's functions to know whether or not a virtual function they implement has been overridden without being explicitly told so.

It would seem you need to go back to the drawing board. Not exactly sure how I'd solve your design issue, but what you're trying now I know simply won't work.


And what if you didn't use virtual methods ?

At this point I am think of a template-base solution. It is possible (albeit not so easy) to use templates to detect whether a given class has a method with a certain signature, or not. Once identified, you can switch, at compile-time, between the lightweight scheme and the heavy scheme.

Note that I do not suggest that all the code be templated, the templated code will only cover the Template (Design Pattern) part of the solution, and the heavy-lifting can be done with regular functions to cut on dependencies.

Also, this can be completely transparent for the clients, providing you do not alter the signature of the methods.


I don't know how to do such detection, but did you consider use of static polymorphism instead? Optimizations can be done at compile-time if every virtual method of Equation is replaced with a template "policy" with default value.

//default implementation of a virtual method turned into a functor
//which optionally takes a reference to equation
class DefaultFunctor1
{
public:
    //...
    double operator()(double x) { return log(x); }
};
template<class F1 = DefaultFunctor1>
class Equation
{
public:
    typedef F1 Functor1;
    //...
private:
    F1 f1;
};
class Solver
{
public:
    //....
    template<class Equation>
    void solve(Equation& eq)
    {
        Loki::Int2Type<
                        Loki::IsSameType<Equation::Functor1, DefaultFunctor1>::value
                       > selector;
        //choose at compile time appropriate implementation among overloads of doSolve
        doSolve(selector);
    }
private:
    //.... overloads of doSolve here
};
int main()
{
    Equation<> eq;
    Solver solver;
    solver.solve(eq); //calls optimized version
    Equation<MyFunctor> my_eq;
    solver.solve(my_eq); //calls generic version
    return 0;
}


Perhaps this helps. It alone doesn't answer your original question, but you can augment your base class (here, Foo) to use a certain interface if it is supplied or use a default method otherwise.

#include <iostream>

struct X {
    virtual void x () = 0;
};

struct Y {
    virtual void y () = 0;
};


struct Foo {
    virtual ~ Foo () {}

    bool does_x () {
        return NULL != dynamic_cast <X*> (this);
    }

    bool does_y () {
        return NULL != dynamic_cast <Y*> (this);
    }

    void do_x () {
        dynamic_cast <X&> (*this) .x ();
    }

    void do_y () {
        dynamic_cast <Y&> (*this) .y ();
    }
};

struct foo_x : public Foo, public X {
    void x () {
        std :: cout << __PRETTY_FUNCTION__ << std :: endl;
    }
};


struct foo_y : public Foo, public Y {
    void y () {
        std :: cout << __PRETTY_FUNCTION__ << std :: endl;
    }
};

struct foo_xy : public Foo, public X, public Y {
    void x () {
        std :: cout << __PRETTY_FUNCTION__ << std :: endl;
    }

    void y () {
        std :: cout << __PRETTY_FUNCTION__ << std :: endl;
    }
};

void test (Foo & f)
{
    std :: cout << &f << " "
        << "{"
        << "X:" << f .does_x () << ", "
        << "Y:" << f .does_y ()
        << "}\n";

    if (f .does_x ())
        f .do_x ();

    if (f .does_y ())
        f .do_y ();
}

int main ()
{
    foo_x x;
    foo_y y;
    foo_xy xy;
    test (x);
    test (y);
    test (xy);
}


What about getting pointer to the base-class function on the first use and compare it with actual one

   class Base { virtual int foo(); }
   class Derived : public Base { virtual int foo(); }

   bool Xxx::checkOverride()
   {
       int (Base::*fpA)();
       int (Base::*fpb)();

       fpA = &Base::foo;
       fpB = &Derived::foo;

       return (fpA != fpB);
   }
0

精彩评论

暂无评论...
验证码 换一张
取 消