468,107 Members | 1,325 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,107 developers. It's quick & easy.

Exception in a derived class constructor

Some amount of memory is allocated inside the Base Constructor using
new. During the construction of a derived object an exception occurred
in the constructor of the derived class.

Will the memory get de allocated which got allocated in Base class
constructor? Will the Base class destructor get called?

class Base
{
int *p;

public:
B() { p = new int[100]; }

~B() { delete[] p; }
};

class Derived : public Base
{
public:
Derived ()
{
/* Exception Occurred!!!!!!!!!!!!! */
}
};

May 15 '06 #1
8 1891

Kannan skrev:
Some amount of memory is allocated inside the Base Constructor using
new. During the construction of a derived object an exception occurred
in the constructor of the derived class.

Will the memory get de allocated which got allocated in Base class
constructor? Will the Base class destructor get called?

[snip]

This really looks like something for the FAQ:

http://www.parashift.com/c++-faq-lite/

/Peter

May 15 '06 #2
dj
Kannan wrote:
Some amount of memory is allocated inside the Base Constructor using
new. During the construction of a derived object an exception occurred
in the constructor of the derived class.

Will the memory get de allocated which got allocated in Base class
constructor? Will the Base class destructor get called?

class Base
{
int *p;

public:
B() { p = new int[100]; }

~B() { delete[] p; }
};

class Derived : public Base
{
public:
Derived ()
{
/* Exception Occurred!!!!!!!!!!!!! */
}
};


I believe the c++ primer book specifically mentions that in such cases
the destructors are guaranteed to be called. Anyway, a debug step
through should answer your question without doubt.
May 15 '06 #3

dj skrev:
Kannan wrote:
Some amount of memory is allocated inside the Base Constructor using
new. During the construction of a derived object an exception occurred
in the constructor of the derived class.

Will the memory get de allocated which got allocated in Base class
constructor? Will the Base class destructor get called?
[snip]
I believe the c++ primer book specifically mentions that in such cases
the destructors are guaranteed to be called. Anyway, a debug step
through should answer your question without doubt.

Stepping through the debugger at best shows the behaviour of that
particular compiler - in debug mode. Why not simply look it up?
Probably it is even faster than checking your compilers implementation.
Certainly the look-up gives you far more value for the investment.

/Peter

May 15 '06 #4
> Some amount of memory is allocated inside the Base Constructor using
new. During the construction of a derived object an exception occurred
in the constructor of the derived class.

Will the memory get de allocated which got allocated in Base class
constructor? Will the Base class destructor get called?

class Base
{
int *p;

public:
B() { p = new int[100]; }

~B() { delete[] p; }

};

class Derived : public Base
{
public:
Derived ()
{
/* Exception Occurred!!!!!!!!!!!!! */
}


The short answer is: Yes. The base destructor is guaranteed to be
called. And any objects in the base class and the derived class already
constructed (i.e. aggregate objects). But the tricky part is that the
destructor of the derived object itself is *not* called. The destructor
is only called for fully contructed objects.

So, if you do any non-managed allocation in the constructor you need to
use try/catch and cleanup the memory before exiting the constructor
(since your destructor will *not* be called in this case). Try to use
RAII objects like smart_ptr or auto_ptr to handle memory allocations
and deallocations automatically in case of exceptions.

But the nice thing is that all other objects - base object(s) and
aggregate objects will be destructed as expected.

/ Phl

May 16 '06 #5
OK the derived class destructor will not be called because the derived
is not fully constructed, when the exception occurs.

But when I stepped through the debugger I see that the Base destructor
also is NOT called. (Also I have given a printf statement in the Base
class destructor to check this.)

May 16 '06 #6

Kannan wrote:
OK the derived class destructor will not be called because the derived
is not fully constructed, when the exception occurs.

But when I stepped through the debugger I see that the Base destructor
also is NOT called. (Also I have given a printf statement in the Base
class destructor to check this.)


and what is your compiler ?

May 16 '06 #7
Kannan posted:
OK the derived class destructor will not be called because the derived
is not fully constructed, when the exception occurs.

But when I stepped through the debugger I see that the Base destructor
also is NOT called. (Also I have given a printf statement in the Base
class destructor to check this.)

Did you compile and run the code I gave you elsethread?
Perhaps your degugger inlined the call to the destructor, and so it
appears that it isn't invoked when you step through -- I've seen that
before.
-Toms
May 16 '06 #8
Disregard my last post.

I was using a MS ver 7.0 compiler and haven't turned on the exception
handler compiler option (/EHa or /EHs). Though the thrown object got
caught in the catch without turning on that option(s). However gcc got
it without giving any compiler options.

So what Phl Melin said is right. The base class destructor got
called, when exception occurred in derived class constructor. That is
the destructor of all fully constructed objects will get called.

Sorry for the confusion. Thank you for the replies.

May 16 '06 #9

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

7 posts views Thread by Douglas Peterson | last post: by
11 posts views Thread by Dave | last post: by
11 posts views Thread by Ivan A. | last post: by
9 posts views Thread by Jeff Louie | last post: by
23 posts views Thread by TarheelsFan | last post: by
10 posts views Thread by Rahul | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.