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

  1. #1
    Registered User
    Join Date
    Aug 2011
    Posts
    35

    '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
    Code:
    class MyClass = new Derived();

  2. #2
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    21,717
    Quote Originally Posted by Darkroman
    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).
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  3. #3
    Algorithm Dissector iMalc's Avatar
    Join Date
    Dec 2005
    Location
    New Zealand
    Posts
    6,304
    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.
    My homepage
    Advice: Take only as directed - If symptoms persist, please see your debugger

    Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"

  4. #4
    Registered User
    Join Date
    Aug 2011
    Posts
    35
    Quote Originally Posted by iMalc View Post
    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.

  5. #5
    Registered User
    Join Date
    Jun 2005
    Posts
    6,290
    Quote Originally Posted by iMalc View Post
    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.

    Quote Originally Posted by iMalc View Post
    It allows for a faster swap operation between two instances of your class.
    It can enable that, yes.

    Quote Originally Posted by iMalc View Post
    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).

    Quote Originally Posted by iMalc View Post
    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.

    Quote Originally Posted by iMalc View Post
    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.
    Right 98% of the time, and don't care about the other 3%.

  6. #6
    Algorithm Dissector iMalc's Avatar
    Join Date
    Dec 2005
    Location
    New Zealand
    Posts
    6,304
    Quote Originally Posted by Darkroman View Post
    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.
    Then I got my point across perfectly
    My homepage
    Advice: Take only as directed - If symptoms persist, please see your debugger

    Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"

  7. #7
    Algorithm Dissector iMalc's Avatar
    Join Date
    Dec 2005
    Location
    New Zealand
    Posts
    6,304
    Quote Originally Posted by grumpy View Post
    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.
    I was referring to the stuff that this talks about, nothing more (points 3 & 4): GotW #59: Exception-Safe Class Design, Part 1: Copy Assignment

    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.
    My homepage
    Advice: Take only as directed - If symptoms persist, please see your debugger

    Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Composition,private Class member variables and methods
    By sigur47 in forum C++ Programming
    Replies: 13
    Last Post: 01-29-2012, 07:10 PM
  2. Replies: 5
    Last Post: 07-25-2008, 04:37 AM
  3. Replies: 25
    Last Post: 10-29-2007, 04:08 PM
  4. Class member variables only readable by member functions?
    By _Elixia_ in forum C++ Programming
    Replies: 4
    Last Post: 10-10-2003, 03:52 PM
  5. Replies: 4
    Last Post: 12-12-2002, 01:32 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21