public inbox for gcc-prs@sourceware.org help / color / mirror / Atom feed
From: Nathan Sidwell <nathan@codesourcery.com> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, Subject: Re: c++/9476: lookup of member in base class template fails Date: Tue, 28 Jan 2003 15:56:00 -0000 [thread overview] Message-ID: <20030128155600.6892.qmail@sources.redhat.com> (raw) 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
next reply other threads:[~2003-01-28 15:56 UTC|newest] Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top 2003-01-28 15:56 Nathan Sidwell [this message] -- strict thread matches above, loose matches on Subject: below -- 2003-01-28 15:26 Jan Van Dijk 2003-01-28 13:14 nathan 2003-01-28 13:06 jan
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20030128155600.6892.qmail@sources.redhat.com \ --to=nathan@codesourcery.com \ --cc=gcc-prs@gcc.gnu.org \ --cc=nobody@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).