220 31703 article Path: news.gmane.org!.POSTED!not-for-mail From: Ville Voutilainen Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Simplify virtual inheritance rules Date: Sun, 19 Mar 2017 22:01:52 +0200 Lines: 84 Approved: news@gmane.org Message-ID: References: <6aa2e439-345e-4f04-8843-f38bb7b825b2@isocpp.org> <2697868.vdYFrBLFDC@tjmaciei-mobl1> <5741111.lt9RR1yvSQ@tjmaciei-mobl1> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1489953721 23691 195.159.176.226 (19 Mar 2017 20:02:01 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 19 Mar 2017 20:02:01 +0000 (UTC) To: "ISO C++ Standard - Future Proposals" Original-X-From: std-proposals+bncBC5JHI7A7ALRBMOHXPDAKGQERHMJQQY@isocpp.org Sun Mar 19 21:01:56 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pg0-f69.google.com ([74.125.83.69]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cph1Q-00052T-H5 for gclcip-std-proposals@m.gmane.org; Sun, 19 Mar 2017 21:01:48 +0100 Original-Received: by mail-pg0-f69.google.com with SMTP id 79sf133286968pgf.2 for ; Sun, 19 Mar 2017 13:01:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-transfer-encoding:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=7LFJhA0r39dWDyHdlFDB2G4+mrB4+vQd8HakcsjKgPY=; b=1u37MlmKQUKUqIQ+dqvxEh8nuPBVRINZfaLbUPgsEivD5r5flVXcZXIsha9Hfc26ZS aD+3AG8+xVPzmJ3MVndqft9lG68KCkbSBIA3yks4VNh2i99St2UO6Fgg11C1OLJaQ+nw bSlw5mlh6SR15SZ2G3bzD2goW6CGx/1WccwOtODsw/IM6hUJLe0ZvW23DtUwm5AfksZ0 Mu19syPWTdcmIU2+U3++la/kazQd8Z7Ggw/f+TAy63Yqt6RfSsD5pr8Xfl1+Z0ZMXI8G VDf1FVlV9Fquy3TVLsw1mwfiQtpBPSaFaH75+i6OsKeC08iecFUjeUe2cChzskhlioKz qYIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-transfer-encoding:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=7LFJhA0r39dWDyHdlFDB2G4+mrB4+vQd8HakcsjKgPY=; b=AqfI9T5cxY22qUYtaPBEHwBMmHUfxOM7ParZfyTDk/m+xF8nrx7BrWm956kxuE981L EQaTyxX0y6YH+3IZjTz1RyPK1bdJfu5x4VNEExvkhR5Ecl27dPGwGs/krLohpexTaAPL 1MXGM82/8DF9GqQYCq5mgKqNBEIQ0mHVKKYpEo3XjhO6r0Dg4TUNJpyvdtJwUv2rUsYx /Z6l4vsOxTxL2hKBZZD0pgJTeuEUWCdbJgrS2fqdhl95/HCjqKfVrA4f4Ic5J1XIxE/+ 53odXipJ/qEAuBQ5LREbQY3tEMCNqZWijVShAZjVkW7awdYr0npFj7n+Kjpt+9AuGgFb A/7 X-Gm-Message-State: AFeK/H0sttt0Egwf0jyh/GqqJI4ZIgK+sCESkvEkuGhwZqS/EBxA7ZYHsAlQCYXdG0tLXA== X-Received: by 10.99.5.150 with SMTP id 144mr5539175pgf.123.1489953714095; Sun, 19 Mar 2017 13:01:54 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.1.17 with SMTP id 17ls11317068otu.16.gmail; Sun, 19 Mar 2017 13:01:53 -0700 (PDT) X-Received: by 10.157.7.50 with SMTP id 47mr12921842ote.17.1489953713340; Sun, 19 Mar 2017 13:01:53 -0700 (PDT) Original-Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com. [2607:f8b0:4003:c06::22f]) by mx.google.com with ESMTPS id f134si6010965oib.166.2017.03.19.13.01.53 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 19 Mar 2017 13:01:53 -0700 (PDT) Received-SPF: pass (google.com: domain of ville.voutilainen@gmail.com designates 2607:f8b0:4003:c06::22f as permitted sender) client-ip=2607:f8b0:4003:c06::22f; Original-Received: by mail-oi0-x22f.google.com with SMTP id a94so14425121oic.2 for ; Sun, 19 Mar 2017 13:01:53 -0700 (PDT) X-Received: by 10.202.54.4 with SMTP id d4mr13828348oia.45.1489953712856; Sun, 19 Mar 2017 13:01:52 -0700 (PDT) Original-Received: by 10.157.13.22 with HTTP; Sun, 19 Mar 2017 13:01:52 -0700 (PDT) In-Reply-To: <5741111.lt9RR1yvSQ@tjmaciei-mobl1> X-Original-Sender: ville.voutilainen@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com; spf=pass (google.com: domain of ville.voutilainen@gmail.com designates 2607:f8b0:4003:c06::22f as permitted sender) smtp.mailfrom=ville.voutilainen@gmail.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com 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:31703 Archived-At: On 19 March 2017 at 21:10, Thiago Macieira wrote: > On domingo, 19 de mar=C3=A7o de 2017 11:32:04 PDT Ville Voutilainen wrote= : >> On 19 March 2017 at 20:20, Thiago Macieira wrote: >> >> Right, so this proposal doesn't produce UB. That leaves the other >> >> compatibility issues. >> > >> > Which ones? >> >> See a couple of emails ago. The cases where the most-derived class >> doesn't have access to the constructor >> of the virtual base; that makes intentionally ill-formed cases well-form= ed. > > Right. This may have been used in existing code to limit inheritance in a= tree > to only classes that are explicitly white-listed as friends at some point= .. > > I'm wondering if now allowing this inheritance is a problem. The technique appears in http://www.stroustrup.com/bs_faq2.html#no-derivati= on > And in this case, the author of the new class is simply saying "I'll have= what > he's having" (the direct base class that includes the virtual base). I > understand that this technique would have been very useful to force a uni= que > identifier per class in the hierarchy, but now we're allowing a derived c= lass > not to override the identifier (or silently forget to). > > Do we need a keyword to specifically allow this new functionality? Grr. Let's not make it that complex. I think another interesting case is th= is: #include struct B { B() {std::cout << "B default" << std::endl;} B(int) {std::cout << "B int" << std::endl;} }; struct D : virtual B { D() : B(42) {} }; struct E : D { }; int main() { E e; } We presumably don't want to change how that behaves. So, in some cases, E does initialize the virtual base, in others, it doesn't. So, trying to keep that unchanged and the no-derivation case working, we have something like 1) if default-initializing B from E is valid, we're done. 2) if default-initializing B from E fails due to access violation, we're do= ne. 3) if default-initializing B from E fails due to overload resolution failure for not finding a viable candidate, don't initialize B in E but instead initialize E in D. 4) any existing explicit initialization of B from E is unchanged, and there's no fallback to any base class. --=20 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 e= mail to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. To view this discussion on the web visit https://groups.google.com/a/isocpp= ..org/d/msgid/std-proposals/CAFk2RUaf23ZfK3v%3Dg4j6gwA6KAOTWNtbB%3D1fGKuRia8= HiNs35Q%40mail.gmail.com. .