220 39173 <806f0ee4-776f-43aa-aad8-e439d89892a7@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: new feature: replace a same old data with the new data. 'virtual' keyword is used. Date: Sun, 15 Jul 2018 09:19:49 -0700 (PDT) Lines: 314 Approved: news@gmane.org Message-ID: <806f0ee4-776f-43aa-aad8-e439d89892a7@isocpp.org> References: <58370075-8584-4d52-be3a-295aa2c8ce40@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_157885_1937005868.1531671589807" X-Trace: blaine.gmane.org 1531671466 26567 195.159.176.226 (15 Jul 2018 16:17:46 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 15 Jul 2018 16:17:46 +0000 (UTC) Cc: rmbeer2@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBJXIVXNAKGQEY4RKZDA@isocpp.org Sun Jul 15 18:17:41 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yw0-f199.google.com ([209.85.161.199]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fejiP-0006nT-DE for gclcip-std-proposals@m.gmane.org; Sun, 15 Jul 2018 18:17:41 +0200 Original-Received: by mail-yw0-f199.google.com with SMTP id i77-v6sf35135837ywe.19 for ; Sun, 15 Jul 2018 09:19:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:x-original-sender:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=CdX7BaK/Ug8Zbn/kGrk31J/9wwE7pS26puLr4AgKqYk=; b=P4397Rp8yXM3/KhMvcc66WqSv1Vg2e3h6XJnEi8LxJzPXdajHrAr2T81Lzxh9JTbq1 N9/9hoB6zooFdxTNIcTOOlQgZlFr5Oho1xHDEwshV0TDsAbNBG9O0ZHrzK6svODLFEVk HTfgwv39TzgYIZqQpoZxIA1CxRiYxlyFswe1e5KCCYdRztJOmyr//x7+cLbwI5lKFD0N QFOUGYINZeUIdJGrhijoEyftmuvBFyZINlb6CkWALj/KkJId+H4/hICUOtsk9tVTZ/rM EbPS7jOYXMipEAMLT99g/g/PEU5gpc/85azDRQWoilbcLETdVJHo7s0tCWVBgOFypIsr RwCw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:x-original-sender:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=CdX7BaK/Ug8Zbn/kGrk31J/9wwE7pS26puLr4AgKqYk=; b=Krg6SvTpNDLHT71GyBpMwOJxTnWdsY/68ejau6vmQZxsWcNzzJThRIldm6J9RP4NOO v6KTauja0gl1K8UqQMUtqGxhH+tQCwVEm1wsgA9PflHbEv3smOu2670k7DHGShdVotIB h0nZJY0XgnTN6liZsYonoM/vgOMoSdimb9Hf3QE+2QPz2rtkQ6OJdGZPq1EAq338DeDt o5YzJfQVvhXF4doWhxVMzcKMiYS47cZz4nouGg+lbY0J5JWCapKEXq9HzUMfELVa9fAe IycVeUC/vu6AjIxo83NZlLMpvkacFY9gw6IghLBvESznzhXkk6EBPrt5OqUgC29StXpS hBoA== 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:cc: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=CdX7BaK/Ug8Zbn/kGrk31J/9wwE7pS26puLr4AgKqYk=; b=bp3msxsEXMstl/9xJnq42I31gF15woJyzXqMDpFkpkUXdSyznS0lCX6kL431eIx05J yLqG4t7zqwoVyNzDchBxrcT/7QBGGVxWSu74SzjYFknrKBztfpdtsITiaTLZfOy6czR4 jCNp2sLrAWfeeuZqyofdFIOo7gVLAhNUPeEcBEqToz9mSIE6YqpCkQnCs6GtEK27DdcC hAx5V6sB4ZkYc9R54RUmDufVnI5/Ribvwrkg2snRqNC05OUVDa1Hn0B+7nVPBhHOjcEd QGOz/G0LxMEHIGBIsQcetbY1cNxyD+qOviLitq47yZGZIHMcH0mM5ees7nzVFu7lUNB2 P/3A== X-Gm-Message-State: AOUpUlH8ibfcuRNkj/G9BydNmYNkuLrdopkBYmsdoyzc/UTXKfLCaDT9 Xj1wUDHpnFpvzNF88Zgxa8sV2g== X-Google-Smtp-Source: AAOMgpcyHqiFaQ87bXkwkMnYXdwnGF6/LD/lTKz67nDL8dfPGh4PWKBUUhWKFGk7dbHl+EAIbxWsdw== X-Received: by 2002:a81:b3c7:: with SMTP id r190-v6mr3884115ywh.57.1531671592004; Sun, 15 Jul 2018 09:19:52 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a25:42d0:: with SMTP id p199-v6ls8335745yba.13.gmail; Sun, 15 Jul 2018 09:19:50 -0700 (PDT) X-Received: by 2002:a5b:349:: with SMTP id q9-v6mr1644194ybp.7.1531671590284; Sun, 15 Jul 2018 09:19:50 -0700 (PDT) In-Reply-To: <58370075-8584-4d52-be3a-295aa2c8ce40@isocpp.org> X-Original-Sender: jmckesson@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org 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:39173 Archived-At: ------=_Part_157885_1937005868.1531671589807 Content-Type: multipart/alternative; boundary="----=_Part_157886_320139548.1531671589807" ------=_Part_157886_320139548.1531671589807 Content-Type: text/plain; charset="UTF-8" On Sunday, July 15, 2018 at 2:25:44 AM UTC-4, rmb...@gmail.com wrote: > > This is based on the other thread: > https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/dSAu_sbyEXA > > I want to start with this new thread with a more complete proposal, since > I realize that you can not think for yourselves and much less study it. > For what it's worth, nobody misunderstood your previous thread. We understood what you were asking for just fine. We get it. The solution simply does not provide enough value. The problem it purports to solve is not encountered by a significant number of C++ coders. And the code examples you've provided as motivation represent coding styles that are incoherent or otherwise are things we would rather people not be doing. That is, this problem is mainly encountered in badly designed systems; it's best to avoid bad design rather than to create a feature that allows it. At the very least, your example of the problem is sufficiently abstract that the primary question I have is "why are you writing your code that way? Why is D inheriting from these things? What is this saying about the relationships between these objects?" Providing an example culled from a real program would make for a more convincing argument than this hypothetical A/B/C/D example. There are also implementation questions to consider. Using your A/B/C/D example, how exactly does this work? This seems like a virtual base class kind of thing, only with members. So... what is `sizeof(B)`? That has to be a static value, fixed at compile time. `B` obviously has a vtable pointer or whatever other machinery is needed to implement virtual functionality. But does `B` reserve sufficient space to store an `A` within it? Because if it does, then *every* `B` must have that space. Even `D::B` still must have enough space to store an `A`, even though `D::B::a` doesn't access that space. That's not a good thing. Furthermore, like virtual inheritance, the question of when `D::B::a` starts pointing to `D::a::A` starts becoming relevant. For example, with normal `virtual` functions, in `B`'s constructor, calling virtual functions will only call overrides in `B`; if `D` overrode any virtuals from `B`, they would not be called from `B`'s constructors. Presumably, virtual members would work the same way. This reinforces the fact that `B` must always have sufficient storage for `B::a` within itself. Why? Because `B`'s constructor does not know that it was called as a base class. Therefore, it must initialize its member subobjects, so it will always initialize `B::a`. And it will never actually use it (unless someone uses `this->B::a`, just as with calling a specific virtual function). So your `D` class will indeed have two `a` subobjects. It's just that one of them is much more difficult to access. At the end of the day, this would be more efficiently done *manually* than with a `virtual` value system. That is, you do this: class B_base { public: virtual A& get_a() = 0; virtual const A& get_a() const = 0; }; class B : public B_base { public: A a = 1; virtual A& get_a() override final {return a;} virtual const A& get_a() const override final {return a;} }; class D : public B_base { public: virtual A& get_a() override {return a;} virtual const A& get_a() const override {return a;} C a = 3; }; `B` is for standalone usage (which is why its overrides are `final`); `B_base` is what you use when you're deriving a class. And `B_base` is what most functions should take as arguments if they want polymorphism. So what is the motivation for your proposal? The above code is more efficient. So why would you not do it? Because you have to type `get_a` to get at the variable? -- 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/806f0ee4-776f-43aa-aad8-e439d89892a7%40isocpp.org. ------=_Part_157886_320139548.1531671589807 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sunday, July 15, 2018 at 2:25:44 AM UTC-4, rmb...@gmail= ..com wrote:
Th= is is based on the other thread: https://groups.google.com/a/is= ocpp.org/forum/#!topic/std-proposals/dSAu_sbyEXA

