'new' and a ctor that throws.

[NoHero]

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

[Graham]

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.)

[NoHero]

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:

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:

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.

[Hobson]

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

[NoHero]

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.

/btw: Nice to read from you Hobson

[Hobson]

/btw: Nice to read from you Hobson

Same here, glad to see you back

Cheers

[Hobson]

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

[NoHero]

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

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

[Graham]

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.