This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: C++ parser issue [templ.res]

On Tuesday 28 January 2003 19:19, Gabriel Dos Reis wrote:
> Mark Mitchell <> writes:
> | --On Tuesday, January 28, 2003 05:03:00 PM +0000 Jan Van Dijk
> |
> | <> 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 (
> therefore 14.6.3/1 applies.

OK, I did some more homework. A few possible issues (and an ICE) remain. 

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; }
        // `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 

t.cpp:17: internal compiler error: in validate_nonmember_using_decl, at

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
tel: +81 3 5476 9461 (home)

Do You Yahoo!?
Yahoo! BB is Broadband by Yahoo!

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]