Question

Possible Duplicate:
Accessing inherited variable from templated parent class

I have been implementing a binary heap as a subclass of priority_queue, and run into a situation I cannot understand, despite considerable effort. Here is the working version of the code. (Background: c is priority_queue’s backing vector.)

#include <queue>
using namespace std;

template <class nodetype>
class BinaryHeap : public priority_queue<int> {
public:
    BinaryHeap() { vec = &c; }
    vector<nodetype> *vec;
};

int main() {
    BinaryHeap<int> b;
}

However, when you change the superclass to:

class BinaryHeap : public priority_queue<nodetype>

…the compiler complains about the usage of c:

h.cpp: In constructor ‘BinaryHeap<nodetype>::BinaryHeap()’:
h.cpp:10: error: ‘c’ was not declared in this scope

This seems all the more strange because:

1. “[c] is equivalent to this->c” (ref) – and if you use vec = &this->c, it does indeed compile.

2. If you add a using-declaration, using priority_queue<nodetype>::c to BinaryHeap, again, it compiles. But this using-declaration ought to be unnecessary.

Edit:

So, apparently this happens because “the compiler does not look in dependent base classes when looking up nondependent names” (ref) – “c” does not depend on a template parameter, and so is nondependent, and priority_queue<nodetype> does depend on a template parameter – nodetype – so is dependent.

priority_queue<int>, on the other hand, doesn’t depend on nodetype, and so is nondependent, and so the compiler does look in it for names when resolving other nondependent names.

Is this correct? And if so:

Why does the standard mandate this behaviour, when “[looking] in dependent base classes when looking up nondependent names” is clearly possible. What is the benefit? A compile-time performance optimisation?

Answer 1

In the end its simply a matter of the standard defining such a behaviour for templates. The (C++11) standard says the following about non dependent name resolution in [temp.nondep] (14.6.3) :

Non-dependent names used in a template definition are found using the usual name lookup and bound at the point they are used.

Since c doesn’t obviously depend on a template parameter the compiler treats it as a non-dependent name. So what happens is basically the following: When the compiler looks at BinaryHeap the actual type of notetype is unknown and therefore priority_queue<nodetype> is too, since it depends on nodetype (it could be a partial specialization). Therefore the compiler can’t look into that type for the resolution (since we are talking about the point where the template is defined, not where it is instantiated). So it looks in the containing scopes for something called c, finding none and therefore rejecting the code. Using this->c (or using priority_queue<nodetype>::c) makes c a dependent name (since its not a member of BinaryHeap it must be a member of priority_queue<nodetype>), so the name lookup is delayed until the point of instantiation of the template, where notetype is known and the compiler can therefore search in priority_queue<nodetype>.

For your edit: yes, that is correct