public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* Re: c++/9937: Failure to lookup base class name when base is template specialization
@ 2003-03-05 15:26 Wolfgang Bangerth
  0 siblings, 0 replies; 5+ messages in thread
From: Wolfgang Bangerth @ 2003-03-05 15:26 UTC (permalink / raw)
  To: nobody; +Cc: gcc-prs

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-----
 


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: c++/9937: Failure to lookup base class name when base is template specialization
@ 2003-03-04 16:26 Wolfgang Bangerth
  0 siblings, 0 replies; 5+ messages in thread
From: Wolfgang Bangerth @ 2003-03-04 16:26 UTC (permalink / raw)
  To: nobody; +Cc: gcc-prs

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

From: Wolfgang Bangerth <bangerth@ticam.utexas.edu>
To: Thomas Witt <witt@ive.uni-hannover.de>
Cc: gcc-bugs@gcc.gnu.org, <gcc-gnats@gcc.gnu.org>
Subject: Re: c++/9937: Failure to lookup base class name when base is template
 specialization
Date: Tue, 4 Mar 2003 10:22:38 -0600 (CST)

 > |     Something seems indeed inconsistent. Your access in struct Z
 > |     is bogus, but this is an extract:
 > 
 > I don't think so.
 > 
 > ~From ISO/IEC 14882
 > 
 > 14.6/2a [...snip...]
 
 Hmph, that's a section that's not in the draft that I use (I don't have a 
 copy of the final standard, unfortunately).
 
 Given what you cite, that would be another but in gcc. At least, this 
 doesn't compile with gcc, but does with icc:
 ----------------------
 template <typename> struct B {};
 struct Z : B<int> { Z::B *b; };
 ----------------------
 
 I must admit that I don't really understand the intention of the standard 
 authors, why this should find B<int>. I also don't understand why the 
 above should compile, but this variant of struct Z shouldn't (and doesn't 
 with either gcc and icc):
 ----------------------
 template <typename> struct B {};
 struct Z : B<int> { B *b; };   // use B, not Z::B
 ----------------------
 
 In any case, all the problems in this report are easily worked around, so 
 while this seems like a bug I wouldn't want to have it high priority.
 
 W.
 
 -------------------------------------------------------------------------
 Wolfgang Bangerth             email:            bangerth@ticam.utexas.edu
                               www: http://www.ticam.utexas.edu/~bangerth/
 
 


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: c++/9937: Failure to lookup base class name when base is template specialization
@ 2003-03-04 16:16 Thomas Witt
  0 siblings, 0 replies; 5+ messages in thread
From: Thomas Witt @ 2003-03-04 16:16 UTC (permalink / raw)
  To: nobody; +Cc: gcc-prs

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

From: Thomas Witt <witt@ive.uni-hannover.de>
To: bangerth@dealii.org, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org,
   nobody@gcc.gnu.org, witt@ive.uni-hannover.de, gcc-gnats@gcc.gnu.org
Cc:  
Subject: Re: c++/9937: Failure to lookup base class name when base is template
 specialization
Date: Tue, 04 Mar 2003 17:10:16 +0100

 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
 bangerth@dealii.org wrote:
 | Synopsis: Failure to lookup base class name when base is template
 specialization
 |
 | State-Changed-From-To: open->analyzed
 | State-Changed-By: bangerth
 | State-Changed-When: Tue Mar  4 15:45:30 2003
 | State-Changed-Why:
 |     This applies to all versions of gcc since at least 2.95:
 |
 |     Something seems indeed inconsistent. Your access in struct Z
 |     is bogus, but this is an extract:
 
 I don't think so.
 
 ~From ISO/IEC 14882
 
 14.6/2a
 
 "The injected-class-name of a class template or class template
 specialization can be used either with or without
 a template-argument-list wherever it is in scope. [Example:
 
 template <class T> struct Base {
 ~  Base* p;
 };
 
 template <class T> struct Derived: public Base<T> {
 ~  typename Derived::Base* p; // meaning Derived::Base<T>
 };
 \x14 end example ]"
 
 So if B<int> is in scope B is as well.
 
 |     I must admit that I don't know whether gcc is right or
 |     wrong here -- the treatment of NS::A and NS::B seems
 |     inconsistent --, but icc at least shares gcc's opinion:
 |     g/x> icc -c x.cc
 |     x.cc(9): error: B is not a template
 |       struct Y : NS::B<int> {  B<int>* b; };
 |                                ^
 
 Yep, I know this. And the Intel frontend developers are busy figuring
 whether they are wrong.
 
 FWIW intel win32 accepts the code. So does como on linux.
 
 Thanks
 
 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+ZM/o0ds/gS3XsBoRAjYHAKCMrNAZkohsxZ0Gq4J1H3jQwwV28ACffmpE
 YbmrZX/Usvn6w0Cm/hgS31g=
 =83X2
 -----END PGP SIGNATURE-----
 


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: c++/9937: Failure to lookup base class name when base is template specialization
@ 2003-03-04 15:45 bangerth
  0 siblings, 0 replies; 5+ messages in thread
