What's wrong with arrays?

In terms of time and space, an array is just about the optimal construct for accessing a sequence of objects in memory. It is, however, also a very low level data structure with a vast potential for misuse and errors and in essentially all cases there are better alternatives. By "better" I mean easier to write, easier to read, less error prone, and as fast.

The two fundamental problems with arrays are that

an array doesn't know its own size the name of an array converts to a pointer to its first element at the slightest provocation Consider some examples: void f(int a[], int s) { // do something with a; the size of a is s for (int i = 0; i<s; ++i) a[i] = i; } int arr1[20]; int arr2[10]; void g() { f(arr1,20); f(arr2,20); } The second call will scribble all over memory that doesn't belong to arr2. Naturally, a programmer usually get the size right, but it's extra work and ever so often someone makes the mistake. I prefer the simpler and cleaner version using the standard library vector: void f(vector<int>& v) { // do something with v for (int i = 0; i<v.size(); ++i) v[i] = i; } vector<int> v1(20); vector<int> v2(10); void g() { f(v1); f(v2); }

Since an array doesn't know its size, there can be no array assignment:

void f(int a[], int b[], int size) { a = b; // not array assignment memcpy(a,b,size); // a = b // ... } Again, I prefer vector: void g(vector<int>& a, vector<int>& b, int size) { a = b; // ... } Another advantage of vector here is that memcpy() is not going to do the right thing for elements with copy constructors, such as strings. void f(string a[], string b[], int size) { a = b; // not array assignment memcpy(a,b,size); // disaster // ... } void g(vector<string>& a, vector<string>& b, int size) { a = b; // ... }

An array is of a fixed size determined at compile time:

const int S = 10; void f(int s) { int a1[s]; // error int a2[S]; // ok // if I want to extend a2, I'll have to chage to an array // allocated on free store using malloc() and use ralloc() // ... } To contrast: const int S = 10; void g(int s) { vector<int> v1(s); // ok vector<int> v2(S); // ok v2.resize(v2.size()*2); // ... } C99 allows variable array bounds for local arrays, but those VLAs have their own problems.

The way that array names "decay" into pointers is fundamental to their use in C and C++. However, array decay interact very badly with inheritance. Consider:

class Base { void fct(); /* ... */ }; class Derived { /* ... */ }; void f(Base* p, int sz) { for (int i=0; i<sz; ++i) p[i].fct(); } Base ab[20]; Derived ad[20]; void g() { f(ab,20); f(ad,20); // disaster! } In the last call, the Derived[] is treated as a Base[] and the subscripting no longer works correctly when sizeof(Derived)!=sizeof(Base) -- as will be the case in most cases of interest. If we used vectors instead, the error would be caught at compile time: void f(vector<Base>& v) { for (int i=0; i<v.size(); ++i) v[i].fct(); } vector<Base> ab(20); vector<Derived> ad(20); void g() { f(ab); f(ad); // error: cannot convert a vector<Derived> to a vector<Base> } I find that an astonishing number of novice programming errors in C and C++ relate to (mis)uses of arrays.