|
Thanks CPallini,
1.
CPallini wrote: Usually algorithms matter.
Algorithm? We are talking about why virtual function degrate performance compared with normal function. My point is that it needs runtime (compared with compile time) getting the address of invoked function and it also needs to have a more level of indirection through __vfptr. Do you agree or think there are any other aspects which matter performance?
2.
CPallini wrote: George_George wrote:
2.3 How to find normal function call address can be determined during compile time and virtual function call address can only be determined during runtime?
I know the answer will be polymorphism, even if I cannot understand the question
My question is, for normal function call, how did an instance of a class find the address of function to be called (surely not through __vfptr).
regards,
George
|
|
|
|
|
In the same way it finds an address for a function called (eg) printf.
If it's within the same module, then the address is written into the calling function's code at link time, and a reference to that place stored in the module. When the module is loaded, part of window's module loader's job is to go through all those references and correct the addresses if the module is loaded at a different address to the one assumed at link time.
Which is why rebasing your DLLs can speed load performance.
If you're accessing from a different DLL, then the address will stored in the export table, probably C++ decorated. In which case, the overhead may end up being similar to a vtable.
This is from memory. Please don't write a post comparing my text to a windows text book's... I bet they're more right.
Iain.
|
|
|
|
|
Thanks Iain,
What do you mean rebase?
Iain Clarke wrote: Which is why rebasing your DLLs can speed load performance.
regards,
George
|
|
|
|
|
I'm too lazy to write an essay on the subject, so I did a google for rebase and dll, clicked on the first link, and got...
http://forums.amd.com/forum/messageview.cfm?catid=11&threadid=55403&enterthread=y[^]
Which seems to be a decent lengthy explanation.
If a DLL's default address (it's base address) is free in vertual memory, that's the address it will be loaded at, the the loaded has to do barely any work.
It it's clashing with an already loaded address, the loader has to load it at a different address, and go through all the code shifting pointers (including function addresses) about. This takes time, which can slow load time noticably. But it takes that time *once*.
Which is why it's a good idea to go to the link tab for the modules in your software, and change the base addresses away from the default.
Note, all these addresses are in the virtual address space of your process, which can be gappy. choose BIG differences in numbers.
Iain.
|
|
|
|
|
Thanks for your clarification, Iain!
I will read it.
regards,
George
|
|
|
|
|
George_George wrote: Algorithm? We are talking about why virtual function degrate performance compared with normal function. My point is that it needs runtime (compared with compile time) getting the address of invoked function and it also needs to have a more level of indirection through __vfptr. Do you agree or think there are any other aspects which matter performance?
I mean, is well known that VTABLE indirection causes a performance loss.
But in the real world usually algorithms matter and usually OOP advantages well balances the performance loss.
George_George wrote: My question is, for normal function call, how did an instance of a class find the address of function to be called (surely not through __vfptr).
Pointer?
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
[my articles]
|
|
|
|
|
Hi CPallini,
1.
CPallini wrote: But in the real world usually algorithms matter
I think you mean other aspect of algorithm other than the algorithm about how to implement virtual function mechanism. Right?
2.
CPallini wrote: Pointer?
The address should be able to resolved at compile time?
regards,
George
|
|
|
|
|
George_George wrote: I think you mean other aspect of algorithm other than the algorithm about how to implement virtual function mechanism. Right?
Of course, leave the virtual function implementation mechanism to compiler designer.
George_George wrote: The address should be able to resolved at compile time?
The address is resolved at compile time (in a broad sense, see Iain Clarke point about DLLs binding).
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
[my articles]
|
|
|
|
|
For points 1 and 2.1: yes, that's correct. As soon as you declare at least one virtual function in your class, a virtual function pointers table will be created and the class will keep a pointer to it, which increases its size.
George_George wrote: 2.2 Are there anything else matters performance?
No, not as far as I know . I don't see anything else that could.
George_George wrote: 2.3 How to find normal function call address can be determined during compile time and virtual function call address can only be determined during runtime?
When a function is not a virtual function, there is no need to "find" the address of the function: whenever the compiler encounter a call to a specific function of a class, it knows that for this specific class, the address of the function is X. Exactly the same way as for global functions. So, it does a direct call to that function.
For a virtual function, it needs to be more intelligent: it's not because I call a function on class Y that it is this one function that needs to be called by the compiler. It is possible that instead the 'compiler' needs to call a function from one of its derivate class (if the class is of that specific type). This is solved by using the virtual table, which is created when the class instance is constructed.
It's quite difficult to explain such things, so I hope my post is clear enough.
|
|
|
|
|
Thanks Cédric,
So in your below points, the address of normal function is resolved at compile time and the address of virtual function is resolved at runtime, right?
Cedric Moonen wrote: When a function is not a virtual function, there is no need to "find" the address of the function: whenever the compiler encounter a call to a specific function of a class, it knows that for this specific class, the address of the function is X. Exactly the same way as for global functions. So, it does a direct call to that function.
For a virtual function, it needs to be more intelligent: it's not because I call a function on class Y that it is this one function that needs to be called by the compiler. It is possible that instead the 'compiler' needs to call a function from one of its derivate class (if the class is of that specific type). This is solved by using the virtual table, which is created when the class instance is constructed.
regards,
George
|
|
|
|
|
If an app is minimized or hidden in the system tray, can we still find a handle to that app? Can we make FindWindow work in this regard? If so, how?
|
|
|
|
|
You could depend on our collective expertise, or....
...you could find out for yourself!
Write a program that does FindWindow, and test it when the victim app is not minimised. Then test it again when the victim is mimised.
Iain.
|
|
|
|
|
I found out that when the app is minimized to system tray, it cannot be found by using FindWindow because the window becomes hidden. Now is there any other way to find the window handle while its minimized in the system tray? I'm running out of ideas so please help me.
->Demsen
|
|
|
|
|
I apologise. I misread your question.
I'm assuming...
There is an application that when running makes a notification icon in the systray / notification area. If you (eg) double click on the icon, it will pop up a nice big dialog box with a name (WindowA) etc that you can FindWindow. But when you finish with that dialog, FindWindow no longer works?
If the dialog was simply being hidden or minimised, then FindWindow should still work - so it's being destroyed. BUT - for a notification icon to work, it must have a window (WindowB) for the shell to send messages to. This window creates WindowA when needed.
When WindowB is up, use Spy++ to look for it. It may not have a parent window, but it will be in the same process as WindowA. It will just take a good lot of looking through Spy++ to find it.
Close down as many programs as you can first, as they'll just make your hunt harder.
You will then get the problem of what to do with the window handle, but that's a separate question.
Iain.
|
|
|
|
|
demxine wrote: I found out that when the app is minimized to system tray, it cannot be found by using FindWindow...
I just tried it and it works fine.
"Normal is getting dressed in clothes that you buy for work and driving through traffic in a car that you are still paying for, in order to get to the job you need to pay for the clothes and the car and the house you leave vacant all day so you can afford to live in it." - Ellen Goodman
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
you could try the EnumWindows function...
|
|
|
|
|
How do i use EnumWindow in this context of OnCopyData?
void CWindowsDVRDlg::CheckTray()
{
LRESULT copyDataResult;
CString mainAppName = "Setup";
CString quitMessage = ("minimized");
CWnd *pOtherWnd = NULL;
//pOtherWnd = CWnd::FindWindow(NULL, (LPCTSTR) mainAppName);
if(pOtherWnd != NULL){
pOtherWnd->SetForegroundWindow();
COPYDATASTRUCT cpd;
cpd.dwData = 0;
cpd.cbData = quitMessage.GetLength()+1;
cpd.lpData = (PVOID)(LPCTSTR) quitMessage;
copyDataResult = pOtherWnd->SendMessage(WM_COPYDATA,
(WPARAM)AfxGetApp()->m_pMainWnd->GetSafeHwnd(),
LPARAM)&cpd);
quitMessage.ReleaseBuffer();
}
}
Should I just replace this line:
//pOtherWnd = CWnd::FindWindow(NULL,(LPCTSTR) mainAppName);
with EnumWindow() and would I be able to get the handle of the hidden window in the system tray? If not, any ideas please?
->Demsen
|
|
|
|
|
not quite... as msdn says "The EnumWindows function enumerates all top-level windows on the screen by passing the handle to each window"...so you will have to check each window handle you get to see if its the window you want...
u will have to fiddle around with a bit im not 100% sure it will fix ur problem...
|
|
|
|
|
demxine wrote: If an app is minimized or hidden in the system tray, can we still find a handle to that app?
Yes.
demxine wrote: Can we make FindWindow work in this regard?
Yes.
"Normal is getting dressed in clothes that you buy for work and driving through traffic in a car that you are still paying for, in order to get to the job you need to pay for the clothes and the car and the house you leave vacant all day so you can afford to live in it." - Ellen Goodman
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
The answer is both yes but how? Can you please post a code showing on how to make FindWindow, get a handle to an app minimized in the system tray (with regards to the OnCopyData code I've posted above)?
|
|
|
|
|
demxine wrote: The answer is both yes but how? Can you please post a code showing on how to make FindWindow, get a handle to an app minimized in the system tray...
Even if the application has been minimized to the taskbar notification area, you can still use FindWindow(), like:
HWND hWnd = FindWindow(NULL, _T("FaxWatch"));
"Normal is getting dressed in clothes that you buy for work and driving through traffic in a car that you are still paying for, in order to get to the job you need to pay for the clothes and the car and the house you leave vacant all day so you can afford to live in it." - Ellen Goodman
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
Hi!
I want to take a closer look to Microsofts Speech API version 5.3 (unmanaged).
The first thing: where can I obtain the API?
One source says, its part of the Platform SDK, the next it is part of the Windows SDK.
So, the Windows SDK is the newer one, but is the Windows SDK for Vista only?
Or can i run and develop Apps for Win2k, XP and Vista on a XP-Platform with it?
Regards!
|
|
|
|
|
Hello Friends,
I am creating a toolbar in which we are using an activeX control for search engine.When focus is on activex control Rich edit box and press alt key than alt key toggle to file menu of internet explorer but at the same time richeditbox hides. Pls give me a clue why it is so?
Thanks in advance.
Yes U Can ...If U Can ,Dream it , U can do it ...ICAN
|
|
|
|
|
.
Nobody can give you wiser advice than yourself. - Cicero
.·´¯`·->Rajesh<-·´¯`·.
Codeproject.com: Visual C++ MVP
|
|
|
|
|
ok, Thanks.
Yes U Can ...If U Can ,Dream it , U can do it ...ICAN
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
