Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations IamaSherpa on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
a[10] == 10[a]; how is that?
- Thread starter Lim
- Start date
WHAT DO YOU MEAN BY 10[a]???????? How should i read this?
This will certanly generate a compile error, first of all because 10 is a NUMBER, not a variable. I'm sorry i'm unable to check that now.
The thing about a[10] == *(a+10) is absoultely correct, but that 10[a]...
What did u ment by that?
This will certanly generate a compile error, first of all because 10 is a NUMBER, not a variable. I'm sorry i'm unable to check that now.
The thing about a[10] == *(a+10) is absoultely correct, but that 10[a]...
What did u ment by that?
lim,
a[index] == *(a+index) b'cos a[index] internally takes address of a and adds index elements to reach the value a[index]...
but certainly what u say is idiotic
-() b'cos address of index added with 'a' elements is gonna not make sense!!
-hth,
shail.
--
There are three methods for writing code in which no bug can be found:
1) Make the code so straightforward that there are obviously no bugs.
2) Make the code so complicated that there are no obvious bugs.
3) Insist that any apparent bugs were really intentional features.
a[index] == *(a+index) b'cos a[index] internally takes address of a and adds index elements to reach the value a[index]...
but certainly what u say is idiotic
-() b'cos address of index added with 'a' elements is gonna not make sense!!-hth,
shail.
--
There are three methods for writing code in which no bug can be found:
1) Make the code so straightforward that there are obviously no bugs.
2) Make the code so complicated that there are no obvious bugs.
3) Insist that any apparent bugs were really intentional features.
When you use array subscripting notation:
a[10];
The compiler automatically converts it to:
*(a+10);
Therefore:
10[a];
equals:
*(10+a);
They produce the same results, just as when adding 1+2 it doesn't matter whether you type:
1+2 or 2+1
Certainly, it's not good programming practice to write
10[a] instead of a[10], but it's perfectly legal.
Nice when people call other people idiots (shail) by implication, particularly when the person saying "idiotic" is dead wrong.
Russ
bobbitts@hotmail.com
a[10];
The compiler automatically converts it to:
*(a+10);
Therefore:
10[a];
equals:
*(10+a);
They produce the same results, just as when adding 1+2 it doesn't matter whether you type:
1+2 or 2+1
Certainly, it's not good programming practice to write
10[a] instead of a[10], but it's perfectly legal.
Nice when people call other people idiots (shail) by implication, particularly when the person saying "idiotic" is dead wrong.
Russ
bobbitts@hotmail.com
- Thread starter
- #9
OK, I wrote the following code to test this:
int main(){
int a[10];
a[9] = 1;
9[a] = 1;
}
ran : gcc -S test.c
and this is the contents of test.s:
.file "test.c"
.version "01.01"
gcc2_compiled.:
.text
.align 4
.globl main
.type main,@function
main:
pushl %ebp
movl %esp, %ebp
subl $56, %esp
movl $1, -20(%ebp)
movl $1, -20(%ebp)
leave
ret
.Lfe1:
.size main,.Lfe1-main
.ident "GCC: (GNU) 2.96 20000724 (experimental)"
look at the 2 movl lines, these are exactly the same and correspond to the a[9] and 9[a] statements, which proves that the statements are exactly equivalent. If this is not in the specifications of the langugage, it could be compiler dependent, but I doubt it.
I've had a programming languages class where I've designed a language, and the a are probably just an indication to add a nd b together to get a new address. The compiler does not check what kind of data type a is, or it would generate an error. Anyway, since it just adds a and b
we know that a+b == b+a
therefore, the statements a and b[a] are equivalent when b is a number and a is a variable!
hth As always, I hope that helped!
Disclaimer:
Beware: Studies have shown that research causes cancer in lab rats.
int main(){
int a[10];
a[9] = 1;
9[a] = 1;
}
ran : gcc -S test.c
and this is the contents of test.s:
.file "test.c"
.version "01.01"
gcc2_compiled.:
.text
.align 4
.globl main
.type main,@function
main:
pushl %ebp
movl %esp, %ebp
subl $56, %esp
movl $1, -20(%ebp)
movl $1, -20(%ebp)
leave
ret
.Lfe1:
.size main,.Lfe1-main
.ident "GCC: (GNU) 2.96 20000724 (experimental)"
look at the 2 movl lines, these are exactly the same and correspond to the a[9] and 9[a] statements, which proves that the statements are exactly equivalent. If this is not in the specifications of the langugage, it could be compiler dependent, but I doubt it.
I've had a programming languages class where I've designed a language, and the a are probably just an indication to add a nd b together to get a new address. The compiler does not check what kind of data type a is, or it would generate an error. Anyway, since it just adds a and b
we know that a+b == b+a
therefore, the statements a and b[a] are equivalent when b is a number and a is a variable!
hth As always, I hope that helped!
Disclaimer:
Beware: Studies have shown that research causes cancer in lab rats.
Think about it, this is how it's translated:
a + b
to the abstract syntax tree:
+
/ a b
so, a[10] =
[]
/ a 10
and 10[a] ==
[]
/ 10 a
and as long as you get one pointer and one integer, it's a valid statement as far as teh compiler is concerned. Keep in mind that the compiler does not read your source in as it's typed, it has to be translated to be understood, and if you look at the syntax tree, it makes perfect sense why both are valid statements, right?
As always, I hope that helped!
Disclaimer:
Beware: Studies have shown that research causes cancer in lab rats.
a + b
to the abstract syntax tree:
+
/ a b
so, a[10] =
[]
/ a 10
and 10[a] ==
[]
/ 10 a
and as long as you get one pointer and one integer, it's a valid statement as far as teh compiler is concerned. Keep in mind that the compiler does not read your source in as it's typed, it has to be translated to be understood, and if you look at the syntax tree, it makes perfect sense why both are valid statements, right?
As always, I hope that helped!
Disclaimer:
Beware: Studies have shown that research causes cancer in lab rats.
- Status
Similar threads
