220 31689 <25e054ca-aac4-4bcc-805a-4e1357de4f37@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Denis Kotov Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Simplify virtual inheritance rules Date: Sun, 19 Mar 2017 05:22:28 -0700 (PDT) Lines: 156 Approved: news@gmane.org Message-ID: <25e054ca-aac4-4bcc-805a-4e1357de4f37@isocpp.org> 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_758_115881469.1489926148125" X-Trace: blaine.gmane.org 1489926150 25916 195.159.176.226 (19 Mar 2017 12:22:30 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 19 Mar 2017 12:22:30 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDY2PNGE6QOBBBHQXHDAKGQESGXWRNY@isocpp.org Sun Mar 19 13:22:24 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yw0-f200.google.com ([209.85.161.200]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cpZqp-00064E-Ob for gclcip-std-proposals@m.gmane.org; Sun, 19 Mar 2017 13:22:23 +0100 Original-Received: by mail-yw0-f200.google.com with SMTP id k13sf367542859ywk.2 for ; Sun, 19 Mar 2017 05:22:30 -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=XqoqRKZ5dFAHAgN0JZBjHa/3tFwtXgdUIg4v4Qy0xAk=; b=ooZkpiEGB//xWCu7ljoHMEBTup16zNSsc998+LyafkETXBeet9/5dqxXiXiHmsO9sR m9LUJIt5Rs/q75GqvK7inpp0/WMo+hYH41dah3V7k2g/emHQ5C1Fc/FY2OPTiY/MddLy yEQLh1WxTV19JIjDNSm0e/0Eq186DIwxyCewv9gl8FZKs93Rt5QH0EnvhjKxN+8JQl+6 5c4MHdaxCr3HB3qC5wkkQhXAsqKlgTGO43DvSlRREIOMJUx7HEls6dfPvZs68Z3emM7Y ymVVpk9qrYi5IKrs5YU9wXq+YQfSwzLGyQgmTd5OFOhRTZqaZsHXWUm3sbZBfrolq19l zX7Q== 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=XqoqRKZ5dFAHAgN0JZBjHa/3tFwtXgdUIg4v4Qy0xAk=; b=DPueJgSxxQAP9ddjCs3DF+krfpDZoxSiD2ML05KVV+5/Mewe0y/Mr04svTJErCDzLr KCj5D4ry2VzfQlRA4uieaKdRmY3jZqHPD2DRr5T7uaOj8XvrHo7RySh5r+ylowRWkabZ /xZx8/NeGvCIH33zAz6wBmUrPbxgKz8TvuQA6bMNX2mlgK5Bxji17YpFwR06iT7mDhX6 NRTy9j2dQzd6impHdtdE0sj3cNewD0YYZ9NbCzIw8WdotZZCGRPMHsLnXmL4i7VCPR5E sv3N8m4xO3A8zYXP30wWGrLnu/7YnjfSZMvx2ZZ45qgXUvrpKITeZQT8rTnlCGNf4C7q vqrA== 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=XqoqRKZ5dFAHAgN0JZBjHa/3tFwtXgdUIg4v4Qy0xAk=; b=CSLRHiDEeVaQN/gaG3xoaXNzcRMLmroXaSQ2QIxFws6r/+SCgvoehSg9Vi68eCNr1O XQdvQR8TM9oQ9GTNRZ0aG5QvS1Hujm8hEpLN9zMUiZ26h9AXHwNSuPsIuKX4XSHvHcAe f1CrqHQt5Xci/pqzzBScRXW+/LCDB1fknJ4MJKJj0y1QhlmLQuHhGeEabMbSrzRw6TEj F+/Rg7nFYvv/v0PEjfazzgXotO9XzRBqrTwQxAaX/Q0U+txHSWbdweAYaVcLd2hNlrmZ qy8GnFSYQk0QtUlaQFZmITPVKB1MIMg+1rbXZQPNNRUu/bLKOgywVZT/fOpFmXAaSfB+ sSIw== X-Gm-Message-State: AFeK/H25RD/m2n407TluHVq7oGpgTKx6XDtnU71Q7jrGsv38bEcbl+l0wfWANhbhOejuYg== X-Received: by 10.129.99.6 with SMTP id x6mr12900549ywb.62.1489926149576; Sun, 19 Mar 2017 05:22:29 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.5.7 with SMTP id 7ls12245204otw.5.gmail; Sun, 19 Mar 2017 05:22:28 -0700 (PDT) X-Received: by 10.157.41.152 with SMTP id n24mr2392942otb.0.1489926148786; Sun, 19 Mar 2017 05:22:28 -0700 (PDT) In-Reply-To: X-Original-Sender: redradist@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:31689 Archived-At: ------=_Part_758_115881469.1489926148125 Content-Type: multipart/alternative; boundary="----=_Part_759_528400850.1489926148125" ------=_Part_759_528400850.1489926148125 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks for comment *T. C.,* But I do not agree that it is not worth to do it. Consider situation of very long chain of inheritance. Why in this chain=20 user has to call every time constructor for *VirtualBase *? It violates an encapsulation. User in derived class does not have to know= =20 something about it parent long long ago ... It will just simplify=20 development of class hierarchy and make class hierarchy looks like in *Java= =20 *or *C#* with one instance of *Base *class and similar rules. Consider another situation where in long chain of inheritance somewhere=20 user inherite *VirtualBase *implicitly with access modifier *'protected'*= =20 or *'private'.* *Why user should know something about parent class ?* =D0=B2=D0=BE=D1=81=D0=BA=D1=80=D0=B5=D1=81=D0=B5=D0=BD=D1=8C=D0=B5, 19 =D0= =BC=D0=B0=D1=80=D1=82=D0=B0 2017 =D0=B3., 0:55:24 UTC+2 =D0=BF=D0=BE=D0=BB= =D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C T. C. =D0=BD=D0=B0= =D0=BF=D0=B8=D1=81=D0=B0=D0=BB: > > > > 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:=20 >> > But I do not see any problems with separate translation unit.=20 >> >> You're asking for this rule:=20 >> >> If the constructor I call initializes the virtual base, I won't have=20 >> to. That rule is unimplementable=20 >> in the presence of separate translation units.=20 >> >> Furthermore, you cannot know what value the constructor you call=20 >> (would) initializes the virtual base with.=20 >> Currently, the intermediate class you initialize will not initialize=20 >> the virtual base at all, so there's a good=20 >> chance that what you're proposing is also an ABI break.=20 >> > > I think OP's proposed rule is something like > > If an indirect virtual base is a (direct or indirect) base of only one=20 > direct base, then you can omit initializing the virtual base. Presumably = in=20 > that case you'd call the complete object constructor of said direct base = so=20 > that it initializes the virtual base, rather than the base object=20 > constructor. > > This wouldn't depend on the definition of the constructors at issue, only= =20 > the classes, and won't run into separate translation issues. It does have= =20 > plenty of other issues, though (e.g., handling of default constructible= =20 > virtual bases, initialization order issues, etc., etc.), and I don't see= =20 > how the headache is worth the minuscule benefit. > --=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/25e054ca-aac4-4bcc-805a-4e1357de4f37%40isocpp.or= g. ------=_Part_759_528400850.1489926148125 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for comment=C2=A0T. C.,

<= /div>
But I do not agree that it is not worth to do it.
Consi= der situation of very long chain of inheritance. Why in this chain user has to call every time con= structor for VirtualBase ?
It violates an encapsula= tion. User in derived class does not have to know something about it parent= long long ago ... It will just simplify development of class hierarchy and= make class hierarchy looks like in Java or C# with one insta= nce of Base class and similar rules.

Consid= er another situation where in long chain of inheritance somewhere user inhe= rite VirtualBase implicitly with access modifier 'protected&#= 39; or 'private'.
Why user should know something about parent clas= s ?

=D0=B2=D0=BE=D1=81=D0=BA=D1=80=D0=B5=D1=81=D0= =B5=D0=BD=D1=8C=D0=B5, 19 =D0=BC=D0=B0=D1=80=D1=82=D0=B0 2017 =D0=B3., 0:55= :24 UTC+2 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0= =BB=D1=8C T. C. =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:


On Saturday, March 18= , 2017 at 6:08:22 PM UTC-4, Ville Voutilainen wrote:
On 18 March 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/25e054ca-aac4-4bcc-805a-4e1357de4f37= %40isocpp.org.
------=_Part_759_528400850.1489926148125-- ------=_Part_758_115881469.1489926148125-- .