'new' member variables of a 'new' class?

This is a discussion on 'new' member variables of a 'new' class? within the C++ Programming forums, part of the General Programming Boards category; What are the advantages and disadvantages of having your members assigned with new?
Code:
m_member = new int(10);
// or
...

'new' member variables of a 'new' class?

What are the advantages and disadvantages of having your members assigned with new?

Code:

m_member = new int(10);
// or
m_member = new int(*(Foo.m_member));

I have done this before, but can't remember what my reasoning was other than "Let's try it!" (I just came back to programming after a bit of a hiatus). Now I'd like to know what would be the use of such things in a class when the class is allocated on the heap already with

What are the advantages and disadvantages of having your members assigned with new?

I would say that there are no advantages. The disadvantage is that you will have to implement RAII yourself. However, I can take this position because there are suitable alternatives: store a container or smart pointer as a member. If not for these alternatives, the reasons for having a pointer member and using new[] or new include the need for dynamic memory allocation (e.g., an array that can be expanded as needed) and the use of polymorphism (where a reference member would not make sense, so you store a pointer to the base class that points to a derived class object).

I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.

Take your pick:
It can allow your class to provide the strong exception guarantee where it otherwise wouldn't.
It allows for a faster swap operation between two instances of your class.
It allows shared ownership of resources.
It helps reduce memory usage of larger sub-objects that are not always required.
It allows for two-phase construction.
It alows you to use the pimpl idiom.

Take your pick:
It can allow your class to provide the strong exception guarantee where it otherwise wouldn't.
It allows for a faster swap operation between two instances of your class.
It allows shared ownership of resources.
It helps reduce memory usage of larger sub-objects that are not always required.
It allows for two-phase construction.
It alows you to use the pimpl idiom.

Not sure what any of that means. I guess I really shouldn't worry too much about it for now until I'm actually at that level of programming or find myself needing it.

It can allow your class to provide the strong exception guarantee where it otherwise wouldn't.

I'm inclined to disagree on that one. Dynamically allocating memory and constructing an object is just one more operation that can fail with an exception. If it is not possible to provide a strong guarantee (eg rollback semantics) without using dynamic memory allocation, explicit dynamic memory allocation (at best) does not make it any easier and (at worst) can make it harder to achieve, because additional failure modes may be introduced.

Originally Posted by iMalc

It allows for a faster swap operation between two instances of your class.

It can enable that, yes.

Originally Posted by iMalc

It allows shared ownership of resources.

.... which is, of course, a double edged sword. Shared ownership schemes tend to place constraints on the behaviour of all objects that share ownership (eg coordinating release of the resource when destroying the last object that claims ownership).

Originally Posted by iMalc

It helps reduce memory usage of larger sub-objects that are not always required.
It allows for two-phase construction.

Two-phase construction is often used, but is not exactly an "encouraged technique". A two-phase construction approach is an open invitation to forget the second phase, and use the object anyway, with potentially catastrophic results. Roughly speaking, it is considered better to defer creation of objects until they are needed (i.e. all data is available to create and initialise a new object), rather than partially construct it and then complete the construction later. No need for the book-keeping to keep track of whether an object is fully constructed, and fewer opportunities for the caller to get the construction process wrong.

Similar comments apply for objects with parts that are not constructed until they are needed ..... effectively that becomes construction process with more than two phases, and requires additional bookkeeping to keep track of what has or hasn't been constructed.

Originally Posted by iMalc

It alows you to use the pimpl idiom.

The pimple idiom (aka compilation firewall) does not generally mean having a member that is an int versus the same member represented as a pointer to int.

It usually means that the implementation in the class is deferred in a manner so the implementation (eg of a helper class that actually does the work) is not visible to the user of the class.

If I seem grumpy or unhelpful in reply to you, or tell you you need to demonstrate more effort before you can expect help, it is likely you deserve it. Suck it up, Buttercup, and read this, this, and this before posting again.

I'm inclined to disagree on that one. Dynamically allocating memory and constructing an object is just one more operation that can fail with an exception. If it is not possible to provide a strong guarantee (eg rollback semantics) without using dynamic memory allocation, explicit dynamic memory allocation (at best) does not make it any easier and (at worst) can make it harder to achieve, because additional failure modes may be introduced.

The examples I've given are not meant to suggest that they should be frequently used. It's just a casual list of possible reasons for code that one might come across, having been written a certain way.

The last one was not a good example, I agree. I thought of that after posting, but couldn't be bothered changing it.