I forgot about the dummy pointers, probably because I thought they were a bad idea to start with. But as long as they exist, they should be used, since it would be disruptive to remove them.

Regards,
Mike

-----Original Message-----
>From: Anthony Kozar 
>Sent: Oct 17, 2006 12:11 AM
>To: Csound Developer list 
>Subject: Re: [Cs-dev] csoundCore.h change == recompiling against API?
>
>Istvan created a bunch of dummy slots for public function pointers in the
>CSOUND struct:
>
> /* SUBR dummyfn_1; */
>    SUBR dummyfn_2[102];
>
>So I believe that new functions can be inserted here instead of at the end.
>For example (assuming these were meant to be public?):
>
>    int (*PvsinSet)(CSOUND *, const PVSDATEXT *value, int n);
>    int (*PvsoutGet)(CSOUND *, PVSDATEXT *value, int n);
> /* SUBR dummyfn_1; */
>    SUBR dummyfn_2[100];
>
>By the way, if the two function pointers above ARE supposed to be public,
>they are not currently!  They were added to the private section of the
>struct (after #ifdef __BUILDING_LIBCSOUND).
>
>Furthermore, I am not so sure that adding new members in the middle of the
>_private_ section will break any hosts or plugins, because by definition
>they cannot see that part of the struct.  (And attempts to do a
>sizeof(CSOUND) should fail to work properly anyways).  In fact, if you are
>adding a new private callback pointer that should be saved on reset, you
>MUST add it to the section near the beginning of the private data (in
>between first_callback_ and last_callback_).
>
>New _public_ data members would have to be added before the check for
>__BUILDING_LIBCSOUND.  There are also a handful of dummy data slots in the
>public section whose names could be changed without harm:
>
>    /** unused */
>    int           dummy_01, dummy_02;
>    void          *dummy_03;
>
>
>Anthony Kozar
>anthonykozar AT sbcglobal DOT net
>
>
>Michael Gogins wrote on 10/14/06 4:15 PM:
>
>> Also, ALL new members, whether functions or data, should be added at the END
>> of the structure. This is the only way to maintain any kind of backward
>> binary compatibility. The only reason the API functions were collected at
>> the beginning was for clarity and legibility.
>
>
>-------------------------------------------------------------------------
>Using Tomcat but need to do more? Need to support web services, security?
>Get stuff done quickly with pre-integrated technology to make your job easier
>Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>_______________________________________________
>Csound-devel mailing list
>Csound-devel@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/csound-devel




-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net