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?
Printable View
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.Quote:
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?
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.
>> 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.
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?
For std::vector, I believe the answer is yes.
Another concern. Even if it is contiguous memory, is it guaranteed to be there before you reference it through an accessor method?
Do you mean you could potentially access array[N], even though it might not exist (ie undefined behavior)?
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?
I mean to me this is exactly the sort of violation of encapsulation that we should be trying to avoid in OOP
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[].Quote:
Even if it is contiguous memory, is it guaranteed to be there before you reference it through an accessor method?
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.
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.
>> 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.
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
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