Re: compile error about destructor

From:

=?Utf-8?B?R2Vvcmdl?= <George@discussions.microsoft.com>

Newsgroups:

microsoft.public.vc.language

Date:

Wed, 20 Feb 2008 05:33:01 -0800

Message-ID:

<670D1E29-6AFE-405F-AB90-E39E8E860367@microsoft.com>

Hi Ben,

I have tried your code, and your code will cause application deadlock
symptom (after statement throw)? Hand-up? Here is the whole code,

#include <iostream>
#include <excpt.h>
#include <windows.h>

using namespace std;

class Foo
{
public:
Foo()
{
cout << "constructing Foo" << endl;
}

virtual ~Foo()
{
cout << "destrucing Foo" << endl;
}

};

void helper()
{
    int* address = NULL;
try{
    Foo foo1;
    (*address) = 1024;
} catch (...)
{
    cout << "access violation caught 1" << endl;
    throw;
}
}

int main()
{
__try{
        helper();
} __except (GetExceptionCode())
{
    cout << "access violation caught 2" << endl;
}
return 0;
}

regards,
George

"Ben Voigt [C++ MVP]" wrote:

George wrote:

Hi Ben,

void fhelper(void)
{
        this_could_fail();
        auto_ptr<T> temp = new T();
        temp->something_likely_to_fail();
}

void f2(void)
{
    __try {
        fhelper();
    }
    __finally {
    }
}

Now the local inside fhelper can be properly unwound when a
structured exception is thrown, because they exist in a unique stack
frame that the compiler support for SEH knows how to deal with.

In your solution, you cares about whether the destructor of local
will be called or not. I think you mean variable temp in your case,
which is the only local variable.

When there is structured exception thrown, I think even if you do not
put
the __try block into another function, destructor of temp will still
be called? Because either structured or unstructured (C++ exception)
will make stack unwinding. It is my mistake before which think
structured exception will not cause stack unwinding, but through
testing, it will.

Why do you think if we put everything into one function will not
invoke temp's destructor? I think even if there is structured
exception in something_likely_to_fail, destructor of temp is still
called.

Any more description please? Or you write a simple sample to prove
your ideas?

If you put everything in one function, it won't even compile. That's why
you started this thread, remember?