From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11166 invoked by alias); 19 Sep 2003 18:46:43 -0000 Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org Received: (qmail 11159 invoked from network); 19 Sep 2003 18:46:42 -0000 Received: from unknown (HELO mail-srv2.micron.com) (137.201.242.130) by sources.redhat.com with SMTP; 19 Sep 2003 18:46:42 -0000 Received: from mail-srv2.micron.com (localhost [127.0.0.1]) by mail-srv2.micron.com (8.12.9/8.12.2) with ESMTP id h8JIkiRQ016522 for ; Fri, 19 Sep 2003 12:46:44 -0600 (MDT) Received: from ntxboimbx07.micron.com (ntxboimbx07.micron.com [137.201.80.94]) by mail-srv2.micron.com (8.12.9/8.12.2) with ESMTP id h8JIkha3016517 for ; Fri, 19 Sep 2003 12:46:43 -0600 (MDT) From: lrtaylor@micron.com X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: pure virtual w/implementation bug in GCC 3.3? Date: Fri, 19 Sep 2003 18:46:00 -0000 Message-ID: <363801FFD7B74240A329CEC3F7FE4CC40D336B@ntxboimbx07.micron.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: To: X-Scanned-By: MIMEDefang 2.33 (www . roaringpenguin . com / mimedefang) X-SW-Source: 2003-09/txt/msg00231.txt.bz2 I was under the impression that virtual functions could not be inlined (see= ms I read that somewhere), because, especially in the case of polymorphism,= which function to call cannot be determined at compile time. I can see ca= ses where the compiler _would_ know that it could be inlined, though. It j= ust seemed that that was a matter of policy in the standard. Is my impress= ion incorrect? Thanks, Lyle Taylor -----Original Message----- From: Eljay Love-Jensen [mailto:eljay@adobe.com] Sent: Friday, September 19, 2003 11:33 AM To: m.; gcc-help@gcc.gnu.org Subject: Re: pure virtual w/implementation bug in GCC 3.3? Hi m, Thank you for the clarification. :-) 10.4 paragraph 2 clearly shows that the construct is illegal. I'll use the sanctioned form: class Foo { public: virtual ~Foo() =3D 0; }; inline Foo::~Foo() { } Sincerely, --Eljay