Printable View
What are the advantages and disadvantages of having your members assigned with new?
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 withCode:m_member = new int(10);
// or
m_member = new int(*(Foo.m_member));
Code:class MyClass = new Derived();
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).Quote:
Originally Posted by Darkroman
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.Quote:
Originally Posted by iMalc
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.Quote:
Originally Posted by iMalc
It can enable that, yes.Quote:
Originally Posted by iMalc
.... 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).Quote:
Originally Posted by iMalc
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.Quote:
Originally Posted by iMalc
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.
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.Quote:
Originally Posted by iMalc
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.
Then I got my point across perfectly :wink:Quote:
Originally Posted by Darkroman
I was referring to the stuff that this talks about, nothing more (points 3 & 4): GotW #59: Exception-Safe Class Design, Part 1: Copy AssignmentQuote:
Originally Posted by grumpy
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.