C++矢量矢量

xbo*_*nez 9 c++ vector

我有一个名为Grid.h的类头文件,其中包含以下2个私有数据对象:

vector<int> column;
vector<vector<int>> row;
Run Code Online (Sandbox Code Playgroud)

一个公共方法,其原型在Grid.h中是这样的:

int getElement (unsigned int& col, unsigned int& row);
Run Code Online (Sandbox Code Playgroud)

上面提到的函数的定义在Grid.cpp中定义如下:

int getElement (unsigned int& col, unsigned int& row)
{
    return row[row][col] ;
}
Run Code Online (Sandbox Code Playgroud)

当我运行该程序时,我收到此错误:

error C2109: subscript requires array or pointer type
Run Code Online (Sandbox Code Playgroud)

什么出错了?

Jon*_*vis 18

return row[row][col];第一行rowint&,而不是vector.

在内部作用域中声明的变量是在外部作用域中隐藏变量,因此编译器正在尝试索引int而不是a vector,这显然是不能做的.

您应该修改变量名称,以便它们不会发生冲突.

编辑:此外,虽然你得到的错误表明编译器找到了错误的row变量,正如A. Levy指出的那样,你的声明也有问题vector,所以即使你修改了变量名,如果你确实声明了vector这里显示的,它不会编译.嵌套模板需要>符号之间的空格,否则编译器将读>>作右移运算符而不是模板声明的一部分.它需要

std::vector<std::vector<int> > row;
Run Code Online (Sandbox Code Playgroud)

要么

std::vector< std::vector<int> > row;
Run Code Online (Sandbox Code Playgroud)

另外,当您在头文件中执行此操作时,您将需要std::在std命名空间的前面添加标记 - 例如vector.如果它在cpp文件中,那么你可以使用using namespace std;但在头文件中这样做会非常糟糕(因为它会污染全局命名空间).如果没有std::标记或using语句,编译器将无法识别vector.


A. *_*evy 8

这可能不是索引问题,但您还需要向量类型声明向量中的嵌套尖括号之间的空格.C++编译器很难说明嵌套模板类型和正确的位移运算符之间的区别.

例:

vector<vector<int> >  vec2d;        // Good.

vector<vector<int>>   anotherVec2d; // Bad!

vector< vector<int> > yetAgain;     // Best IMHO. 
                                    // Keeps the white space balanced.
Run Code Online (Sandbox Code Playgroud)

  • @KevenK,两个符号之间的空格阻止编译器将它们视为单个运算符.我希望我可以对你的评论进行投票. (9认同)
  • 在这种情况下,空间非常重要.解析器使用最大的munch进行解析,因此它可以获取最大的令牌.这意味着在`vector <vector <int >>`它将解析`>>`作为移位运算符而不是模板声明的一部分.您需要额外的空间来向编译器指示您正在声明模板而不是带有移位运算符的表达式. (3认同)
  • 现在已经改变了.如果您正在使用当前的编译器,您可以编写"vector <vector <int >>"并获得您期望的结果.尚不标准,但VS2010,g ++,几乎可以肯定其他人现在支持它. (3认同)
  • @ Mark/Jonathan:如果我的评论在每个编译器上都不正确,我很抱歉.我有点纠正,虽然这听起来像是一些编译器的缺点.我不能说我个人使用了太多不同的编译器,但我知道它至少可以用于Microsoft C++编译器,因为至少VC++ 2005(可能更早). (2认同)
  • 所以,真的,这是语言的缺陷,而不是编译器.一些编译器编写者选择打破标准以克服这个缺陷(如果这是你使用的唯一编译器,但是会损害可移植性并导致问题,这很方便),而其他人则选择遵循该标准.幸运的是,下一个标准修复了语言中的这一缺陷,因此它不再是一个问题.我真的不会说这是编译器中的缺陷,因为这是当前标准的方式. (2认同)