220 5448 article Path: news.gmane.org!not-for-mail From: Maurice Bos Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Not initializing virtual bases of abstract classes Date: Fri, 19 Jul 2013 18:38:18 +0200 Lines: 109 Approved: news@gmane.org Message-ID: References: <1503830.THvxmT3oxn@tjmaciei-mobl2> <1986604.uDTMXs9MNi@tjmaciei-mobl2> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11c3a9686892fa04e1dff538 X-Trace: ger.gmane.org 1374251925 3115 80.91.229.3 (19 Jul 2013 16:38:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 19 Jul 2013 16:38:45 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCNPPMPKVYDRBEGXUWHQKGQERFJ64VQ@isocpp.org Fri Jul 19 18:38:46 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ea0-f198.google.com ([209.85.215.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1V0DhZ-0004B1-9J for gclcip-std-proposals@m.gmane.org; Fri, 19 Jul 2013 18:38:41 +0200 Original-Received: by mail-ea0-f198.google.com with SMTP id m14sf4670892eaj.1 for ; Fri, 19 Jul 2013 09:38:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-beenthere:mime-version:in-reply-to:references:from:date :message-id:subject:to:x-gm-message-state:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-google-group-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe:content-type; bh=wQbV6qDK8JlNQTiW27lGS7M8QW/ABlTmYsTxp18JM1M=; b=TjryIpTKL3vJbtG/0xRus4zX3+0/PSZxhintvIbyLcLX+uR+vfPkErSREavL2Iex8S OIdREil4MTWMUyGqO6huk5L8Tcsyy8oNPhEaIueGb60xXMYM/KWTWWTBKB5iVi1/eeKA z5i8uUVFowsGaDlzJTuxFKs3wLweOV/mbFI1hxxQjJGeGecfDSwPGpoTTS064oM+2buW j9gjrH0hsjlHT0xKvU8QXCEyj1ffryRVZR2EouOx+zNZ9T2SW7kTCeySDk+vnitQRzKq J8m2y9dLT5NrOEx9KYoVevy5Vjf5RhVz7ioG0i9CTzIqy+JfWveyZvkxhhRjYJMycZrV m5FA== X-Received: by 10.112.34.197 with SMTP id b5mr4231892lbj.19.1374251920392; Fri, 19 Jul 2013 09:38:40 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.152.23.198 with SMTP id o6ls116311laf.53.gmail; Fri, 19 Jul 2013 09:38:39 -0700 (PDT) X-Received: by 10.152.22.42 with SMTP id a10mr7954974laf.30.1374251919584; Fri, 19 Jul 2013 09:38:39 -0700 (PDT) Original-Received: from mail-la0-f52.google.com (mail-la0-f52.google.com [209.85.215.52]) by mx.google.com with ESMTPS id uq6si7929681lbc.54.2013.07.19.09.38.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 19 Jul 2013 09:38:39 -0700 (PDT) Received-SPF: neutral (google.com: 209.85.215.52 is neither permitted nor denied by best guess record for domain of m-ou.se@m-ou.se) client-ip=209.85.215.52; Original-Received: by mail-la0-f52.google.com with SMTP id fo12so3605389lab.11 for ; Fri, 19 Jul 2013 09:38:39 -0700 (PDT) X-Received: by 10.152.44.133 with SMTP id e5mr7984897lam.15.1374251919296; Fri, 19 Jul 2013 09:38:39 -0700 (PDT) Original-Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [2a00:1450:4010:c04::236]) by mx.google.com with ESMTPSA id p20sm6376878lbb.17.2013.07.19.09.38.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 19 Jul 2013 09:38:38 -0700 (PDT) Original-Received: by mail-lb0-f182.google.com with SMTP id r11so3676390lbv.27 for ; Fri, 19 Jul 2013 09:38:38 -0700 (PDT) X-Received: by 10.112.12.225 with SMTP id b1mr7865113lbc.3.1374251918065; Fri, 19 Jul 2013 09:38:38 -0700 (PDT) Original-Received: by 10.112.73.240 with HTTP; Fri, 19 Jul 2013 09:38:18 -0700 (PDT) In-Reply-To: <1986604.uDTMXs9MNi@tjmaciei-mobl2> X-Gm-Message-State: ALoCoQmQFzgQZ5VK/nyoMIOGIAuuiTHOns3gwwUYeTKI5X7Pz8yJn20Ty1z3F4G8YX/Q4w6aFi8w X-Original-Sender: m-ou.se@m-ou.se X-Original-Authentication-Results: mx.google.com; spf=neutral (google.com: 209.85.215.52 is neither permitted nor denied by best guess record for domain of m-ou.se@m-ou.se) smtp.mail=m-ou.se@m-ou.se 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:5448 Archived-At: --001a11c3a9686892fa04e1dff538 Content-Type: text/plain; charset=ISO-8859-1 > I still don't see the problem. Why don't you make one of the virtuals that > you > have become pure? That solves your problem. > > You said that you have some intermediate classes that inherit the virtual > base, and yet you don't provide an explicit constructor initialisation for > the > virtual base. Clearly, those intermediate classes cannot be instantiated. > > If those classes can't be instantiated, why can't you make them abstract? > Just > add "= 0" to any of the virtual methods that you must already have. > > Consider this situation: struct A { explicit A(int); virtual void x() { foo(); } }; struct B : virtual A { virtual void x() override { bar(); } }; struct C1 : B { C1() : A(1) {} }; struct C2 : B { C2() : A(2) {} }; Here, you can't 'just add "= 0"' without having to put the {bar();} definition in both C1 and C2. However, either making B implicitly abstract (because it doesn't initialise its virtual base A), or explicitly making it abstract (using some new syntax) would solve the problem and make this code valid. (It's not that uncommon for a most derived class to not override any (virtual) member functions. For example, in the bottom class of a classic 'diamond' inheritance structure.) -- --- 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/. --001a11c3a9686892fa04e1dff538 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I still don&#= 39;t see the problem. Why don't you make one of the virtuals that you have become pure? That solves your problem.

You said that you have some intermediate classes that inherit the virtual base, and yet you don't provide an explicit constructor initialisation = for the
virtual base. Clearly, those intermediate classes cannot be instantiated.
If those classes can't be instantiated, why can't you make them abs= tract? Just
add "=3D 0" to any of the virtual methods that you must already h= ave.


Consider this situation:

=A0=A0=A0 struct A {
=A0=A0=A0= =A0=A0=A0 explicit A(int);
=A0=A0=A0 =A0=A0=A0 virtual void x() { foo()= ; }
=A0=A0=A0 };
=A0=A0=A0 struct B : virtual A {
=A0=A0=A0 =A0=A0=A0 virtual void x() override { bar(); }
=A0=A0=A0 };
=A0=A0=A0 struct = C1 : B { C1() : A(1) {} };
=A0=A0=A0 struct C2 : B { C2() : A(2) {} };

Here, you can't 'just add "=3D 0"' without having= to put the {bar();} definition in both C1 and C2. However, either making B= implicitly abstract (because it doesn't initialise its virtual base A)= , or explicitly making it abstract (using some new syntax) would solve the = problem and make this code valid.

(It's not that uncommon for a most derived class to not override an= y (virtual) member functions. For example, in the bottom class of a classic= 'diamond' inheritance structure.)

--
 
---
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-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/<= /a>.
 
 
--001a11c3a9686892fa04e1dff538-- .