|
Wasn't support for makefiles removed in VC.net? I think you have to use a command line option like "vcbuild". There is more information here[^].
Alternatively, this[^] may be of use.
|
|
|
|
|
He wanted to export the settings (to get a mak-File).
Greetings from Germany
|
|
|
|
|
KarstenK wrote: He wanted to export the settings (to get a mak-File)
Did I not understand his question? I think he wanted to generate a c++ makefile, but there is no support for makefiles in VC.net (or if there is I am not aware of it).
|
|
|
|
|
Hi KarstenK,
I'm looking for a Microsoft Developer Studio Generated NMAKE File. There was an option to generate the .mak file in Visual C++ 6.0 Version [Project->Export MakeFile], that option is not available in Visual Studio.Net. I'm looking for that.
Please share if you know how to generate .
thanks and regards,
Rajesh
|
|
|
|
|
Rajesh_Parameswaran wrote: i KarstenK,
I'm looking for a Microsoft Developer Studio Generated NMAKE File. There was an option to generate the .mak file in Visual C++ 6.0 Version [Project->Export MakeFile], that option is not available in Visual Studio.Net. I'm looking for that.
Please share if you know how to generate .
I'm 90% sure you can't do this in VC.net
|
|
|
|
|
I am using a picture box and a static control. I am trying to render the video on the picture box so whenever the video is render the picture box gets painted . I have placed a static control on top of the picture box and I have painted the frame of the static control. My problem is whenever the picture box is painted during render the video my static control also gets painted and the painted frame is washed out. I want the painted frame to remain the same even the picture box is painted.I getting flickers if i repaint the static control.
|
|
|
|
|
I didnt underatsn why u r keeping the static control on top of the picture box
but the way u can make static control trasparent is.. over ride the OnCtlColor handlr and do the followin
HBRUSH UrDialog::OnCtlColor(CDC* pDC, CWnd* pWnd, UINT nCtlColor)
{
HBRUSH hBr = CDialog::OnCtlColor( pDC, pWnd, nCtlColor );
if (nCtlColor == CTLCOLOR_DLG || nCtlColor == CTLCOLOR_STATIC)
{
//hBr = m_BkGndBrush;
pDC->SetBkMode(TRANSPARENT);
}
return hBr;
}
|
|
|
|
|
Hi, I had a problem in printing a String class string to a file where I had declared:
string str1[10], str2[10];
And in str1[6] and str2[6] has the values which I wanna store the values by writing them to a txt file using the format:
// write to apsignal.txt
newfile= fopen("apsignal.txt","w");
if (newfile==NULL)
{
cout<<"Error opening apsignal.txt";
fclose(newfile);
return -1;
}
//Print to file with the signal strengths and corresponding clientIDs.
fprintf(newfile,"1" " %s" " %s", &str1[6], &str2[6] );
fclose(newfile);
however, it seems like it cannot print out the values in the txt file as it is a string class? So I was wondering if anyone can give me other alternatives to write the values into this text file?
Thanks! I had put in the coding below and pls take a look at the apsignal.txt and you will know what I mean. Thanks for any help!
ap1.txt:
Variable = .iso.org.dod.internet.private.enterprises.9.9.273.1.3.1.1.3.1.8.105.118.116.108.95.97.112.49.0.32.166.80.182.220<br />
Value = Integer32 -38<br />
<br />
End of MIB subtree.<br />
ap2.txt:
Variable = .iso.org.dod.internet.private.enterprises.9.9.273.1.3.1.1.3.1.8.105.118.116.108.95.97.112.49.0.32.166.80.182.220<br />
Value = Integer32 -40<br />
End of MIB subtree.<br />
apsignal.txt:
1 ÌÌÌÌa<I ÌÌÌÌÑ_I
The program:
#include <stdio.h><br />
#include <stdlib.h><br />
#include <cstdio><br />
#include <conio.h><br />
#include <time.h><br />
#include <fstream><br />
#include <iostream><br />
#include <windows.h><br />
#include <string><br />
#include "carpark.h"<br />
#include <cstdlib><br />
<br />
<br />
int temp (void);<br />
int output(void);<br />
<br />
using namespace std;<br />
<br />
int clientID = 1;<br />
int row,col;<br />
<br />
<br />
float signalstrength[2][2];<br />
int main(void)<br />
{<br />
int count=1;<br />
while(count<20)<br />
{<br />
count++;<br />
<br />
output();<br />
<br />
Sleep(1);<br />
<br />
}<br />
<br />
<br />
return 0;<br />
<br />
}<br />
<br />
<br />
int temp(void)<br />
{<br />
<br />
<br />
system("snmputil walk 192.168.200.91 public .1.3.6.1.4.1.9.9.273.1.3.1.1.3 > ap1.txt");<br />
<br />
system("snmputil walk 192.168.200.92 public .1.3.6.1.4.1.9.9.273.1.3.1.1.3 > ap2.txt");<br />
<br />
<br />
return 0;<br />
<br />
<br />
<br />
<br />
}<br />
<br />
<br />
int output(void)<br />
{<br />
string str1[10], str2[10];<br />
float num1,num2;<br />
FILE *newfile; <br />
<br />
ifstream ap1File("ap1.txt");<br />
if(! ap1File)<br />
{<br />
cout<<"Error opening ap1.txt!"<<endl;<br />
ap1File.close();<br />
return -1;<br />
}<br />
<br />
while(! ap1File.eof())<br />
{<br />
for (row = 0; row<8; row++)<br />
{<br />
<br />
ap1File>>str1[row];<br />
<br />
}<br />
cout<<str1[6]<<endl; <br />
}<br />
ap1File.close();<br />
<br />
ifstream ap2File("ap2.txt");<br />
<br />
if(! ap2File)<br />
{<br />
cout<<"Error opening ap2.txt!"<<endl;<br />
ap2File.close();<br />
return -1;<br />
}<br />
<br />
while(!ap2File.eof())<br />
{<br />
for (row=0;row<8;row++)<br />
{<br />
ap2File>>str2[row];<br />
<br />
<br />
}
<br />
<br />
}<br />
ap2File.close();<br />
cout<<str2[6]<<endl;<br />
<br />
newfile= fopen("apsignal.txt","w");<br />
if (newfile==NULL)<br />
{<br />
cout<<"Error opening apsignal.txt";<br />
fclose(newfile);<br />
return -1;<br />
}<br />
<br />
<br />
fprintf(newfile,"1" " %s" " %s", &str1[6], &str2[6] );<br />
fclose(newfile);<br />
<br />
<br />
cout <<"complete output()"<<endl;<br />
<br />
return 0;<br />
}
|
|
|
|
|
1/ You don't need that amount of code.
2/ Use pre tag, instead of code.
By doing string str [16] , you made 16 separate strings, not one string 16 characters long.
You have two choices...
a/ Use chars, and be class C code.
char str1 [16], str2 [16];
strcpy (str1, "hello");
strcpy (str2, "world");
newfile= fopen("apsignal.txt","w");
fprintf (newfile, "Test: %s %s\n", str1, str2);
b/ Use the string class.
std::string str1, str2;
str1 = "hello";
str2 = "world";
newfile= fopen("apsignal.txt","w");
fprintf (newfile, "Test: %s %s\n", str1.c_str(), str2.c_str());
That's from memory - it might be cstr instead of c_str.
I hope that helps,
Iain.
|
|
|
|
|
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 DLL s 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
|
|
|
|
|