[snips]
On Thu, 10 Apr 2008 03:13:31 -0700, Nick Keighley wrote:
> It is *not* a design flaw of C++.
It's not? Okay, so explain to me, when you see this:
string a = someval;
func(a);
how you tell, without hunting for the prototype or definition of func,
whether a will be modified.
Oh, right, you can't.
Yes, references are nice, references are good. *Hiding* the fact that
something may smash your values into chaos without even a hint that this
might occur is a design flaw.
Tell me, do you tend to use global variables a lot? No? Why not?
I'll tell you why not: because experience has taught you that doing so
leads to chaos, as you can never be quite entirely certain, without
tedious analysis, whether some other bit of code somewhere may modify the
variable just when you need it's unmodified value.
Hey, guess what? *Exactly* the same problem - something "else" may be
modifying your value, without so much as a hint of an indication that it
even *might* be doing this, and why? Because somewhere, buried in all
that mess of code you're maintaining, is a function which *looks like*
it's getting a *value* but which is actually getting a reference... it's
just hiding the fact.
Yeah, references are nice and fine and dandy, but hiding the fact that
something may be sma****ng your data is *not* nice, it's about a bad a
design as one could come up with, short of actually making everything
global.
Make it _obvious_ that there's a reference involved, that changes
things. If that code, for example, read as func( ref a ); then you know,
right when you see the function call, that there's a reference involved,
a is probably going to be modified, whereas func(a);, unless a is a
pointer, is not going to have the same issue.
C++ is a fun language in a lot of ways and it brings in boatloads of
goodies many another language could benefit from... but this is not one
of its good points, this hiding the fact of references.
|
