In macro-less ANSI C: typedef struct IUnknownVirtualFunctionTable_ { uint32_t (*QueryInterface)(void *thisPointer, REFID interfaceIdentifier, void **pointerToReceivePointerToInterface); uint32_t (*AddRef)(void *thisPointer); uint32_t (*Release)(void *thisPointer); } IUnknownVirtualFunctionTable; typedef struct IUnknown_ { IUnknownVirtualFunctionTable *iunknownVirtualFunctionTable; } IUnknown; To declare a new interface deriving from IUnknown in C, copy the IUnknownVirtualFunctionTable declaration, rename it, and add new function pointers at its end; then copy the IUnknown declaration, rename it, make the pointer be a pointer to your new interface, and add any data members you need at its end. Of course, you have to actually implement these function pointers somewhere. In your object factory, just create the appropriate structs and wire up the pointers and function pointers. This is byte for byte identical to a C++ class for IUnknown. Original Message: ----------------- From: Ron Kuper ronkuper@xxxxxxxxxxx Date: Thu, 3 Feb 2005 19:07:25 -0500 To: gmpi@xxxxxxxxxxxxx Subject: [gmpi] Re: low level API That XPCOM web site is most unfortunate. It manages to cloud the fundamental elegance of the approach with macros and complexity. Disregard this if you already know what COM is. In C++, all COM is an abstract base case, looks something like this (datatypes changed to for clarity) struct IUnknown { virtual long QueryInterface( const GUID& iid, void** ppInterface ) = 0; virtual long AddRef() = 0; virtual long Release() = 0; }; Everything in the word inherits from IUnknown. If you want some other interface, you create a new ABC, give it a unique IID, and have QueryInterface in your object know how to cast to the new interface. I believe you can implement this in native C, even without tables of function pointers: long Foo_QueryInterface( void* pvFoo, const GUID* pIID, void** ppIntf ); long Foo_AddRef( void* pvFoo ); long Foo_Release( void* pvFoo ); Unfortunately icky macros are necessary to bridge the clean looking struct to be C-callable. ----- Original Message ----- From: "Paul Davis" <paul@xxxxxxxxxxxxxxxxxxxxx> To: <gmpi@xxxxxxxxxxxxx> Sent: Thursday, February 03, 2005 4:52 PM Subject: [gmpi] Re: low level API > >>>Shall we tentativly pencil in COM as a binary interface? > >> > >> I know nothing of it. Can you either describe what that means, or point > >> me to some public docs that aren't entangled with Windows-ness? > > > >I found this... > > > >XPCOM > > > >The open source, Windows-ness-free version of COM > > > >http://www.mozilla.org/projects/xpcom/ > > ugh. > > i sincerely believe this to be completely the wrong style of > technology for GMPI to be adopting, no matter what form it is in. > > for all the lack of details in VST specifications, at least there is > an API there that doesn't require getting one's head around some > sizable chunk of programming methodology above and beyond the language > in question. > > i imagine this would apply to COM as well, for what its worth. > > so that i am clear, see: > > http://ardour.org/cgi-bin/viewcvs.cgi/ardour/libs/ardour/ardour/ladspa.h?rev =1.2&content-type=text/vnd.viewcvs-markup > > this isn't GMPI, and it has lots of problems, but its a single header > file that has sufficient for hundreds of FX (non-instrument) > plugins. its simple, its fairly clean, it requires no knowledge to use > it other than basic C and knowledge of how to load a shared object (i > think). > > GMPI's metadata and event systems will require greater complexity, for > sure, but i'd be much happier if we can stay away from the > infrastructure that stuff like (XP)COM represents. i'd like to point > out that IDL's have a dismal record of adoption by the programming > world, but no shortage of people to promote their benefits. > > --p > > ---------------------------------------------------------------------- > Generalized Music Plugin Interface (GMPI) public discussion list > Participation in this list is contingent upon your abiding by the > following rules: Please stay on topic. You are responsible for your own > words. Please respect your fellow subscribers. Please do not > redistribute anyone else's words without their permission. > > Archive: //www.freelists.org/archives/gmpi > Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe > ---------------------------------------------------------------------- Generalized Music Plugin Interface (GMPI) public discussion list Participation in this list is contingent upon your abiding by the following rules: Please stay on topic. You are responsible for your own words. Please respect your fellow subscribers. Please do not redistribute anyone else's words without their permission. Archive: //www.freelists.org/archives/gmpi Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe -------------------------------------------------------------------- mail2web - Check your email from the web at http://mail2web.com/ . ---------------------------------------------------------------------- Generalized Music Plugin Interface (GMPI) public discussion list Participation in this list is contingent upon your abiding by the following rules: Please stay on topic. You are responsible for your own words. Please respect your fellow subscribers. Please do not redistribute anyone else's words without their permission. Archive: //www.freelists.org/archives/gmpi Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe