Bug 32762 - Lost variable scope with template class that inherits from templated class using args of the first class
Summary: Lost variable scope with template class that inherits from templated class us...
Status: RESOLVED INVALID
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 4.1.2
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-07-14 02:24 UTC by Javier Mena
Modified: 2007-07-14 05:19 UTC (History)
2 users (show)

See Also:
Host: i486-linux-gnu
Target: i486-linux-gnu
Build: i486-linux-gnu
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Javier Mena 2007-07-14 02:24:58 UTC
I'm using gcc versión 4.1.2 (Ubuntu 4.1.2-0ubuntu4). I'm trying to compile this relatively simple code, but it doesn't compiles. The compiler says (i translated some phrases from spanish to english):

javimena@javimena-desktop:~/cppexamples$ g++ Example1.cc
Example1.cc: In constructor ‘XRIVarArray<Float>::XRIVarArray(int)’:
Example1.cc:37: error: ‘x’ was not declared in this scope


The only file is Example1.cc:
--------------------------------------------------------
// line: 1
#include <cstdio>


template<class Float>
class XRIVar {
public:
  Float min;
  Float max;
};


template<class Var>
class VarArray {
protected:
  Var* x;
public:
  VarArray() {
    x = 0L;
  }
  VarArray(int n) {
    x = new Var[n];
  }
  
  Var& operator [](int n) {
    return x[n];
  }
};


template<class Float>
class XRIVarArray : public VarArray< XRIVar<Float> > {
public:
  XRIVarArray(int n)
    : VarArray< XRIVar<Float> >(n){
    for (int i=0; i < n; i++) {
      x[i].min = 2;       // line: 37
      x[i].max = 10;
    }
  }
};


int main() {
  using namespace std;

  XRIVarArray<double> xva(5);
  printf( "%g\n", xva[1].max);


  return 0;
}

--------------------------------------------------------

If I inherit from a class without template arguments, the there is no problem. The workaround for now is to replace x[i] with this->x[i].

But I think this is still a bug.
Comment 1 Andrew Pinski 2007-07-14 05:19:46 UTC
> The workaround for now is to replace x[i] with this->x[i].
This is not just a workaround but the correct fix.  the reason is because x is not dependent so it has to be looked up at definition time and not instantation time (and definition time does not take into account depdent inherited classes).  See http://gcc.gnu.org/gcc-3.4/changes.html for more info.