|
Hi friends,
If I have an array containing integer and I want to access elements of it using pointers.
int i=0;
int *ptr=array;
int value=0;
for(i=0; i < 10;i++)
value=*(ptr+i);
for(i=0; i < 10;i++)
value=*ptr++;
Is there any performance hit of
value=*(ptr+i);
over
value=*ptr++;
Vikram S
|
|
|
|
|
Please look the updated code
int array[]={1,2,3,4,5,6,7,8,9,10};
int i=0;
int *ptr=array;
int value=0;
for(i=0; i < 10;i++)
value=*(ptr+i);
for(i=0; i < 10;i++)
value=*ptr++;
|
|
|
|
|
vikrams wrote: for(i=0; i < 10;i++)
value=*ptr++;
should be a little faster than:
vikrams wrote: for(i=0; i < 10;i++)
value=*(ptr+i);
But it's likely to be the same with: value=array[i]
|
|
|
|
|
vikrams wrote: for(i=0; i < 10;i++)
value=*(ptr+i);
for(i=0; i < 10;i++)
value=*ptr++;
I don't know if the compiler is able to optimize this, but if we disregard from eventual compiler optimizations the second for-loop will be faster.
Consider the first for-loop.
For each round-trip you...
1) increase the value of i which is held in a register
2) load the address of ptr into another register
3) add the value of i to the register holding ptr
4) assign to value using indirect addressing
Now consider the second for-loop.
For each round-trip you...
1) increase the value of i which is held in a register
2) assign the value of i using indirect addressing
There's more to it than this, but I've omitted parts that are the same for both for-loops such as calculation of the size of the data type pointed to and similar.
It's possible that the compiler is smart enough to optimize the first for-loop so it would generate the same machine code as if you would have written ptr[i], which I beleive would generate the fastest execution, but you have to look at the generated assembler code to be able to figure that one out. An exercise for the reader.
Hope this helps
--
Roger
It's supposed to be hard, otherwise anybody could do it!
|
|
|
|
|
Microsoft VC++ 6.0 compiler generated following code
for: value=*(ptr+i);
mov edx, DWORD PTR _i$[ebp]
mov eax, DWORD PTR _ptr$[ebp]
mov ecx, DWORD PTR [eax+edx*4]
mov DWORD PTR _value$[ebp], ecx
for: value=*ptr++;
mov eax, DWORD PTR _ptr$[ebp]
mov ecx, DWORD PTR [eax]
mov DWORD PTR _value$[ebp], ecx
mov edx, DWORD PTR _ptr$[ebp]
add edx, 4
mov DWORD PTR _ptr$[ebp], edx
|
|
|
|
|
Yep, the compiler optimizes the first for-loop and generates the exact same assembler as ptr[i].
Conclusion:
Writing *(ptr + i) generates faster code than *ptr++.
However, for readability reasons I recommend writing ptr[i].
Have a nice weekend
--
Roger
It's supposed to be hard, otherwise anybody could do it!
|
|
|
|
|
It generates faster code because there is no code to update the value of ptr. The two operations do different things so it is like comparing apples and oranges.
You may be right
I may be crazy
-- Billy Joel --
Within you lies the power for good - Use it!
|
|
|
|
|
PJ Arends wrote: It generates faster code because there is no code to update the value of ptr.
You're talking about the resulting assembler code and in that aspect it's obvious.
However, I was not sure how the compiler would deal with the (ptr + i) operation since I haven't tested it, which I hope was clear enough in my previous post.
PJ Arends wrote: The two operations do different things
Nope. Both for-loops walks through the array getting the value of each element and assigns it to 'value'.
However, the statement for getting the value of each element is different, but I interpreted vikram's question as if this doesn't matter.
Like you said: "You may be right, I may be crazy".
Have a nice weekend PJ
--
Roger
It's supposed to be hard, otherwise anybody could do it!
|
|
|
|
|
I guess my problem is not in setting up the initial directory for the
CFileDialog but rather in changing it when the dialog is up and running.
When the user selects a file type from file type selection list, say
.bmp type file, for example, I want the path changed from the current
dialog path to a bitmap directory. Any idea of how to get the dialog
change to a different directory?
Thanks for your help.
Linus
|
|
|
|
|
Subclass CFileDialog and override OnTypeChange which will get called when the user selects another filter.
Hope this helps
--
Roger
It's supposed to be hard, otherwise anybody could do it!
|
|
|
|
|
hi,
very nice, but how will i change now the Path to my specified? e.g C:\\Templates!
like Word 2003 when i will save a Doc as Dot?
|
|
|
|
|
I assume you know that if you write a path to a directory in the filename field and click 'Open', your file list will be updated with contents of that directory.
You can simulate this behaviour by the following steps:
1. Save the eventual already written information in the filename field
2. Paste the desired directory path to the filename field
3. Send a WM_COMMAND message simulating a click on the 'Open' button
4. Restore the previously wrriten contents of the filename field
Read Hans Dietriech's excellent article[^] if you need more info of how to do this in code.
Hope this helps
--
Roger
It's supposed to be hard, otherwise anybody could do it!
|
|
|
|
|
Do you need to save current path for next time?
|
|
|
|
|
|
hi,
I am getting an MIDL2039 warning when you compile an .idl file .
Can anyone plz help me?
Thanx in advance,
skuu
|
|
|
|
|
I guess you've added the oleautomation keyword to an interface definition.
The MIDL compiler is complaining about the interface not being compliant with oleautomation, e.g you've used variables that cannot be represented with a VARIANT.
Or in other words from MSDN:
"MIDL2039 : interface is not automation marshaling conformant, requires Windows NT 4.0 SP4 or greater
The interface does not meet the requirements for an OLE Automation interface. Check to make sure the interface is derived from IUnknown or IDispatch."
Hope this helps
--
Roger
It's supposed to be hard, otherwise anybody could do it!
|
|
|
|
|
thank u roger.
I like to know whether it is possible to disable this warning.
rgds,
skuu
|
|
|
|
|
By settings the 'oleautomation' option for an interface you ask the MIDL compiler for help making sure that the interface is compliant with the automation standard.
Asking for the compilers help and then tell it to shut up doesn't make any sense.
Remove the 'oleautomation' keyword from the interface definition instead.
Hope this helps
--
Roger
It's supposed to be hard, otherwise anybody could do it!
|
|
|
|
|
Hello,
I'm translating my application to different languages using resources files. I don't know how to manage different configurations of my Visual C++ project for each language. I've never done it before.
Can somebody point me to an article discussing that subject?
Thanks,
Sincerely
Allad
----
Navigator - Your best alternative to Windows Explorer
|
|
|
|
|
google for "resources DLL"
You need to create a small DLL containing only the resources for the different language.
When loading the application, you will load the appropriate resource DLL, either from the current locale, or from a user setting.
Maximilien Lincourt
Your Head A Splode - Strong Bad
|
|
|
|
|
Thanks for replying.
But I don't wan't to create a language DLL. I just want to have a different configuration of my project for each language.
Can you help?
Allad
----
Navigator - Your best alternative to Windows Explorer
|
|
|
|
|
hi,
I want to develop an application in VC++ , which can read data from USB port
but i try with getting hardware address for USB port like parallel port 0x378,0x379,0x37A , at last i can't able to do for USB port can any one knew means ,plz forward the corresponding things
If it is possible or not
it's very urgent
send reply
|
|
|
|
|
Hi, it's a little harder to read from an USB port instead of a RS232 port, but here's some source code for you: http://www.lvr.com/hidpage.htm[^] (Resources for Developers of USB Devices in the Human Interface Device Class)
|
|
|
|
|
You have to communicate with a device driver for the USB device since you cannot access hardware from user mode.
Most USB device drivers adds one or more virtual COM ports that can be used the same way as any ordinary COM port, i.e. using ::CreateFile(), ::ReadFile(), ::WriteFile() and so on.
Have a look in Hardware Programming section[^] for more info about how to communicate with COM ports and similar.
Hope this helps
--
Roger
It's supposed to be hard, otherwise anybody could do it!
|
|
|
|
|
You don't communicate with the USB port in the same way as, say, a COM port, but with the device attached to the USB port via the driver.
The tigress is here
|
|
|
|