Thread: Can someone help with my seg fault?

Originally Posted by laserlight

Actually, I think it came up recently here (or maybe Codeguru, I get mixed up sometimes, especially with George2 around).

It happens when you try to access an inherited, non-dependent name in a derived class. Here we go:

Code:

#include <iostream>

template <typename T>
struct A
{
   void hello()
   {
      std::cout << "A::hello()" << std::endl;
   }
};

template <typename T>
struct B : public A<T>
{
   B()
   {
      this->hello();
   }
};

You might think the part highlighted in red can be removed. It can't be.

Originally Posted by laserlight

In this case it can be removed and be replaced with B<T>:: since hello() is non-virtual.

True. I should have worded differently. There are several ways to make the call, but none of them are just "hello()."

Originally Posted by laserlight

In this case it can be removed and be replaced with B<T>:: since hello() is non-virtual.

By the way, the reason this occurs is that all names must unambiguously resolvable at the point of template declaration. That doesn't mean that all type information must be present, but you have to help the compiler a little bit.

For one thing, there could possibly be a specialization of A which does not declare the hello() member function. In that case, B's lookup of the symbol "hello" would be unresolved at declaration time because it could possibly be referring to a global, non-templated function. But the compiler has no way of knowing that, because the declaration of the global hello() need not exist in the current translation unit. You have to clarify by specifying "this->" in order to say, "I really do intend for this name to refer to a member."

You're right that you could have used A<T>:: or B<T>:: instead, but the pointer syntax guarantees that the lookup will be virtual if necessary.

EDIT: My example was poor, because if hello() had been virtual, it would not have been valid to call it inside B's constructor.

Originally Posted by Elysia

And just why is it ignorant? I can use it everywhere I want to help IntelliSense out a bit to bring up members of the class itself.

Changing the way you write code just to take advantage of a feature of a particular IDE is silly.

There is absolutely nothing wrong with this-> unless there is really, really good reason that.
Otherwise, all I can see is that it's a taste thing. You may not like it, but that doesn't mean it's bad.

And what if you change a member function to make it static? Now the this-> syntax is invalid and you get to go through all your code to change it.

Not having to write this-> everywhere is one of the biggest advantages of OO.