Dynamic memory allocation

This is a discussion on Dynamic memory allocation within the C++ Programming forums, part of the General Programming Boards category; deal...

  1. #91
    pronounced 'fib' FillYourBrain's Avatar
    Join Date
    Aug 2002
    Posts
    2,297
    deal
    "You are stupid! You are stupid! Oh, and don't forget, you are STUPID!" - Dexter

  2. #92
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,411
    Good luck with your quest!
    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.

  3. #93
    Registered User C_ntua's Avatar
    Join Date
    Jun 2008
    Posts
    1,853
    I don't get one thing of the whole discussion, though that might be based on my lack of knowledge. But, doesn't technically vector call new to allocate memory on the heap? That's the way I see it, that's why I said the discussion is kind of pointless. It is like comparing a door to a house. The one includes the other. I don't really see how dynamically allocating a chunk of memory and assigning a pointer be compared with an object that does that and many many other things.

    And I don't see why new cannot be better than a vector. Much better maybe not. But generally better of course it can be. Problem: store X int inserted by the user. Then make calculations with those values, which wont be further changed.
    Answer1: dynamically allocate an array of X to store the values.
    Answe2: use a vector of size X to store the values.
    Note that both answers will work. But if I had said:
    Answer3: dynamically allocate an array of X+2 to store the values
    then a lot would say that answer1 is obviously better, since you don't need the extra 8 bytes. But the vector will use more than 8 extra bytes.
    So there are cases that new is better, slightly but yet better. But why not use the slightly better solution? Its free.


    >> That is true. On the other hand, these checks are unavoidable, even if you implement a dynamic array by hand. If they are avoidable, then push_back() was avoidable to begin with, so you have simply used the wrong function. <<
    I meant what if you don't need to use a function at all?

  4. #94
    pronounced 'fib' FillYourBrain's Avatar
    Join Date
    Aug 2002
    Posts
    2,297
    It really doesn't matter unless you're a zealot.
    "You are stupid! You are stupid! Oh, and don't forget, you are STUPID!" - Dexter

  5. #95
    Registered User
    Join Date
    Jan 2005
    Posts
    7,317
    >> But, doesn't technically vector call new to allocate memory on the heap? That's the way I see it, that's why I said the discussion is kind of pointless. <<

    The discussion is not pointless. Just because both techniques use the same type of memory allocation doesn't mean one isn't better than the other.

    >> It is like comparing a door to a house. The one includes the other. <<

    A house is better for living in than a door. Sure, you could start with a door and build a house around it, but why put in the extra work if you already have a house that an expert built for you?

    As to your problem and answer, I fail to see where the extra 8 bytes come from. Could you go into more detail. It seems to me both would be virtually the same. Also note that even though new[] and vector are not exactly the same, the minor differences that may seem to favor new[] are overshadowed by the simple benefit of automatic memory management.

  6. #96
    Registered User C_ntua's Avatar
    Join Date
    Jun 2008
    Posts
    1,853
    I meant that new int[X+2] will allocate 2 more int than new[X], thus 8bytes if you assume an int to be 4 bytes. Which will make new[X] better in a way, since it lacks nothing but gains some space. So new[X] will be better than a vector since it lacks nothing (for the given example) and gains some space.

  7. #97
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    21,310
    Quote Originally Posted by Daved
    "better" is not subjective. It is objective. It is based on facts and reasoning.
    Once you have settled on the facts, "better" is objective. However, the choice of facts can be subjective (e.g., I may value a particular criterion more than another based simply on "experience" or "intuition").

    Quote Originally Posted by FillYourBrain
    All that was placed before me was to show that there exists at least one case that dynamic is just fine and could be used.
    No, that there exists at least one case where manual memory management is fine is self-evident (it must be used, at least indirectly, to implement any container that performs memory management). The question of whether such manual memory management is better than RAII is a question in general, not in special cases.

    Quote Originally Posted by C_ntua
    I meant that new int[X+2] will allocate 2 more int than new[X], thus 8bytes if you assume an int to be 4 bytes. Which will make new[X] better in a way, since it lacks nothing but gains some space. So new[X] will be better than a vector since it lacks nothing (for the given example) and gains some space.
    That sounds like a straw man argument. Why allocate X+2 when you only need X? How is new[X] better than vector<T>(X)? In terms of space, you may only end up saving on the capacity variable since the array size is equal to its capacity. Besides, this is not "free", as you claim. The price is manual memory management.
    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

  8. #98
    Registered User
    Join Date
    Oct 2001
    Posts
    2,129
    In performance critical code, when debugging, you might want memory bounds checking, but if you use bounds checking in your performance critical code, perhaps it slows it down too much to debug. vector<> uses bounds checking, new[] doesn't.
    Last edited by robwhit; 10-01-2008 at 09:22 PM.

  9. #99
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    4,147
    vector<> uses bounds checking, new[] doesn't.
    Traditionally 'std::vector<?>:perator [int_type]' doesn't do bounds checking where 'std::vector<?>::at(int_type)' does. I don't know of a single provider that does checking for 'std::vector<?>:perator [int_type]' in release mode. I'd be interesting in knowing of this bizarre case you use.

    Edit: And as far as it goes: I've always interpreted the standard as implying that 'std::vector<?>:perator [int_type]' must not do bounds checking even though some implementations do when some compiler flag or macro is or isn't set or defined.

    Soma
    Last edited by phantomotap; 10-01-2008 at 09:34 PM.

  10. #100
    Registered User
    Join Date
    Oct 2001
    Posts
    2,129
    Hmm. Umm... lemme do some research...

  11. #101
    Registered User
    Join Date
    Oct 2001
    Posts
    2,129
    Aha... yeah I wasn't talking about release mode. I was talking about debugging.

  12. #102
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    4,147
    Aha... yeah I wasn't talking about release mode.
    Did... did you just go "aha"?! O_o

    Edit: Aha! I actually know of eight library distributions that never do bounds checking for 'std::vector<?>perator [int_type]' debugging mode or no.

    Edit: Aha! ^_^

    Soma
    Last edited by phantomotap; 10-01-2008 at 10:51 PM.

  13. #103
    Registered User
    Join Date
    Oct 2001
    Posts
    2,129
    Yes. O_o

  14. #104
    Registered User
    Join Date
    Jan 2005
    Posts
    7,317
    >> So new[X] will be better than a vector since it lacks nothing (for the given example) <<

    Here is where you're missing the important point. new[x] does lack something. And that something, automatic memory management, is not trivial at all. The extra eight bytes that I assume you are talking about coming from the overhead of the vector (?) is trivial. Can you think of a use of new[] or vector where the size will be small enough to not dwarf those two bytes?


    >> I don't know of a single provider that does checking for 'std::vector<?>::operator [int_type]' in release mode. <<

    I think the latest versions of VC++ do. Although you can turn that behavior off.


    >> I've always interpreted the standard as implying that 'std::vector<?>::operator [int_type]' must not do bounds checking <<

    I've never heard that. How would it make such a requirement? The bounds check shouldn't be more than a comparison against the size of the vector, so it would be difficult to require it via a complexity guarantee.

  15. #105
    Registered User
    Join Date
    Jan 2005
    Posts
    7,317
    >> Once you have settled on the facts, "better" is objective. <<

    Perhaps a better way to put it is that once you've defined what better means (in our case in almost always means a program that works better, is easier to maintain, less likely to fail, easier to extend, etc), then the determination of what is better can be based on facts and reasoning. The point is that if someone claimed that square wheels were better for vehicles than round ones because "better" is subjective, you'd just laugh. Is it possible that a situation exists where a square wheel works better for that situation than a round one? Sure. But under the common definition, it's pretty obvious that the facts and reasoning point to the round wheel being better.

    The point is that vector versus new[] is not subjective. My original claim stands. I have yet to hear or read of a situation where it made more sense to use new[]/delete[] rather than vector (except perhaps in the implementation of a vector or similar container).

Page 7 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