🚀 go-pugleaf

Henk Kampman (henk_kampman@idsys.nl) wrote:

|> Why is the destructor only called for fully contructed objects?
|> To my oppinion this results in code duplication in the contructor and destructor

|> For example:


|> class a
|> {
|> public:
|>    char* mBuffer1;
|>    char* mBuffer2;
|>    a();
|>    ~a();
|> };

|> a::a()
|> {
|>    mBuffer1 = NULL;
|>    mBuffer2 = NULL;

|>    try
|>    {
|>       mBuffer1 = new char[1000];
|>       if(mBuffer1 == NULL) |>          throw MemError;

|>       mBuffer2 = new char[1000];
|>       if(mBuffer1 == NULL)
|>          throw MemError;
|>    }
|>    catch(...)  // allocation failed
|>    {
|>       delete mBuffer1;  
|>       delete mBuffer2;

|>       throw;
|>    }

|> }

|> a::~a()
|> {
|>    delete mBuffer1;
|>    delete mBuffer2;
|> }

Basically, the most correct way of writting this would be to change the
pointer declarations to auto_ptr, and forget the try/catch block
completely.  In fact, I would generally write it this way, with the
initialization in the initialization part of the constructor, e.g.:

    a::a()
        :   mBuffer1( new char[ 1000 ] )
        ,   mBuffer2( new char[ 1000 ] )
    {
    }

If you really insist on using pointers, then the way I would write this
would be simply:

    a::a()
    {
        mBuffer1 = new char[ 1000 ] ;
        try
        {
            mBuffer2 = new char[ 1000 ] ;
        }
        catch (...)
        {
            delete mBuffer2 ;
        }
    }

Still a lot simpler, and it works.  Note that this solution (which seems
the most natural to me) would be impossible if the destructor were to be
called on the incomplete object.

In general, for destruction of an incomplete object to work, you are
required to use special flags (like initializing the pointers to NULL);
not destructing avoids these.

(Note that compared to your examples, I do not test the results of new
for NULL.  The draft standard prohibits new from ever returning NULL,
and this behavior can be simulated with older compilers by defining a
new_handler which throws the desired exception.)
-- 
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils en informatique industrielle--
                             --Beratung in industrieller Datenverarbeitung

[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]