Dynamic memory allocation

This is a discussion on Dynamic memory allocation within the C++ Programming forums, part of the General Programming Boards category; so your argument would be that you are skipping the delete step so its better to instantiate a vector class ...

  1. #31
    pronounced 'fib' FillYourBrain's Avatar
    Join Date
    Aug 2002
    Posts
    2,297
    so your argument would be that you are skipping the delete step so its better to instantiate a vector class yet not use its abilities?
    "You are stupid! You are stupid! Oh, and don't forget, you are STUPID!" - Dexter

  2. #32
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    21,734
    so your argument would be that you are skipping the delete step so its better to instantiate a vector class yet not use its abilities?
    One of the "abilities" of the standard containers is memory management.

    That said, I had the impression that you were giving an example of when a fixed sized array is better, since the data size is fixed.
    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. #33
    Registered User
    Join Date
    Jan 2005
    Posts
    7,318
    >> so your argument would be that you are skipping the delete step so its better to instantiate a vector class yet not use its abilities? <<

    I'm not sure I understand your question. In this case a vector provides the same functionality as a dynamic array, plus it provides exception safety and a guard against memory leaks that comes from the automatic memory management. Just because you're not using push_back doesn't mean that you're not using vector appropriately.

    >> I had the impression that you were giving an example of when a fixed sized array is better, since the data size is fixed. <<

    Compile-time fixed? We were talking about new[]/delete[] versus vector.

  4. #34
    pronounced 'fib' FillYourBrain's Avatar
    Join Date
    Aug 2002
    Posts
    2,297
    no, variable sized. And I'm not disregarding the use of the vector here as bad, but the advantage is limited.

    Plus, does the standard specify that the internal array will ALWAYS be contiguous memory?
    "You are stupid! You are stupid! Oh, and don't forget, you are STUPID!" - Dexter

  5. #35
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,612
    For std::vector, I believe the answer is yes.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  6. #36
    pronounced 'fib' FillYourBrain's Avatar
    Join Date
    Aug 2002
    Posts
    2,297
    Another concern. Even if it is contiguous memory, is it guaranteed to be there before you reference it through an accessor method?
    "You are stupid! You are stupid! Oh, and don't forget, you are STUPID!" - Dexter

  7. #37
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,612
    Do you mean you could potentially access array[N], even though it might not exist (ie undefined behavior)?
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  8. #38
    pronounced 'fib' FillYourBrain's Avatar
    Join Date
    Aug 2002
    Posts
    2,297
    yeah, sure. Resize the thing, get the pointer to the first element, and access the nth element. Guaranteed that its not moved, resized, smaller than n at that time?
    "You are stupid! You are stupid! Oh, and don't forget, you are STUPID!" - Dexter

  9. #39
    pronounced 'fib' FillYourBrain's Avatar
    Join Date
    Aug 2002
    Posts
    2,297
    I mean to me this is exactly the sort of violation of encapsulation that we should be trying to avoid in OOP
    "You are stupid! You are stupid! Oh, and don't forget, you are STUPID!" - Dexter

  10. #40
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    21,734
    Even if it is contiguous memory, is it guaranteed to be there before you reference it through an accessor method?
    It sounds like you are grasping for straws. The answer depends on what you mean, but either way it is no worse than new[]+delete[].
    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

  11. #41
    pronounced 'fib' FillYourBrain's Avatar
    Join Date
    Aug 2002
    Posts
    2,297
    No, I really think you should be guaranteed that the behavior will be this way before you start using it like that.

    there is a "reserve" method that forces allocation to be that big ahead of time... but resize doesn't.
    "You are stupid! You are stupid! Oh, and don't forget, you are STUPID!" - Dexter

  12. #42
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,612
    Quote Originally Posted by FillYourBrain View Post
    yeah, sure. Resize the thing, get the pointer to the first element, and access the nth element. Guaranteed that its not moved, resized, smaller than n at that time?
    If you resize to N + 10 elements, then of course the Nth element is guaranteed to exist.
    Operator [] is a wrapper to the Nth element you specify, wherever it may be. Even if it's moved to some far-off location.
    Otherwise I think it would break a lot of expectations.

    Unfortunately, it doesn't guarantee that the Nth element exists unless you made sure to push back enough elements or resize to enough elements. Otherwise you can access out-of-bounds, which would lead to undefined behavior.

    Which kindof a shame, if you ask me. It really should throw an exception.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  13. #43
    Registered User
    Join Date
    Jan 2005
    Posts
    7,318
    >> And I'm not disregarding the use of the vector here as bad, but the advantage is limited. <<

    There is one obvious advantage (automatic memory management) and no disadvantages. I don't understand the point you are making.

    Nobody is claiming the vector is sliced bread. It's just better (even if only a little) than new[]/delete[] in every case I've ever heard of.


    >> there is a "reserve" method that forces allocation to be that big ahead of time... but resize doesn't. <<

    I think you're confused about vector's functionality. The resize function allocates space and instantiates objects in that space (like new[]). The reserve function allocates space but doesn't create objects, requiring the use of push_back.

  14. #44
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by FillYourBrain View Post
    yeah, sure. Resize the thing, get the pointer to the first element, and access the nth element. Guaranteed that its not moved, resized, smaller than n at that time?
    If you have given the vector a size from the start (or resized it later, or taken it's size after a number of "push_back" operations), then you can be guaranteed that elements are going to be there, yes. You can, however, not rely on element 7 being there if you haven't in some way made the vector at least 7 elements long.

    And as long as you do not resize the vector, a ppinter to any element will remain valid forever. Obviously, any resiziing (either extending or shortening) may invalidate a pointer holding the address of the vector content.

    And vectors are GUARANTEED to be implemented in one contiguous chunk of memory. [obviously, we are talking about the virtual address, in the physical memory, that may be discontiguous, but unless you are working inside a driver, you don't need to know that].

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  15. #45
    pronounced 'fib' FillYourBrain's Avatar
    Join Date
    Aug 2002
    Posts
    2,297
    the only disadvantage exists if the resize is not guaranteed to allocate the memory before access. You understand what I'm saying here right? The size of the allocated memory internal is not the same as the "size" of the vector. It doesn't technically need to be allocated until the element is accessed
    "You are stupid! You are stupid! Oh, and don't forget, you are STUPID!" - Dexter

Page 3 of 8 FirstFirst 12345678 LastLast
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. To find the memory leaks without using any tools
    By asadullah in forum C Programming
    Replies: 2
    Last Post: 05-12-2008, 07:54 AM
  2. Replies: 16
    Last Post: 01-01-2008, 03:07 PM
  3. Dynamic memory allocation.
    By HAssan in forum C Programming
    Replies: 3
    Last Post: 09-07-2006, 05:04 PM
  4. Dynamic memory allocation...
    By dicorr in forum C Programming
    Replies: 1
    Last Post: 06-24-2006, 03:59 AM
  5. pointers
    By InvariantLoop in forum C Programming
    Replies: 13
    Last Post: 02-04-2005, 08:32 AM

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