C++ 模板中的名称查找
我有一些 C++ 代码在没有 -fpermissive 选项的情况下不再编译.这是我无法共享的专有代码,但我认为我已经能够提取一个简单的测试用例来演示问题.这是 g++ 的输出
I have some C++ code that is no longer compiling without the -fpermissive option. It's propriety code that I can't share, but I've think I've been able to extract a simple test case that demonstrates the problem. Here is the output from g++
template_eg.cpp: In instantiation of 'void Special_List<T>::do_other_stuff(T*) [with T = int]':
template_eg.cpp:27:35: required from here
template_eg.cpp:18:25: error: 'next' was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive]
template_eg.cpp:18:25: note: declarations in dependent base 'List<int>' are not found by unqualified lookup
template_eg.cpp:18:25: note: use 'this->next' instead
这里是产生问题的代码:
So here is the code the generates the problem:
template<class T> class List
{
public:
void next(T*){
cout<<"Doing some stuff"<<endl;
}
};
template<class T> class Special_List: public List<T>
{
public:
void do_other_stuff(T* item){
next(item);
}
};
int main(int argc, char *argv[])
{
Special_List<int> b;
int test_int = 3;
b.do_other_stuff(&test_int);
}
我不是想找出如何修复代码以使其再次编译.这只是将 next(item) 更改为 this->next(item) 的问题我试图更好地理解为什么这种改变是必要的.我在这个页面上找到了一个解释:http://gcc.gnu.org/onlinedocs/gcc/Name-lookup.html虽然这个解释很有用,但我仍然有一些问题.我的函数采用 T*(指向类型 T 的指针)这一事实不应该使它依赖于模板参数.用我自己的话来说,编译器(gcc 4.7)不应该能够确定 next() 函数在基类 List 中吗?为什么有必要在每个这样的调用前加上 this-> ?我注意到 clang 3.1 表现出相同的行为,所以我假设 c++ 标准中有一些要求需要这种行为.任何人都可以提供理由吗?
I am not trying to find out how to fix the code to make it compile again. That's simply a matter of changing next(item) to this->next(item) I'm trying to better understand why this change is necessary. I found an explanation on this page: http://gcc.gnu.org/onlinedocs/gcc/Name-lookup.html While that explanation was useful, I still have some questions. Shouldn't the fact that my function takes a T* (pointer to type T) make it dependent on the template argument. In my own wording, shouldn't the compiler (gcc 4.7) be able to figure out that the next() function is in the base class List? Why is it necessary to prepend this-> in front of every such call? I've notice that clang 3.1 exhibits the same behavior, so I assume that there is some requirement in the c++ standard that requires this behavior. Could anyone provide a justification for it?
推荐答案
问题是模板是分两遍处理的(按照标准,VS 不然).在第一遍中,在类型替换之前,查找并检查所有不依赖于模板参数的内容.一旦类型被替换,从属名称就会在第二次传递中被解析.
The problem is that templates are processed in two passes (according to the standard, VS does otherwise). In the first pass, before the type substitution, everything that does not depend on the template arguments is looked up and checked. Dependent names are then left to resolve in the second pass, once the type has been substituted.
现在,在第一遍中没有任何内容表明next
依赖于模板参数,因此它需要在类型替换之前解析.现在,因为基本类型是在当前模板的模板参数上模板化的,编译器无法查看它(它可能专门用于某些类型,并且不知道我们正在实例化模板的类型 T
与,我们不知道使用哪个专业化,即基础 depends 在 T
上,我们在知道 T
之前正在检查).
Now, in the first pass there is nothing that indicates that next
is dependent on template arguments, and thus it needs to resolve before type substitution. Now, because the base type is templated on the template argument of your current template, the compiler cannot look into it (it might be specialized for some types, and without knowing what type T
we are instantiating the template with, we cannot know which specialization to use, i.e. the base depends on T
and we are checking before knowing T
).
添加 this->
的技巧将 next
变成了依赖名称,这反过来意味着查找被延迟到第二遍,其中 T
是已知的,因为 T
是已知的,所以 List
也是已知的,可以查询.
The trick of adding this->
turns next
into a dependent name, and that in turn means that lookup is delayed until the second pass, where T
is known, and because T
is known, List<T>
is also known and can be looked up into.
EDIT:上述答案的措辞中缺少的一个重要细节是第二阶段查找(在类型替换之后)只会添加在参数相关查找期间找到的函数.也就是说,如果 next
是与 T
关联的命名空间中的自由函数,它将被找到,但它是基础上的成员,对于 ADL 上的 ADL 不可见T
.
EDIT: One important detail missing in the wording of the answer above is that second phase lookup (after type substitution) will only add functions found during argument dependent lookup. That is, if next
was a free function in a namespace associated with T
it would be found, but it is a member on the base, which is not visible for ADL on T
.
相关文章