[gmpi] Re: low level API

  • From: "gogins@xxxxxxxxxxxx" <gogins@xxxxxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Fri, 4 Feb 2005 10:11:18 -0500

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

Other related posts: