Store Function Pointers to any Member Function

前端 未结 4 1514
太阳男子
太阳男子 2020-12-30 16:59

My Event Manager

For a event manager I need to store many pointers to functions in a vector to call them when the event is triggered. (I will provide the source co

相关标签:
4条回答
  • 2020-12-30 17:07

    You can use functors to achieve this. If you wrap a functor around your member functions you can make a vector out of functors. A functor looks like this:

    template <class T> class MyFunctor
    {
    private:
        T* ObjectPtr;
        void (T::*MemberFunction) ();
    public:
        void operator () ()
        {
            return (*this->ObjectPtr.*this->MemberFunction)();
        }
    };
    

    So basically a functor overrides the () operator and returns the member function stored in the functor class. Functors can be quite complex if you want them to work with different signatures but in this article you can get further information.

    http://www.codeproject.com/Articles/7112/Pointers-to-Member-Functions-and-Functors

    0 讨论(0)
  • 2020-12-30 17:09

    Not a direct response, so bear with me.

    Before we start: This is generally referred to as the Observer pattern, you might find lots of confused information on the web about it, and many failed implementations, but who knows you might also strike gold.

    Okay, so first the question has a fundamental flaw: it fails to consider that capturing object references is tricky, because object lifetimes are bounded.

    Therefore, even before we delve into the specifics of an implementation we need to ask ourselves how to handle stale references. There are two basic strategies:

    1. Not having stale references, this implies that registered objects unregister themselves automatically upon destruction. The mechanism can be factored out in a base class.

    2. Having a way to tell good and stale references apart when inspecting them, and lazily collecting the stale ones. The mechanism can be enforced using a shared_ptr/weak_ptr pair and realizing that weak_ptr are observers of the shared_ptr.

    Both solutions are viable and neither implementation is perfect. The base class mechanism assumes you can actually modify your class hierarchy while the weak_ptr trick assumes that all observes will be heap-allocated and their lifetime controlled by a weak_ptr.

    I will make an example using shared_ptr (and make use of a number of C++11 facilities, though none is mandatory here):

    class EventManager {
        typedef std::unique_ptr<Observer> OPtr;
        typedef std::vector<OPtr> Observers;
    public:
    
        // Callback observers of "name"
        // Returns the number of observers so invoked
        size_t signal(std::string const& name) const {
            auto const it = _observers.find(name);
            if (it == _observers.end()) { return 0; }
    
            Observers& obs = it->second;
    
            size_t count = 0;
            auto invoker = [&count](OPtr const& p) -> bool {
                bool const invoked = p->invoke();
                count += invoked;
                return not invoked; // if not invoked, remove it!
            };
    
            obs.erase(std::remove_if(obs.begin(), obs.end(), invoker), obs.end());
    
            if (obs.empty()) { _observers.erase(it); }
    
            return count;
        }
    
        // Registers a function callback on event "name"
        void register(std::string const& name, void (*f)()) {
            _observers[name].push_back(OPtr(new ObserverFunc(f)));
        }
    
        // Registers an object callback on event "name"
        template <typename T>
        void register(std::string const& name, std::shared_ptr<T> const& p, void (T::*f)()) {
            _observers[name].push_back(OPtr(new ObserverMember<T>(p, f)));
        }
    
    
    private:
        struct Observer { virtual ~Observer() {} virtual bool invoke() = 0; };
    
        struct ObserverFunc: Observer {
            ObserverFunc(void (*f)()): _f(f) {}
    
            virtual bool invoke() override { _f(); return true; }
    
            void (*_f)();
        };
    
        template <typename T>
        struct ObserverMember: Observer {
            ObserverT(std::weak_ptr<T> p, void (T::*f)()): _p(p), _f(f) {}
    
            virtual bool invoke() override {
                std::shared_ptr<T> p = _p.lock();
                if (not p) { return false; }
    
                p->*_f();
                return true;
            }
    
            std::weak_ptr<T> _p;
            void (T::*_f)();
        };
    
        // mutable because we remove observers lazily
        mutable std::unordered_map<std::string, Observers> _observers;
    }; // class EventManager
    
    0 讨论(0)
  • 2020-12-30 17:22

    You will have to use std::function. This is the only way to achieve a generic callback. As soon as you involve function pointers instead of function objects, it is not generic, will never be generic, and can never be made to be generic.

    unordered_map<string, vector<std::function<void()>>>
    

    Function pointers are bad and should never be explicitly used in C++, only passed to templates like std::bind and std::function's constructor, and member function pointers are even worse.

    0 讨论(0)
  • 2020-12-30 17:22

    This is the typical case where you should use polymorphism instead of function (or member function) pointers.

    As you noted, your component classes should inherit from a common class Component, which contains virtual method(s) representing the event(s):

    class Component
    {
    public:
        virtual void OnPlayerLevelUp()
        {
        }
    };
    
    class ComponentSound : public Component
    {
    public:
         // override it
        void OnPlayerLevelUp()
        {
            // do the actual work
        }
    };
    

    Your ListEvent type will now look like this:

    typedef unordered_map<EventKey, vector<Component*>> ListEvent;
    

    As for the optional void* paramenter in event methods, you can specify it as an optional parameter, but the fact that it's a void* is a bad sign (use of void* can lead to loss of type safety), so I would suggest that you look for a different way to achieve what you want.

    0 讨论(0)
提交回复
热议问题