>>>>> On 8 Jun 1995 14:46:57 GMT, horstman@sjsumcs.sjsu.edu (Cay
Horstmann) said:

    Cay> Or does new/delete do some true magic and set some kind of information in the
    Cay> partially constructed heap object *j so that delete j only undoes the
    Cay> succesful part? If so, is that true magic guaranteed to happen with
    Cay> overloaded new/delete? Thanks for any enlightenment!

It appears so to me. Please don't ask me the specifics, rationale
etc. I had this doubt once and I looked up the WP for it.

  15.2  Constructors and destructors                       [except.ctor]

2 An object that is partially constructed will have destructors executed
  only for its fully constructed sub-objects.  Should a constructor  for
  an  element  of  an  automatic array throw an exception, only the con
  structed elements of that array will be destroyed.  If the  object  or
  array  was allocated in a new-expression, the storage occupied by that
  object is sometimes deleted also (_expr.new_).

    Cay> Cay

Hope this helps.
--
Peace.... +<:-)

Anil
akv@cacs.usl.edu

[Not speaking for anyone including myself]

Suppose I have a class
 class Employee
 { string _name;
 public:
   Employee(string n) : _name(n) { ::register(_name); }
 };

and then I am concerned about exceptions in a call to new Employee("Joe").
So I do

 Employee* j;
 try
 { j = new Employee("Joe");
 }
 catch(...)
 { delete j;
   throw;
 }

This will work fine if the constructor to Employee succeeds. But if the
constructor fails, either because the operator new or the string copy
constructor fails, then *j is not actually constructed, so I have no
business deleting it. Let's look at this in gory detail.

If operator new fails, I don't want to have operator delete invoked.

If operator new succeeds but the string copy constructor fails, I want
to have operator delete invoked but not the Employee destructor.

If operator new and the string copy constructor succeed but ::register fails,
I want to destroy and delete *j.

Maybe I am really muddleheaded this morning, but I don't see a good
way of handling this situation without actually knowing the kinds of
exceptions that operator new and the string copy constructor throw.

Or does new/delete do some true magic and set some kind of information in the
partially constructed heap object *j so that delete j only undoes the
succesful part? If so, is that true magic guaranteed to happen with
overloaded new/delete? Thanks for any enlightenment!

Cay

In article nn8@jupiter.SJSU.EDU, horstman@sjsumcs.sjsu.edu (Cay Horstmann) writes:
>Suppose I have a class
> class Employee
> { string _name;
> public:
>   Employee(string n) : _name(n) { ::register(_name); }
> };
>
>and then I am concerned about exceptions in a call to new Employee("Joe").
>So I do
>
> Employee* j;
> try
> { j = new Employee("Joe");
> }
> catch(...)
> { delete j;
>   throw;
> }
>
>This will work fine if the constructor to Employee succeeds. But if the
>constructor fails, either because the operator new or the string copy
>constructor fails, then *j is not actually constructed, so I have no
>business deleting it. Let's look at this in gory detail.
>
>If operator new fails, I don't want to have operator delete invoked.
>
>If operator new succeeds but the string copy constructor fails, I want
>to have operator delete invoked but not the Employee destructor.
>
>If operator new and the string copy constructor succeed but ::register fails,
>I want to destroy and delete *j.
>
>Maybe I am really muddleheaded this morning, but I don't see a good
>way of handling this situation without actually knowing the kinds of
>exceptions that operator new and the string copy constructor throw.
>
>Or does new/delete do some true magic and set some kind of information in the
>partially constructed heap object *j so that delete j only undoes the
>succesful part? If so, is that true magic guaranteed to happen with
>overloaded new/delete? Thanks for any enlightenment!

If the Employee ctor exits via an exception, the already-constructed
sub-objects of Employee are destroyed, then the space acquired
by new is automatically deleted, then the exception is propagated to
its handler (if any). This is according to the draft standard. What some
current compiler actually does might be different.

You don't want use delete or operator delete() on the Employee
object in the catch clause, since it either was never allocated
(if string::string(char*) throws) or was already deleted (if
the string copy ctor or the Employee ctor throws).

---
Steve Clamage, stephen.clamage@eng.sun.com