delete and exception

[Neelesh Bodas]

Hi all,
suppose the ctor of the class throws. Thus, at this point in time, some
memory has been allocated but the object couldnot be constructed. Also,
the memory is not yet freed. Does the c++ std automatically guarantee
the call to operator delete?

The relavent code is :

class Int {
public:
Int()
{
throw 100;
}
~Int()
{
// this will never be called, since the ctor throws.
}
};
int main()
{
Int *p = new Int;

// will p be deleted at this point without doing an explicit call to
delete (provided the ctor throws)?
}

TC++PL Edition 3, 14.4.5 says that the memory should be freed. But it
doesnot say clearly whether it will be freed by calling operator
delete() or something else.
Thanks in advance
Neelesh,

[Ivan Vecerina]

"Neelesh Bodas" <ne***********@gmail.com> wrote in message
news:11**********************@o13g2000cwo.googlegr oups.com...
: Hi all,
: suppose the ctor of the class throws. Thus, at this point in time, some
: memory has been allocated but the object couldnot be constructed. Also,
: the memory is not yet freed. Does the c++ std automatically guarantee
: the call to operator delete?
Yes.

: TC++PL Edition 3, 14.4.5 says that the memory should be freed. But it
: doesnot say clearly whether it will be freed by calling operator
: delete() or something else.

Each new operator has a corresponding delete-operator, which is called
automatically when the construction of an allocated object fails.

In the standard, this is described in §5.3.4/17:
<<< If any part of the object initialization described above terminates by
throwing an exception and a suitable deallocation function can be found,
the deallocation function is called to free the memory in which the object
was being constructed, after which the exception continues to propagate in
the context of the new-expression. If no unambiguous matching
deallocation function can be found, propagating the exception does not
cause the object's memory to be freed. [Note: This is appropriate when
the called allocation function does not allocate memory; otherwise, it is
likely to result in a memory leak. ] >>>

This is actually the (only) purpose of placement-delete operators:
When defining a placement-new operator on your own, you must also
provide a matching placement-delete operator (with the same extra
parameters), which will be called to released allocated memory
in case a constructor throws.

hth -Ivan
--
http://ivan.vecerina.com/contact/?subject=NG_POST <- email contact form
Brainbench MVP for C++ <> http://www.brainbench.com

[Neelesh Bodas]

Thanks Ivan.

So suppose I write my own operator new and operator delete to the
previous code. (Note - they are not placement operators)

#include <iostream>
using namespace std;

void * operator new (size_t t) // my own global operator new
{
cout << "operator new called" << endl;
return malloc(t);
}

void operator delete(void* mem) // corresponding operator delete
{
cout << "operator delete called" << endl;
free(mem);
}

// Rest of the code is same as given in the previous post, copied here
for completeness.

class Int {
public:
Int() { cout << "Constructor called " << endl; throw 100; }
~Int() { cout << "destructor called" << endl; }
};

int main()
{
Int *p = new Int;
}
In this case, I observe that the messages "operator new called" and
"Constructor called".Also, the ctor throws. But I donot see the message
"operator delete called" printed anywhere.
Should'nt the memory allocated by ::operator new() be freed using
::operator delete() ?

I am using g++ 3.4.2.

What am I exactly missing here?

Thanks a lot,
Neelesh

[Sumit Rajan]

"Neelesh Bodas" <ne***********@gmail.com> wrote in message
news:11**********************@g43g2000cwa.googlegr oups.com...

Thanks Ivan.

So suppose I write my own operator new and operator delete to the
previous code. (Note - they are not placement operators)

#include <iostream>
using namespace std;

void * operator new (size_t t) // my own global operator new
{
cout << "operator new called" << endl;
return malloc(t);
}

void operator delete(void* mem) // corresponding operator delete
{
cout << "operator delete called" << endl;
free(mem);
}

// Rest of the code is same as given in the previous post, copied here
for completeness.

class Int {
public:
Int() { cout << "Constructor called " << endl; throw 100; }
~Int() { cout << "destructor called" << endl; }
};

int main()
{
Int *p = new Int;
}

int main()
{
try {
Int *p = new Int;
}
catch(...) {
std::cerr << "\n\nCaught\n\n";;
}
}

In this case, I observe that the messages "operator new called" and
"Constructor called".Also, the ctor throws. But I donot see the message
"operator delete called" printed anywhere.
Should'nt the memory allocated by ::operator new() be freed using
::operator delete() ?

I am using g++ 3.4.2.

What am I exactly missing here?

IIRC, if you do not catch an exception, terminate() will be called. The
default behavior of terminate() is to call abort().

