Ah, now I get it! Actually, the main purpose of csdl.h is to enable the
dynamically loaded opcodes in csound5 to compile as they are written
without having to modify them to use the API.

Is that correct?

If so, I have no problem with csdl.h at all -- as long as Csound internally
does not directly or indirectly include csdl.h, or use the macros in it,
and as long as it is POSSIBLE to use the API to write new opcodes without
directly or indirectly including csdl.h, or using the macros in it. 

In other words, it should be possible for one to include only csound.h and
never see those macros, and only call the API to do what csdl.h does; or to
include csound.h and csdl.h (or maybe just csdl.h), and use the macros --
if one prefers.

Do you think that's possible?

Original Message:
-----------------
From: John ffitch jpff@cs.bath.ac.uk
Date: Wed, 19 Nov 2003 20:44:19 +0000 (GMT)
To: csound-dev@eartha.mills.edu
Subject: [CSOUND-DEV:3419] Re: Csound API Split, design


I totally disagree.  I dislike C++ because I cannot understand what it is 
doing.  A C macro is just a textual structure -- OK a LISP macro is nicer 
-- but it allowed the convertion of many opcode to loadable without 
changing the code, and moving back when there were problems.
==John


--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .