Printable View
I figured out how I can access my array but I have to manually increase the pointer to loop thru the entire array. I'm just wondering is this a good programming practice? or is there a better way to do this.
Ex.
int x[10];
int ptr_x;
ptr_x=x;
now if I want to use the pointer to change lets say x[1] I would have to add 1 to ptr_x;
it's called pointer arithmetic, but:
int *ptr_x;
it's perfectly acceptable to do traversals like that.
Why use a pointer?
Code:int x[10];
...
for ( int i = 0; i < 10; ++i )
{
cout << x[ i ] << endl;
}
I can't use global variables and I need to use like 5 different functions.
Why can't you pass the array to the functions?
they're faster. using an index means you have to *(arr + i), but using a pointer, it's just *ptr. You'd want to use pointers in inner loops of often-called code, for example.Quote:
Originally Posted by cpjust
Shouldn't a good compiler optimize it down to that anyways?Quote:
they're faster. using an index means you have to *(arr + i), but using a pointer, it's just *ptr.
Only if you have proved your point with profiler.Quote:
You'd want to use pointers in inner loops of often-called code, for example.
Otherwise you want everywhere to use code that is simplier to read
Unless you are JUST doing a loop for the purpose of walking through an array without actually doing anything with the array, I would say that there is no measurable difference between the two - if the array is huge, cache-misses will be more noticably than the addition of a pointer and the index. On x86 it is essentially just a more complex addressing mode to get there, which won't affect the time the processor takes to get there, only the size of the code will be different.
Of course, any modern compiler will understand these type of references, and optimize it.
There are situations where a pointer is more efficient, but for most purposes, if the code is easy to read, that is more important.
--
Mats
Pointer is better than Array , i hv a example
A array example:-
if we see in low level...... than we known that, there is a lots of step before adding these two value , first step to calculate the address of x[4] and How its calculate, look , first of all x array hv only hold its first element's address , and formulae of calculate addressing is { x's address + (type size)*(index no) } .Code:int x[10];
int ans = x[4] + x[5];
in array example , complier calculate more .
A Pointer Example:-
in this example complier calcute the address only one time, b/c ptr already hv the address of 4th index and if we add in address the we hv 5th index.Code:int x[10];
int *ptr = &x[4];
int ans = *ptr + *(ptr+1);
thats why pointer is better then array.
You have to show the assembly result of the compilation with the optimization turned on to prove your statement...
Otherwise its just a guess... And I belive - you guessed wrong.
I compared the assembly output of the MinGW port of g++ 3.4.2 with these two sample programs:Quote:
Pointer is better than Array , i hv a example
Code:// Sample Program A
int main()
{
int x[10] = {0};
int ans = x[4] + x[5];
}
Lo and behold, their assembly output with the -O1 optimisation flag was the same... and again for the -O2 flag!Code:// Sample Program B
int main()
{
int x[10] = {0};
int *ptr = &x[4];
int ans = *ptr + *(ptr+1);
}
(I only checked with -O1 and -O2.)
Compiler may do something like this:Quote:
Originally Posted by obaid
Note that those 4 * 4 and 5 * 4 are constants that the compiler will calculate during compilation.Code:lea ebx, x
mov eax, [ebx + 4 *4]
add eax, [ebx + 5 * 4]
mov ans, eax
Quote:
if we see in low level...... than we known that, there is a lots of step before adding these two value , first step to calculate the address of x[4] and How its calculate, look , first of all x array hv only hold its first element's address , and formulae of calculate addressing is { x's address + (type size)*(index no) } .
in array example , complier calculate more .
A Pointer Example:-
Code:int x[10];
int *ptr = &x[4];
int ans = *ptr + *(ptr+1);
I don't really see how this is more efficient. Did you have a different processor architecture in mind?Code:lea ebx, x
lea ebx, [ebx + 4 *4]
mov eax, [ebx]
add eax, [ebx+1 * 4]
mov eax, ans
If the compiler can figure out how to convert array indexes into pointer references, then it can do that for both of the above cases, so there's really no difference. I have not seen a compiler that does badly at this sort of things for the last several years, at least not GCC or Microsoft versions. If you use a different compiler, then I suggest you take a look at the code the compiler generates, and if there's really different results, then you probably want to look at what other compilers you can use.Quote:
in this example complier calcute the address only one time, b/c ptr already hv the address of 4th index and if we add in address the we hv 5th index.
thats why pointer is better then array.
--
Mats
Sir,
its not a assembly language problem , its a memory adressing management problem which hv to face the complier. okz
If you are trying to say that accessing by pointers is better than accessing by array indices because the compiler has to do more work in optimisation for the latter, then I think you are programming in the wrong language for your taste.Quote:
its not a assembly language problem , its a memory adressing management problem which hv to face the complier. okz
If not, how can your example possibly be valid when even at machine level both programs do exactly the same thing?
What do you mean? Calculating the address of x[4] or calculating address of x[0] and index with 4 * sizeof(int) are really equivalent in the computers mind.Quote:
Originally Posted by obaid
There are of course differences in some processor architectures which may make one or the other more efficient, but as long as the compiler can sort out that the code isn't going to be affected by "changing from one form to the other", it can do so.
Unless you specifically KNOW that the compiler generates particularly bad code for some PARTICULAR code, you can assume that any array references that can be easier/better solved with a temporary pointer variable, the compiler will use a temporary pointer.
However, if you start adding extra variables for the reason that you think the compiler won't solve the problem, you may find that the compiler generates WORSE code.
_IF_ you play around with code in this way, make sure:
1. That you retain the original code for future versions of the compiler, where it does compile it properly.
2. Verify that your code actually DOES run faster - and that the difference is noticable - reducing the prologue of a for-loop by one cycle in a loop that runs 2000 times isn't worth it.
3. Make CLEAR comments on why you do this.
4. Keep track of whether the next version of compiler actually does it equally well.
5. Make sure you are optimizing code that matters.
--
Mats
Well put.Quote:
Originally Posted by laserlight
--
Mats
Chapter 6. Correctness, simplicity, and clarity come first
Chapter 8. Don't optimize prematurely
"Spur not a willing horse (Latin proverb): Premature optimization is as addictive as it is unproductive. The first rule of optimization is: Don't do it. The second rule of optimization (for experts only) is: Don't do it yet. Measure twice, optimize once."
"It is far, far easier to make a correct program fast than it is to make a fast program correct."
Thankz For All , laserlight , matsp , vart .
may be my concept is wrong, but plz give me a good example to change my wrong concept!!!
thankz again.
I'm not sure it's as easy as "give me an example of where I'm wrong". First of all, the rules cpjust gives are useful - if your application runs in half a second, most people won't care if you get it down to a quarter second. Obviously, if it takes half a minute or more, there may be room for improvement. In this, find the part of code that runs for the longest time and try to find a way to make that run faster.
But the important rule here is also that "it's hard to beat the compiler".
And just to prove the point:
becomes [snipped for brevity]:Code:int func1(int *x)
{
int *ptr = &x[4];
int ans = *ptr + *(ptr+1);
return ans;
}
int func2(int *x)
{
int ans = x[4] + x[5];
return ans;
}
// Sample Program A
int main()
{
int x[10] = {0};
int i;
for(i = 0; i < 10; i++) {
x[i] = i;
}
printf("func1: %d, func2: %d\n", func1(x), func2(x));
return 0;
}
This is from gcc 3.4.2, with -fomit-frame-pointer -O3.Code:_func1:
movl 4(%esp), %edx
movl 20(%edx), %eax
movl 16(%edx), %ecx
addl %ecx, %eax
ret
.globl _func2
_func2:
movl 4(%esp), %edx
movl 20(%edx), %eax
movl 16(%edx), %ecx
addl %ecx, %eax
ret
So the difference between your two examples is absolutely NOTHING. Just a bit more C-code and harder to understand in example one, which isn't a benefit.
As I have said before, there are different processor architectures, and some C constructions may be more or less efficient in some ways, but as long as the result is correct, the compiler can pretty much do as it likes with how it generates the actual code.
It is entirely possible to make the compiler generate WORSE code by "confusing the compiler", e.g. using more variables and making things more complex.
--
Mats