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