在c ++中只使用std :: string而不是char数组和std :: vector / list而不是数组有任何实际限制吗？

题

我在代码中痴迷地使用向量，列表，字符串和字符串。是否有任何捕获22会让我对使用数组，chars和wchars更感兴趣？

基本上，如果在支持标准模板库的环境中工作，那么使用基元类型的情况实际上更好吗？

解决方案

99％的时间和99％的标准库实现，你会发现std :: vectors足够快，使用它们带来的便利性和安全性将超过任何小的性能成本。

对于那些非常罕见的情况，当你真的需要裸机代码时，你可以将矢量视为C风格的数组：

vector <int> v( 100 );
int * p = &v[0];
p[3] = 42;

C ++标准保证向量是连续分配的，因此保证可以正常工作。

关于字符串，便利因素变得无法容忍，性能问题往往会消失。如果你去攻击C风格的字符串，你也会回到strlen（）这样的函数的使用，这些函数本身就非常缺乏。

对于列表，在使用它们之前，您应该三思而后，甚至三次，无论是您自己的实现还是标准。使用矢量/数组可以更好地解决绝大多数计算问题。列表中常见的原因很大程度上是因为它们是教科书和培训课程编写者用来一次性解释指针和动态分配的便捷数据结构。我作为前培训课程作家在这里发言。

其他提示

我会坚持使用STL类（向量，字符串等）。它们更安全，更易于使用，更高效，内存泄漏的可能性更小，而AFAIK，它们至少在DEBUG时间（Visual C ++）进行一些额外的运行时边界检查。

然后，测量性能。如果您确定瓶颈在STL类上，则转到C样式字符串和数组用法。

根据我的经验，在矢量或字符串使用方面存在瓶颈的可能性非常低。

一个问题是访问元素时的开销。即使使用向量和字符串，当您通过索引访问元素时，您需要首先检索缓冲区地址，然后添加偏移量（您不要手动执行，但编译器会发出此类代码）。使用原始数组，您已经拥有缓冲区地址。这种额外的间接性可能会在某些情况下导致显着的开销，并且在您希望提高性能时需要进行性能分析。

如果您不需要实时回复，请坚持使用您的方法。它们比字符更安全。

你偶尔会遇到这样一种场景，即你自己做一些事情可以获得更好的性能或内存使用率（例如，std :: string通常有大约24字节的开销，12字节用于std :: string本身的指针，以及动态分配的一个标题块。）

我参与了从std :: string转换为const char *的项目，保存了明显的内存（10的MB）。我不相信这些项目是你所谓的典型项目。

哦，使用STL会损害您的编译时间，并且在某些时候可能会出现问题。当您的项目导致超过GB的目标文件传递给链接器时，您可能需要考虑其中有多少是模板膨胀。

我曾参与过多个项目，其中字符串的内存开销已成问题。

值得提前考虑您的应用程序需要扩展的程度。如果你需要存储无限数量的字符串，那么在全局管理的字符串表中使用 const char * 可以节省大量的内存。

但一般情况下，除非有充分的理由不这样做，否则一定要使用STL类型。

我认为默认的内存分配技术是向量的缓冲区，而字符串是每次当前分配的内存用完时分配双倍内存量的缓冲区。这可能是浪费。您当然可以提供自定义分配器...

要考虑的另一件事是堆栈与堆。静态大小的数组和字符串可以放在堆栈上，或者至少编译器会为您处理内存管理。如果新的编译器提供相关的C99 / C ++ 0x功能，它们也将为您处理动态大小的数组。向量和字符串将始终使用堆，如果您有严格的约束，这可能会引入性能问题。

根据经验，使用什么已经存在，除非它以其速度/内存开销伤害你的项目......你可能会发现，对于99％的东西，STL提供的课程可以节省你的时间和精力，几乎没有对应用程序性能的影响。（即“避免过早优化”）

许可以下： CC-BY-SA 和归因