Well, there's a bit of a speed boost with straight arrays, depending on what you're doing. And if you're not using any of the fancy functionality, making lots of vectors when you could easily get by using lots of arrays can bloat up your program, I imagine. My tilemap class in my editor uses vectors internally because they're easy to edit, but I use arrays in the game engine for speed, and because I don't need the STL functionality anymore.

Different tools for different situations.

The interface of an array is also supported by std::vector and iterators act like pointers (even more, they are implemented just as simple pointers sometimes for std::vector), so using an iterator is like using a pointer and using std::vector is like using a C-array.

std::vector is the choice when you need to use a self-resizeable container with random access (or even better, direct access) to any element of it in constant time.

If you already know the size (or limit) of the vector/array and you know it won't change, you can use a simple C-array and you'll still be able to use it in STL algorithms, in this case pointers to elements of the C-array are just random access iterators.

I don't get your point. What kind of game can be made using a C-array but not with std::vector?

Ppl should be used to receive objects as references (or pointer to them), in that case I don't see the "implementation dependent" behavior in there, they'll act the same way as if you were receiving a C-array:

int feed_me(std::vector<int> & v)
{
  return *v.begin() + *(v.end() - 1);
}

int main()
{
  //...
  std::vector<int> g(10, 9);
  //...
  std::cout << feed_me(g) << std::endl;
  //...
}

If you didn't receive it as reference or pointer, you'd get a copy of it, something you couldn't do with C-arrays without creating a few helper functions first.

The point is:
std:vector is like using an array.

gcc will even inline the [] operator calls, so you won't see a difference in the generated code (just tried it).

What you should do is to check what data structure you need. And then use it.
If you need dynamic arrays use vector.
If you need static arrays use normal arrays.
If you need a stack, use the stack...

It's pretty straight forward.

Iteraters are not pointers. If you treat them as pointers, you're begging for problems. Iteraters aren't guarenteed to be only a CPU word in size.

What about the case of returning an array?

For a C-array, you just do:

int iArray[20];
int *FuncName()
{
  return iArray;
}

It is immediately obvious how to treat the return value. If you don't want someone to be able to change the return value, use a 'const int *FuncName()'. You are guarenteed that no copy operation will result, and that any changes you make will stick.

However, what about:

vector<int> iVec;
vector<int> &FuncName()
{
  return iVec;
}

Will this code result in a copy? Maybe; it depends on what they do on their end. It's far too easy for someone to do the wrong thing. Sure, you can do:

vector<int> iVec;
vector<int> *FuncName()
{
  return *iVec;
}

to virtually guarentee that a copy operation doesn't occur. However, if you've ever worked with a std::vector*, you'll know it's really annoying and ugly (->[] is not a normal thing, and adding in a lot of (*) is also annoying).

Do you? Do std::vector's have copy symantics? Are you sure? Are you sure that some implementations aren't allowed to implicitly reference vectors?

What I do in my game is use temporary vectors, then copy all the information from them into a pointer that has been created with new [ vector.size() ]. Because vectors are bigger and when I want to network a game, I can't send a vector because (I believe, I could be wrong) that they have pointers, and sending the address of something is no good.

Someone was telling me that the standard does say the elements are linear or something to that effect.

Oh wait it says that accessing any element is O(1) time. That means there must be a direct mapping. Hmm I don't have my copy of the standard with me right now.

Anyway, if we are talking about performance you have to talk about an implementation of STL. And all the implementions I've seen store elements linearly in memory.

And I will bet you that using an iterator and accessing an vector using [] will generate the identical assembly code that an array would, at least for MSVC.NET. Adding elements will take more code than a C array if you don't allow resizing. I would prove it were I not on vacation .

No. More code is generated for adding elements to the std::vector because it has to check to see if its size is too much.

If you take an example of you want to make an array of 50 elements. In the C method you allocate a new 50-element array and add 50 things to it. In the C++ method you do the same in a std::vector.

If you are using actual C, the C way is faster and generates less code. If you are using dynamic arrays in C++ with objects, then the array method may be SLOWER than the std::vector method because std::vector takes advantage of std::allocator and placement new to prevent redundant data copy. In the std::vector case with primitive objects, it will be slower than an array because of size checks, but the std::vector was is easier and safer imho and and speed decrease is worth it, and all of the speed advantages just make it better.

I kindof awnsered my own question today. I tried to make a multidimentional array out of vectors and MSVC got mad at me, so I decided to just write a 2D array template class using new and delete and it works great and looks much cleaner then the iterator BS I surely would have had to write with the vector approach.

Anyone want to see the class? Mabey you can tell me how to better it a little? OK!! You convinced me. here it is you nags!

Regarding the 2d array class:

You should use a virtual constructor, declare a copy ctor and an opertator=

Other than that, it looks ok at the first glance