This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: C++ parser issue [templ.res]
- From: Jan Van Dijk <janvandijkinjapan at yahoo dot co dot jp>
- To: Gabriel Dos Reis <gdr at integrable-solutions dot net>,Mark Mitchell <mark at codesourcery dot com>
- Cc: "gcc at gnu dot org" <gcc at gnu dot org>
- Date: Wed, 29 Jan 2003 21:35:42 +0000
- Subject: Re: C++ parser issue [templ.res]
- Organization: TU/Eindhoven
- References: <61030000.1043774708@warlock.codesourcery.com> <m3u1ft9j55.fsf@uniton.integrable-solutions.net>
- Reply-to: jan at etpmod dot phys dot tue dot nl
On Tuesday 28 January 2003 19:19, Gabriel Dos Reis wrote:
> Mark Mitchell <mark@codesourcery.com> writes:
> | --On Tuesday, January 28, 2003 05:03:00 PM +0000 Jan Van Dijk
> |
> | <janvandijkinjapan@yahoo.co.jp> wrote:
> | > void good(){ f(); } // no B<T>:: required
> |
> | I *think* this is a parser bug; i.e., this should be an error.
> |
> | The question is whether any of the arguments to the function is
> | dependent. Since we are in a non-static member function, a key
> | question is whether the "this" parameter should be included, but
> | I think not.
>
> "f()" in the above expression is neither a type-dependent expression
> nor a value-dependent expression 14.6.2/1:
>
> [...] Expressions may be type-dependent (on the type of a tem-plate
> parameter) or value-dependent (on the value of a non-type template
> parameter). In an expression of the form:
>
> postfix-expression ( expression-list opt )
>
> where the postfix-expression is an identifier, the identifier
> denotes a dependent name if and only if any of the expressions in
> the expression-list is a type-dependent expression (14.6.2.2).
>
> therefore 14.6.3/1 applies.
OK, I did some more homework. A few possible issues (and an ICE) remain.
Consider:
template <class T> struct B { int i; };
template <class T> struct D : public B<T>
{
// D<T> and B<T> are dependent: OK
void i1() { D<T>::i=0; }
void i2() { B<T>::i=0; }
// 14.6.2.2/2: `this' is inside i3(), enclosing class dependent.
// Hence this is dependent. It is part of the expression: OK.
void i3() { this->i=0; }
// this should not compile, and doesn't: OK
void i4() { i=0; }
// 3.4.1/2 does not work here: this does not compile. Why?
using B<T>::i;
void i5() { i=0; }
// and this causes an ICE:
void i6() { using B<T>::i; i=0; }
};
OK, so gcc (HEAD,yesterday) now correctly compiles i1(), i2() and i3(), and
correctly refuses i4(). But is it correct that i5() does not compile? I would
think that 3.4.1/2 (using directive) would work as usual. It would bring i in
scope, and from the using statement (using B<T>::i) it is obvious that i is a
dependent name. Hence i5() seems correct, apart from the semantics it would
be no different from i2(). The same goes for i6(), but that even causes an
ICE:
t.cpp:17: internal compiler error: in validate_nonmember_using_decl, at
cp/decl2.c:4152
which is obviously not good behaviour.
As a side note: it is frustrating that the intuitive form (plain `i=0;' in the
derived class) does not work, while the seamingly equivalent `this->i' is OK.
More precisely, it is counter-intuitive that the interpretation of the name
(i) is _delayed_ by adding _more_ information about the namespace where it
can be found. I'm sure this has been anticipated by the standard committee,
and assume there is a good reason for this behaviour.
A pointer to additional reading would be appreciated, though. (Otherwise I'll
wait for the next edition of the D&E of C++). I guess a lot of people who use
templated class hierarchies are going to be unpleasantly surprised by the
superb quality of gcc-3.4. A note or such a pointer in gcc/cp/NEWS could
perhaps help?
With kind regards, Jan van Dijk.
--
Keio-Tsuushin Residence
Jan van Dijk, Room 210
2 Chome 19-30, Mita Minato-ku
108 Tokyo, Japan
jan@etpmod.phys.tue.nl
tel: +81 3 5476 9461 (home)
__________________________________________________
Do You Yahoo!?
Yahoo! BB is Broadband by Yahoo! http://bb.yahoo.co.jp/