GCC 3.4.0 and template type resolution bug (OT)

[Michael Veksler]

This is off topic for gcc@gcc.gnu.org....
You should take it to comp.lang.c++.moderated or some such.

René Rebe wrote:
>   Michael Veksler  wrote:
> > 
> > You should use this->m_info, otherwise the compiler will look for 
m_info 
> > outside your classes,
> 
> I find this behavior a bit counter-intuitive. In which section is it
> enforced by the ANSI standard?

I don't have the time to re-read that section in the standard.


This behavior makes a lot of sense. Consider the following:

  int count;

  template <class T> struct A {
     int count;
  };

  template <class T>  struct B : public A<T> {
     int Get() { return count; }
  };

  // First specialization.
  template <> struct A<int> {};

Now, what do you think should happen in B<int>::Get() ?
Obviously,  A<int>::count does not exist, so 
it is either an error, or A<int>::Get() should 
read ::count.

Now, consider an extension to the example:
  // A second specialization
  template <>  struct B<int> : public A<int> {
     int Get() { return count; }
  };

It looks quite redundant - it looks exactly the same
as the non-specialized case. The only difference is
that here, it is not obvious why it should be rejected.
B<int> can simply use ::count. To be consistent,
the non-specialized B<int> should also access ::count.

Conclusion:

  The only consistent way to handle B<T>
  it is to access ::count from any B<T>.


Now, for gcc-3.2 and many other "old days" compilers
will do something inconsistent:

  If global count is accessible B<double>::Get() will
  access the global variable. If count is inaccessible,
  B<dobule>::Get() will access A<double>::count.

This means that even with gcc-3.2 you should use
this->count to access the base class. Otherwise your
private count is practically exposed to spoofing
(mostly accidental).