Re: A question about destructor
#include <fstream>
#include <string>
using namespace std;
class HowMany {
static int objectCount;
public:
HowMany() { objectCount++; }
static void print(const string& msg = "")
{
if(msg.size()!=0)
cout << msg << ":" << "objectCount = " << objectCount << endl;
}
~HowMany()
{
objectCount--;
print("~HowMany()");
}
};
int HowMany::objectCount = 0;
HowMany f(HowMany x)
{
x.print("x argument inside f()");
return x;
}
int _tmain(int argc, TCHAR* argv[], TCHAR* envp[])
{
int nRetCode = 0;
// initialize MFC and print and error on failure
if (!AfxWinInit(::GetModuleHandle(NULL), NULL, ::GetCommandLine(), 0))
{
// TODO: change error code to suit your needs
_tprintf(_T("Fatal Error: MFC initialization failed\n"));
nRetCode = 1;
}
else
{
HowMany h;
HowMany::print("after construction of h");
HowMany h2 = f(h);
HowMany::print("after call to f()");
}
return nRetCode;
}
I'm a C++ beginner,and now I have three questions:
1. Why the destructor will be called at the end of "HowMany f(HowMany x) "
function, I think the "x" object is not a new object, it's an object
passed
from outside of this function.
The object is passed by value. This means that a temp object is created for
passing to the function.
That object will be deallocated when the function call is over.
2. Why the desturctor will be called twice at the end of main function.
because there are 2 stack based objects in your main function: h and h2.
both will be deallocated at the end of the main function.
3. It is not related with the code sample. I wonder CLS is really useful
to
C++? Is it better than MFC?
With CLS you mean the .NET framework?
The ability to do interop with .NET code is very valuable IMO, since it
allows C++ to have the advantages of C++, as well as the ability to use the
enormous amount of features of .NET.
MFC is primarily usefull for writing large native applications. though I
have to say I have never used it much, I don't think that .NET will replace
MFC soon because they are geared towards different things.
--
Kind regards,
Bruno van Dooren
bruno_nos_pam_van_dooren@hotmail.com
Remove only "_nos_pam"