I want to = start with this new thread with a more complete proposal, since I realize t= hat you can not think for yourselves and much less study it.

For what it's worth, nobody misunderstood y= our previous thread. We understood what you were asking for just fine. We g= et it.

The solution simply does not provide enough= value. The problem it purports to solve is not encountered by a significan= t number of C++ coders. And the code examples you've provided as motiva= tion represent coding styles that are incoherent or otherwise are things we= would rather people not be doing. That is, this problem is mainly encounte= red in badly designed systems; it's best to avoid bad design rather tha= n to create a feature that allows it.

At the v= ery least, your example of the problem is sufficiently abstract that the pr= imary question I have is "why are you writing your code that way? Why = is D inheriting from these things? What is this saying about the relationsh= ips between these objects?" Providing an example culled from a real pr= ogram would make for a more convincing argument than this hypothetical A/B/= C/D example.

There are also implementation questio= ns to consider. Using your A/B/C/D example, how exactly does this work? Thi= s seems like a virtual base class kind of thing, only with members.

So... what is `sizeof(B)`? That has to be a static value,= fixed at compile time. `B` obviously has a vtable pointer or whatever othe= r machinery is needed to implement virtual functionality. But does `B` rese= rve sufficient space to store an `A` within it? Because if it does, then every `B` must have that space. Even `D::B` still must have enough spa= ce to store an `A`, even though `D::B::a` doesn't access that space.

