Re: c++/9476: lookup of member in base class template fails

[Nathan Sidwell <nathan at codesourcery dot com>]

The following reply was made to PR c++/9476; it has been noted by GNATS.

From: Nathan Sidwell <nathan@codesourcery.com>
To: jan@etpmod.phys.tue.nl
Cc: gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org, nobody@gcc.gnu.org,
   gcc-prs@gcc.gnu.org
Subject: Re: c++/9476: lookup of member in base class template  fails
Date: Tue, 28 Jan 2003 15:51:52 +0000

 Jan Van Dijk wrote:
 > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=9476
 > 
 > You (Nathan) said that `the usual' lookup rules apply here. In these words I 
 > read that within D<X> the data member i could be found in the base class 
 > B<X>, according to 3.4.1/7.
 Nope. you do not look in dependent bases.
 
 
 > In fact, I believed that the requirement that `specializations of templates 
 > are known before first use of the template' was exactly to make code like 
 > this have a clear meaning, independent of the presence of specialisations of 
 > the base class. (Otherwise, a specialisation B<double> could re-define the 
 > type of i.)
 A specialization could indeed do that. That's why dependent bases are ignored
 in parse lookup. The specialization rule is so the compiler knows not to
 implicitly instantiate B<double>, where the definition of such a class would
 be needed.
 
 > In your mail you also say that `the koenig lookup should be resolved at parse 
 > time. (see example in 14.6/9)'.
 yup, and it would fail, giving an error. g++ is incorrectly waiting until
 instantaition time.
 
  > Well, in the code in my report a definition
 > of `int i' is present in the base class which is seen at parse time, so what 
 > is the problem? The example in 14.6.9 is different: there the line `d++' 
 > refers to a d that is not there (yet). It is declared a few lines lower.
 that first call 'f (1)' calls '::f (char)' and is resolved at parse time.
 Note that the later declaration of '::f (int)' is not considered. The second
 call of 'f (T (1))' is delayed until instantiation time, and resolves to ':: f (int)'
 
 > As a sidenote: earlier today a similar report has been posted (9447). It may 
 > be taken into acount in this discusssion. In the audit trail of that PR, 
 > Paolo Carlini expresses his belief that these _are_ parser bugs, BTW. Also 
 > Gabriel Dos Reis seems to be certain that the present behaviour is not 
 > correct (mailing list, today). 
 I took gaby's email to be agreeing with me (it can be read either way).
 there is a parser bug, I believe it to be that 'f ()' is not rejected
 
 Please refer to Mark Mitchell's email of a few days ago about two stage
 lookup.
 
 nathan
 -- 
 Nathan Sidwell    ::   http://www.codesourcery.com   ::     CodeSourcery LLC
           The voices in my head said this was stupid too
 nathan@codesourcery.com : http://www.cs.bris.ac.uk/~nathan/ : nathan@acm.org