43

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);
}

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?

Avatar33
  • 787
  • 5
  • 14

3 Answers3

64

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.

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).

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: 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.

David Rodríguez - dribeas
  • 204,818
  • 23
  • 294
  • 489
  • Thanks! So if I understand correctly the arguments to next are not relevant. The fact that next() takes a dependent argument, does not make next() dependent? – Avatar33 May 17 '12 at 16:25
  • @Avatar33: `next()` is dependent, but the second phase lookup will only add results from ADL, which don't include members of the base. I might have to revisit the form of the answer... – David Rodríguez - dribeas May 19 '14 at 17:40
  • Still confused.. Without `this->`, phase 1 can't find `next` since it is dependent. Phase 2 can't find it since it can't be found by ADL. With `this->`, it is found by a lookup method (no ADL) in phase 2, i.e., the lookup will go into base class? TIA. – toddwz Feb 18 '16 at 17:26
  • @toddwz: During the second phase the compiler has access to everything that is declared prior to the expression being resolved *and* also ADL. The second phase is not *only* ADL. Note that when you add `this->` what you are changing is not just *when* but also *what* is being resolved. In `next()` the compiler needs to find through lookup `next`, in `this->next()` unqualified lookup is for `this`, which resolves to the specialization (after type instantiation, since we are in the second phase), and then `next` is looked up within the instantiated template. – David Rodríguez - dribeas Feb 19 '16 at 09:40
  • @David Rodríguez - dribeas, thank you for the explanation. – toddwz Feb 19 '16 at 18:54
  • Sound really sketchy in that if a free function with the signature existed in the outer scopes, it would be resolved without warning, resulting a hard to find bug. – Adrian Oct 09 '21 at 21:17
14

You need to write this-> as:

this->next(item);

Here this-> part is required because next() is an inherited member from template base, and if you read the error message carefully, it is suggested there itself:

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

Read this article which has explained two-phase name lookup in C++:

MaksymB
  • 1,267
  • 10
  • 33
Nawaz
  • 353,942
  • 115
  • 666
  • 851
5

If your base class is a template instance, then there's no way to know that next refers to a name in the base class -- after all, the name needn't even exist (think about specializations)! Thus, you have to assert to the compiler that next is actually a class member by saying this->, or List<T>::next, or by prepending using List<T>::next; to your derived class template.

Kerrek SB
  • 464,522
  • 92
  • 875
  • 1,084
  • This last `using` technique is very helpful in the case of `using`/`typedef` declarations in the base class, for which you can't use `this->`. You could explicitly use `typename Base::MyType` wherever you refer to the type, or more conveniently you can declare `using typename Base::MyType;` in the derived class. – Jeremy Jan 05 '17 at 10:47