220 31684 article Path: news.gmane.org!.POSTED!not-for-mail From: "T. C." Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Simplify virtual inheritance rules Date: Sat, 18 Mar 2017 15:55:24 -0700 (PDT) Lines: 105 Approved: news@gmane.org Message-ID: References: <6aa2e439-345e-4f04-8843-f38bb7b825b2@isocpp.org> <2340e1b0-09bd-4f5b-bf15-7605eaed858b@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_768_1454849518.1489877724618" X-Trace: blaine.gmane.org 1489877726 5771 195.159.176.226 (18 Mar 2017 22:55:26 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 18 Mar 2017 22:55:26 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCQ43G7NQIIRBXPVW3DAKGQEW7UVXOI@isocpp.org Sat Mar 18 23:55:21 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ot0-f198.google.com ([74.125.82.198]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cpNFo-0000qv-E7 for gclcip-std-proposals@m.gmane.org; Sat, 18 Mar 2017 23:55:20 +0100 Original-Received: by mail-ot0-f198.google.com with SMTP id p41sf233194902otb.4 for ; Sat, 18 Mar 2017 15:55:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=CYhQmIbnujNbxQ7RdPny8Dy9AlogkW9YAyMtAFXXW3U=; b=OT3TNTk1bfe8YmiBAvMlw/C7Xjpb4PeoNXYJsJTTueISIJV3sYcbgnde+q1v+NUE9s BTaL2ZKRWJF/RUO4/1P1/HDxVnNZYAjZpBau3F2Wq5rKSP2jtQWSvU2bczXgg+nJL9UG PhBTRYzbXxxEsD3Hh20JGs3pGL6P152VLeoA+H8XJcghKdueNZNyxdfag7keDXFk3Cuy RrTEMxvHsxxx1KdDba3HOVG2zOl+j/FNE2aF6WdVflaAE4sxRE/2D8ndEftwq2JgOL8x Uvj4Ysl1e8RA3yFksJAeu70O/hTkrm6wqKZb0th/Pp4q0HxhJfkl5+ynXp+aV8FdN0cn 2V0A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=CYhQmIbnujNbxQ7RdPny8Dy9AlogkW9YAyMtAFXXW3U=; b=NJceAbmI5IazDIR5g8Jds9N4ILqgJ1OA1Sg4NxhV1nSmr20Zu51ixQ7mDCtAaBA5C7 i6XFdvz3V6qDri19DPB4w7gxEmLYs3ekDZpE538CmGwDx4lKgguzOLHWiRF69sahZnOI GJqQbtp7jrJX73+8IozEnv259fNP7NCTvmk9WFBUdk4Lz9g4R3uImnwf1VCKYhs5/iC0 r8nqqIQsbXcjVsjUlI3AbDewr/Bn/Kk3OoUe0pek8CYKaZB48sxCHODrhCifldzEagIi 4yJz/NnVsOWQHeSgmAJ8K9Dt46L9QUq/qMTO2CnQvVVgTje26/zud4IqO4AYNveH+gnc 2NHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:x-original-sender:reply-to:precedence :mailing-list:list-id:x-spam-checked-in-group:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=CYhQmIbnujNbxQ7RdPny8Dy9AlogkW9YAyMtAFXXW3U=; b=DSnKYcKgN2REVZqG/GhnBjmfRBT21V3mFNhdeHESbfGxCmO07NTyY9cop1ph0+H4Vg Ijenjumbk+83ZyGi4t2m9vaRwS7XBRj2NNHoidGvMCXuGB0nLUeh/r/M7FGMm/Krl+rh t1JPXMLWzztsao8ZZuXqvpdNDB3b01i6psRXi9Bj14WHFlsslUeKrBaMuwriJyY8fdFt KXnbyrHF3xuEZqnb6GXgxnFBRy2oWLfaLHgokJOFhDmCMK8t6ILe/IvbVtkmuPgfk463 L/I2qkAM1oQqENONZI1bK4gzzmOiWpnTg/89ZAne/UNgEgET7kcVMcxaR2yTgevYH/UI 7hcA== X-Gm-Message-State: AFeK/H2j158vqHps0RX4DiODu8/o4P1Xv+8txI32iJtEKLpC1yOgpSe86cCtu+fa7AIvFQ== X-Received: by 10.157.1.238 with SMTP id e101mr9747166ote.62.1489877725912; Sat, 18 Mar 2017 15:55:25 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.53.6 with SMTP id o6ls11036262otc.47.gmail; Sat, 18 Mar 2017 15:55:25 -0700 (PDT) X-Received: by 10.157.43.165 with SMTP id u34mr1576849ota.5.1489877725154; Sat, 18 Mar 2017 15:55:25 -0700 (PDT) In-Reply-To: X-Original-Sender: rs2740@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:31684 Archived-At: ------=_Part_768_1454849518.1489877724618 Content-Type: multipart/alternative; boundary="----=_Part_769_1018248968.1489877724618" ------=_Part_769_1018248968.1489877724618 Content-Type: text/plain; charset=UTF-8 On Saturday, March 18, 2017 at 6:08:22 PM UTC-4, Ville Voutilainen wrote: > > On 18 March 2017 at 23:18, Denis Kotov > > wrote: > > But I do not see any problems with separate translation unit. > > You're asking for this rule: > > If the constructor I call initializes the virtual base, I won't have > to. That rule is unimplementable > in the presence of separate translation units. > > Furthermore, you cannot know what value the constructor you call > (would) initializes the virtual base with. > Currently, the intermediate class you initialize will not initialize > the virtual base at all, so there's a good > chance that what you're proposing is also an ABI break. > I think OP's proposed rule is something like If an indirect virtual base is a (direct or indirect) base of only one direct base, then you can omit initializing the virtual base. Presumably in that case you'd call the complete object constructor of said direct base so that it initializes the virtual base, rather than the base object constructor. This wouldn't depend on the definition of the constructors at issue, only the classes, and won't run into separate translation issues. It does have plenty of other issues, though (e.g., handling of default constructible virtual bases, initialization order issues, etc., etc.), and I don't see how the headache is worth the minuscule benefit. -- 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. To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b16cfa2e-0aea-45c3-a822-87e196a10ddb%40isocpp.org. ------=_Part_769_1018248968.1489877724618 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Saturday, March 18, 2017 at 6:08:22 PM UTC-4, V= ille Voutilainen wrote:
On 18 M= arch 2017 at 23:18, Denis Kotov <redr...@gmail.com> wrote:
> But I do not see any problems with separate translation unit.

You're asking for this rule:

If the constructor I call initializes the virtual base, I won't hav= e
to. That rule is unimplementable
in the presence of separate translation units.

Furthermore, you cannot know what value the constructor you call
(would) initializes the virtual base with.
Currently, the intermediate class you initialize will not initialize
the virtual base at all, so there's a good
chance that what you're proposing is also an ABI break.

I think OP's proposed rule is some= thing like

If an indirect virtual base is a (direc= t or indirect) base of only one direct base, then you can omit initializing= the virtual base. Presumably in that case you'd call the complete obje= ct constructor of said direct base so that it initializes the virtual base,= rather than the base object constructor.

This wou= ldn't depend on the definition of the constructors at issue, only the c= lasses, and won't run into separate translation issues. It does have pl= enty of other issues, though (e.g., handling of default constructible virtu= al bases, initialization order issues, etc., etc.), and I don't see how= the headache is worth the minuscule benefit.

--
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.
To view this discussion on the web visit https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/b16cfa2e-0aea-45c3-a822-87e196a10ddb= %40isocpp.org.
------=_Part_769_1018248968.1489877724618-- ------=_Part_768_1454849518.1489877724618-- .