Jump to content
  • Advertisement
Sign in to follow this  
Toadhead

Vectors or Arrays?

This topic is 4835 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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.?

Share this post


Link to post
Share on other sites
Advertisement
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.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
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.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
that would be vector<bool> ... silly parser

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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. :)

Share this post


Link to post
Share on other sites
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 legit

vector<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]

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!