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

由于std::liststd::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::vectorstd::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。