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?
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
One of the "abilities" of the standard containers is memory management.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.
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
>> 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?
"You are stupid! You are stupid! Oh, and don't forget, you are STUPID!" - Dexter
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
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
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
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[].Even if it is contiguous memory, is it guaranteed to be there before you reference it through an accessor method?
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
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
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
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.
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