compile error about destructor
-
Try compiling without the /EHsc switch. As opposed to SEH, C++ exception handling model supports "stack unwinding". It is aware of automatic objects, and it calls their destructors. Basically, use C++ exception handling where it is possible, and fallback to SEH only when there are no other ways. See here.
"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 DavidCrow, I compile with /EHa in my question and experiment. If you have Visual Studio, you can have a try. :-) 1. If you remove destructor, it is fine; 2. If you change to try/catch, it is fine. I do not know why. regards, George
-
Hi DavidCrow, I compile with /EHa in my question and experiment. If you have Visual Studio, you can have a try. :-) 1. If you remove destructor, it is fine; 2. If you change to try/catch, it is fine. I do not know why. regards, George
George_George wrote:
2. If you change to try/catch, it is fine.
As opposed to SEH, C++ exception handling model supports "stack unwinding". It is aware of automatic objects, and it calls their destructors.
George_George wrote:
I do not know why.
Now you do.
"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
-
George_George wrote:
2. If you change to try/catch, it is fine.
As opposed to SEH, C++ exception handling model supports "stack unwinding". It is aware of automatic objects, and it calls their destructors.
George_George wrote:
I do not know why.
Now you do.
"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 DavidCrow, But even if in my sample, we use try/catch, we are still dealing with structured exception -- access violation, and access violation is not a C++ exception. :-) So, when change to try/catch, I do not agree with you we are in C++ exception category. Any comments?
DavidCrow wrote:
As opposed to SEH, C++ exception handling model supports "stack unwinding". It is aware of automatic objects, and it calls their destructors.
regards, George
-
No zengkun100, The destructor could be invoked even if it is structured exception, if you change my code from __try to try, and change __except to catch. Here is the output, constructing Foo destructing Foo access violation caught You can see if we change the keyword, structured exception is caught and destructor is called before handler. Not as you quoted -- "If an exception occurs, the destructor cannot be called.". regards, George
George_George, the answer is very clear now. Different keyword, different exception handling method. Use C++ exception handling whenever possible :)
A Chinese VC++ programmer
-
George_George, the answer is very clear now. Different keyword, different exception handling method. Use C++ exception handling whenever possible :)
A Chinese VC++ programmer
Any rule in C++ mentioned we can not use object with destructor in __try block with /EHa compile option? I can not find. So, I do not agree. :-) regards, George
-
Hi DavidCrow, But even if in my sample, we use try/catch, we are still dealing with structured exception -- access violation, and access violation is not a C++ exception. :-) So, when change to try/catch, I do not agree with you we are in C++ exception category. Any comments?
DavidCrow wrote:
As opposed to SEH, C++ exception handling model supports "stack unwinding". It is aware of automatic objects, and it calls their destructors.
regards, George
George_George wrote:
...we use try/catch, we are still dealing with structured exception...
Not according to everything that I've read on the subject. Microsoft's
__try/__catchis SEH. Perhaps you should read this."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
-
Moving out Foo foo1 will result in the same compile error, my purpose of this post is to find the root cause of compiler error, i.e. at which point I violate the C++ standard. Any ideas, Iain? regards, George
George_George wrote:
at which point I violate the C++ standard
At the point of using MS-specific SEH.
Let's think the unthinkable, let's do the undoable, let's prepare to grapple with the ineffable itself, and see if we may not eff it after all.
Douglas Adams, "Dirk Gently's Holistic Detective Agency" -
George_George wrote:
...we use try/catch, we are still dealing with structured exception...
Not according to everything that I've read on the subject. Microsoft's
__try/__catchis SEH. Perhaps you should read this."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
Yes, DavidCrow. What I do not agree with you is you mentioned when there is structured exception, during stack unwinding, the local object's destructor is not called. Through my experiment, it is not true. You can try the following code and see if structured exception occurs, like access violation, during stack unwinding, destructor is also called. So the question can be asked in two ways, 1. Why __try/__except does not work with structured exception with destructor; 2. Why try/catch work with structured exception with destructor. Now we are talking about (2).
#include #include #include using namespace std; class Foo { public: Foo() { cout << "constructing Foo" << endl; } virtual ~Foo() { cout << "destrucing Foo" << endl; } }; int main() { int* address = NULL; try{ Foo foo1; (*address) = 1024; } catch (...) { cout << "access violation caught" << endl; } return 0; }
regards, George -
Any rule in C++ mentioned we can not use object with destructor in __try block with /EHa compile option? I can not find. So, I do not agree. :-) regards, George
George_George wrote:
So, I do not agree.
You are getting stubborn.
George_George wrote:
Any rule in C++ mentioned we can not use object with destructor in __try block with /EHa compile option?
The C++-Standard is not about MS-specific compiler internal like
/EHaor__tryWhich with its two leading underscores clearly says "I am vendor-specific". Fact is, that you can tell the compiler to use C++ exceptions and you can tell the compiler to use the Standard-predating SEH.Let's think the unthinkable, let's do the undoable, let's prepare to grapple with the ineffable itself, and see if we may not eff it after all.
Douglas Adams, "Dirk Gently's Holistic Detective Agency" -
George_George wrote:
at which point I violate the C++ standard
At the point of using MS-specific SEH.
Let's think the unthinkable, let's do the undoable, let's prepare to grapple with the ineffable itself, and see if we may not eff it after all.
Douglas Adams, "Dirk Gently's Holistic Detective Agency"Hi jhwurmbach, More detals? I replied with detailed description and verification sampples, http://www.codeproject.com/script/Forums/View.aspx?fid=1647&select=2403023&fr=39#xx2403023xx[^] regards, George
-
George_George wrote:
So, I do not agree.
You are getting stubborn.
George_George wrote:
Any rule in C++ mentioned we can not use object with destructor in __try block with /EHa compile option?
The C++-Standard is not about MS-specific compiler internal like
/EHaor__tryWhich with its two leading underscores clearly says "I am vendor-specific". Fact is, that you can tell the compiler to use C++ exceptions and you can tell the compiler to use the Standard-predating SEH.Let's think the unthinkable, let's do the undoable, let's prepare to grapple with the ineffable itself, and see if we may not eff it after all.
Douglas Adams, "Dirk Gently's Holistic Detective Agency"So jhwurmbach, your point is __try and __except does not work with local object with destructor? Is there a rule in MSDN covering this? Please read to get my analysis, http://www.codeproject.com/script/Forums/View.aspx?fid=1647&select=2403023&fr=35#xx2403023xx[^] regards, George
-
So jhwurmbach, your point is __try and __except does not work with local object with destructor? Is there a rule in MSDN covering this? Please read to get my analysis, http://www.codeproject.com/script/Forums/View.aspx?fid=1647&select=2403023&fr=35#xx2403023xx[^] regards, George
George_George wrote:
Please read to get my analysis,
We are not here to do your work, George. Most of us have jobs, so we help here when we can, not every time you find something that you disagree with. A little due diligence on your part will go a long way.
"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
-
Yes, DavidCrow. What I do not agree with you is you mentioned when there is structured exception, during stack unwinding, the local object's destructor is not called. Through my experiment, it is not true. You can try the following code and see if structured exception occurs, like access violation, during stack unwinding, destructor is also called. So the question can be asked in two ways, 1. Why __try/__except does not work with structured exception with destructor; 2. Why try/catch work with structured exception with destructor. Now we are talking about (2).
#include #include #include using namespace std; class Foo { public: Foo() { cout << "constructing Foo" << endl; } virtual ~Foo() { cout << "destrucing Foo" << endl; } }; int main() { int* address = NULL; try{ Foo foo1; (*address) = 1024; } catch (...) { cout << "access violation caught" << endl; } return 0; }
regards, GeorgeOkay. SEH is different from C++ exception.
__try __catchblock indicates that this is a SEH, andtry catchindicates that this is a C++ exception. MSDN said that :in Visual C++ 2005, all objects in scope when the asynchronous exception is generated will not be destroyed even if the asynchronous exception is handled.where asynchronous exception is SEH. In your code, Foo's destructor will not be called, so compiler generates an error. If you comment this linecout << "destrucing Foo" << endl;int Foo's destructor, and your code will be compiled.A Chinese VC++ programmer
-
Okay. SEH is different from C++ exception.
__try __catchblock indicates that this is a SEH, andtry catchindicates that this is a C++ exception. MSDN said that :in Visual C++ 2005, all objects in scope when the asynchronous exception is generated will not be destroyed even if the asynchronous exception is handled.where asynchronous exception is SEH. In your code, Foo's destructor will not be called, so compiler generates an error. If you comment this linecout << "destrucing Foo" << endl;int Foo's destructor, and your code will be compiled.A Chinese VC++ programmer
Great, zengkun100! 1.
zengkun100 wrote:
Foo's destructor will not be called, so compiler generates an error. If you comment this line cout << "destrucing Foo" << endl; int Foo's destructor, and your code will be compiled.
No. You can try to comment out the statements in destructor and the compiler error still exists. 2. try/catch can catch structured exception, in my case, access violation is not a C++ exception and is a structured exception, agree? But try/catch can catch it and calling destructor, unwinding stack quite well. You can try (2) by changing my sample from __try to try and __except to catch(...). regards, George
-
George_George wrote:
Please read to get my analysis,
We are not here to do your work, George. Most of us have jobs, so we help here when we can, not every time you find something that you disagree with. A little due diligence on your part will go a long way.
"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
Thanks all the same, DavidCrow! I appreciate your participation. :-) regards, George
-
Great, zengkun100! 1.
zengkun100 wrote:
Foo's destructor will not be called, so compiler generates an error. If you comment this line cout << "destrucing Foo" << endl; int Foo's destructor, and your code will be compiled.
No. You can try to comment out the statements in destructor and the compiler error still exists. 2. try/catch can catch structured exception, in my case, access violation is not a C++ exception and is a structured exception, agree? But try/catch can catch it and calling destructor, unwinding stack quite well. You can try (2) by changing my sample from __try to try and __except to catch(...). regards, George
I don't know which compiler you use. My IDE is VS2008 beta 2, after I commented the line, the program compiled successfully.MSDN said that
Arguments a The exception-handling model that catches asynchronous (structured) and synchronous (C++) exceptions. s The exception-handling model that catches C++ exceptions only and tells the compiler to assume that extern C functions do throw an exception. c If used with s (/EHsc), catches C++ exceptions only and tells the compiler to assume that extern C functions never throw a C++ exception. /EHca is equivalent to /EHa. Remarks Use /EHs to specify the synchronous exception handling model (C++ exception handling without structured exception handling exceptions). If you use /EHs, then your catch clause will not catch asynchronous exceptions. Also, in Visual C++ 2005, all objects in scope when the asynchronous exception is generated will not be destroyed even if the asynchronous exception is handled. Under /EHs, catch(...) will only catch C++ exceptions. Access violations and System..::Exception exceptions will not be caught. Use /EHa to specify the asynchronous exception handling model (C++ exception handling with structured exception handling exceptions). /EHa may result in a less performant image because the compiler will not optimize a catch block as aggressively, even if the compiler does not see a throw. Use /EHa if you want to catch an exception raised with something other than a throw. The following sample will generate an exception: Copy Code // compiler_options_EHA.cpp // compile with: /EHa #include #include using namespace std; void fail() { // generates SE and attempts to catch it using catch(...) try { int i = 0, j = 1; j /= i; // This will throw a SE (divide by zero). } catch(...) { // catch block will only be executed under /EHa cout<<"Caught an exception in catch(...)."<<endl; } } int main() { __try { fail(); } // __except will only catch an exception here __except(EXCEPTION_EXECUTE_HANDLER) { // if the exception was not caught by the catch(...) inside fail() -
So jhwurmbach, your point is __try and __except does not work with local object with destructor? Is there a rule in MSDN covering this? Please read to get my analysis, http://www.codeproject.com/script/Forums/View.aspx?fid=1647&select=2403023&fr=35#xx2403023xx[^] regards, George
George_George wrote:
So jhwurmbach, your point is __try and __except does not work with local object with destructor?
NO. His point is that C++ spec is not going to discuss vendor specific compiler options. I don't understand why anyone would even need to explain that, it seems so obvious.
George_George wrote:
Is there a rule in MSDN covering this?
Zengkun100 already posted it. If you are not going to read peoples replies with the intention of listening to them and understanding them what is the point?
led mike
-
I don't know which compiler you use. My IDE is VS2008 beta 2, after I commented the line, the program compiled successfully.MSDN said that
Arguments a The exception-handling model that catches asynchronous (structured) and synchronous (C++) exceptions. s The exception-handling model that catches C++ exceptions only and tells the compiler to assume that extern C functions do throw an exception. c If used with s (/EHsc), catches C++ exceptions only and tells the compiler to assume that extern C functions never throw a C++ exception. /EHca is equivalent to /EHa. Remarks Use /EHs to specify the synchronous exception handling model (C++ exception handling without structured exception handling exceptions). If you use /EHs, then your catch clause will not catch asynchronous exceptions. Also, in Visual C++ 2005, all objects in scope when the asynchronous exception is generated will not be destroyed even if the asynchronous exception is handled. Under /EHs, catch(...) will only catch C++ exceptions. Access violations and System..::Exception exceptions will not be caught. Use /EHa to specify the asynchronous exception handling model (C++ exception handling with structured exception handling exceptions). /EHa may result in a less performant image because the compiler will not optimize a catch block as aggressively, even if the compiler does not see a throw. Use /EHa if you want to catch an exception raised with something other than a throw. The following sample will generate an exception: Copy Code // compiler_options_EHA.cpp // compile with: /EHa #include #include using namespace std; void fail() { // generates SE and attempts to catch it using catch(...) try { int i = 0, j = 1; j /= i; // This will throw a SE (divide by zero). } catch(...) { // catch block will only be executed under /EHa cout<<"Caught an exception in catch(...)."<<endl; } } int main() { __try { fail(); } // __except will only catch an exception here __except(EXCEPTION_EXECUTE_HANDLER) { // if the exception was not caught by the catch(...) inside fail()Thanks zengkun100, Your reply is great! Two more comments, 1.
zengkun100 wrote:
Use /EHs to specify the synchronous exception handling model (C++ exception handling without structured exception handling exceptions). If you use /EHs, then your catch clause will not catch asynchronous exceptions. Also, in Visual C++ 2005, all objects in scope when the asynchronous exception is generated will not be destroyed even if the asynchronous exception is handled. Under /EHs, catch(...) will only catch C++ exceptions. Access violations and System..::Exception exceptions will not be caught.
It means under /EHs mode, structured exception still exists, but we can not catch it and destructor of local object is not called during structured exception triggered stack unwinding. Right? BTW: but I have proved it is not true. I have posted my sample below and if you compile with /EHsc and you can see the output is -- means destructor is still called during stack unwinding, not the same as the above statement from MSDN. -------------------- constructor destructor -------------------- 2. I have wrote some code to verify that when using /EHa, during exception triggered stack unwinding, the destructor of local object is invoked. Could you help to review my code to see whether both my conclusion and the code are correct please? :-)
#include <iostream> using namespace std; class Foo { public: Foo() { cout << "constructor" << endl; } virtual ~Foo() { cout << "destructor" << endl; } }; int main () { int i = 1; int j = 0; try{ Foo foo; i = i / j; } catch (...) { cout << "catch structured exception -- division by zero" << endl; } }
My output: -------------------- constructor destructor catch structured exception -- division by zero -------------------- have a good weekend, George -
George_George wrote:
So jhwurmbach, your point is __try and __except does not work with local object with destructor?
NO. His point is that C++ spec is not going to discuss vendor specific compiler options. I don't understand why anyone would even need to explain that, it seems so obvious.
George_George wrote:
Is there a rule in MSDN covering this?
Zengkun100 already posted it. If you are not going to read peoples replies with the intention of listening to them and understanding them what is the point?
led mike
Thanks led mike,
led mike wrote:
NO. His point is that C++ spec is not going to discuss vendor specific compiler options. I don't understand why anyone would even need to explain that, it seems so obvious.
I agree and for myself, I will not use __try/__except, and I just need to maintain some legacy code. :-) have a good weekend, George