The basic vs c/c++ discussion will always be, no matter what. Usually lead by c/c++ ppl protecting their job, and basic ppl protecting their basic. :)
There're a lot of ppl who say that inheriting too much leads to messy code. I never inherit. I treat my code as icons/components in a modular system with wires (think synthesizers). The stuff I connect to eachother is flat, no inherited stuff.
Exactly how did you write B+ code? Could be the same way I did.. (see the B+ tutorial-section, 'own gadgets')
Having all the gadgets, images and variables stored as ints in banks and use global functions as 'methods' for those variables. Perfect datahiding, and nearly like classes.
You use constants for the peek/poke adresses? Or do you remember all the stuff? Or do you make quick tables as reference (like I did in the tuts)?
The way I write my flat objects in Bmax is exactly like those components in a modular synth. The object has inputs and outpus and wiretypes. As long as all the ins/outs/wiretypes don't change, you can simply replace any object without a milllion others not working anymore.
There're a lot of ppl who say that inheriting too much leads to messy code. I never inherit. I treat my code as icons/components in a modular system with wires (think synthesizers). The stuff I connect to eachother is flat, no inherited stuff.
Exactly how did you write B+ code? Could be the same way I did.. (see the B+ tutorial-section, 'own gadgets')
Having all the gadgets, images and variables stored as ints in banks and use global functions as 'methods' for those variables. Perfect datahiding, and nearly like classes.
You use constants for the peek/poke adresses? Or do you remember all the stuff? Or do you make quick tables as reference (like I did in the tuts)?
The way I write my flat objects in Bmax is exactly like those components in a modular synth. The object has inputs and outpus and wiretypes. As long as all the ins/outs/wiretypes don't change, you can simply replace any object without a milllion others not working anymore.