Calling resize (or specifying a size in the constructor) allocates the contiguous memory immediately, just like new[]. That is guaranteed by the standard.
Printable View
Calling resize (or specifying a size in the constructor) allocates the contiguous memory immediately, just like new[]. That is guaranteed by the standard.
resize() is guaranteed to allocate the memory. Not only does it allocate the memory, but it initialises the objects to be inserted.Quote:
the only disadvantage exists if the resize is not guaranteed to allocate the memory before access.
That is often true, but this is also true for new[]/delete[], unless you take pains to scale the dynamically allocated array to just the right size.Quote:
The size of the allocated memory internal is not the same as the "size" of the vector.
I hear you guys and I'll take your word for it, but I gotta tell ya. We're developing an unnatural fear of things that aren't automatically deleted or garbage collected. I say this having spent two years working with java programmers. These people have lost (or never had) important understanding of the code they write.
I don't see the logic in using a more cumbersome tool just so that users "understand" what they're doing better. I think any tool will be mismanaged by unqualified programmers. The language (and best practices of that language) should be designed primarily to make the qualified programmer's job easier.
new/delete more cumbersome? really?
In the face of exceptions and pure human carelessness, I would say that it is a healthy fear. Perhaps you have not read Stroustrup's answer to the FAQ How do I deal with memory leaks?Quote:
I hear you guys and I'll take your word for it, but I gotta tell ya. We're developing an unnatural fear of things that aren't automatically deleted or garbage collected.
EDIT:
Consider this function:Quote:
new/delete more cumbersome? really?
Suppose bar() might throw an exception. How would you fix the potential memory leak? Would you even recognise that there is a potential memory leak?Code:void foo(size_t n)
{
Widget* widgets = new Widget[n];
bar(widgets, n);
delete[] widgets;
}
I will concede that it may be safer. For simple methods that read from a network stream though I really don't see the need to worry about it.
It should be noted that the original poster's variable length arrays does not have the possibility of memory leaks and could be used instead.
>> new/delete more cumbersome? really? <<
Of course. You have to remember to call delete.
>> It should be noted that the original poster's variable length arrays does not have the possibility of memory leaks and could be used instead. <<
But why should they, when vector is standard?
If you need a fixed-length array, you should be using std::tr1::array instead!
Of course, it isn't dynamic and must be determined at compile time.
And if it isn't determined at compile time, it's dynamic!
The variable length vector allows for the buffer of variable length without the possibility of memory leak. Within the scope of a function, this produces the least overhead and is easiest to read. That's what I'm talking about.
Since its apparently going into the standard or already in it, its a pretty smart addition
>> That's easy. Using an array is cleaner. It acts like a fixed length array. Why dynamically allocate inside a vector? <<
I don't think it's any cleaner. It may be more efficient, but I'm not sure that would be an issue in most cases.
If you find that a variable length array is noticeably more efficient in your application and you know you only need to build with gcc, then I wouldn't have a problem using a variable length array over vector for that situation.
>> Within the scope of a function, this produces the least overhead and is easiest to read. That's what I'm talking about. <<
I don't understand this point. How is it easier to read than a vector? (Note: I posted an example earlier of the two lines needed for the vector.)