220 17473 <9a923017-a97e-4bed-bcf3-decabf30ecae@isocpp.org> article Path: news.gmane.org!not-for-mail From: Columbo Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: In-class definition of pure virtual functions Date: Thu, 23 Apr 2015 03:27:59 -0700 (PDT) Lines: 157 Approved: news@gmane.org Message-ID: <9a923017-a97e-4bed-bcf3-decabf30ecae@isocpp.org> References: <55377A89.7000807@gmail.com> <06dcb70f-d339-477f-9b03-38e4e57c90da@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_207_712141927.1429784879451" X-Trace: ger.gmane.org 1429784884 24930 80.91.229.3 (23 Apr 2015 10:28:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 23 Apr 2015 10:28:04 +0000 (UTC) Cc: dibeas@ieee.org To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDRN5RPSR4MRBMES4OUQKGQEVM3HCIQ@isocpp.org Thu Apr 23 12:28:03 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vn0-f70.google.com ([209.85.216.70]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YlEMV-00028S-42 for gclcip-std-proposals@m.gmane.org; Thu, 23 Apr 2015 12:28:03 +0200 Original-Received: by vnbf1 with SMTP id f1sf5498355vnb.1 for ; Thu, 23 Apr 2015 03:28:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version:content-type:x-original-sender :reply-to:precedence:mailing-list:list-id:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=SqEThxr3AMPfAxWDxd3g9+iYG1JAmMZI0rj8ZVaY8Lo=; b=iLaTqfsx/vhtmyqoP45qzYDAyUIynXQzkX7CFBR+PwmGLOgEGi/afOHfywWMjee5XU tKqhlJjE+oIl5WQAf/3N1eF8zLR+Y9Uf1wrhj2RZxHdWinnw5SgwTNQ8jkIGcVOQM0fj rFxab8MffwWhz1E+YwR3+6Bky5qrikVhmTso2k++NwIACdSmoAj2RfKulgy1SvIRXcsm J+fPN/WQit+6oUCqP7zBKLiZPjCzOqRu1CLZzC65jlObf7UNkcyeRTDOE5JhRkfJm6BN 9PbgyNMcjlQOC7aKxRsGcnQoWiUgfnbSVTdMg5JaDWM19jB7iNMHGPQ6kaK7M9/+ALOw j99g== X-Gm-Message-State: ALoCoQnDNsSp6l55Om+qwwiWbO9bMJzSZJxuKYGEFiuYBANqru4GST4PdeJCMGrdNdm82e2jfmiX X-Received: by 10.236.199.72 with SMTP id w48mr2849530yhn.58.1429784881284; Thu, 23 Apr 2015 03:28:01 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.86.72 with SMTP id o66ls1104362qgd.6.gmail; Thu, 23 Apr 2015 03:28:00 -0700 (PDT) X-Received: by 10.140.93.226 with SMTP id d89mr22278qge.38.1429784880341; Thu, 23 Apr 2015 03:28:00 -0700 (PDT) In-Reply-To: X-Original-Sender: R.HL@gmx.net Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:17473 Archived-At: ------=_Part_207_712141927.1429784879451 Content-Type: multipart/alternative; boundary="----=_Part_208_1043002358.1429784879451" ------=_Part_208_1043002358.1429784879451 Content-Type: text/plain; charset=UTF-8 Let me get this straight. The only (substantial) difference between struct A1 { virtual void f(); }; and struct A2 { virtual void f() = 0; } is that A2 is *abstract* and derived classes are forced to override and define f to be able to be a most-derived class - right? However, I can provide an in-class definition for A1::foo: struct A1 { virtual void f(){} }; 7.1.2/3 specifies that this is equivalent to struct A1 { virtual void f(); }; inline void A1::f() {} So this would cause the same problems as struct A1 { virtual void f() = 0 {}; }; However, for the sake of consistency, even though in-class definitions might not be optimal - wouldn't it still be feasible to make those available for pure virtual functions? Assuredly there is a reason that VC++ allows this? -- --- You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/. ------=_Part_208_1043002358.1429784879451 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Let me get this straight. The only (substantial) differenc= e between
struct = A1 { virtual void f(); };=
and
struct A2 { = virtual void<= span style=3D"color: #000;" class=3D"styled-by-prettify"> f() =3D 0; <= /span>}
is that A2 is abstract and derived classes are forced to o= verride and define f to be able to be a most-derived class - right? However= , I can provide an in-class definition for A1::foo:
struct A1 { virtual void f<= /span>(){}= };
7.1.= 2/3 specifies that this is equivalent to
struct A1 { virtual void f(); };
inline void A1:= :f<= span style=3D"color: #660;" class=3D"styled-by-prettify">() {}
So this would= cause the same problems as
<= span style=3D"color: #008;" class=3D"styled-by-prettify">struct A1 { virtual void f() =3D 0 {}; };
However, for the sake of consistency, = even though in-class definitions might not be optimal - wouldn't it still b= e feasible to make those available for pure virtual functions?
Assuredly= there is a reason that VC++ allows this?

--

---
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
------=_Part_208_1043002358.1429784879451-- ------=_Part_207_712141927.1429784879451-- .