From: bangerth @ 2003-03-04 15:45 UTC (permalink / raw)
  To: gcc-bugs, gcc-prs, nobody, witt

Synopsis: Failure to lookup base class name when base is template specialization

State-Changed-From-To: open->analyzed
State-Changed-By: bangerth
State-Changed-When: Tue Mar  4 15:45:30 2003
State-Changed-Why:
    This applies to all versions of gcc since at least 2.95:
    
    Something seems indeed inconsistent. Your access in struct Z
    is bogus, but this is an extract:
    ------------------------
    namespace NS {
      struct A {};
    
      template <class T>
      struct B {};
    }
    
    struct X : NS::A      {  A* a;      };
    struct Y : NS::B<int> {  B<int>* b; };
    --------------------
    While struct X seems to be ok, struct Y seems not:
    g/x> /home/bangerth/bin/gcc-3.4-pre/bin/gcc -c x.cc
    x.cc:9: error: ISO C++ forbids declaration of `B' with no type
    x.cc:9: error: expected function-definition
    
    I must admit that I don't know whether gcc is right or
    wrong here -- the treatment of NS::A and NS::B seems
    inconsistent --, but icc at least shares gcc's opinion:
    g/x> icc -c x.cc
    x.cc(9): error: B is not a template
      struct Y : NS::B<int> {  B<int>* b; };
                               ^
    
    I leave this to more experienced language lawyers.
    
    W.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=9937


^ permalink raw reply	[flat|nested] 5+ messages in thread

* c++/9937: Failure to lookup base class name when base is template specialization
@ 2003-03-04 12:26 witt
  0 siblings, 0 replies; 5+ messages in thread
From: witt @ 2003-03-04 12:26 UTC (permalink / raw)
  To: gcc-gnats


>Number:         9937
>Category:       c++
>Synopsis:       Failure to lookup base class name when base is template specialization
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          rejects-legal
>Submitter-Id:   net
>Arrival-Date:   Tue Mar 04 12:26:01 UTC 2003
>Closed-Date:
>Last-Modified:
>Originator:     Thomas Witt
>Release:        3.2.2
>Organization:
>Environment:
Linux 2.4.18 ix86 glibc 2.2.5
Suse 8.0
Reading specs from /opt/gcc-3.2.2/lib/gcc-lib/i686-pc-linux-gnu/3.2.2/specs
Configured with: ../gcc-3.2.2/configure --enable-threads=posix --enable-long-long --prefix=/opt/gcc-3.2.2 --disable-nls --enable-shared --enable-languages=c,c++ --enable-__cxa_atexit
Thread model: posix
gcc version 3.2.2
>Description:
$ gcc --save-temps namespace.cpp
namespace.cpp:23: error: syntax error before `*' token
namespace.cpp:28: error: syntax error before `*' token

B* and B<int>* aren't found. They should be found in the same way as
A is found in gunc::X definition.

IIUC the following paragraphs from the std apply.

9/2
3.4/3
10.2/2
14.2/6
14.6.1/2a

They basically say that the name of a base class is in the scope of the derived class. I.e. you can
refer to it using an unqualified-id no matter in what namespace the base class name is declared.

I can provide full-text citations if needed.
>How-To-Repeat:
# 1 "namespace.cpp"
# 1 "<built-in>"
# 1 "<command line>"
# 1 "namespace.cpp"

namespace hunc
{
  struct A {};

  template <class T>
  struct B
  {
  };
}

namespace gunc
{
  typedef hunc::B<int> Ybase;

  struct X : hunc::A
  {
    A* a;
  };

  struct Y : hunc::B<int>
  {
   B<int>* b;
  };

  struct Z : hunc::B<int>
  {
    B* c;
  };
}

int main()
{
}
>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted:


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2003-03-05 15:26 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-03-05 15:26 c++/9937: Failure to lookup base class name when base is template specialization Wolfgang Bangerth
  -- strict thread matches above, loose matches on Subject: below --
2003-03-04 16:26 Wolfgang Bangerth
2003-03-04 16:16 Thomas Witt
2003-03-04 15:45 bangerth
2003-03-04 12:26 witt

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).