Re: c++/9937: Failure to lookup base class name when base is template specialization

[Wolfgang Bangerth <bangerth@ticam.utexas.edu>]

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

From: Wolfgang Bangerth <bangerth@ticam.utexas.edu>
To: gcc-gnats@gcc.gnu.org
Cc:  
Subject: Re: c++/9937: Failure to lookup base class name when base is template
 specialization
Date: Wed, 5 Mar 2003 09:21:09 -0600 (CST)

 ---------- Forwarded message ----------
 Date: Wed, 05 Mar 2003 12:19:27 +0100
 From: Thomas Witt <witt@ive.uni-hannover.de>
 To: Wolfgang Bangerth <bangerth@ticam.utexas.edu>
 Subject: Re: c++/9937: Failure to lookup base class name when base is
     template specialization
 
 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
 
 Wolfgang,
 
 Wolfgang Bangerth wrote:
 |>|>14.6/2a [...snip...]
 |>
 |>Aargh it's 14.6.1/2a. Sorry for that.
 |
 | Hm, I still don't get it. 14.6 is about name resolution, and while it
 | mentions that the name of class itself (without template arguments) is
 | injected, it doesn't say anything about the name of base classes. maybe
 | it's still that my copy is outdated. The DR you cite explains the matter.
 
 As I said earlier it's from a Technical Corrigendum 1 draft. I shouldn't
 have quoted from that document without explicitly saying so.
 
 For details on the TC1 status and procedure you may want to read this.
 
 http://www.cuj.com/experts/2102/sutter.htm
 
 |
 | OK, I'll note in the synopsis that it's about a DR. The DR is not in
 | resolved state, so I guess people will want to wait with implementing
 | until this is settled.
 
 The DR is marked as being part of TC1.
 
 | Should we put this into "suspended" state?
 
 Given the fact that the published std documents will make this a bug any
 time soon, I don't think so.
 
 |>Sadly, they are not. This kind of problems tend to prop up when you are
 |>dealing with any kind of code generator. Code generators rely heavily on
 |>uniform handling of ordinary types and template specialisations.
 |
 | But they are not in a lot of ways. Think about name lookup for members of
 | base classes, etc...
 
 That's a different issues. The problem we are dealing with is not about
 templates. It's about template specializations (read a template
 instantiated for one specific set of template arguments). These should
 and do behave in the same way as ordinary UDTs.
 
 What causes the problem is that derivation from A is handled differently
 than derivation from B<int>. From the generators point of view it should
 be transparent whether the base is a template specialization or not.
 
 Thomas
 
 - --
 Dipl.-Ing. Thomas Witt
 Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet
 Hannover
 voice: +49(0) 511 762 - 4273, fax: +49(0) 511 762-3001
 http://www.ive.uni-hannover.de
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.2.1 (MingW32)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
 
 iD8DBQE+Zd0/0ds/gS3XsBoRAnPwAJ96T+isLguJ+BACS1oDk3w4ZvStyQCfbX3o
 rRz27E7lmc+5Ipc0XEE2aT8=
 =XIOO
 -----END PGP SIGNATURE-----