This is not quite correct (at least, it is not like COM). What is returned should be a function table, i.e. a pointer to an array of function pointers, not  a single function pointer (that would be just like COM).

The beauty of COM is that if you have a C++ class with all virtual functions, the virtual function table is, exactly, a pointer to an array of function pointers, so there is a complete alias between pure virtual C++ classes and COM intefaces.

But don't be distracted by my talk about C++. The same principle is valid in C. (Even though this kind of thing is easier to program and to maintain in C++.)

Another thing is, you can only call QueryInterface in COM off an existing object. So the way this would be used in the Csound API is create an instance of Csound, then call QueryInterface off the instance to obtain the API function tables.

-----Original Message-----
From: Richard Dobson 
Sent: Nov 9, 2005 11:20 AM
To: csound-devel@lists.sourceforge.net
Subject: Re: [Cs-dev] Syntactic sugar request

Istvan Varga wrote:
> Victor Lazzarini wrote:
> 
>> What is "Query-Interface" ?
> 
> 
> I assume this function (Top/csound.c):
> 
> PUBLIC int csoundQueryInterface(const char *name, void **iface, int 
> *version)
> {
>     if (strcmp(name, "CSOUND") != 0)
>       return 1;
>     *iface = csoundCreate(NULL);
>     *version = csoundGetVersion();
>     return 0;
> }
> 
> In its current form it does not look very useful, but I think the
> intended purpose is to return a table of function pointers and the
> version of the selected interface. Of course, it now creates an
> actual instance of Csound, and returns the package (and not API)
> version, which may or may not be the intended behavior.
> 

Well, not, it doesn't implement the intended bahaviour.

In very rough hand-wavy pseudo-code which is probably wrong in all sort of C 
details, I envisaged something like:

/* header file */
#define CSOUND_TABLEGET_ID 0xabcd10594631ffff

typedef   MYFLT (*csoundTableGetfn)(void *csound, int table, int index);

/* app file */
csoundTablegetfn *csoundTableGet = NULL;

csoundQueryinterface(csound,CSOUND_TABLEGET_ID, csoundTableGet);
/* or in COM style:
    csound->QueryInterface(CSOUND_TABLEGET_ID, csoundTableGet);
*/

if(csoundTableGet){
	/* get the table data, etc*/
}
else{
	printf("This version of Csound does not support 'csoundTableGet'\n":
	abort();
}


Of course, if something like this is not possible, we will just have to live 
with an "evolving" API which may require host apps to be rebuilt each time.

	
Richard Dobson




-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-devel





-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Michael Gogins wrote:

> This is not quite correct (at least, it is not like COM). What is returned
> should be a function table, i.e. a pointer to an array of function pointers,
> not  a single function pointer (that would be just like COM).
> 

But my proposal is precisely not to return a whole API table, but to return very 
possible a single function that has been defined after the API was frozen for 
release. After all, csoundQueryInterface is itself an API function.  Maybe the 
object returned will contain a mini function table with a single function in it; 
but that is an implementation detail. I am trying to describe the "big picture" 
here.

So, there will be a csound object called "csound",  adn you will be implementing 
an App a year from now that happens to know that, say, Stephen has defined a new 
API function defined in some headerfile , and Istvan has 
define a new API function defined in the header file . These 
functions by definition cannot be in the "canonical" API.  Older applications 
will not know about them, and can still use the latest build of csound.lib, 
because the canonical API structure has been preserved.

But: the new app does know about the new functions and can access them via 
QueryInterface. It has no need to obtain the whole API function table ~again~.


>
> Another thing is, you can only call QueryInterface in COM off an existing
> object. So the way this would be used in the Csound API is create an instance
> of Csound, then call QueryInterface off the instance to obtain the API
> function tables.
> 

Exactly. That is what my example was intended to demonstrate; ~except~ that it 
does not access the API table (you already have that, by definition), but 
enables access to more recent functions OUTSIDE the frozen canonical API table:


> csoundQueryinterface(csound,CSOUND_TABLEGET_ID, csoundTableGet); 

Which as I indicated would be in C++ semantics:

csound->QueryInterface(CSOUND_TABLEGET_ID, csoundTableGet);

But please note I am not trying to dot all the i's and cross all the t's here; 
just to suggest the ~principle~ of a mechanism to access API functions defined 
too late to get into the full canonical API function table - hence, a way to 
freeze the API at some point without losing the possibility for new functions to 
be defined in later versions of csound.

But maybe it is all too complicated, and rebuilding apps each time the API is 
changed is easier.

Richard Dobson








-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Richard Dobson wrote:

> But maybe it is all too complicated, and rebuilding apps each time the 
> API is changed is easier.

Maybe I missed some important detail, but why would any addition of
a new function break existing code ?


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net