As long as any interface is just a list of function pointers, it is indeed
future-proof as long as you only add new pointers to it, and do not insert
them or change any of the existing ones.

Original Message:
-----------------
From: stevenyi stevenyi@csounds.com
Date: Wed, 26 Nov 2003 07:43:58 -0800
To: csound-dev@eartha.mills.edu
Subject: [CSOUND-DEV:3544] Re: Reset in Csound5


Hi Michael,

Thanks for explaining this again for me. =)  

One question I have with splitting the host and plugin interface, it
seems that you can add to either the HostInterface or PluginInterface
and you'd be future-proof.  Is this correct?  Or would you break plugins
if you add to the HostInterface?  

thanks,
steven



On Wed, 2003-11-26 at 07:23, gogins@pipeline.com wrote:
> I think it best if plugins communicate with host through functions only.
> Internally, however, Csound can and should use data members because that
is
> significantly faster. GLOBALS (perhaps to be renamed "Csound") is used by
3
> parties in 3 ways:
> 
> Hosts of Csound, via function pointers
> Plugins in Csound, via function pointers
> Internal functions of Csound (taking Csound * for multiple instancing),
via
> data members
> 
> There must be only Csound or GLOBALS structure for all 3 parties; however
> for the sake of clarity hosts can use 1 function pointer interface, and
> plugins can use another function pointer interface. Something like this?
> 
> typedef struct HostInterface {
> void (function1*)();
> void (function2*)();
> ...
> Csound_ *csound;
> };
> typedef struct PluginInterface {
> void (function1*)();
> void (function2*)();
> ...
> Csound_ *csound;
> };
> typedef struct Csound_ {
> HostInterface *hostInterface;
> PluginInterface *pluginInterface;
> int datamember1;
> double datamember2;
> ...
> };
> 


--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .

I may be showing my ignorance here again, but I thought Steven was correct
in his concern.  In the scenario below, once you link a plugin to the
interface, if the size of HostInterface changes, won't the position of
PluginInterface within Csound_ change?  Won't this break the plugin and
require recompiling?

Anthony Kozar
anthony.kozar@utoledo.edu


On 11/26/03 11:46 AM, gogins@pipeline.com etched in
stone:

> As long as any interface is just a list of function pointers, it is indeed
> future-proof as long as you only add new pointers to it, and do not insert
> them or change any of the existing ones.

> On Wed, 2003-11-26 at 07:23, gogins@pipeline.com wrote:
>> typedef struct Csound_ {
>> HostInterface *hostInterface;
>> PluginInterface *pluginInterface;
[...]

Never mind!

I see that they are pointers now.  Sorry. :|

Anthony Kozar
anthony.kozar@utoledo.edu

On 11/26/03 11:57 AM, Anthony Kozar etched in
stone:

> I may be showing my ignorance here again, but I thought Steven was correct
> in his concern.  In the scenario below, once you link a plugin to the
> interface, if the size of HostInterface changes, won't the position of
> PluginInterface within Csound_ change?  Won't this break the plugin and
> require recompiling?

Yeah, that's what I didn't think about too. =)  

On Wed, 2003-11-26 at 09:03, Anthony Kozar wrote:
> Never mind!
> 
> I see that they are pointers now.  Sorry. :|
> 
> Anthony Kozar
> anthony.kozar@utoledo.edu

Well, I was remembering a discussion from before where the interface was not
stored in the instance as a pointer and someone suggested that you would
then be able to cast from CSOUND* to CSOUND_INTERFACE* freely.  It looks as
though splitting the API will not allow this easy casting to be used if the
interfaces are stored as pointers (not that it makes a significant
difference).

Anthony Kozar
anthony.kozar@utoledo.edu


On 11/26/03 12:05 PM, stevenyi etched in stone:

> Yeah, that's what I didn't think about too. =)
> 
> On Wed, 2003-11-26 at 09:03, Anthony Kozar wrote:
>> Never mind!
>> 
>> I see that they are pointers now.  Sorry. :|
>> 
>> Anthony Kozar
>> anthony.kozar@utoledo.edu
>