Thread: C++ Explict Dynamic Memory Allocation - Why?

  1. #1
    Registered User
    Join Date
    May 2011
    Posts
    30

    C++ Explict Dynamic Memory Allocation - Why?

    I don't really understand why one would want to use new in C++. I know what it does, but I don't understand WHY you'd use it. The main purpose I see is in arrays, but honestly, who uses arrays when not handling trivial amount of data? List, deque, vector, map, etc. does all the dynamic memory stuff for us, arguably faster than an array, in some circumstances. The other use, allowing for a permanent variable, I don't see either. I mean, you're going to lose the pointer anyway when the scope ends, unless you return it... so why not just pass-by-value? Can someone clear all of this up for me? Thanks!

  2. #2
    C++ Enthusiast M.Richard Tober's Avatar
    Join Date
    May 2011
    Location
    Georgia
    Posts
    56
    Pretty sure new is how the STL containers you mentioned allocate new memory.

    Following a chain of headers from vector, to stl_vector.h, to stl_iterator_base_funcs.h, to allocator.h, to c++allocator.h, to new_allocator.h - citing line 49,59, and 51 read:

    Code:
       *  This is precisely the allocator defined in the C++ Standard. 
       *    - all allocation calls operator new
       *    - all deallocation calls operator delete
    You're implementation may vary some, but I'm confident your compiler uses new and delete also. The attraction of C++ is it retains and expands on C's ability to "touch the metal". A programmer can use library's to rock and roll, or drop into the code and write their own library.
    Last edited by M.Richard Tober; 05-29-2011 at 07:03 AM. Reason: <sp> siting -> citing

  3. #3
    Registered User Inanna's Avatar
    Join Date
    May 2011
    Posts
    69
    To answer questions like this I think about how it benefits me. Thanks to the STL I do not need to create my own containers, and a whole category of dynamic allocation goes away because things like arrays and lists and trees are already there for the using.

    Excluding containers, when does dynamic allocation help? I can think of two times right now.
    • Very large objects or a lot of objects are better stored on the heap than the stack because the stack is limited.
    • Objects that need to persist after leaving the scope they are created in can not be stored on the stack.

    The list is short because I am only thinking of stack vs. heap and ignoring differences between pointer and non-pointer. It is easy to lump pointers and heap memory together, but pointers are useful beyond dynamic allocation.

    The other use, allowing for a permanent variable, I don't see either. I mean, you're going to lose the pointer anyway when the scope ends, unless you return it... so why not just pass-by-value?
    Passing by value means you make a copy of the object. What if it is of a type that can not be copied or copies are expensive?

  4. #4
    Registered User VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,607
    Sometimes there are no words.....

    I invite you to read either Bjarne's C++ book or pretty much any book about C++ to understand what new is for and how and why it should be used.

  5. #5
    Registered User
    Join Date
    Aug 2010
    Location
    Poland
    Posts
    733
    Quote Originally Posted by Shokwav View Post
    I don't really understand why one would want to use new in C++. I know what it does, but I don't understand WHY you'd use it.
    Because this is fundamental dynamic object creation. Without 'new' and 'placement new' STL could not do its job. C++ gives you a wide variety of tools and it is your responsibility to use them properly. STL is just an "additional" implementation, which can be replaced with a different one if you want.

    For example, in Java, you cannot implement your own String class, which would work in the same way. Why? Because, for example, you cannot overload the + operator. Java creators "take care" of the programmers disallowing them to overload operators, because from their point of view operator overloading can be overused (and lead to bad designs or something), but they do it themselves - they CHEAT.

    In C++ you can create your std::string, your own vectors, your own STL. C++ goes even farther - it enables you to overload the new operator.

    Passing by value means you make a copy of the object. What if it is of a type that can not be copied or copies are expensive?
    If it cannot be copied it will not compile (if you attempt to copy it). If copies are expensive... they are expensive, what do you want to know more? You can use smart pointer and copy only the pointer, which is another thing that can be added to the language by 3rd party, unlike in java where you must stick to its references. And yes, smart pointers also make use of new/delete.

  6. #6
    Registered User
    Join Date
    May 2011
    Posts
    30
    I don't think I was clear enough in my original post. I understand what new and delete do. I already know STL uses them, obviously. I just don't see why you'd need them explicitly.

  7. #7
    Registered User
    Join Date
    Oct 2006
    Posts
    3,445
    Quote Originally Posted by Shokwav View Post
    I don't think I was clear enough in my original post. I understand what new and delete do. I already know STL uses them, obviously. I just don't see why you'd need them explicitly.
    because it's expensive (poor performance) to pass whole objects around everywhere. it's much more efficient to create an object on the heap and pass around a pointer to it. imagine if an object was many thousands or millions of bytes in size. do you really want to copy all that data every time you pass it between functions? dynamic allocation and pointers are the only reasonable way to accomplish this. it's not uncommon for the stack to only be about 1MB, so a very large object must necessarily be created elsewhere. the heap is the logical choice.

  8. #8
    Registered User
    Join Date
    Jun 2005
    Posts
    6,815
    Quote Originally Posted by Elkvis View Post
    because it's expensive (poor performance) to pass whole objects around everywhere. it's much more efficient to create an object on the heap and pass around a pointer to it. imagine if an object was many thousands or millions of bytes in size. do you really want to copy all that data every time you pass it between functions? dynamic allocation and pointers are the only reasonable way to accomplish this. it's not uncommon for the stack to only be about 1MB, so a very large object must necessarily be created elsewhere. the heap is the logical choice.
    A pointer or (in C++) a reference to an object can be obtained - and therefore it is possible to pass an object around without creating a copy of it - regardless of whether that object has been dynamically allocated or not.

    The distinction between heap and stack - and any performance benefits of using one or the other - has been minimal or non-existent with modern operating systems since the mid 1990s. If you are still writing code for a machine running MS-DOS 5 with some form of extended memory, then you might need to worry about such things. While it is true that modern operating systems impose address quotas on processes, the quotas are usually much larger than 1MB.

    The main practical reason that one needs to explicitly use dynamic memory allocation is that the amount of memory (or number of objects) is not known until the program is run. The standard containers (which do dynamic memory allocation under the covers) can eliminate the need to do it explicitly, but some applications require different performance or other behavioural characteristics that are not offered by the standard library.
    Last edited by grumpy; 05-29-2011 at 09:53 PM.
    Right 98% of the time, and don't care about the other 3%.

    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.

  9. #9
    Registered User
    Join Date
    Aug 2010
    Location
    Poland
    Posts
    733
    Quote Originally Posted by Shokwav View Post
    I just don't see why you'd need them explicitly.
    I meant that usually you don't use them explicitly unless you write your own memory manager.
    Last edited by kmdv; 05-29-2011 at 11:32 PM.

  10. #10
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,895
    Quote Originally Posted by Shokwav View Post
    I don't think I was clear enough in my original post. I understand what new and delete do. I already know STL uses them, obviously. I just don't see why you'd need them explicitly.
    Usually you don't. But that doesn't mean you can remove them from the language, because the STL is just another library, really. It relies on the language in order to do its job. If new/delete aren't in the language, there would be no STL.
    Also, sometimes the STL is not sufficient. Until C++11, there were no hash containers in the STL. Anyone wanting to implement one would have to use new/delete explicitly.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  11. #11
    Registered User
    Join Date
    May 2011
    Posts
    30
    Yes, yes, yes, I understand that new and delete are used in the libraries themselves; I was never denying that. Thank you all for your help.

  12. #12
    Registered User
    Join Date
    Oct 2006
    Posts
    3,445
    Quote Originally Posted by grumpy View Post
    The distinction between heap and stack - and any performance benefits of using one or the other - has been minimal or non-existent with modern operating systems since the mid 1990s
    I don't see how they could possibly have eliminated the copying penalty at the operating system level. the only way I can think of is to use the x86 paging mechanism and copy-on-write, but that would give application code a lot of low level access to kernel-space things.

  13. #13
    Registered User
    Join Date
    Jun 2005
    Posts
    6,815
    Quote Originally Posted by Elkvis View Post
    I don't see how they could possibly have eliminated the copying penalty at the operating system level. the only way I can think of is to use the x86 paging mechanism and copy-on-write, but that would give application code a lot of low level access to kernel-space things.
    My comment that you quoted concerned different performance (or lack thereof in modern systems) offered by heap and stack, not on the overhead of copying objects.
    Right 98% of the time, and don't care about the other 3%.

    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.

  14. #14
    Registered User
    Join Date
    Oct 2006
    Posts
    3,445
    Quote Originally Posted by grumpy View Post
    My comment that you quoted concerned different performance (or lack thereof in modern systems) offered by heap and stack, not on the overhead of copying objects.
    any system that accesses memory as a contiguous block will have no penalty for heap versus stack access.

    While it is true that modern operating systems impose address quotas on processes, the quotas are usually much larger than 1MB.
    as an example, the default stack size for a win32 thread is 1MB, if you specify 0 for stack size when calling CreateThread(). since you cannot always be sure you are not running in a child thread (without explicitly checking for it), it's not unreasonable to expect that you might need to plan for this situation.

  15. #15
    Nasal Demon Xupicor's Avatar
    Join Date
    Sep 2010
    Location
    Poland
    Posts
    179
    There are times when you need a lot of different derived objects kept in one heterogeneous container. Probably the most basic thing you can do is vector<Base*> - you'd then new and delete objects. You can of course use vector<shared_ptr<Base> > - smart pointers would clean after themselves, so you'd only use new then, no delete. * I'd imagine it to be not uncommon situation. So while you surely don't use new every two other lines in your source code - I can't see it being that big of a rarity (delete - maybe, but not new). Certainly not to a point where you'd question yourself what that strange highlighted keyword is. :P

    *) There are of course other containers, e.g. boost::ptr_* etc. ;)

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Dynamic Memory Allocation
    By JamesD in forum C Programming
    Replies: 10
    Last Post: 03-12-2011, 12:08 AM
  2. what is dynamic memory allocation
    By dbzx in forum C Programming
    Replies: 7
    Last Post: 06-08-2009, 08:11 AM
  3. Memory dynamic allocation
    By elvio.vicosa in forum C Programming
    Replies: 8
    Last Post: 10-16-2007, 03:30 AM
  4. Help with dynamic memory allocation
    By malooch in forum C Programming
    Replies: 2
    Last Post: 12-13-2006, 01:26 PM
  5. Dynamic Memory Allocation
    By oranges in forum C++ Programming
    Replies: 3
    Last Post: 11-28-2006, 07:50 AM