This may be an opportune time to revisit the issue of C++ -- I think we 
should change the CSOUND struct and its functions to a proper C++ class.

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.

About C++... In C++, if a class contains virtual functions, pointers to 
those functions are kept in a simple C array of function pointers (the 
virtual function table). In the body of the class structure itself, the very 
first member of the class is a pointer to the virtual function table (in 
some compilers named "vtbl"). (For classes without virtual functions, the 
member functions are simply C function bodies and there is no "vtbl").

To call a virtual function, the C++ compiler takes C++ source code such as

PointerToMyClass->MyVirtualFunction(a, b, c);

and translates it to machine language which, as C code, would look like:

PointerToMyClass->vtbl[23](PointerToMyClass, a, b, c);

The functions in the CSOUND struct, because they are function pointers, are 
actually virtual functions. However, I did not go so far as to create a 
separate virtual function table outside the CSOUND struct, and a "vtbl" 
pointer to that virtual function pointer as the first member of the CSOUND 
struct, because then it would not have been possible to write C code such 
as:

PointerToCsound->CsoundFunction(PointerToCsound, a, b, c);

Instead, we would always have been writing code with an explicit extra 
indirection through the vtbl, like this:

PointerToCsound->CsoundVTBL->CsoundFunction(PointerToCsound, a, b, c);

Therefore, I again suggest that the CSOUND struct, and the internals of 
Csound, be rewritten as a genuine C++ class with all virtual functions.

In one move, this would greatly improve (a) the maintainability of Csound, 
because the C++ compiler will then automatically take care of all this 
function table housekeeping; (b) the simplicity of the Csound code base 
itself, since the compiler will hide the "this" pointer and the vtbl from 
view; and (c) the simplicity of the Csound API, which would primarily become 
a C++ API, with the C version of the API being an alias for the C++ version 
instead of the reverse as it now is.

Regards,


----- Original Message ----- 
From: "Victor Lazzarini" 
To: "Developer discussions" 
Sent: Saturday, October 14, 2006 2:37 PM
Subject: Re: [Cs-dev] csoundCore.h change == recompiling against API?


>I moved them to the end. I noticed there are functions
> mixed in with the data fields at the end, so I don't
> think the convention of having functions only at the
> beginning is holding.
>
> Victor
>
>>
>> Your changed to H/csoundCore.h are different as they add
>> new functions to the API; I was under the impression that
>> all th efunctions were supposed to be at the start?
>>
>>   Anyway as Victor added them he probably has a better
>> idea which they are, and so is best placed to move them.
>>
>> ==John ffitch
>>
>> ----------------------------------------------------------
>> --------------- 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
> 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

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

I will make these changes then.

At 05:11 17/10/2006, you wrote:
>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

Victor Lazzarini
Music Technology Laboratory
Music Department
National University of Ireland, Maynooth 


-------------------------------------------------------------------------
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

I moved the functions as suggested. However I want to point out that
even when they were at the of the CSOUND structure, they were public,
and I can't see that if they were left there they would not be, as there is
nothing stopping them from being public, apart from convention.

In fact these API functions are used in Tclcsound and were working fine
either at the end or in the middle of the structure

I could not move the data fields as there were not enough free space in
the middle of the structure, so  I left them at the end.

Victor

At 05:11 17/10/2006, you wrote:
>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

Victor Lazzarini
Music Technology Laboratory
Music Department
National University of Ireland, Maynooth 


-------------------------------------------------------------------------
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