数组应该用在C ++中吗？

由于std::list和std::vector存在，是否有理由在C ++中使用传统的C数组，或者应该避免，就像malloc ？

在C ++ 11中， std::array是可用的，答案是“是的，应该避免数组”。在C ++ 11之前，您可能需要使用C数组来分配自动存储中的数组（即在堆栈上）。

当然，虽然在C ++ 11中使用std::array ，但实际上只适用于静态数据。 C风格的数组比std::vector有三个重要的优点：

他们不需要dynamic分配。出于这个原因，C风格的数组将是首选的地方，你可能有很多非常小的数组。像一个n维点说：
```
 template <typename T, int dims> class Point { T myData[dims]; // ... }; 
```
通常情况下，人们可以想象一个dims将会非常小（2或3）， T是一个内置types（ double ），并且可能以std::vector<Point>结尾，并带有数百万个元素。你绝对不希望成千上万的dynamic分配3倍。
支持静态初始化。这只是静态数据的一个问题，其中像这样的：
```
 struct Data { int i; char const* s; }; Data const ourData[] = { { 1, "one" }, { 2, "two" }, // ... }; 
```
这通常优于使用vector（和std::string ），因为它避免了所有的初始化问题; 数据是预先加载的，在任何实际的代码可以执行之前。
最后，与上面相关，编译器可以从初始化器中计算出数组的实际大小。你不必数它们。

如果你有权访问C ++ 11， std::array解决了前两个问题，在第一种情况下，肯定应该优先使用C风格的数组。然而，它并没有解决第三个问题，并且让编译器根据初始化符的数量维度数组仍然是selectC样式数组的依据。

永远不要说“从不”，但我同意他们的angular色被STL的真实数据结构大大地削弱了。

我也会说，封装在对象内应该尽量减less这种select的影响。如果该数组是私有数据成员，则可以将其交换出来而不影响您的类的客户端。

我已经在安全关键系统上工作，您无法使用dynamic内存分配。内存必须始终在堆栈上。因此，在这种情况下，您将使用数组，因为在编译时，大小是固定的。

在c++ array给你固定大小的快速替代dynamic大小的std::vector和std::list 。 std :: array是c++11中的新增function之一。它提供了std容器的好处，同时还提供了C风格数组的聚合types语义。

所以在c++11我肯定会使用std::array ，它是必需的，通过向量。但是我会避免C++03 C风格的数组。

大多数情况下，不，我想不出一个理由使用原始数组，比如vectors 。 如果代码是新的 。

如果您的库需要与需要数组和原始指针的代码兼容，则可能不得不使用数组。

我知道很多人都指出std :: array分配堆栈上的数组，堆std :: vector。但似乎都不支持非本地alignment。如果你正在做任何你想要使用SSE或VPX指令的数字代码（因此分别需要128或256字节alignment），C数组似乎仍然是你最好的select。

我会说数组仍然是有用的，如果你正在存储一个小静态数据为什么不。

数组的唯一优点（当然包含在需要的时候会自动pipe理其取消分配的东西）通过std::vector我可以想到的是vector不能传递其数据的所有权，除非您的编译器支持C ++ 11并移动构造函数。

C风格的数组是一个基本的数据结构，所以会有更好的使用它的情况。但是，对于一般情况，请使用四舍五入隐藏数据angular落的更高级的数据结构。 C ++允许你用内存做一些非常有趣和有用的事情，其中很多都使用简单的数组。

你应该在内部使用STL容器，但是你不应该在不同模块之间传递指向这些容器的指针，否则你最终会依赖于地狱。例：

 std::string foo; // fill foo with stuff myExternalOutputProc(foo.c_str());

是一个非常好的解决scheme，但不是

 std::string foo; // fill foo with stuff myExternalOutputProc(&foo);

原因是std :: string可以用许多不同的方式实现，但是一个c样式的string总是一个c样式的string。