Deallocation upon constructor failure

[Dave]

Hello all,

In the program below, why am I not seeing operator delete being invoked? If
a constructor throws, isn't allocated memory supposed to be released and
then the exception re-propagated?

Thanks,
Dave
#include <iostream>

using namespace std;

class foo
{
public:
foo() { throw 1; }

static void *operator new(size_t s)
{
cout << "foo::operator new()" << endl;
return ::operator new(s);
}

static void operator delete(void *p)
{
cout << "foo::operator delete()" << endl;
::operator delete(p);
}
};

int main()
{
new foo;
}

[Alf P. Steinbach]

* Dave:

In the program below, why am I not seeing operator delete being invoked?

Because execution goes straight to std::terminate.

Catch that exception somewhere.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Dave]

> > In the program below, why am I not seeing operator delete being invoked?

Because execution goes straight to std::terminate.

Catch that exception somewhere.

Here's the program I'm now running per your suggestion:

#include <iostream>

using namespace std;

class foo
{
public:
foo() { throw 1; }

static void *operator new(size_t s)
{
cout << "foo::operator new()" << endl;
return ::operator new(s);
}

static void operator delete(void *p)
{
cout << "foo::operator delete()" << endl;
::operator delete(p);
}
};

int main()
{
try
{
new foo;
}
catch(...)
{
cout << "Exception handler" << endl;
}
}

OK, catching the exception in main() did allow foo::operator delete() to be
called. Here's the output:

foo::operator new()
foo::operator delete()
Exception handler

So, operator delete is called immediately after operator new().
Specifically, it is called before the exception is propagated on. Now my
question is: Why did I have to catch the exception in order for operator
delete to be called given that the call to operator delete() occurs before
any exception processing anyway? What is the real sequence of events going
on here, both with and without the exception handler?

Thanks!

[Alf P. Steinbach]

* Dave:

Now my question is: Why did I have to catch the exception in order for
operator delete to be called
As I recall, whether cleanup is performed or not when you have an unhandled
exception, is implementation defined.

given that the call to operator delete() occurs before
any exception processing anyway?
That statement, "anyway", is contrary to the facts you have established.

What is the real sequence of events going
on here, both with and without the exception handler?

With: operator delete, catch handler, normal exit.
Without: std::terminate, bye.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Dave]

"Dave" <be***********@yahoo.com> wrote in message
news:11*************@news.supernews.com...

In the program below, why am I not seeing operator delete being

invoked?
Because execution goes straight to std::terminate.

Catch that exception somewhere.
Here's the program I'm now running per your suggestion:

#include <iostream>

using namespace std;

class foo
{
public:
foo() { throw 1; }

static void *operator new(size_t s)
{
cout << "foo::operator new()" << endl;
return ::operator new(s);
}

static void operator delete(void *p)
{
cout << "foo::operator delete()" << endl;
::operator delete(p);
}
};

int main()
{
try
{
new foo;
}
catch(...)
{
cout << "Exception handler" << endl;
}
}

OK, catching the exception in main() did allow foo::operator delete() to

be called. Here's the output:

foo::operator new()
foo::operator delete()
Exception handler

So, operator delete is called immediately after operator new().
Specifically, it is called before the exception is propagated on. Now my
question is: Why did I have to catch the exception in order for operator
delete to be called given that the call to operator delete() occurs before
any exception processing anyway? What is the real sequence of events going
on here, both with and without the exception handler?

Thanks!

As it turns out, I believe I have a non-compliant compiler.5.3.4/17
indicates my deallocation function should be called regardless of whether or
not the exception is caught.