Exception-safe constructors

[François Duranleau]

Hi!

I was writing some piece of code and then, after pondering on some
readings in "More Effective C++" by Scott Meyers (Item 10) and the book of
Stroustrup (section 14.4.1 in the hardcover special edition), I tested one
of their solutions to write constructors that avoid memory leaks upon
exceptions. But the leaks were still there!

So I wrote a simple test case and here is the code:

%%%%%

#include <iostream>

using namespace std ;

class chose_binouche
{
public :

chose_binouche()
{
cout << "ctor" << endl ;
}

~chose_binouche()
{
cout << "dtor" << endl ;
}

} ;

class bidon
{
public :

chose_binouche a ;
chose_binouche b ;

bidon()
: a() ,
b()
{
throw "exception" ;
}

~bidon()
{
}

} ;

int
main()
{
bidon b ;
return 0 ;
}

%%%%%

In theory (according to the readings mentionned above), the destructors
for the field a and b in class bidon should be called after the exception
is thrown in the constructor; however, the output of the program was:

ctor
ctor
Aborted (core dumped)

No dtor displayed!

The compiler I am using is g++-3.3.3 and g++-3.4.0 on a Fedora Core 2
Linux station, and I was about to send a bug report but then again maybe
there is something I didn't get right. Unfortunately, I do not have
another compiler at hand to see what it does on other environments.

Can someone else confirm this or prove me wrong?

--
F.D.

[Alf P. Steinbach]

* 9-1?Q?Fran=E7ois_Duranleau?=:

I was writing some piece of code and then, after pondering on some
readings in "More Effective C++" by Scott Meyers (Item 10) and the book of
Stroustrup (section 14.4.1 in the hardcover special edition), I tested one
of their solutions to write constructors that avoid memory leaks upon
exceptions. But the leaks were still there!

So I wrote a simple test case and here is the code:

%%%%%

#include <iostream>

using namespace std ;

class chose_binouche
{
public :

chose_binouche()
{
cout << "ctor" << endl ;
}

~chose_binouche()
{
cout << "dtor" << endl ;
}

} ;

class bidon
{
public :

chose_binouche a ;
chose_binouche b ;

bidon()
: a() ,
b()
{
throw "exception" ;
}

~bidon()
{
}

} ;

int
main()
{
bidon b ;
return 0 ;
}

%%%%%

In theory (according to the readings mentionned above), the destructors
for the field a and b in class bidon should be called after the exception
is thrown in the constructor;
Nope.

There is no catch for the thrown exception.

In this case the standard specifies a call to std::terminate (or the
installed std::terminate-handler) and unfortunately leaves it unspecified
whether destructors are called or not -- unfortunate because a guarantee
of no destructor-calling in this case would be very nice.
however, the output of the program was:

ctor
ctor
Aborted (core dumped)

Correct (as would be calls of the destructors, unfortunately).

--
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?

[Victor Bazarov]

François Duranleau wrote:

Hi!

I was writing some piece of code and then, after pondering on some
readings in "More Effective C++" by Scott Meyers (Item 10) and the book
of Stroustrup (section 14.4.1 in the hardcover special edition), I
tested one of their solutions to write constructors that avoid memory
leaks upon exceptions. But the leaks were still there!

So I wrote a simple test case and here is the code:

%%%%%

#include <iostream>

using namespace std ;

class chose_binouche
{
public :

chose_binouche()
{
cout << "ctor" << endl ;
}

~chose_binouche()
{
cout << "dtor" << endl ;
}

} ;

class bidon
{
public :

chose_binouche a ;
chose_binouche b ;

bidon()
: a() ,
b()
{
throw "exception" ;
}

~bidon()
{
}

} ;

int
main()
{
Add:
try {
bidon b ;
Add
} catch (...) { }
return 0 ;
}

%%%%%
.... and see if there is any difference...

I tested this on MIPSpro version 7.4 and it gave me

ctor
ctor
dtor
dtor
Caught <exception>


In theory (according to the readings mentionned above), the destructors
for the field a and b in class bidon should be called after the
exception is thrown in the constructor; however, the output of the
program was:

ctor
ctor
Aborted (core dumped)

No dtor displayed!

The compiler I am using is g++-3.3.3 and g++-3.4.0 on a Fedora Core 2
Linux station, and I was about to send a bug report but then again maybe
there is something I didn't get right. Unfortunately, I do not have
another compiler at hand to see what it does on other environments.

Can someone else confirm this or prove me wrong?

See above.

V

[François Duranleau]

On Wed, 6 Oct 2004, Alf P. Steinbach wrote:

* 9-1?Q?Fran=E7ois_Duranleau?=:

[snip beginning of code]

int
main()
{
bidon b ;
return 0 ;
}

%%%%%

In theory (according to the readings mentionned above), the destructors
for the field a and b in class bidon should be called after the exception
is thrown in the constructor;

Nope.

There is no catch for the thrown exception.

In this case the standard specifies a call to std::terminate (or the
installed std::terminate-handler) and unfortunately leaves it unspecified
whether destructors are called or not -- unfortunate because a guarantee
of no destructor-calling in this case would be very nice.

Ah! Either I missed that information or they didn't mention that subtlety
(I do not have a copy of the standard's specification). Anyway, I tried
with an added try-catch block and now it's ok (with g++).

Thanks!

--
F.D.

[François Duranleau]

On Wed, 6 Oct 2004, Victor Bazarov wrote:

[snip code]

int
main()
{

Add:
try {

bidon b ;

Add
} catch (...) { }

return 0 ;
}

%%%%%

... and see if there is any difference...

I tested this on MIPSpro version 7.4 and it gave me

ctor
ctor
dtor
dtor
Caught <exception>

I did the same with g++ and the result is right. Thanks.

__________________________________________________ ________________________
François Duranleau Étudiant Ph.D. Informatique
LIGUM Université de Montréal

"Sacrifices are a necessary factor in creating a new destiny. A small
misfortune becomes the cornerstone of a greater happiness."
- Emperor Dornkirk, in _The Vision of Escaflowne_