This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Why this change? It could break a lot of code


> 
> The below change planned for Gcc 3.4, is really necessary?  I think it would
> break a lot of code, and it goes against the usual practice in C++: (derived
> class inherits all the functionality from base, theres is an implicit this->
> resolution for accesing members, ::name is required to access identifiers
> with the same name of a class member, etc.)
That is not also true as you needed an this-> when you had a local variable
called n, this is the same as that.

> 
> Because a derived templated class is just another case of the usual
> inheritance, the behavior below is contradictory.
> 
> Why this change?, is because of the "C++ Standard"?.  Maybe in this case the
> "C++ Standard" is wrong.

Because that is the way the C++ Standard says, yes that is not really a reason 
but do you want a C++ Compiler or do you want a G++ (like VC++?).

Also the behavior you want is contradictory to what types do also, using typename 
is needed now.

> 
> 
> 
> CHANGE PROPOSED:
> 
> In a template definition, unqualified names will no longer find members of a
> dependent base. For example,
>         template <typename T>struct B {
> 	  int m;
> 	  int n;
> 	  int f ();
> 	  int g ();
> 	};
> 	int n;
> 	int g ();
> 	template <typename T> struct C : B<T> {
> 	  void g ()
> 	  {
> 	    m = 0; // error
> 	    f ();  // error
> 	    n = 0; // ::n is modified
> 	    g ();  // ::g is called
> 	  }
> 	};
> 
> 
> 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]