• entries
383
1075
• views
352549

Signals with arguments

60 views

I hope I'm not boring everyone to death with my signal coding adventures. I suppose it's a bit dry but hopefully this hurdle will be overcome soon.

I've cleaned up the code for the signals a little bit, structured them across a number of header files, put in some namespaces and fixed my project directory structure to make it a little more sensible. It's now starting to look like a proper project, albeit a rather empty one at this stage.

I also put in a wrapper around the evil C style casts I'm doing to allow me to use a global memory pool for signal to slot connections. Adapting an example from Don Clugston's Fast Delegate code I turned my C casts into a C++ version called nasty_cast:

/**    nasty_cast - designed to swap one block of memory to another    Done to subvert the C++ type casting system    This is a horrible hack, but it makes the global memory buffer happen    Some ideas were taken from Don Clugston's casts in his Fast Delegate code    for how to do the casts and type checking*/template <class OutputClass, class InputClass>inline OutputClass nasty_cast(InputClass input){	typedef int ERROR_CannotUseNastyCast[sizeof(InputClass)==sizeof(OutputClass) ? 1 : -1];	return *(OutputClass *)(&(input));}

The nasty_cast is soley used to swap a FastDelegate function pointer like object to a generic type for storage, and then back again when it is needed to be used, like so:

(nasty_cast(slotInfo->functionDelegate))(a1, a2, a3);

It's all (more than a little bit of) a hack, but it makes the magic happen.

I've also extended the signal class to variants that take arguments. At the moment I've got versions that can accept zero, one, two or three arguments (called Signal0, Signal1, Signal2 and Signal3 respectively). I don't think there's a way I can template my way around the number of arguments so I'm stuck with having to make multiple copies of the code. As such I'm going to stop at three until the code gets a bit more stable or I have a pressing need to implement a version that takes more than that.

Now I need to implement the "Event" version of the signal. The Event version is like the signal in that it has a function like interface that sends message-like information to multiple targets, except unlike the signal the targets return a boolean flag to indicate that the message has been dealt with and that no further targets need to receive the message. I'm also going to put in a priority value that allows the event targets to be ordered properly.

The question I'm still unsure about is whether the return flag should be true to indicate the messages should still be passed and false to indicate it should be stopped, or the other way round (true to indicate the message has been dealt with and false to indicate that it hasn't and processing should continue). Both sound like logical choices to me.

Events are now done. I went with returning false to continue and true to loop, as it makes more sense from the perspective of the callee ("Have I dealt with this message?").

I think the signal system is now complete (to a prototype level). Time to move on.

There are no comments to display.

Create an account

Register a new account