Csound › Csound - Dev

ENVIRON

Classic

List

Threaded

8 messages Options

Istvan Varga

ENVIRON

I have changed most functions that take a Csound instance pointer as first
argument to consistently use ENVIRON* type instead of a random mix of sometimes
ENVIRON* and other times void* (this also allowed for removal of the annoying
casts from void* to ENVIRON*). ENVIRON is now also declared if you #include
csound.h, but only as an "opaque" type of which the contents cannot be accessed.

One question that remains is whether ENVIRON should be changed to use a name
that better describes its function as a C equivalent of a Csound class (e.g.
CSOUND or CSOUND5 - 7 character names are preferred because they preserve
code and comment formatting). Any ideas ?

-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Csound-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/csound-devel

Michael Gogins

Re: ENVIRON

Thanks. I prefer CSOUND.

Regards,
Mike

-----Original Message-----
From: Istvan Varga <[hidden email]>
Sent: Aug 11, 2005 6:13 AM
To: [hidden email]
Subject: [Cs-dev] ENVIRON

I have changed most functions that take a Csound instance pointer as first
argument to consistently use ENVIRON* type instead of a random mix of sometimes
ENVIRON* and other times void* (this also allowed for removal of the annoying
casts from void* to ENVIRON*). ENVIRON is now also declared if you #include
csound.h, but only as an "opaque" type of which the contents cannot be accessed.

One question that remains is whether ENVIRON should be changed to use a name
that better describes its function as a C equivalent of a Csound class (e.g.
CSOUND or CSOUND5 - 7 character names are preferred because they preserve
code and comment formatting). Any ideas ?

-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Csound-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/csound-devel

-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Csound-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/csound-devel

Istvan Varga

Re: ENVIRON

So, should I rename the structure to CSOUND ?

Michael Gogins wrote:

> Thanks. I prefer CSOUND.
>
> -----Original Message-----
> From: Istvan Varga <[hidden email]>
> Sent: Aug 11, 2005 6:13 AM
> To: [hidden email]
> Subject: [Cs-dev] ENVIRON
>
> One question that remains is whether ENVIRON should be changed to use a name
> that better describes its function as a C equivalent of a Csound class (e.g.
> CSOUND or CSOUND5 - 7 character names are preferred because they preserve
> code and comment formatting). Any ideas ?

Michael Gogins

Re: ENVIRON

In reply to this post by Istvan Varga

Yes, by all means rename it to CSOUND.

You have never indicated your opinion of my frequent suggestion to make CSOUND a real C++ class and all the function pointers would just be virtual member functions. As I have said before there is a good alias between C functions and C++ functions if the C++ class is a completely virtual class.

I am completely confident that this would make Csound easier to maintain and extend without any untoward side effects. The C API would simply be an alias for the C++ class.

What do you think?

Regards,
Mike

-----Original Message-----
From: Istvan Varga <[hidden email]>
Sent: Aug 12, 2005 9:41 AM
To: [hidden email]
Subject: Re: [Cs-dev] ENVIRON

So, should I rename the structure to CSOUND ?

Michael Gogins wrote:

-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Csound-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/csound-devel

-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Csound-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/csound-devel

Istvan Varga

Re: ENVIRON

Michael Gogins wrote:

> Yes, by all means rename it to CSOUND.

It is now renamed to CSOUND (struct CSOUND_).

> You have never indicated your opinion of my frequent suggestion
> to make CSOUND a real C++ class and all the function pointers
> would just be virtual member functions.

What is the major problem with having a C interface ?

-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Csound-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/csound-devel

Michael Gogins

Re: ENVIRON

There is no "problem" with a C interface which, of course, must be retained.
And I must say, the C interface seems to be in much better shape lately,
partly thanks to your work.

Still there are some real advantages to a native C++ interface:

The association of the CSOUND *instance pointer with all functions becomes
automatic.

The maintenance of the Csound API function table becomes automatic.

It becomes very difficult to re-introduce global variables to Csound and
easier to exclude them.

It becomes possible to very easily derive new classes from Csound.

It becomes easy to generate a Python (PERL, Lisp, C#, what have you)
interface to Csound using SWIG.

Regards,
Mike

----- Original Message -----
From: "Istvan Varga" <[hidden email]>
To: <[hidden email]>
Sent: Friday, August 12, 2005 3:10 PM
Subject: Re: [Cs-dev] ENVIRON

> Michael Gogins wrote:
>
>> Yes, by all means rename it to CSOUND.
>
> It is now renamed to CSOUND (struct CSOUND_).
>
>> You have never indicated your opinion of my frequent suggestion
> > to make CSOUND a real C++ class and all the function pointers
> > would just be virtual member functions.
>
> What is the major problem with having a C interface ?
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle
> Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Csound-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

john ffitch

Re: ENVIRON

As you explained it, it relied on an implementation detail rather
than a language feature, and so I for one am not happy with building in
a trap.
==John ffitch

-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Csound-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/csound-devel

Michael Gogins

Re: ENVIRON

In reply to this post by Istvan Varga

I understand what you're saying, and I too would avoid traps.

But it isn't much of a trap. If the implementation changes, the alias changes, but Csound keeps working in its C++ API. Then we would have to write some glue code to keep the C API working.

Actually, I don't much care which way the alias goes. Csound could be implemented as a simple C++ class aliased to a C API, or it could be implemented as a C API with a virtual function table and aliased to a simple C++ class. I prefer the first because it automates a lot of maintenance. But the second would still permit a C++ programmer to derive a new class from CSOUND.

Regards,
Mike

-----Original Message-----
From: [hidden email]
Sent: Aug 13, 2005 3:44 AM
To: [hidden email]
Cc: [hidden email]
Subject: Re: [Cs-dev] ENVIRON

As you explained it, it relied on an implementation detail rather
than a language feature, and so I for one am not happy with building in
a trap.
==John ffitch

-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Csound-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/csound-devel

-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Csound-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/csound-devel