A programming alias is much the same as an alias used for a person’s
identity. Consider how you can declare a sub from a C++ DLL in your program. If
necessary or desirable, you can give it an alias too:
Declare Sub MySub Lib "z:\MyLibrary.DLL" Alias "_MySub"
(Arg1 as string, Arg2 as string)
In this case, the alias was necessary because the function name in the library
begins with a leading underscore, which isn’t legal in VB. The declaration
enables you to call the _MyFunction routine in the
library by the name MyFunction, which VB will accept.
Even though you have two different names for the function, both names refer to
the same function.
This optimization is concerned with the kind of aliasing that occurs when the
same object in memory is referred to by more than one name. Assume, for example,
you use the MySub routine (previously sketched) like
this:
Dim szName as string
MySub szName, szName
According to the declaration statement, MySub receives
two string variables as arguments. This example meets that requirement, even though
the two variables happen to be the same. When MySub is
called, the arguments are passed and MySub does whatever
it needs to do with the argument variables. There is nothing special about that,
is there?
Ordinarily, no. But recall that, by default, VB passes arguments by reference.
Instead of passing by value, in which a routine receives copies of the arguments
passed on the stack, the two arguments passed to MySub are
actually the memory locations of the string variables.
Because it no longer is working with a copy of the argument variable, a routine
that receives an argument by reference has the power to change the original variable
by modifying the value stored at its location in memory.
The MySub example is a special case. The same variable
is used for both of its arguments, and both arguments are passed by reference.
This means that MySub receives the same memory location
for each argument. Therefore if MySub modifies the
value of one of its arguments, it will unknowingly also modify the other argument
as well.
From the perspective of an optimizing compiler, this poses a problem. One of
the general forms of optimization mentioned earlier is register optimization,
in which values are kept as easily accessible to the CPU as possible. When multiple
variables refer to the same memory location, only one instance of the variable
needs to be copied to a CPU register. That is, if the address of the first instance
of szName is already in a register, copying the address of the second instance
of szName is redundant. But how is the compiler supposed
to know that the two arguments are really identical?
Register optimization can be confusing when two arguments actually refer to
the same thing, so VB ordinarily avoids this problem by not doing this kind of
optimization. If you use Assume No Aliasing as an optimization, you are telling
the compiler that each variable name you use refers to a value held in a memory
location separate and distinct from the values referred to by every other variable
name. This opens up the prospect of successful register optimization. If you inadvertently
slip in a dual reference, however, you may actually slow down your program.