That's not a good thing.

Furthermore, like virtual inheritance, the question of when `D::B::a` sta= rts pointing to `D::a::A` starts becoming relevant. For example, with norma= l `virtual` functions, in `B`'s constructor, calling virtual functions = will only call overrides in `B`; if `D` overrode any virtuals from `B`, the= y would not be called from `B`'s constructors.

Presumably, virtual members would work the same way. This reinforces the f= act that `B` must always have sufficient storage for `B::a` within itself. = Why? Because `B`'s constructor does not know that it was called as a ba= se class. Therefore, it must initialize its member subobjects, so it will a= lways initialize `B::a`. And it will never actually use it (unless someone = uses `this->B::a`, just as with calling a specific virtual function).

So your `D` class will indeed have two `a` subobject= s. It's just that one of them is much more difficult to access.

At the end of the day, this would be more efficiently= done manually than with a `virtual` value system. That is, you do t= his:

class B_base
{
pu= blic:
=C2=A0 virtual= A& get_a() =3D 0;
=C2= =A0 virtua= l <= span style=3D"color: #008;" class=3D"styled-by-prettify">const A& get_a() const =3D 0;
};

class B : public B_= base
{<= /span>
= public:
=C2=A0 A a =3D 1;

=C2=A0 virtual A& get_a() = override final {return a;}
=C2=A0 virtual = const A&<= span style=3D"color: #000;" class=3D"styled-by-prettify"> get_a() const override final {return a;}
};
class D : public B_base
{
public:
=C2=A0 virtual A&am= p; get_a() override {return a;}
=C2=A0 virtual co= nst A& get_a() const override {= return a;}

=C2=A0 C a <= /span>=3D<= span style=3D"color: #000;" class=3D"styled-by-prettify"> 3;
};

`B` is for standalone usage (which is why its overrides are `final`); `B_= base` is what you use when you're deriving a class. And `B_base` is wha= t most functions should take as arguments if they want polymorphism.
<= div>
So what is the motivation for your proposal? The above c= ode is more efficient. So why would you not do it? Because you have to type= `get_a` to get at the variable?

--
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/806f0ee4-776f-43aa-aad8-e439d89892a7= %40isocpp.org.
------=_Part_157886_320139548.1531671589807-- ------=_Part_157885_1937005868.1531671589807-- .