1

Say I have two sets of code,

std::vector<float>v1;

and

std::vector<float> *pV2 = new std::vector<float>(10);

What is the difference between the two other than the fact that you will have a larger chunk of memory allocated with the pointer to the vector? Is there an advantage to one vs. the other?

In my mind, it seems like allocating the pointer is just more of a hassle because you have to deal with deallocating it later.

foboi1122
  • 1,557
  • 3
  • 17
  • 35
  • example 2 is wrong, there is no need to heap allocate the vector, it will do that itself internally – paulm Feb 14 '14 at 00:30
  • 1
    http://stackoverflow.com/questions/6500313/c-why-should-new-be-used-as-little-as-possible – TT_ Feb 14 '14 at 00:35
  • 2
    @paulm _'example 2 is wrong'_ No, it isn't **wrong**! Just prone to be managed in a wrong way. – πάντα ῥεῖ Feb 14 '14 at 00:35
  • http://stackoverflow.com/questions/17299951/c-vector-what-happens-whenever-it-expands-reallocate-on-stack – Pixelchemist Feb 14 '14 at 00:35
  • thank you everyone for all your help, so I guess the smart thing to do is just not call it as a pointer? Seems allocation is always done on the heap unless otherwise specified. – foboi1122 Feb 14 '14 at 00:42
  • _'unless otherwise specified'_ You **can't really** _'specify otherwise'_ unless giving a different allocator type as 2nd parameter for `std::vector<>`, or replacing the inner workings of `new()[]`! – πάντα ῥεῖ Feb 14 '14 at 01:19
  • Yes it is *WRONG* it should be using std::unique_ptr if there is some reason to allocate it on the heap, raw pointers will just cause bugs. – paulm Feb 14 '14 at 08:50

2 Answers2

1

What is the difference between the two other than the fact that you will have a larger chunk of memory allocated with the pointer to the vector?

  1. 'will have a larger chunk of memory allocated'
    This isn't necessarily true! The std::vector might choose a much larger default initial size for the internally managed data array than 10.
  2. 'What is the difference between the two'
    The main difference is that the 1st one is allocated on the local scopes stack, and the 2nd one (usually) goes to the heap. Note: The internally managed data array goes to the heap anyway!!

To ensure proper memory management when you really have to use a std::vector<float>* pointer allocated from the heap, I'd recommend the use of smart pointers, e.g.:

std::unique_ptr<std::vector<float> > pV2(new std::vector<float>(10));

For more details have a look at the documentation of <memory>.

πάντα ῥεῖ
  • 83,259
  • 13
  • 96
  • 175
0

One of the critical differences is scope. In your first example, the vector will probably either be a member of a class, or it will be local to a function. If it's a class member, it will be destroyed when the containing object is destroyed. If it's local to a function, it will be destroyed when the function ends. The object absolutely cannot exist beyond that, so you have to be very careful if you try passing its address to another part of your program.

When you manually allocate something on the heap instead, it will exist for as long as you want. You're in complete control of the deallocation, which means you can create it in one object/function, and use or delete it in another whenever you need to.

It's also quite useful in various situations to be able to delay instantiation of an object until it's actually required. For example, it may need different construction parameters depending on user input, or you may want to take advantage of polymorphism (i.e. decide at runtime which sub-class to instantiate).

Another key difference for some situations is available memory. If you create an object locally to a function, it will reside on the stack. There is a lot less space available on the stack than on the heap, so you can run into difficulties when using particularly large objects (although that won't happen with a vector because it allocates on the heap internally anyway).

It's worth noting that the actual amount of memory used by the object is the same, whether it's on the stack or on the heap. The only difference is that if you manually allocate something on the heap, then you will also have a pointer to it. That's only an extra 4 or 8 bytes though, which is negligible in most cases.

Peter Bloomfield
  • 5,009
  • 22
  • 34
  • _'It's worth noting that the actual memory usage for the object is the same'_ No, it isn't! It differs by `sizeof(std::vector) - sizeof(std::vector*)` on either stack or heap ... – πάντα ῥεῖ Feb 14 '14 at 01:13
  • @πάνταῥεῖ: Can you elaborate on what you mean? Why would the size be different? – Peter Bloomfield Feb 14 '14 at 01:19
  • Adding another `std::vector` object to the heap (the OP's 2nd case), would require additional `sizeof(std::vector)` (eventually aligned) bytes from there, wouldn't it?? – πάντα ῥεῖ Feb 14 '14 at 01:23
  • I don't think so. The allocation should be exactly the same size no matter where it is. If it wasn't, then array traversal and pointer arithmetic would be different, depending on whether the data was on the stack or heap. – Peter Bloomfield Feb 14 '14 at 01:29
  • I think you misunderstood: For the data managed internally by the `std::vector<>` object, there's no difference (as I also mentioned in my answer). But for the `std::vector<>` object itself managed on heap or stack, there is (at least [`sizeof(std::vector - sizeof(std::vector`](http://ideone.com/fdB9F4))! It's a bit nitpicking, but might matter when calling a function recursively and using a stack allocated vector. For the overall memory consumption of a process there's no considerable difference at all. – πάντα ῥεῖ Feb 14 '14 at 01:40
  • OK, I see what you're getting at. There's no additional memory usage overall though (which is the point I was making in my answer). It's just a question of *where* the allocation takes place. – Peter Bloomfield Feb 14 '14 at 01:48
  • _'It's just a question of where the allocation takes place.'_ Yes, exactly. But there are cases when the _where_ matters! Sorry discussion of [tag:c++] language features needs to be precise ... – πάντα ῥεῖ Feb 14 '14 at 01:49