And why can't opcodes just #include  and call them directly?

On Wed, Apr 25, 2012 at 19:13, michael.gogins@gmail.com
 wrote:
> Because it enables opcodes to obtain the API functions, and to call them,
> from the Csound pointer that  is passed to the opcode routines.
>
> T-Mobile. America’s First Nationwide 4G Network
>
>
> ----- Reply message -----
> From: "Felipe Sateler" 
> To: "Developer discussions" 
> Subject: [Cs-dev] cenviron_ and the API
> Date: Wed, Apr 25, 2012 5:41 pm
>
>
> This is not really the question I asked. I agree that, given that a
> list of functions is stored, it is better to store them at a separate
> structure. Let me rephrase: Why does the CSOUND object need to contain
> (a pointer to) a list of API functions?
>
> On Wed, Apr 25, 2012 at 18:08, Michael Gogins 
> wrote:
>> I doubt you are ignorant, but anyway...
>>
>> (1) Makes it easier to maintain backwards compatibility of the Csound
>> structure. There is no need to use padding. New data members are added
>> at the end of the structure, and new API function pointers are added
>> at the end of the vtable.
>>
>> (2) For the same reason, makes it easier to maintain the code for the
>> Csound structure and the factory functions.
>>
>> (3) The Csound API could be made into a perfect COM object by
>> including an AddRef and Release member. There would be the same binary
>>  layout for both the C Csound API and the COM interface.
>>
>> (4) Ditto for a C++ interface. It would have the same binary layout, A
>> factory returning a Csound class pointer could in fact be returning a
>> Csound structure pointer.
>>
>> (5) Similarly, if Csound were actually implemented in C++ rather than
>> in C, a factory returning a Csound struct pointer could in fact be
>> returning a Csound class pointer.
>>
>> Regards,
>> Mike
>>
>>
>> On Wed, Apr 25, 2012 at 4:59 PM, Felipe Sateler 
>> wrote:
>>> On Wed, Apr 25, 2012 at 17:53, Michael Gogins 
>>> wrote:
>>>> Csound 6, the API should be refactored and reconsidered. In
>>>> particular, instead of individual function pointer members, it should
>>>> have one pointer to a table of function pointers, i.e. a proper
>>>> virtual function table like a C++ class
>>>
>>> Pardon my ignorance, but what purpose does the csound function pointer
>>> list fulfill?(
>>>
>>> --
>>>
>>> Saludos,
>>> Felipe Sateler
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond. Discussions
>>> will include endpoint security, mobile security and the latest in malware
>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>>
>> --
>> Michael Gogins
>> Irreducible Productions
>> http://www.michael-gogins.com
>> Michael dot Gogins at gmail dot com
>>
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>
> --
>
> Saludos,
> Felipe Sateler
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>



-- 

Saludos,
Felipe Sateler

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-dev

On Thu, Apr 26, 2012 at 11:01, Michael Gogins  wrote:
> On Unix or Linux maybe they could, because the API symbols might have been
> bound when the opcode was loaded. On Windows, they could not without not
> only #include-ing csound.h, but also explicitly linking with the Csound
> library.
>
> In other words, using the virtual function table in the Csound object, you
> don't need to link to the Csound library to write an opcode that calls the
> API. You just need to #include the header file.

Ah, I see. Indeed, now looking at the sources, the pd class works
exactly like this: it needs to link with pd, but only in windows
(there is a difference, though: the symbols are provided by the pd
executable, not a library).
Is there an advantage to not linking against the csound library?

>
> This is object-oriented C programming. The CSOUND struct is a class and the
> API function pointers in the struct are its methods.

I can see that. But OOP does not require a particular syntax:
method(object, args) is as much OOP as object->method(args).

-- 

Saludos,
Felipe Sateler

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

With all the re-factoring and what not, will it be possible with
Csound 6 for developers to build truly standalone Csound frontends,
i.e., frontends that don't need to link to a Csound library at
run-time?

On 26 April 2012 16:10, Michael Gogins  wrote:
> There are several advantages to not linking with the API library. When
> linking, there are 2 potential sources of incompatibility, the CSOUND type
> and the library version. When not linking, there is only 1 potential source
> of incompatibility, the CSOUND type (i.e. API version).
>
> Also there would be some slight time saved in the linking loader, though I
> doubt this is worth worrying about.
>
> To my mind, as well, this approach just seems more elegant.
>
> Regards,
> Mike
>
>
> On Thu, Apr 26, 2012 at 10:40 AM, Felipe Sateler  wrote:
>>
>> On Thu, Apr 26, 2012 at 11:01, Michael Gogins 
>> wrote:
>> > On Unix or Linux maybe they could, because the API symbols might have
>> > been
>> > bound when the opcode was loaded. On Windows, they could not without not
>> > only #include-ing csound.h, but also explicitly linking with the Csound
>> > library.
>> >
>> > In other words, using the virtual function table in the Csound object,
>> > you
>> > don't need to link to the Csound library to write an opcode that calls
>> > the
>> > API. You just need to #include the header file.
>>
>> Ah, I see. Indeed, now looking at the sources, the pd class works
>> exactly like this: it needs to link with pd, but only in windows
>> (there is a difference, though: the symbols are provided by the pd
>> executable, not a library).
>> Is there an advantage to not linking against the csound library?
>>
>> >
>> > This is object-oriented C programming. The CSOUND struct is a class and
>> > the
>> > API function pointers in the struct are its methods.
>>
>> I can see that. But OOP does not require a particular syntax:
>> method(object, args) is as much OOP as object->method(args).
>>
>> --
>>
>> Saludos,
>> Felipe Sateler
>>
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>
>
> --
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

you can already do this, just build a static libcsound. Set dynamicCsoundLibrary=1
in scons.

Victor
On 26 Apr 2012, at 21:30, Rory Walsh  wrote:

> With all the re-factoring and what not, will it be possible with
> Csound 6 for developers to build truly standalone Csound frontends,
> i.e., frontends that don't need to link to a Csound library at
> run-time?
> 
> On 26 April 2012 16:10, Michael Gogins  wrote:
>> There are several advantages to not linking with the API library. When
>> linking, there are 2 potential sources of incompatibility, the CSOUND type
>> and the library version. When not linking, there is only 1 potential source
>> of incompatibility, the CSOUND type (i.e. API version).
>> 
>> Also there would be some slight time saved in the linking loader, though I
>> doubt this is worth worrying about.
>> 
>> To my mind, as well, this approach just seems more elegant.
>> 
>> Regards,
>> Mike
>> 
>> 
>> On Thu, Apr 26, 2012 at 10:40 AM, Felipe Sateler  wrote:
>>> 
>>> On Thu, Apr 26, 2012 at 11:01, Michael Gogins 
>>> wrote:
>>>> On Unix or Linux maybe they could, because the API symbols might have
>>>> been
>>>> bound when the opcode was loaded. On Windows, they could not without not
>>>> only #include-ing csound.h, but also explicitly linking with the Csound
>>>> library.
>>>> 
>>>> In other words, using the virtual function table in the Csound object,
>>>> you
>>>> don't need to link to the Csound library to write an opcode that calls
>>>> the
>>>> API. You just need to #include the header file.
>>> 
>>> Ah, I see. Indeed, now looking at the sources, the pd class works
>>> exactly like this: it needs to link with pd, but only in windows
>>> (there is a difference, though: the symbols are provided by the pd
>>> executable, not a library).
>>> Is there an advantage to not linking against the csound library?
>>> 
>>>> 
>>>> This is object-oriented C programming. The CSOUND struct is a class and
>>>> the
>>>> API function pointers in the struct are its methods.
>>> 
>>> I can see that. But OOP does not require a particular syntax:
>>> method(object, args) is as much OOP as object->method(args).
>>> 
>>> --
>>> 
>>> Saludos,
>>> Felipe Sateler
>>> 
>>> 
>>> ------------------------------------------------------------------------------
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond. Discussions
>>> will include endpoint security, mobile security and the latest in malware
>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>> 
>> 
>> 
>> 
>> --
>> Michael Gogins
>> Irreducible Productions
>> http://www.michael-gogins.com
>> Michael dot Gogins at gmail dot com
>> 
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>> 
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

That is a contradiction in terms. To use csound, a program must link with csound. with the existing api, it is possible link with csound only at build time (static linking), partly at build time and partly at run time (dynamic linking), or only at run time (dynamic loading).

Ah, I see. Sometimes I have to laugh at how far I've got using the API
with such a limited understanding of computer science!

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I'm thinking of the case where a developer writes an instrument and
then provides a frontend for it. The instrument doesn't use any file
writing opcodes, and the frontend looks after all the audio IO. Would
one still have to use libsndfile, I mean, is it possible to use Csound
without it, or is libsndfile so tied up in the internals of Csound
that it's simply part of Csound now? It makes little difference to me
or my work. libsndfile rocks. I'm just curious.

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

you would need to build csound without all the sndfile writing code, a major surgery in the sources. Easier to link against a static libsndfile, which is what we do on ios and android.

Victor

On 26 Apr 2012, at 23:06, Rory Walsh  wrote:

> I'm thinking of the case where a developer writes an instrument and
> then provides a frontend for it. The instrument doesn't use any file
> writing opcodes, and the frontend looks after all the audio IO. Would
> one still have to use libsndfile, I mean, is it possible to use Csound
> without it, or is libsndfile so tied up in the internals of Csound
> that it's simply part of Csound now? It makes little difference to me
> or my work. libsndfile rocks. I'm just curious.
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

On 26/04/2012 15:40, Felipe Sateler wrote:
..
>>
>> This is object-oriented C programming. The CSOUND struct is a class and the
>> API function pointers in the struct are its methods.
>
> I can see that. But OOP does not require a particular syntax:
> method(object, args) is as much OOP as object->method(args).
>

But of course they are not equivalent. OOP canonically describes objects 
in terms of (internal) state and (mostly public) behaviour. In the 
construct method(object,args) the behaviour is both semantically and 
conceptually primary, and might be applied  to any number of objects, 
possibly in error (e.g. calling the method on an unintended object 
instance). In the construct object->method(args) the state is  primary, 
and calling the method is effectively guaranteed to apply to the correct 
instance of state (in C++ via the all-important internal 'this' 
pointer). We can even say that the set of methods is itself part of the 
state of the object. So while both might be regarded as kinds of OOP, 
the former example is more literally MOP - method-oriented programming, 
while the latter is SOP - state-oriented programming.

Richard Dobson

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

On Fri, Apr 27, 2012 at 06:49, Richard Dobson
 wrote:
> On 26/04/2012 15:40, Felipe Sateler wrote:
> ..
>>>
>>> This is object-oriented C programming. The CSOUND struct is a class and the
>>> API function pointers in the struct are its methods.
>>
>> I can see that. But OOP does not require a particular syntax:
>> method(object, args) is as much OOP as object->method(args).
>>
>
> But of course they are not equivalent. OOP canonically describes objects
> in terms of (internal) state and (mostly public) behaviour. In the
> construct method(object,args) the behaviour is both semantically and
> conceptually primary, and might be applied  to any number of objects,
> possibly in error (e.g. calling the method on an unintended object
> instance).

The method is stateless (it keeps the state in the passed structure),
so there are no unintended object instances. Unless you mean calling
methods on uninitialized instances, which would be the same as doing
object->method(args) on a NULL pointer.

Remember that we are talking about doing OOP in C. This means that the
actual syntax will be:
object->method(object, args).

> In the construct object->method(args) the state is  primary,
> and calling the method is effectively guaranteed to apply to the correct
> instance of state (in C++ via the all-important internal 'this'
> pointer). We can even say that the set of methods is itself part of the
> state of the object.

This is a bit of a stretch, specially on languages like C++ that do
not allow dynamic extension of classes. A class is set in stone at
compile time, and cannot be modified - ergo, it is part of the global
state, not the object state. Just the same as a function in C.

> So while both might be regarded as kinds of OOP,
> the former example is more literally MOP - method-oriented programming,
> while the latter is SOP - state-oriented programming.

I beg to disagree. OOP is about objects and operations on objects.
Syntactic sugar over who goes first in left-to-right order is
irrelevant. Now, keeping the function table is useful for implementing
inheritance, and a vtable for polymorphism. But I hope the target is
not to reinvent those 2 things here.


-- 

Saludos,
Felipe Sateler

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/l

On 27/04/2012 14:43, Felipe Sateler wrote:
..
>>> I can see that. But OOP does not require a particular syntax:
>>> method(object, args) is as much OOP as object->method(args).
>>>
>>
>> But of course they are not equivalent. OOP canonically describes objects
>> in terms of (internal) state and (mostly public) behaviour. In the
>> construct method(object,args) the behaviour is both semantically and
>> conceptually primary, and might be applied  to any number of objects,
>> possibly in error (e.g. calling the method on an unintended object
>> instance).
>
> The method is stateless (it keeps the state in the passed structure),
> so there are no unintended object instances. Unless you mean calling
> methods on uninitialized instances, which would be the same as doing
> object->method(args) on a NULL pointer.
>

No, I don't mean that. I mean when you have more than one active object 
instance (lets, say, a number of oscillators), and you pass the struct 
representing the state of an oscillator to the method:


val = tick(osc1);

which e.g. updates an internal phase held in osc1,

it is easy to introduce a bug by (through such a thing as a typo) 
passing an unintended struct instance, e.g. osc2 when you meant osc1.
Whereas, when you call a C++ method on an osc, the language ensures 
methods are correctly associated with states. All I am saying is that 
there is a non-trivial difference between the two forms of expression - 
in the first the programmer holds the relation in their head, in the 
second the compiler does it for you. This is the sort of thing that is 
meant when commentators say C "allows" OOP, but C++ "supports" it. Of 
course, what is "support" for one programmer is "enforcement" to 
another, so YMMV.



> Remember that we are talking about doing OOP in C. This means that the
> actual syntax will be:
> object->method(object, args).
>

Sure. It's about as close to C++ as C can get, but semantically is still 
a bit of a chimera. And if you have both "object" and "object1", the 
typo situation can in principle still arise. With the liberal reliance 
on editor auto-completion, if anything such hazards are more rather than 
less likely. Auto-completion does make the use of long names more 
comfortable to work with, but it is also a reason why, in choosing 
names, the price is even more eternal vigilance. Hence, when doing "OOP 
in C", name selection and distinction is more than usually important.

Richard Dobson



------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net