|
Sorry for the late reply...well...I've followed the way u coded by changing the fprintf to fprintf (newfile, "Test: %s %s\n", str1.c_str(), str2.c_str()); but it doesn't seem to work. Is there anything I need to import or I've left it out?
|
|
|
|
|
(1)
Cabomba wrote: fprintf(newfile,"1" " %s" " %s", &str1[6], &str2[6] );
Sould probably be
fprintf(newfile, "1 %s %s", str1[6].c_str(), str2[6].c_str() );
(2) Why don't you use ofstream class to write to file?
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]
|
|
|
|
|
thanks for the reply but I'm not really sure how to use ofstream to print the string string to a txt file...
|
|
|
|
|
Hello everyone,
I am not sure whether I am wrong or the Windows Internals Book 4th version is wrong.
Here is what the book says in Chapter 7, Memory Management from Page 444 to Page 445
--------------------
Thus, the Process: Page File Bytes performance counter is actually the total process private committed memory, of which none, some or all may be in the paging file (In fact, it's the same as the Process: Private Bytes performance counter).
--------------------
This is what help from perfmon said about Page File Bytes Counter
--------------------
Page File Bytes is the current amount of virtual memory, in bytes, that this process has reserved for use in the paging file(s). Paging files are used to store pages of memory used by the process that are not contained in other files. Paging files are shared by all processes, and the lack of space in paging files can prevent other processes from allocating memory. If there is no paging file, this counter reflects the current amount of virtual memory that the process has reserved for use in physical memory.
Private Bytes is the current size, in bytes, of memory that this process has allocated that cannot be shared with other processes.
--------------------
Absolutely Page File Bytes and Private Bytes are different. Any comments?
thanks in advance,
George
|
|
|
|
|
Hello everyone,
I want to know why virtual function's footprint and performance is compared with normal function call.
Here is my analysis, please review whether I am correct. Thanks.
1. foorprint
class Foo
{
protected:
char * pName;
int nSize;
virtual void copyName(char* pN) {return;}
void virFunc() {return;}
};
Class Foo instance will consume 12 bytes other than 8 bytes to hold an additonal __vfptr pointing to the entry address of virtual function table. If we remove virtual keyword, the footprint of class Foo instance will consume only 8 bytes.
2. performance
2.1 Virtual function call's performance is worse than normal function call is because it needs to use __vfptr to find the virtual function table, then invokes the function. Here using __vfptr brings one more level of indirection compared with normal function call, which is the most important reason making the performance worse.
2.2 Are there anything else matters performance?
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?
Please comment whether my understanding of 1 and 2 are correct or not?
thanks in advance,
George
|
|
|
|
|
George_George wrote: 2.2 Are there anything else matters performance?
Usually algorithms matter.
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 
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]
|
|
|
|
|
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
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
