'new' and a ctor that throws.

Is it true, that when I create an instance of an object with 'new' and the ctor throws, the default operator new will deallocate the memory? And if yes, does it call my dtor?

I am just curious because I have a class which does a lot of new'ing in the ctor, and I am aware of the fact that new my throw an exception I have to catch.

Best,
Florian

Yes, the memory will be released; no the destructor will not be called.

An object's lifetime starts on successful exit of a constructor and ends at entry to the destructor. If a ctor throws, the object has never existed, so its dtor will not be called. (Note that the dtors of any member variables that have been fully constructed will be called.)

Thank you Graham. Indeed my nightmare came true.

I have a container class storing an huge amount of related data. To avoid a clumsy program I use 'new' to allocate the data when only needed. But lets say:

Code:

---

class Foo
{
  ISomething *m, *n, *o, *p, *q;
public:

  Foo ( void )
  {
      m = new Something;
      n = new Something; // [1]
      o = new Something;
      // p and q will be allocated later
  }
};

---

So if the new at [1] throws the space allocated by 'm' will not be released, thus leading to a memory leak?

But by your definition:

Quote:

---

Note that the dtors of any member variables that have been fully constructed will be called.

---

If I use std::auto_ptr around m I can avoid this, right? Since the auto_ptr is fully constructed at the point where n fails to allocate.

auto_ptr or shared_ptr will help with your problem. The reason of all your troubles is that you missed following guideline: one class should be responsible for managing at most one resource. This topic is covered at one of GotW chapters, but I cannot remember which one :)

Cheers

Quote:

---

Originally Posted by Hobson

The reason of all your troubles is that you missed following guideline: one class should be responsible for managing at most one resource. This topic is covered at one of GotW chapters, but I cannot remember which one :)

---

No my troubles comes from a design that has a LOT OF "has a" relationships. ;) :wave:

/btw: Nice to read from you Hobson ;)

Quote:

---

Originally Posted by NoHero

/btw: Nice to read from you Hobson ;)

---

Same here, glad to see you back :)

Cheers

Here it is, might be helpful: http://www.gotw.ca/gotw/066.htm

Quote:

---

Originally Posted by Hobson

Here it is, might be helpful: http://www.gotw.ca/gotw/066.htm

---

Thank you very much, very helpful :wave:
And thank you Graham for clearing this up for me :wave:

Quote:

---

Originally Posted by NoHero

If I use std::auto_ptr around m I can avoid this, right? Since the auto_ptr is fully constructed at the point where n fails to allocate.

---

Yes, but... I wouldn't use auto_ptr to manage resources for a class, unless you explictly disable copying. If you use auto_ptr, you'll just transfer all the caveats of using auto_ptr itself to your class - can't use it in a standard container, etc...

As Hobson says, shared_ptr is a better bet because it doesn't tie you down with potentially infuriating restrictions.