scope question

[Christof Warlich]

Hi,

just being curious:
Anyone having a clue why the commented lines do not compile?

Thanks,

Christof

class B {
public:
int x;
};
template<int t> class TB: public B {
public:
int y;
TB() {
// Does compile
x = 0;
B::x = 0;
}
};
template<int t> class D: public TB<t> {
public:
D() {
// Does not compile:
//x = 0;
//B::x = 0;
//y = 0;
// Does compile
this->B::x = 0;
this->x = 0;
D<t>::x = 0;
TB<t>::x = 0;
this->y = 0;
TB<t>::y = 0;
}
};
int main() {}

 

[Kira Yamato]

Hi,

just being curious:
Anyone having a clue why the commented lines do not compile?

Thanks,

Christof

class B {
public:
int x;
};
template<int t> class TB: public B {
public:
int y;
TB() {
// Does compile
x = 0;
B::x = 0;
}
};
template<int t> class D: public TB<t> {
public:
D() {
// Does not compile:
//x = 0;
//B::x = 0;
//y = 0;
// Does compile
this->B::x = 0;
this->x = 0;
D<t>::x = 0;
TB<t>::x = 0;
this->y = 0;
TB<t>::y = 0;
}
};
int main() {}

Google "two phase name lookup C++"

 

[Pavel Shved]

Hi,

just being curious:
Anyone having a clue why the commented lines do not compile?

Thanks,

Christof

class B {
public:
int x;};

template<int t> class TB: public B {
public:
int y;
TB() {
// Does compile
x = 0;
B::x = 0;
}};

template<int t> class D: public TB<t> {
public:
D() {
// Does not compile:
//x = 0;
//B::x = 0;
//y = 0;
// Does compile
this->B::x = 0;
this->x = 0;
D<t>::x = 0;
TB<t>::x = 0;
this->y = 0;
TB<t>::y = 0;
}};

int main() {}

Try changing line

this->B::x = 0;

to
this->B::x = "The conversion is impossible!";

Still compiles. Try even more: change

this->B::x = 0;

to
this->std::iostream::x = "Still compiles...";

And if you replace ublic TB<t> with ublic TB<2> it starts
compiling commented strings...

templates are soo tricky If you play with them a bit, you can
deduce some rules, but for strict ones you should consult standard, i
think.
After some experiments i deduced that compiler delays checking of this-

something correctness to instantation of template, as well as

instantation of templated parents. So he merely doesnt see that B is
our parent and x and y are member variables when compiling D's
constructor.

 

[Christof Warlich]

Try changing line
to
this->B::x = "The conversion is impossible!";

Still compiles. Try even more: change
to
this->std::iostream::x = "Still compiles...";

And if you replace ublic TB<t> with ublic TB<2> it starts
compiling commented strings...

oh, oh - I shouldn't have asked: For decades, I felt so
comfortable with my naive belief in C++ ;-(.

Anyway, thanks a lot for this insight, though I'd better
try to forget .... ;-).

 

[Pavel Shved]

oh, oh - I shouldn't have asked: For decades, I felt so
comfortable with my naive belief in C++ ;-(.

Oh, no, you don't need to get disappointed with C++. The reason why
is described in C++-faq-lite, which link to you may easilly find in
google; check Templates section. I'd post it here, but i consider
unfair repeating what i've learned from experience of this group
subscribers.

 

[James Kanze]

just being curious:
Anyone having a clue why the commented lines do not compile?

The difference is due to dependent vs. non-dependent name
look-up. Basically, the compiler separates names in a template
into two categories, dependent and non-dependent. If the name
is non-dependent, it is lookup up at the point where the
template is defined. If it is dependent, it is looked up when
the template is instantiated, using ADN, and ony ADN.

Basically, a name is dependent if it is used in a context which
depends on the template arguments. The exact rules are a bit
complicated, but that's the gist of it.

class B {
public:
int x;};

template<int t> class TB: public B {

Note that B is not dependent. Regardless of the instantiation
argument, B is B, and cannot change. So the compiler will
consider it during non-dependent name look-up.

public:
int y;
TB() {
// Does compile
x = 0;
B::x = 0;

Obviously. The compiler finds the x in B, in both cases.

}};

template<int t> class D: public TB<t> {

Here, on the other hand, the base class is dependent. The
compiler cannot take it into account for non-dependent name
lookup, since it has no idea what could be in it.

public:
D() {
// Does not compile:
//x = 0;
//B::x = 0;
//y = 0;

That's because the names above are non-dependent, and are looked
up immediately, here, at the point of definition. And because,
at this time, the compiler cannot consider the base class,
because it doesn't know what will or will not be in it. (There
could be an explicit specialization that it hasn't seen yet, for
example.)

In the first and third cases, it's a simple case of the compiler
not finding the name at all. In the second, the B:: tells the
compiler to look in B, but the compiler doesn't have (or doesn't
know that it has) a base of type B, so it doesn't have an object
to associate with the x it finds in B.

// Does compile
this->B::x = 0;
this->x = 0;
D<t>::x = 0;
TB<t>::x = 0;
this->y = 0;
TB<t>::y = 0;

All of these introduce a dependent context, so name look-up is
defered until instantiation.

}};

int main() {}

Try adding some instantiations:

template<> class TB<0> {} ;

int main()
{
TD< 0 > doh ;
}

That should cause a lot of errors. And also show why the
compiler can't look at the base class in non-dependent name
lookup.

Functions are even more fun, since whether a function is
dependent or not depends on its arguments. So we get things
like:

class A {} ;
void f( int ) ;
void f( A ) ;

template< typename T >
class TBase
{
public:
void f( int ) ;
void f( T ) ;
} ;

template< typename T >
class TDerived : public TBase
{
public:
void g()
{
this->f( 43 ) ; // calls TBase<>::f( int )
// (if there is one)
f( 43 ) ; // calls ::f(int)
this->f( A() ) ; // calls TBase<>::f( A )
// (if there is one)
f( A() ) ; // calls ::f(A), even if
// instantiated for A.
f( T() ) ; // calls TBase<>::f( T ), even
// if instantiated for A.
}
} ;

Note that if you instantiate TDerived<A>, then the last two
function calls in TDerived<>::g() are exactly the same, same
name, same arguments. Except that one calls the global function
(because it doesn't depend on T), and the other calls the
function in the base class (because it does depend on T, so it's
name lookup includes the base class).

Now throw in a few overloads and conversions, and let operator
overload resolution work with different sets of functions, and
create some real confusion. (If any of a function's arguments
are dependent, the function name is looked up in a dependent
fashion.)