From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6462 invoked by alias); 12 Nov 2003 14:29:22 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 6450 invoked by alias); 12 Nov 2003 14:29:21 -0000 Date: Wed, 12 Nov 2003 14:29:00 -0000 Message-ID: <20031112142921.6447.qmail@sources.redhat.com> From: "gdr at integrable-solutions dot net" To: gcc-bugs@gcc.gnu.org In-Reply-To: <20031011162654.12581.pinskia@gcc.gnu.org> References: <20031011162654.12581.pinskia@gcc.gnu.org> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug c++/12581] [3.4 Regression] gcc rejects typeof use for the return type X-Bugzilla-Reason: CC X-SW-Source: 2003-11/txt/msg01007.txt.bz2 List-Id: ------- Additional Comments From gdr at integrable-solutions dot net 2003-11-12 14:29 ------- Subject: Re: [3.4 Regression] gcc rejects typeof use for the return type "gabor dot greif at lucent dot com" writes: | ------- Additional Comments From gabor dot greif at lucent dot com 2003-11-12 14:03 ------- | (In reply to comment #6) | > ... | > | > | I ask myself why a typeof construct cannot be an unqualified-id? | > | > Meaning? | > | > -- Gaby | > | | Hmmm, I assume you do not understand what I am meaning. (Your question is a bit | overloaded :-) Thnks for successfully resolving the call :-) | Here is what I think. Let's modify my the simplified example: | | | | struct bar | { | void setfoobar(int); | int getfoobar(void) const; | static int (bar::* const getter1)(void) const; | }; | | template | T* JustAPointer(void); | | typedef __typeof__(JustAPointer()->getfoobar()) GETTER_RESULT; | | GETTER_RESULT (bar::* const bar::getter1)(void) | const = &bar::getfoobar; | -------------------------------------------------------------------- | | I strongly assume this is legal _and_ compiles. Given that this is a GNU extension, it is valid construct only if the doc says so :-) But I can see your point. As an aside, the next version of C++ will have something like typeof called "decltype", which is a "reference preserving typeof". The current draft stabdardese says that decltype() is a simple-type-specifier -- which is not the same as an unqualified-id. | GETTER_RESULT is a typedef-name, right? | The new C++ parser only accepts an unqualified-id in that | position, so typedef-name implies unqualified-id. | | Now, by statement of Mark (comment #3), a typeof construct can be used | everywhere a typedef-name can occur. So typeof-construct implies typedef-name | (basically), and by transitiveness: typeof-construct implies unqualified-id. I can't follow. Mark was saying that in standardese, it would be a simple-type-specifier (and I agree with him), and a simple-type-specifier does not imply an unqualified name. | Maybe I am a bit dense today, but I still cannot see what is illegal in the | example in comment #1. I can see an implementation problem but I can't see a problem from user point-of-view. And with compatibility with decltype, I would accept the code, but I'm not going to fix it now so I can't revert Mark's decision. I can just suggest a feature-request. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12581