problem with templates and parent variables accessing

Hi, I don't know why my chiled class cannot access parent's variables.
I am using mingw 5.1.3 toolchain.

This works:

Code:

#include <iostream>

using namespace std;

template< class T >
class first
{
protected:
    int abc;
    T   def;
public:
    first()
    {
        abc = 3;
        def = 4;
    }
};

class second : first< int >
{
public:
    int get_abc()
    {
        return abc;
    }
    //
    int get_def()
    {
        return def;
    }
};

int main()
{
    second a;
    //
    cout << a.get_abc() << endl;
    cout << a.get_def() << endl;
    //
    return 0;
}

but if I change the child to a template class it doesn't:

Code:

#include <iostream>

using namespace std;

template< class T >
class first
{
protected:
    int abc;
    T   def;
public:
    first()
    {
        abc = 3;
        def = 4;
    }
};

template< class T >
class second : first< T >
{
public:
    T get_abc()
    {
        return abc;
    }
    //
    T get_def()
    {
        return def;
    }
};

int main()
{
    second<int> a;
    //
    cout << a.get_abc() << endl;
    cout << a.get_def() << endl;
    //
    return 0;
}

I get errors that abc and def weren't declared in this scope.

Does anyone know a way to overcome this problem( but still keep the hierarchy like ...child2: child1< template > : parent< template > and not move the variables from parent to chiled )?

Thanks.
Domen

Read Why am I getting errors when my template-derived-class uses a member it inherits from its template-base-class?

Originally Posted by laserlight

Read Why am I getting errors when my template-derived-class uses a member it inherits from its template-base-class?

Wow, that's pretty strange.
It looks to me to be either a bug in compilers that don't allow it, or in the standard if that's what it says.

That's what the standard says, and it's a concession to compiler writers, not a bug. Doing it any other way would lead to even more complex compilers, slower compilation, and perhaps even a few edge cases that are simply ambiguous.

We may call it what we will, but if the standards says it isn't allowed, then we must abide by the rules. Thankfully, there is a very solution available, by just using this->.

Thanks!

This makes the code a bit uglyer but if it's in the standard then I guess that it's so for a good reason.

Regards, Domen.

All right, I'm just kidding but:
I think "this->" was created by the guys who designed the compilers to fix errors like this one, nothing more.

But seriously:
Unless absolutely necessary, I don't use the this-> pointer. Just a point of personal preference I guess, but when I see code littered with this->, I cringe...

Originally Posted by CornedBee

That's what the standard says, and it's a concession to compiler writers, not a bug. Doing it any other way would lead to even more complex compilers, slower compilation, and perhaps even a few edge cases that are simply ambiguous.

Any idea what the specific implications were?

According to the FAQ I linked to:

Here's the rule: the compiler does not look in dependent base classes (like B<T>) when looking up nondependent names (like f).

So my guess is that the concession is to relieve the compiler of the need to search in dependent base classes when looking up non-dependent names.

Yes, but when would that be so prohibitively expensive?

Originally Posted by dudeomanodude

All right, I'm just kidding but:
I think "this->" was created by the guys who designed the compilers to fix errors like this one, nothing more.

"this->" wasn't created to solve this problem. It would have worked anyway.

"this->" wasn't created to solve this problem. It would have worked anyway.

I know, i was just kidding.

Originally Posted by robwhit

Yes, but when would that be so prohibitively expensive?

Actually, I confused this issue with a similar one. This one is about not introducing subtle bugs, not about compiler performance or complexity. Consider this apparently harmless piece of code.

Code:

void foo()
{
  // Do something.
}

template <typename T>
class bar
{
public:
  void whatever();
};

template <typename T>
class barder : public bar<T>
{
public:
  void something()
  {
    foo();
  }
};

What's the effect of this code? It calls ::foo(), of course, right? Right?


But what if someone comes along and adds a specialization to bar:

Code:

template <>
class bar<sometype>
{
public:
  void whatever();
  void foo(); // hehe
};

If dependent names are looked up for unqualified names, barder<sometype>::something() would - without doubt very surprisingly for the author - call bar<sometype>::foo() instead of ::foo().


That's the actual reason for this little quirk. The performance/complexity issue is about the typename and template keywords.

Thanks!