Regards,
Sumit.
--
Sumit Rajan <su****@msdc.hcltech.com>

[Neelesh Bodas]

Sumit Rajan wrote:

IIRC, if you do not catch an exception, terminate() will be called. The
default behavior of terminate() is to call abort().

Yes Sumit, you are right. I forgot this subtle point that stack
unwinding takes place _only_ when the exception is caught, not
otherwise.

Thanks a lot.

[Ivan Vecerina]

"Neelesh Bodas" <ne***********@gmail.com> wrote in message
news:11**********************@g43g2000cwa.googlegr oups.com...
:
: Sumit Rajan wrote:
: > IIRC, if you do not catch an exception, terminate() will be called.
The
: > default behavior of terminate() is to call abort().
: >
:
: Yes Sumit, you are right. I forgot this subtle point that stack
: unwinding takes place _only_ when the exception is caught, not
: otherwise.

Actually, I think this is implementation-defined: when an exception
is not caught, unwinding may or may not take place.

In your case and on your platform, it obviously did not take place.
Regards,
Ivan
--
http://ivan.vecerina.com/contact/?subject=NG_POST <- email contact form

[Neelesh Bodas]

Ivan Vecerina wrote:

Actually, I think this is implementation-defined: when an exception
is not caught, unwinding may or may not take place.

Oh, thanks for that. I was probably under a wrong assumption. So what I
now understand is that - stack unwinding is _guaranteed to take place_
only if an exception is caught.

Thanks.

[Greg Comeau]

In article <11**********************@g43g2000cwa.googlegroups .com>,
Neelesh Bodas <ne***********@gmail.com> wrote:

Sumit Rajan wrote:

IIRC, if you do not catch an exception, terminate() will be called. The
default behavior of terminate() is to call abort().

Yes Sumit, you are right. I forgot this subtle point that stack
unwinding takes place _only_ when the exception is caught, not
otherwise.

If I understand what you just meant, no, that's not the case.
--
Greg Comeau / Celebrating 20 years of Comeauity!
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

[Neelesh Bodas]

Greg Comeau wrote:

In article <11**********************@g43g2000cwa.googlegroups .com>,
Neelesh Bodas <ne***********@gmail.com> wrote:

Yes Sumit, you are right. I forgot this subtle point that stack
unwinding takes place _only_ when the exception is caught, not
otherwise.

If I understand what you just meant, no, that's not the case.

So do you mean to say (please select exactly one option ;-) )
1) Stack unwinding might or might not take place when exception goes
uncaught
2) Stack unwinding _must not_ take place when the exception is
uncaught?
3) Stack unwinding _must_ take place whenever an exception is thrown,
irrespective of whether exception is caught or uncaught
4) None of the above. (please give explanation if you select this)

actually I am almost totally confused. Thanks for the help.

[Greg Comeau]

In article <11**********************@f14g2000cwb.googlegroups .com>,
Neelesh Bodas <ne***********@gmail.com> wrote:

Greg Comeau wrote:

In article <11**********************@g43g2000cwa.googlegroups .com>,
Neelesh Bodas <ne***********@gmail.com> wrote:

>Yes Sumit, you are right. I forgot this subtle point that stack
>unwinding takes place _only_ when the exception is caught, not
>otherwise.

If I understand what you just meant, no, that's not the case.

So do you mean to say (please select exactly one option ;-) )
1) Stack unwinding might or might not take place when exception goes
uncaught
2) Stack unwinding _must not_ take place when the exception is
uncaught?
3) Stack unwinding _must_ take place whenever an exception is thrown,
irrespective of whether exception is caught or uncaught
4) None of the above. (please give explanation if you select this)

actually I am almost totally confused. Thanks for the help.

15.5.1p2: "In the situation where no matching handler is found,
it is implementation-defined whether or not the stack is unwound
before terminate()is called. In all other situations, the stack
shall not be unwound before terminate()is called. An implementation
is not permitted to finish stack unwinding prematurely based on a
determination that the unwind process will eventually cause a call
to terminate()."
--
Greg Comeau / Celebrating 20 years of Comeauity!
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

[Neelesh Bodas]

Greg Comeau wrote:

15.5.1p2: "In the situation where no matching handler is found,
it is implementation-defined whether or not the stack is unwound
before terminate()is called. In all other situations, the stack
shall not be unwound before terminate()is called. An implementation
is not permitted to finish stack unwinding prematurely based on a
determination that the unwind process will eventually cause a call
to terminate()."

Yes, the confusion exists no more. Thanks.