Well, at least this is the case for
Windows float and double, isn't it ?
Probably, since all hardware on Windows seem to be using
the very common IEEE 754 format for floating points. But
that isn't something required by the C standard, some sys-
tems may use a different bit representation for floating
points.
I've done it many times and it always worked fine :
&a is the address of 'a' so it's its memory location.
Well, you were lucky. The standard doesn't define what
the result of subtracting pointers not within the same
object is (or, in the case of arrays, one beyond the
end of the array), so you are relying on whatever your
compiler makes out of it. Some other compiler might
give you a different result.
Except for this actual example (when variables are stored
in stack w/ their adresses allocated by the compiler)
There also is no requirement for a stack in the C stan-
dard. Most (or probably all) compilers will employ
something stack-like for local variables, but that is
a decision the compiler writer makes, not something
prescribed by the standard.
if the location of 'a' thru 'z' are well stored
(i.e, like in an array) then the following code works fine :
unsigned int size = (unsigned int)( &z - &a );
Yes, it may seem to work on your system with the specific
compiler you are using. If you want your program to work
only on that system and with that compiler then this is
probably all fine, just dont expect it to work anymore
under different circumstances.
Hum, no : if &z is the highest address
and &a is the lowest address then (&z - &a)
is the number of bytes (less one sizeof) and not the
number of variables (unless 'a' and 'z' are chars)
That may well be the case. Since you are relying on un-
defined behaviour everything you get is "right". Just for
the fun of it: on my system (x86-64 Linux and with gcc)
the output of this program
#include <stdio.h>
int main( void )
{
double a, b;
printf( "%d\n", ( int ) ( &a - &b ) );
return 0;
}
is -1. So obviously at least some of the deductions you
were led to make by the behaviour on your system aren't
valid from what I see on my machine. And that's quite
ok since the behaviour of that program isn't defined,
so whatever the output is is correct. (And I have de-
finitely worked with machines were variables defined
later had lower addresses).
For even more giggles take this program:
#include <stdio.h>
int main( void )
{
double a, b, c;
printf( "%d\n", ( int ) ( &a - &c ) );
return 0;
}
The output on my machine is still -1...
But I am a bit puzzled - I would expect the difference
between two pointers of the same type to be number of
variables of that type in between, not the number of
bytes. Otherwise the behaviour (while undefined) would
be even more weird on your machine since e.g. for
arrays you can rely on the difference between the
addresses of two of its elements to be the number of
elements in between. But then, again, the moment you
do something undefined everything can happen.
Since you try to treat these variables (at least in the
respect of initialization) as if they make up an array,
would it be possible to atually use an array? Then ini-
tialization is rather simple:
double a2z[ 26 ] = { 0.0 };
Yes of course, but the problem is that these
variables names are not as simple as 'a'...'z'
and they are used individually (am I clear here ?)
So then, to use your suggestion I should do something like
#define VAR_THIS d[0]
#define VAR_THAT d[1]
#define VAR_SOMETHING d[2]
... etc ...
#define VAR_MAX 10 // for instance
double d[VAR_MAX];
memset( d, 0, VAR_MAX * sizeof(d[0]) );
VAR_THIS = ... ;
VAR_THAT = ... ;
x = ... VAR_THIS ... VAR_THAT ... ;
... but then, to write the whole set
of #define looks a bit heavy to me !
Of course, this is the probably even worse than
writing
a = b = c = .... = z = 0.0;
since it's much harder to understand. The only conclusion
is that what you want to do can't be done in a portable
fashion in C.
Refards, Jens