I'm glad I could help clear some things up.

As for linking with libcsound.a at run time, that sort of thing is standard
on Linux and Unix, but on Windows, you can't link at run time without either
(a) coding with LoadLibrary and GetProcAddress, or (b) linking with a static
import library. The Csound scheme should work on all platforms and therefore
must be a lowest common denominator, which means exporting only functions
and having the host push the function table into the plugin so that these
issues need not arise.

You are correct that it's OK to insert new functions at the end of the
function list but ahead of the data members.

============================================
Michael Gogins
gogins at pipeline period com
Irreducible Productions
CsoundVST, an extended version of Csound for programming music and sound
Available at http://sourceforge.net/projects/csound/
============================================


----- Original Message ----- 
From: "stevenyi" 
To: "Csound Developers Discussion List" 
Sent: Monday, November 17, 2003 12:34 AM
Subject: [CSOUND-DEV:3351] Re: Csound API Split, design


> > The reason the function pointers are members of the globals structure is
to
> > make it a true interface. This means an opcode does not need to LINK
with
> > the csound API, only to declare the order and signatures of the function
> > pointers in the Csound globals structure. The technical term for such a
> > table of function pointers is "interface."
>
> Gotcha.  It's funny as I've read about vtables and of course work with
> interfaces all the time in Java, but I never realized the implementation
> and how it all fits in to object inheritance and method overriding.
> Cool!  =)
>
> > In other words, with csoundSomething(csound,args) you need to #include
> >  and link with libcsound.a. If you link with libcsound.a, or
if
> > you reference DATA members of GLOBALS, there is no guarantee your plugin
> > will work with a later version of Csound.
>
> Hmm... I thought that the links would get resolved at run-time and that
> the you could still just use csound.h without linking to libcsound.a at
> compile-time; I think that's where I was getting tripped up. But wait a
> second... none of the opcode plugins in the Opcodes dir are being linked
> to libcsound.a now (csound5 cvs). Oh... they're using GLOBAL cglob
> directly, so it's beginning to make sense.
>
> I was thinking that all of the data should be private as well, and that
> the API functions in csoundSomething(csound, args) form would be
> sufficient.
>
>
> > Therefore, it is a requirement for all public API functions to be a
member
> > of the GLOBALS struct and to be properly filled in. New functions should
be
> > appended to the list, not inserted at the beginning or in the middle, so
> > that older plugins will continue to be able to call the right function
> > pointers off the GLOBALS pointer.
>
> The GLOBAL struct right now has all function pointers first, then data
> members.  As long as no code is directly accessing the data members,
> it's alright to append functions after the functions but before the
> data, yes?
>
>
> Thanks for the long email!  It definitely cleared up a bunch of things
> for me.
>
> steven
>

> As for linking with libcsound.a at run time, that sort of thing is standard
> on Linux and Unix, but on Windows, you can't link at run time without either
> (a) coding with LoadLibrary and GetProcAddress, or (b) linking with a static
> import library. The Csound scheme should work on all platforms and therefore
> must be a lowest common denominator, which means exporting only functions
> and having the host push the function table into the plugin so that these
> issues need not arise.

Yikes!  I didn't realize windows dll's were so nuts. I started reading
into static import libraries and DEF files and __declspec(dllexport) and
__declspec(dllimport) and it's quite a chore. I did find this though:

http://cygwin.com/ml/cygwin/2000-06/msg00688.html

and if I understand it correctly, we'd be able to get rid of the
function pointers in the GLOBAL struct and have all the symbols exported
and imported and linked correctly for windows.  Granted, for windows
opcode plugin developers they would have to add -DUSEDLL compiler flag,
but that's nothing compared to having to make the jump to using function
pointers.  

This seems like it would also be as future-proof as your function table
system, i.e. as long as none of the exported functions are removed,
you're fine.  It does have the advantage of not needing to rely on
maintaining the order of function pointers in the GLOBAL struct. 

I really hope this will work out as a possible solution.  I think the
study of building an Opcode Plugin, say, at a University electronic
music/programming course would be greatly eased if they didn't have to
deal with function pointers and the syntax that surrounds their use. 
Also, I think this will be much easier to generate doxygen documentation
for as we could do it per-function as opposed to one large doc that
would have to explain every entry in the whole GLOBAL struct. 

Thanks,
steven