[music-dsp] C or C++ ?
lists at silverblade.co.uk
Sat Apr 3 19:48:54 EST 2004
Hi Ross (helpful as always!)
I had a look at XPCOM as you suggested... It seems a bit awkward, especially
considering that I'd like to support other compilers such as Delphi in the
future (and XPCOM appears to only work with C, C++ and Perl, if I read the
The guide for portability was an interesting read though - but as my project
is compiled using GCC/G++ only, and only the plugin API is going to be
"public", I'm thinking maybe some of that doesn't apply to me!
I was going to implement the plugin API in C++, wrap them with a C
interface, and then wrap that with C++ again... But thats messy and one word
springs to mind: Overhead.
True, not much overhead, but it's still un-necessary IMO.
Having spent most of the day considering alternative solutions, I think I
may have found one... Basically just have an event handler in each plugin,
that just does everything the host wants. GetName could return the plugin
name, even without an instance of it, while Create could spawn an instance
of whatever object the plugin contains.
This kinda detaches from the not-so-wonderful-in-the-end idea I had where
the plugin had its own struct to describe a virtual device, and another
struct to describe instances of that device. Very messy, as I couldn't think
of a way to describe something that doesn't exist but still has a presence
(ie, to obtain a device name from a plugin w/o instantiating the device
I had also contemplated using multithreading and having the event processing
routine of each class wait for some thread object (event/signal) in a loop -
but this would also induce a lot of overhead and possibly thread-unsafety.
So now, I'm thinking of maybe hacking together some small macros that let
you assign event handlers individually to events...
Right now the entire project is in a bit of a mess, mainly due to constant
re-organization and improvements. I sense a lot of fun ahead when I end up
removing the redundant "sender" object parameter in the event processor, and
Anyway, thanks for the suggestions.
> Hi Andrew,
> A few thoughts:
> The lack of an ABI for C++ is a major pain.
> You could look into XPCOM (what Mozilla uses), this is a light-weight
> in-process COM-like component system which let's you do objects, portably.
> You could have implemented in C++ and then wrapped with a C interface.
> I think C is a good idea for a plugin API, as you say, you can always wrap
> it. One major advantage of a C interface is that it's much easier to
> interface to other languages. Just make sure you specify the calling
> Best wishes
> ----- Original Message -----
> From: "Andrew Greenwood" <lists at silverblade.co.uk>
> To: "a list for musical digital signal processing"
> <music-dsp at shoko.calarts.edu>
> Sent: Sunday, April 04, 2004 3:16 AM
> Subject: [music-dsp] C or C++ ?
> > For my music program, I'm designing a framework to accommodate things
> > virtual socket creation/destruction, etc.
> > Originally, I wrote it in C++, but then realized that problems would
> > due to name mangling.
> > So I have re-implemented the framework in C.
> > Anyway I'm having difficulty actually getting my head around how the
> > processing will be done for things like mouse clicks, draw requests, and
> > likes.
> > I'd like to somehow create a C++ wrapper for the API, but again, I'm
> > exactly of how to do this.
> > Any ideas?
> > And if you were writing a plugin, would you rather do it in C or C++?
> > dupswapdrop -- the music-dsp mailing list and website:
> > subscription info, FAQ, source code archive, list archive, book reviews,
> dsp links
> > http://shoko.calarts.edu/musicdsp
> > http://ceait.calarts.edu/mailman/listinfo/music-dsp
> dupswapdrop -- the music-dsp mailing list and website:
> subscription info, FAQ, source code archive, list archive, book reviews,
More information about the music-dsp