在我的例子中,矢量更合适 - C ++

时间:2012-01-21 03:43:19

标签: arrays performance vector

我已经阅读过Stack Overflow和其他地方的传感器,它们比读取和写入的数组更快。我的程序有一个有趣的问题,我正在阅读的文件包含许多不同类型的片段,但我不知道每种类型的片段有多少,直到我阅读它们。因此,例如,如果片段1可以通过

识别
struct frag_1
{
    int number1;
    int number2;
};

我已经通过文件循环,计算每个片段类型出现的次数,分配类型为片段结构的内存数组,如示例结构,然后我填充它们并操纵它们。

看起来好像矢量读取和写入要快得多,动态,因为我可以动态添加它们,通常更好的练习。

这是真的吗?谢谢。

2 个答案:

答案 0 :(得分:0)

实际上,对于这种模式,deque通常是最佳选择。为此目的使用vector,除非您至少可以粗略猜测最终大小,否则将需要大量的分配/复制/空闲周期,因为实现使用的矢量太小。

答案 1 :(得分:0)

您似乎在此处有两个对象列表:片段本身,number1number2作为此特定类型片段的成员。

首先,碎片本身。根据您的描述,使用std::vector,尤其是如果您事先不知道您将拥有多少片段。 (你说的是。)它会为你做内存分配,并大大减少错误的变化,这大大超过任何(非常微小的)速度改进,这样做会让你自己赚钱。

至于成员,请考虑:

struct frag_1
{
    int numbers[2];
};

(另外,考虑更好的变量名称,因为这可能会让你(或我们)更明确地回答哪个是“更好”。)

请注意,我只考虑了矢量与阵列供您使用。如果以后需要通过某个成员查找某个片段,那么某种类型的映射类型可能更合适。如果您只是加载并循环遍历所有片段(并使用它们全部),那么std::vector通常适用于大多数情况。


在调整大小期间显示std:vector的效果:如果您知道矢量的最终大小,则可以提前通知矢量。如果您不知道最终大小,那么您不知道,并且无论容器,都可以调整大小和内存分配。大多数容器,即使发生重新分配,也会产生O( n )性能。你问的问题,以及其他帖子似乎暗示的是,resize将成为你的瓶颈。所以:个人资料。更有可能的是,矢量将完成工作,并且足够快,你不会关心调整大小。如果您正在从磁盘读取内容,单独的磁盘I / O通常会大大超过调整大小操作,因此优化它们毫无意义。