Vectors or Arrays?
Author
Someone told me I shouldnt use arrays but I should use vectors (from the STL) instead. Whats actually the big difference? Why shouldnt I use arrays??
Can anyone tell me which is faster, better etc.?
Arrays sizes must be defined at compile-time. All they have to go for them is that they are fast to create. Vectors are classes that encapsulate dynamic arrays (created with new). They have variable sizes and loads of extra functionality. They are slightly slower to create than fixed-size arrays, but just as fast, and more convenient, than dynamically-allocated arrays.
Unless you have a solid and well-reasoned reason not to, use a vector.
Unless you have a solid and well-reasoned reason not to, use a vector.
Plus, the standard states that each element in a vector only takes up 1 bit of memory. Very handy for storing state information, and it lets you skip all of the bitwise/bitshifting that you'd have to do if you used any other type.
vector<bool> has ... issues that render it unsuitable to many tasks. For starters, it doesn't contain bool: that too clever bit-packing idea is something that has come back to bite the collective arses of the C++ Committee.
Quote:Original post by Fruny
Arrays sizes must be defined at compile-time.
int sizeOfArray;cin >> sizeOfArray;int *myArray = new int[sizeOfArray]; delete [] myArray;Obviously you don't have to define array sizes at compile-time. Unless I'm mistaken, what you probably wanted to say was that arrays cannot be used as dynamically as such things as lists, as an array is usually allocated as a "pre-defined block" which is then filled. However even the size of arrays can be dynamically changed, but usually when you need that - you probably should have been using a list.
If you need maximum speed to access indexed data, I guess Arrays is the way to go.
Quote:However even the size of arrays can be dynamically changed, but usually when you need that - you probably should have been using a list.
Not necessarily; lists don't have very good traversal speeds compared to vectors due to non-continguously allocated memory, and vectors only suffer from resizing when you add to a location other than the end. If you don't often have to remove things from the middle, and spend a lot of time instead traversing, then a vector may still be suitable.
Fruny, I'm not certain which tasks vector<bool> are unsuitable for? I respect your opinions and experience, so please know that I am genuinely interested.
Why would it matter how the data is stored within the container? [], at() and *_iterator all return bool, do they not?
I only suggested it because the syntax is easy and familiar, it uses a reasonable amount of memory, and it seems like it isn't really known to many.
I do have one good use for them...
The main reason I used them was because I was working with quaternion Julia sets on a 3D grid which contained 1625^3 points. If vector<bool> did not auto-magically bit-pack the data, the same sets I'm generating now on a measly 2GB of RAM would take 16GB. I'm just grateful that they made a special case for the vector/bool combination so I didn't have to write it myself, that's all. :)
Why would it matter how the data is stored within the container? [], at() and *_iterator all return bool, do they not?
I only suggested it because the syntax is easy and familiar, it uses a reasonable amount of memory, and it seems like it isn't really known to many.
I do have one good use for them...
The main reason I used them was because I was working with quaternion Julia sets on a 3D grid which contained 1625^3 points. If vector<bool> did not auto-magically bit-pack the data, the same sets I'm generating now on a measly 2GB of RAM would take 16GB. I'm just grateful that they made a special case for the vector/bool combination so I didn't have to write it myself, that's all. :)
Quote:Original post by taby
Why would it matter how the data is stored within the container? [], at() and *_iterator all return bool, do they not?
Not with std::vector<bool> they don't. They return an object that is convertible to bool (I strongly suggest you have a look at the code). What that means is that you cannot take the address of an element - as you can with the other vector types, and manipulate the object through that pointer:
vector<int> ivec(50);int* iptr = &ivec[5]; // Perfectly legitvector<bool> bvec[50];bool* bptr = &bvec[5]; // Won't do you any good.It is common to take the address of the first element of a vector to get access to the underlying dynamic array, but you can't do that with vector<bool>. It doesn't store bools internally, so you can't expect it to be able to return you the address of a stored bool, can you?
Quote:I'm just grateful that they made a special case for the vector/bool combination so I didn't have to write it myself, that's all. :)
They should really have provided a separate container rather than violate vector's contract. After all, we already have std::bitset and, now, boost::dynamic_bitset. So it's not really like we neet vector<bool> to be packed... because now it is impossible to have an unpacked std::vector.
[Edited by - Fruny on August 10, 2005 8:48:33 PM]
Quote:Original post by Caminman
Obviously you don't have to define array sizes at compile-time.
I have addressed dynamically allocated arrays. Considering that they are only accessible through a pointer, they aren't stricto-sensu an array. Variable Length Arrays (VLAs) are a C99 addition which isn't part of C++.
Quote:However even the size of arrays can be dynamically changed, but usually when you need that - you probably should have been using a list.
Nope, you can't change the size of an array.
Quote:If you need maximum speed to access indexed data, I guess Arrays is the way to go.
There shouldn't be any access speed difference between a vector and an array. And certainly not between a vector and a dynamically-allocated array.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
