gcc: Template class child can't directly access parent fields

OK this has to be a bug in gcc 4.3. At the very least the error reporting should be considered a bug since it starts spewing unreadable characters.

Normally a child class can access the fields of a parent class as though they were her own. Not so in gcc 4.3 if the class is templated. You need to use the this pointer indirection to get at them.

Code:

#include <iostream>

template<int i>
class A
{
	public:
	int f ; // a field
} ;


template<int i>
class B : public A<i>
{
	public:
	B()
	{
		f = 2 ;
	}
} ;


int main(int argc, char *argv[])
{
B<0>  bc ;
std::cout << bc.f << std::endl ;

}

This compiles and runs fine in MS Vis. studio. On linux, for gcc 4.3.0, it gives this 'informative' error

child.cpp: In constructor â:
child.cpp:15: error: â was not declared in this scope

In the constructor if you replace f by this->f it will compile.

This is due to two-phase name lookup. The gcc compiler is correct, and MSVC is wrong to compile it. As far as the weird characters in the error message, I have no idea.

Originally Posted by brewbuck

This is due to two-phase name lookup. The gcc compiler is correct, and MSVC is wrong to compile it. As far as the weird characters in the error message, I have no idea.

I've read a similar phrase somewhere else. Care to elaborate? Is this something the standard specifies with regards to how things are compiled?

Originally Posted by SevenThunders

I've read a similar phrase somewhere else. Care to elaborate? Is this something the standard specifies with regards to how things are compiled?

The compiler should not assume that f is a member of the parent class. There is no way of knowing whether, at the time of instantiation of B<>, whether there has been a specialization of A<> which does not include this member.

If the compiler blindly allowed it, you might have a situation where the reference to f is referring to a parent member in one case, and some completely different object (for instance a global variable) in some other case. It's safer to force you to be explicit about it.

OK I'll answer my own question with this link, which even explains two-phase name lookup.
http://womble.decadentplace.org.uk/c...ml#base-lookup

Seems a bit complex. How is it a great idea like templates, becomes filled with unnecessary complexity and hazards when implemented in C++?

Originally Posted by brewbuck

The compiler should not assume that f is a member of the parent class. There is no way of knowing whether, at the time of instantiation of B<>, whether there has been a specialization of A<> which does not include this member.

If the compiler blindly allowed it, you might have a situation where the reference to f is referring to a parent member in one case, and some completely different object (for instance a global variable) in some other case. It's safer to force you to be explicit about it.

Why not simply check the available possible resolutions for f, and only report the error if such an ambiguity arises? That would be a more liberal compiler protocol and give us perfectly reasonable results.

A programmer doesn't want to have to keep track of all possible compiler semantics. ie I have to remember half way in the middle of a huge template, that I'm accessing a parent field instead of a child field. Isn't that the reason why we have such wonderful things as function overloading and templates to begin with?

Oh well, just another glitch in my love hate relationship with C++.

Originally Posted by SevenThunders

Why not simply check the available possible resolutions for f, and only report the error if such an ambiguity arises? That would be a more liberal compiler protocol and give us perfectly reasonable results.

Do you really want your code to suddenly become wrong just because somebody declares a global variable named 'f'?

To me, going from "compiles" to "doesn't compile" based on whether I declare a variable doesn't make much sense.

Originally Posted by brewbuck

Do you really want your code to suddenly become wrong just because somebody declares a global variable named 'f'?

To me, going from "compiles" to "doesn't compile" based on whether I declare a variable doesn't make much sense.

I cant seem to get that to happen via MS VC which does compile with references to the parent class variables.

Maybe I did something wrong.

Code:

#include <iostream>


template<int i>
class A
{
	public:
		int f ;
		void print()
		{
			std::cout << f << std::endl ;
		}
} ;


template<int i>
class B : public A<i>
{
	public:
		B()
		{
//			f = i ;
		}
} ;



int f = 2 ;

int main(int argc, char *argv[])
{

	B<7> aa ;
	aa.print() ;
}

You have no specialization of A<> which does not contain f. And given MSVC's proven inability to handle this construct properly, I'm not sure it's a good test bed.

In this case it would switch to using the global f (or it that is removed, error out when instantiating a B, whose A doesn't have the f member).

Code:

#include <iostream>

template<int i>
class A
{
	public:
		int f ;
		void print()
		{
			std::cout << f << std::endl ;
		}
} ;

template<int i>
class B : public A<i>
{
	public:
		B()
		{
			f = i ;
		}
} ;

template <>
class A<8>
{
    public:
    void print()
    {
        std::cout << "no f" << std::endl;
    }
};

int f = 2 ;

int main()
{

	B<8> aa ;
	aa.print() ;
	std::cout << "global f " << f << '\n';
}

GCC would always go for the global f (if it is declared before the classes) and won't change the meaning of code based on which specializations are available (f refers to one thing or nothing at all).

Has it been mentioned that the simple workaround to accessing members of the template parent is to use the this pointer:

Code:

B()
{
     this->f = i ;
}

Even MSVC can't argue with this and just plug in any f it happens to find.

Templates also, unfortunately, add a lot of complexity into the language. Asking compiler vendors to be able to handle all of this stuff without programmer interaction is just not plausible.
It's hard enough already to write a C++ compiler, and the standard has to make sure it isn't impossible.

The problem with VC++ implementation is that it is possible to have the meaning of a piece of code completely changed from the outside. Here the same piece of code can be made to use a global variable without modifying itself (class B). It is probably related to how it doesn't require the typename keyword in case of dependent types. Again it is possible that an identifier within the same piece of code can be both a type or a variable name, depending on the context outside that code. (While the programmer has to type less, having a compiler guess what might be meant doesn't seem in the spirit of C++.)