On Thu, Sep 1, 2011 at 7:18 PM, David Robillard
<d@drobilla.net> wrote:
The main issue you'll find with going the C++/RTTI route is that #2 no
longer is possible, since virtual objects are not POD, so you can't
safely write them through a ringbuffer (or copy them around manually in
general).
True, I'm currently just adding functions to an existing class, rather than the subclassing option. That makes reading / writing the class to/from a ringbuffer easier, as they're all the same size... For performance I'm aware that its causing extra work, but for simplicity I'm going to keep it this way :D
The uglest bit of having one class is having a fixed amount of variables, and only some are being used. I've circumvented madness by creating set() functions, that initialize the "type" variable, and also takes the right parameters for that event type & stores them in the class. Does mean that there's some pointless data being transferred into / outta the JACK thread using the ringbuffers... oh well!
You can, of course, copy around *pointers* to them. This means you have
to dynamically allocate them. If you want to be able to create events in
a real-time thread, you will have to get into more advanced C++ and make
a custom allocator for that etc. etc.
Pointers: That's exactly what I'm doing... and I do need to dynamically allocate them too... so I decided to do that in a non-RT thread, and have a ringbuffer of new events, and a ringbuffer of valid events, where the JACK RT thread can pull one of the Events from the "store" of new events, and then fill it in in a RT context, and then push that pointer onto the other ringbuffer that's going to be processed in another non-RT context... It might be a little more complex than needed, but its serving my purposes now :)
Passing strings around isn't possible due to the nature of strdup(), so I've enumerated all the messagesthat the JACK thread might need to send, and then have a big switch to handle all the different error messages. Not very nice but its RT safe. I've done the same for sending the PATH and SIGNATURE elements of OSC messages.
Functors & closures, yeah I suppose... for now this system is working, and quite easy to add new types to (does need a big recompile after a change though.. as heaps of headers include the "Event" type, as its pretty much to core of the Engine.. :)
-Harry