Hi, Sunir Shah!
On 22 Jul 97 03:11:26 you wrote to Thomas Maeder
SS> void foo( int& HeyIMagicallyAlterYourVariableWithoutTellingYou )
TM> Hey, look again! I tell you I alter your variable! I'm a reference!
SS> Hey, look again! The caller doesn't have a clue.
That's the very point about it. The caller will not change the code it the
implementator decide padd by value is not efficient and switch to pass-by
ref. The passing so can be really transparent.
(But taking it word-by-word the caller of course have a clue, he must read
the dox or at least look at the prototype. And if you simply afraid about a
founction writing back to your variables unnoticably, you probably put things
upside down. Such behavior have to be documented very strongly, and be known
to user. And it's not a bit related to tech of passin, be it address, ref or
anything. )
SS> This is by far my biggest gripe with C++. It turns it into BASIC.
I can't see anything resembling basic.
SS> /* 2. Declaring data in random places */
SS> int HiIAmRandomlyDeclaredHere;
TM> This feature alone makes it worth for a C programmer to use a C++
TM> compiler to compile his code.
SS> I've been making heavy use of the right-click/Go to Definition feature
SS> in VC++ lately.
:) Good feature. But under normal circumstances one use it only to find
globals. Local variables are defined just when they're introduced, ie. where
you start really using them. That point must be clear for a programmer.
Keeping them separate, at the beginning { is not really order, just like when
you drag everything from your desktop to the drawer. :)
TM> If you always declare a variable where you initialize it, you'll never
TM> forget to erase the declaration when you don't need the variable any
TM> more. More, you won't read from an uninitialized variable.
SS> Yes/no... it would be ok if everyone programmed in nice blocks. It's
SS> not a major issue, it's just annoying that I lose track of data.
If you lose track of data that proggy is probably poorly designed. And AFAIK
no tools or cude syntac can fix poor design.
SS> It's because I'm still having problems coupling data with code. To
SS> me, they're separate things... code operates on data. Objects are
SS> both. Data is not separated.
I did never call local temporary variables "data". To me, data is something
ermanent. variables, like one used as `for(int i=1; ... )' is just part of
code like the for statement. So why it should be declared elsewhere?
TM> int HiIAmRandomlyDeclaredHere = ButICannotFindWhereHereIs;
SS> Yes, but where is ButICannotFindWhereHereIs? ;)
Does that matter? It already has the proper value. If you want to track it
back, think out where it could be initialised in a meaningful way the first
time, and probably there it will be. :)
Paul
... Ki, ha nem mi, ‚s mikor, ha nem most???
--- OS/2 Warp
---------------
* Origin: The FlintStones' Cave in BedRock (2:371/20)
|