9 Mar
2004
9 Mar
'04
3:37 p.m.
On Tue, Mar 09, 2004 at 06:49:46PM +0100, Tim Goetze wrote:
thanks for providing the code. i'll not argue it
is not complete
seeing that it seems impossible to obtain ladspa.h or gcc from your
workplace. :)
It's not impossible to get them, and in fact I'm using five versions
(for different targets) of g++ daily. It's just that I'm not paid to
do this during work hours, so I limited the code to the essential part.
In fact Alcatel Space paid for all the replies to your posts today.
without making an absolute estimate of the complexity
of your snippet,
and presuming it will compile and work flawlessly, i think it is safe
to say it is more complex than the PortInfo proposal.
But still trivially simple. If someone writing a host falls over this,
he will probably never reach the end. There are much more complicated
issues to deal with.
next, i would like you to consider that if this
mechanism becomes
reality, we'll have to give a watertight explanation in the ladspa
header.
Sure.
also still in dire need of explanation is the fact
that an array is
referenced as 'PortNames' but contains data that will not fit this
name.
"For historical reasons". It's in the good company of the 'gecos'
field in /etc/passwd for example.
i do admit the mechanism is elegant, and makes for a
compact object
file. but these are secondary virtues, with no good reason given why
they should preceed primary virtues: readability, simplicity, fool-
proof operation, versatility.
I never claimed compactness or versatility as a virtue. It *is* readable
and simple. Nothing in C is ever foolproof - an invalid pointer will
hit you no matter how you implement the enums. There's the demolition
tool to test for this.
lastly, you still haven't given a good reason why
non-integer values
should not be associated with labels.
As I said, it's a different problem. And your proposal is a clean way
to solve part of it. But IMHO it should be generalised, but then it
probably enters the RDF domain.
--
Fons