I am stuck at C++ 98
I have written a basic event system in C++, similar to how things are done in scripting languages.
Events/callbacks are stored in a map
std::hash_map<uint32_t, std::vector<EVENTHANDLER> >
API example
ES es;
es.On("MyEvent", MyCallback);
Event event(1,2,3);
es.Emit("MyEvent", event);
es.Off("MyEvent", MyCallback);
I want to implement the typical One method, where after the callback is executed, it is then removed so that it only ever fires once. In JS this is easy, you can wrap the callback in an anonymous function
one(event, cb){
this.on(event, (e) => {
cb(e);
this.off(event, cb);
});
}
But I cannot use lambda in C++ 98. Is there any other trivial way to do this? I thought maybe if a callback registers with "one" it can be put into a vector of "one" callbacks that must be iterated each time an event is emitted, but that is a backup solution.
There doesn't seem to be any reason your ES can't do this.
Add the capability to call es.Once("MyEvent", MyCallback);
Have this and es.On set a boolean flag inside wherever you're storing these things, bool once
After running a task, if task.once, just do Off(TheEventImRunning, TheCallbackItUses).
So it's the logic you proposed, but without using a lambda. Just write it normally in your functions, with a boolean stored somewhere to decide whether or not the extra logic needs to be run.
Alternatively, you could consider binding MyCallback to some wrapper that additionally does the Off() call. If MyCallback is just a function pointer or a std::function then this is probably quite easy. But we cannot give concrete examples without knowing more about your code.
Related
In a project that we intended to write in C++, we use a C-library. This C library provides functions to register callbacks, that are called on each interrupt. We register our callbacks inside the constructor.
So we basically have the following (simplified) structure:
OurClass::OurClass() {
//the registerISRCallback is the C function, that accepts as first parameter the pin,
//the interrupt is expected on and as second parameter a function pointer:
//void (*callbackFunction)(int number, int time)
registerISRCallback(SCLK, handle_interrupt);
}
void OurClass::handle_interrupt(int pin, int time) {
//example: Blink a Led on the instance-LedPin
}
the problem however is twofold:
because it is a member function, the handle_interrupt method has the signature void (OurClass::*)(int, int). Therefore it is not possible to use it like this.
this class can be instantiated multiple times, so using a singleton would also not work, because our callback may differ per instance (each instance could for example have a different LedPin.
are there any more solutions to use this C API function inside our class and keep the code clean and readable?
Your class may integrate a static method that you pass as a C callback function (provided the calling conventions are made compatible; if not possible, wrap it in a pure C call).
In addition, let your class keep a static table of the created instances, in correspondence to the pins. When a callback is invoked, by knowing the pin, you will know which instance to activate.
Create a C-style API (C outside, C++ inside), which itself registers as a single callback and allows to register multiple C++ callbacks. That would require some list-handling.
When the interrupt occurs, call all of them and let them decide whether they need to react, according to the callback parameters.
Alternatively, see the more luxurious proposal (mapping pin to one of multiple callbacks) in the comment by Story Teller, which basically does the detection of which callback is needed centrally.
I am trying to create a function in Objective-C for monitoring a pointer declared on my C/C++ side of code by using KVO. Is there a way to do this?
To elaborate. I have a C object pointer. I pass that pointer as void* through my bridge function down to Objective-C side of the code.
Is it possible to use the pass-down void* to set up KVO and notify via:
-(void)observeValueForKeyPath:(NSString *) keyPath of Object:...
when the C object pointer is modified by C side of code?
KVO, with its ability to just observe a property and automatically get notifications every time it changes, seems like magic, but really all it is is Apple automatically changing your property's setter from this:
- (void)setFoo:(Foo *)newFoo {
self.foo = newFoo;
}
into this:
- (void)setFoo:(Foo *)newFoo {
[self willChangeValueForKey:#"foo"];
self.foo = newFoo;
[self didChangeValueForKey:#"foo"];
}
The will and didChangeValueForKey: methods are what cause the KVO system to check for observers for the property, and notify them if there are any. The automatic substitution of the setter is done by taking advantage of the extremely dynamic nature of Objective-C, which makes it relatively simple to patch methods and alter them at runtime (this is, incidentally, why the dynamic keyword is needed to implement KVO properties in Swift). Of course, these dynamic features do not exist in C or C++.
What you will need to do, then, is to have your C code define two callbacks; one which the C code will call before changing the value, and another which it will call afterwards. Once you've got this set up, have the Objective-C side register these callbacks somewhere in your setup process, and have the callbacks call the willChangeValueForKey: and didChangeValueForKey: methods. Once you've done this, you should be able to observe the property using the normal KVO methods.
I'm working on a piece of software that is constructed from a series of "modules". Modules can be connected together to form the full application (one module might go to another, sort of an implied state machine). Each module can render to the screen, get updates and access state from other modules. Note that the modules are still within the same process, so no IPC needs to be designed into this.
However, these modules do not directly depend on each other. There is a singleton object that has the sole purpose of managing message passing between the modules. When you want to register for an event from any module:
CPostMaster::Instance().RegisterEvent("TheEventName", [](std::string const& data) { /* the callback */ });
The data variable is serialized data. Can be anything, but usually is XML or JSON. To send the event you do:
std::string serialized_data = /* serialized data, do this before calling */;
CPostMaster::Instance().SendEvent("TheEventName", serialized_data);
The 2nd parameter is optional.
Having a "master authority" for message passing has a drawback: The events themselves can't send varying parameters without utilizing some sort of serialization or type erasure (removes type safety from the picture and impacts performance).
But it also has the benefit of strict/strong coupling not being required, which means that at any given time a different module can be responsible for sending a specific event without the receiving modules having to change.
The alternative seems to be not using a singleton, and instead each module receives an object that it can use to subscribe to. This could get messy especially when you are passing them around everywhere, it will quickly mean that functions start taking boilerplate parameters.
What is a good design for message passing in a system such as this? How can it be improved and be made manageable? Type safety and open/close principles are important here. I think it's OK to have direct dependencies across modules so long as they can be mocked (for unit testing) and easily swapped out should modules change without severely impacting the whole system (but this is part of the open/close principle).
First: I dislike singletons. The only singleton I accept is a singleton manager (some sort of central instance distributor) that handles a defined init and deinit of all "singletons" in a defined order.
But back to your problem:
Your title already has the solution: Define a message interface. If you want type-safety define an IMessage with common attributes.
Then define specializations of IMessage which then are consumed by your callbacks.
The tricky part is: You will need RTTI for that, which is odd in c++, I know but might be worth the benefits, if you are restricted to gcc or visual studio, you could make use of those types, or implement some simple RTTI in the IMessage itself to avoid dynamic_cast.
To avoid boilerplate code in a callback which checks and casts around the IMessage I would provide a utility function (pseudo code, adjust for pointers, references, smart ptrs, const correctness etc.)
T SafeCast<T>(IMessage message);
depending on the implementation of your compiler you should add restrictions to T to be of a sub type of IMessage and what should happen when the cast fails (exception, nullptr, etc).
Alternatively: Check how others have solved this (maybe Qt's Signals&Slots or something in Boost)
I would make the sub modules dependent on a parent class (in your case the singleton). Then you could pass this object's reference along the line, to be used in the modules.
Module(Handler& h) : _h(h) { }
void do_stuff(){
_h.RegisterEvent("TheEventName", [](std::string const& data)
{ /* the callback */ })
Then I would register your Module class itself, or another class, as an Event, and on the Handler side, I would formalize the messaging in a way that you'd get multiple callbacks instead of just one. You'd have to formalize your message though, but you'd have type safety instead of passing strings.
For example the handler, while parsing a message, he'd call:
_callback.start(); //signals the start of a message
_callback.signalParam1(1); //calls Module.signalParam(int);
_callback.signalParam2("test"); //calls Module.signalParam2(const char*);
_callback.end();
Your Module would need to implement those.
I am entering a realm that is new to me, but basically I need to implement callbacks in C++. I am designing a toolkit for myself to use to simplify my life. Basically it is a .dll plugin that will be exposing a lot of functions to my other .dll plugins.
One of these functions is HookEvent(const char *event_name, void *callback) which will allow me to hook different events that get fired. Here would be an example...
Example_Plugin1.dll does HookEvent("player_spawn", &Plugin1::Event_PlayerSpawn);
Example_Plugin2.dll does HookEvent("player_spawn", &Plugin2::Event_PlayerSpawn);
I need to figure out the best (and preferably easiest) method of setting up a callbacks system that will work well for this. I have been reading up on C++ callbacks for a few hours now, and found quite a few different approaches.
I assume the easiest thing to do would be make a template, and use typedef bool (ClassName::*EventHookCallback)(IGameEvent, bool); After that, I am a bit foggy.
I also read that Delegates or a .NET style events system are other possible approaches. I am already somewhat confused, so I don't want to confuse myself more, but figured it was worth asking.
Here is a link to the C++ .NET style events system I was reading about.
http://cratonica.wordpress.com/2010/02/19/implementing-c-net-events-in-c/
So what do you guys suggest? Any tips as far as implementing it would be most appreciated.
If you want generalized event firing Boost.Signals2 might be applicable.
The Boost.Signals2 library is an
implementation of a managed signals
and slots system. Signals represent
callbacks with multiple targets, and
are also called publishers or events
in similar systems. Signals are
connected to some set of slots, which
are callback receivers (also called
event targets or subscribers), which
are called when the signal is
"emitted."
Even if you don't need this level of flexibility you should be able to simplify the function binding in your code using Boost.Bind, or the C++0x equivalents.
EDIT:
There's an excellent discussion from Herb Sutter of the issues you could face here. You could use this for guidance if you decide you don't need the full Boost feature set, and so roll your own.
How about using Qt Signal and Slot? It does what callbacks do but without the messiness of making anything not part of your callback parameters global.
Boost.Signals would be my choice, combined with things like boost::bind and Boost.Function.
I would use an abstract base class as a plugin interface. (And in fact, I have used a pattern like the one below before.)
Library, PluginIfc.h:
class PluginIfc {
public:
virtual ~PluginIfc() = 0;
virtual bool EventCallback(const char* event_name, IGameEvent, bool) = 0;
};
// For Windows, add dllexport/dllimport magic to this declaration.
// This is the only symbol you will look up from the plugin and invoke.
extern "C" PluginIfc* GetPlugin();
Plugin:
#include <PluginIfc.h>
class Plugin1 : public PluginIfc {
public:
virtual bool EventCallback(const char* event_name, IGameEvent, bool);
Plugin1& get() { return the_plugin_obj; }
bool Event_PlayerSpawn(IGameEvent, bool);
// ...
private:
std::vector<std::string> _some_member;
static Plugin1 the_plugin_obj; // constructed when plugin loaded
};
Plugin1 Plugin1::the_plugin_obj;
PluginIfc* GetPlugin() { return &Plugin1::get(); }
This way, your plugin classes can easily have members, and C++'s virtual call mechanism takes care of giving you a good this pointer in EventCallback.
It may be tempting to make a virtual method per event type, say just make Event_PlayerSpawn and similar methods virtual. But then whenever you want to add an event type, if this means changing class PluginIfc, your old compiled plugins are no longer compatible. So it's safer to use a string event identifier (for extensibility) and have the main callback sort events off to more specific methods.
The major drawback here (as compared to a signal-slot type implementation) is that all callbacks must take the same set of arguments. But your question sounded like that would be adequate. And it's often possible to work within that limitation by making sure the set of arguments is very flexible, using strings to be parsed or Any-style objects.
Sounds like you might be interested in how to build your own plugin framework. The problems you'll encounter are likely the same. Have a look at this nice Dr Dobbs article Building Your Own Plugin Framework.
Hope this helps!
Implementing your own callback system is non-trivial.
My understanding is that your aim is to map event types to specific callback functions.
E.g. if "player_spawn" event is risen the &Plugin1::Event_PlayerSpawn will be called.
So what you should do is the following:
1) Define all the events of interest. Make them as generic as possible. They can
encapsulate any information you need
2) Create a Registrar. I.e. a class that all modules register their interest for specific
methods. E.g. Registrar.register(player_spawn,this,Event_PlayerSpawn);
3) Registrar has a queue of all subscribers.
4) You can also have a uniform interface for the modules. I.e. all module implement a specific function but based on event's data can do different things
5) When an event occurs, all the subscribers interested for the specific event get notified by calling the appropriate function
6)Subscriber can de-register when ever is need
Hope this helps.
What is mean by delegates in c++, does sort function in c/c++ which takes a compare function/functor as last parameter is a form of delegate?
"delegate" is not really a part of the C++ terminology. In C# it's something like a glorified function pointer which can store the address of an object as well to invoke member functions. You can certainly write something like this in C++ as a small library feature. Or even more generic: Combine boost::bind<> with boost::function<>.
In C++ we use the term "function object". A function object is anything (including function pointers) that is "callable" via the function call operator().
std::sort takes a "predicate" which is a special function object that doesn't modify its arguments and returns a boolean value.
Callback functions in C++ can be (loosely) referred as a form of delegates ( though delegate term is not used for this). The callback functions use Pointers to Functions to pass them as parameters to other functions.
But delegates in C# is more advanced compared to callback functions in C++.
To delegate work means to share the work load with others. In real life, if you were to delegate your task, ie if you are a manager, you would be sharing your work expecting others to complete a task without you having to know how.
The concept is the same in C++ and any other languages having the capability of delegates. In C you could see this as a delegate:
int calculate(int (*func)(int c), int a, int b)
Because you are expected to send a pointer, to another function which will compute some work for you. I recently wrote a blog post on function pointers in Python and C, check it out, you might find it helpfull. This might not be the "traditional" way to delegate work in C or C++, but then again, the termonoligy says i am a bit right.
Delegation is mostly used as a way to pass functions to functionality embedded in a class (pimpl, aggregation, private inheritance). They are mainly (inlined) functions of one line, calling functions of member-classes. As far as I know, it has nothing to do with C#'s delegates.
In this sense, a function-pointer as used in qsort is not a delegate, but a callback in which framework modules can be extended by user-software as in the Hollywood principle.
Delegate: An object that acts like a multi-function pointer with a subscription system. It really simplifies the use of static or 'object' member function pointers for callback notifications and event handling.
This link explains Delegates in a lucid manner or you may also refer to the MSDN link.