• entries
    383
  • comments
    1075
  • views
    352550

Signal Processing

Sign in to follow this  
Trapper Zoid

54 views

I was feeling a bit crook this morning so I decided to work on coding up the signal system rather than decipher more research papers. The prototype code I have now is ugly as sin in parts - partly due to my savage beating of C++'s strongly typed system with blunt objects - but it appears to be working for the first simple tests.

So far I've got a simple signal class that can accept either of member or static functions with no arguments, which it can then call all of them through in a list. It's pretty similar to sigslot in operation, except sigslot to my knowledge doesn't accept static functions.

Although my implmenetation is a bit sluggish with debugging symbols turned on, with the symbols turned of my entirely unscientific benchmark tests put it as running about a third faster than sigslot does in my trial test; on my MacBook Pro it can trigger about 60 million slot functions per second. If it turns out that isn't fast enough I'm sure there's plenty I could optimise in the kludges I've put in there; that can wait until it's demonstratably a problem.

For the function calls I've used an implementation called FastDelegate, which acts a bit like boost::bind or boost::function but can perform the call in only two lines of assembler. It does this by not strictly conforming to the C++ standard and employing a whole raft of hacks around various compiler options. Normally I'd be a bit wary of code like this, however it's clear it's been tested on a wide range of platforms and more importantly: it's exceedingly well documented. Code with lots of insightful comments conveys a whole heap of trust to me. It seems to run fine so far on both MinGW on my PC and whatever XCode is using under the hood to compile on my MacBook Pro.

I've also employed a global memory manager to handle all the connections between signals and slots. As I mentioned in the mammoth brainstorming post I made previously, the signals and slot objects need to store lists of what they are connected up to in order for them to disconnect when either of them is destroyed. Given I prefer to use memory pools to keep all my dynamic memory in one place for these kinds of things I rolled one together that should work for all types of signal/slot connections.

The main nastiness of my memory manager is dealing with the multiple types that the FastDelegate function pointer objects can be in. Given a signal can be defined via a template to have a variety of different parameters (in type as well as number), I needed some kind of data type that I can easily morph between types. In theory this shouldn't be too problematic, as every FastDelegate object is exactly the same size in memory and every specific signal type only works on one type of FastDelegate. But in practice the type checking capabilities of C++ make this annoying to fix as it keeps complaining about type incompatibilities.

I'm not that versed in advanced C++ so I'm not sure if there's an easy way to do this, but at the moment I'm just using a basic meaningless data type crafted from a union of possible FastDelegates (to ensure they're all the same size, even though logically I'm sure they have to be). Then I just bash it senseless with C style casts into in finally converts into something that the compiler doesn't throw a hissy fit over. It's an extremely nasty and brutish method, and I haven't yet found a variant that doesn't cause warnings or errors on both compilers.

I've still also got to put in the capability to disconnect signals at will, then after a few more tests to ensure things are working and maybe a bit of code cleanup I can move on to signals that can accept arguments. After I get the single argument variant working (involving some templane shennanigans), it's a simple matter of cut and paste with a bit of editing to make the ones for multiple arguments. I might as well go up to eight just in case. Then I can make the alternative signal variants; the ones that use priorities and the ones that act more like simple function pointers.
Sign in to follow this  


0 Comments


Recommended Comments

There are no comments to display.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now