Post by firstname.lastname@example.org Post by bartc Post by email@example.com
double dx=(x2-x1), dy=(y2-x1); // Used *only* in next two lines
double distance = sqrt(dx*dx+dy*dy);
double angle = atan2(dy,dx);
If code only needs to use dx and dy in the second line above, and nowhere
else, it would be helpful to be able to end their scope immediately after
Why? If they really are used nowhere else, then a smart compiler will
Sure the compiler will know it, but if code needs to use similar temporary
variables more than once, it will be necessary to either change the second
usage from a declaration to an assignment, add a standalone declaration and
change both usages to assignment, or tweak the second usage to use different
names from the first. By contrast, if the scopes were limited, then such
issues would be avoided.
In cases involving pointers, limiting variable scope would have other
rectangle *rp = &someObject->bounds;
double objectX = (rp->left+rp->right) / 2;
double objectX = (rp->top+rp->bottom) / 2;
someObject = realloc(someObject, newSize);
if (!someObject) fatal_error();
Code like the above would leave a dangling pointer in scope. If rp
isn't going to be used after the computations of objectX and objectY,
the fact that it's left dangling after the realloc() would course be
no big deal, but if it rp is going to be used later on, it would be
necessary to reload it with &someObject->bounds.
This is general problem with using pointers in C programs.
When you have, say, a large tree full of pointers to elements of a
dynamic array, and you resize the array resulting in a new base address,
then all the thousands of pointers will be out of date.
By contrast, all non-static variables in functions should be considered
to be temporary working variables. Maybe you will detect the odd bug by
using the minimal possible scope envelope for each, but it's more likely
to make more work trying to program with and around such practices.
Lifetimes won't be in nice nested scopes but will overlap.
(This sounds a bit like the strict hierarchical import system on one of
my languages. It's hard to structure things to avoid mutual/circular
imports, and it restricts compilation order.
The next compiler will drop restrictions and life much easier.)
Post by firstname.lastname@example.org Post by bartc
I think there are already enough possibilities for scope inside
functions (so an infinite number of versions of the same identifier can
be used, and if that's not enough, you can use upper/lower case variations).
Those don't help if the *purpose* of a temporary variable is to set the
initialization value for something else, since ending the scope of the
temporaries would imply ending the scope of anything initialized therewith.
How about a special temporary variable, perhaps starting with "$", that
can only be used once? Your examples use them twice, meaning two
variables to replace rp for example. However source then starts to look
some compiler's intermediate code. HLLs are supposed to make life
simpler and take care of such details.