JC> or even something as simple as:
JC> #define evilfunc(arg) func(&arg)
Ugh! That's beyond evil... and ugly to boot.
JC> This allows C code to cause problems just like C++ code can - in the
JC> client code, it doesn't look like any pointers are involved at all,
JC> it appears that whatever is passed as an argument can't possibly be
JC> affected by the function.
I'd say it's worse. In C, I'm justified in assuming that a passed
argument won't be affected. In C++, I should be aware of references and
the possibility that my argument will be affected.
JC> I think there are two basic lessons here: 1) you can write as bad of
JC> code as you want to, almost regardless of language, and 2) if you us
JC> code without knowing at least a little about what it does, you get
JC> exactly what you deserve.
I'd add a third lesson - it's easy to blame a language when in fact the
fault is bad coding practice.
Regards,
Daniel ddjones@pinn.net
---
þ RM 1.31 1604 þ _ __ _/ < | The evolution of humanity
---------------
* Origin: Selective Source Virginia Beach, VA (757)471-6776 (1:275/102)
|