GCC 3.4.0 and template type resolution bug

GCC 3.4.0 and template type resolution bug

[Rene Rebe]

Hi,

compiling one of our C++ projects I found a quite strange behaviour
(==bug?) of gcc-3.4.0. The 3.4.0 version is not able to deduce m_info
in the base template class's when the inherited class is a template,
too. Although it does work with normal classes. (Of course the code
does compile with earlier version of GCC - such as 3.2.3.)


  template <typename INFO>
  class Basic
  {
  protected:

    INFO* m_info;
  };

  template <typename INFO>
  class Std : public Basic <INFO>
  {
  public:

    bool testMe () { return m_info != 0; }
  };

  class Normal : public Basic <int>
  {
  public:
    bool testMe () { return m_info != 0; }
  };

int main () {
  return 0;
}

The error is:

gcc34-template.cc: In member function `bool Std<INFO>::testMe()':
gcc34-template.cc:15: error: `m_info' undeclared (first use this function)
gcc34-template.cc:15: error: (Each undeclared identifier is reported only once for each function it appears in.)

Sincerely yours,
  René Rebe
    - ROCK Linux stable release maintainer

--  
René Rebe - Europe/Germany/Berlin
  rene@rocklinux.org rene@rocklinux-consulting.de
http://www.rocklinux.org http://www.rocklinux-consulting.de

Re: GCC 3.4.0 and template type resolution bug (no)

[Michael Veksler]

gcc-3.4 is correct (gcc-3.2 was buggy). Please read gcc-3.4 release notes.

You should use this->m_info, otherwise the compiler will look for m_info 
outside your classes,







Rene Rebe <rene@rocklinux-consulting.de>
Sent by: gcc-owner@gcc.gnu.org
29/04/2004 09:12
 
        To:     gcc@gcc.gnu.org
        cc:     valentin@rocklinux-consulting.de
        Subject:        GCC 3.4.0 and template type resolution bug


Hi,

compiling one of our C++ projects I found a quite strange behaviour
(==bug?) of gcc-3.4.0. The 3.4.0 version is not able to deduce m_info
in the base template class's when the inherited class is a template,
too. Although it does work with normal classes. (Of course the code
does compile with earlier version of GCC - such as 3.2.3.)


  template <typename INFO>
  class Basic
  {
  protected:

    INFO* m_info;
  };

  template <typename INFO>
  class Std : public Basic <INFO>
  {
  public:

    bool testMe () { return m_info != 0; }
  };

  class Normal : public Basic <int>
  {
  public:
    bool testMe () { return m_info != 0; }
  };

int main () {
  return 0;
}

The error is:

gcc34-template.cc: In member function `bool Std<INFO>::testMe()':
gcc34-template.cc:15: error: `m_info' undeclared (first use this function)
gcc34-template.cc:15: error: (Each undeclared identifier is reported only 
once for each function it appears in.)

Sincerely yours,
  René Rebe
    - ROCK Linux stable release maintainer

-- 
René Rebe - Europe/Germany/Berlin
  rene@rocklinux.org rene@rocklinux-consulting.de
http://www.rocklinux.org http://www.rocklinux-consulting.de

Re: GCC 3.4.0 and template type resolution bug

[Vladimir Prus]

Rene Rebe wrote:

> The 3.4.0 version is not able to deduce m_info
> in the base template class's when the inherited class is a template,

>   template <typename INFO>
>   class Std : public Basic <INFO>
>   {
>   public:
> 
>     bool testMe () { return m_info != 0; }
>   };

I think it's called "2-phase lookup". The "m_info" name is non-dependent, so
it's looked up at the time template declaration is parsed, and names from
Basic are not used (in fact, you can later declare 10 specialization of
Basic, all with different members).

To make the example compile, just make the name dependendent by using

    bool testMe () { return this->m_info != 0; }

gcc 3.4 is the first version which implements 2-phase lookup, that's why you
did not get any problems with previous versions.

- Volodya

Re: GCC 3.4.0 and template type resolution bug (no)

[Rene Rebe]

Hi,

thanks for the quick answer. Indeed I have read the release notes -
some days ago - and must have overread some lines.

On: Thu, 29 Apr 2004 09:23:23 +0300,
    Michael Veksler <VEKSLER@il.ibm.com> wrote:
> gcc-3.4 is correct (gcc-3.2 was buggy). Please read gcc-3.4 release notes.
> 
> You should use this->m_info, otherwise the compiler will look for m_info 
> outside your classes,

I find this behaviour a bit counter-intuitive. In which section is it
enforced by the ANSI standard?

Sincerely yours,
  René Rebe
    - ROCK Linux stable release maintainer

--  
René Rebe - Europe/Germany/Berlin
  rene@rocklinux.org rene@rocklinux-consulting.de
http://www.rocklinux.org http://www.rocklinux-consulting.de

Re: 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).

Re: GCC 3.4.0 and template type resolution bug (no)

[Giovanni Bajo]

Rene Rebe wrote:

> I find this behaviour a bit counter-intuitive. In which section is it
> enforced by the ANSI standard?

[temp.dep]/3.

Giovanni Bajo