Greetings again,
I asked a friend who does a lot of C++ work to take a brief look at this.
He shook his head sadly at the use of macros instead of inline functions, the use of casts to obliterate type safety, of #define's instead of typedefs, and the obscuring of the likelihood that ->data is a struct. He said, basically, this is C, not C++, regardless of what the file extension says. I poked around some more and it looks like a lot of the Ugen code was lifted from another, older project-- maybe that was C code?
These are fair criticisms in general, but sometimes we do have our own reasons for implementing things the way we do. In other instances, we probably should adopt better practices. In the end, it's just how our warped minds work. Our goal isn't necessarily to make C++ happy, but rather to make ChucK users happy (and fitter, and more productive).
I'd be willing to do the gruntwork of search-and-replacing code, if someone who knows what they're doing wants to tell me pretty much exactly what to do. If nobody jumps up to do that over the next day or two, it'd probably be a better use of time to start learning CSound instead, and maybe have another look at ChucK in a few years if anyone gets it 64-bit safe by then.
I think it's gonna take a system-wide evaluation/fixing/testing to make things robustly 64-bit. Until then it's hard to say what needs to be done. We are fully planning to do that at some future point. For now, is it possible to compile ChucK in 32-bit mode under linux (similar to the 64-bit Apple G5)?
Ironically, I got interested in ChucK because CSound seemed a very kludgy way to do audio programming. - Oh well, there's always SuperCollider ;)
We think it's a good idea to learn as many languages as possible. Different tools tailored for different tasks! Best, Ge!