220 39187 <94b23f30-9b24-40b2-b89c-6bdaf38c689e@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: rmbeer2@gmail.com 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: Tue, 17 Jul 2018 22:54:40 -0700 (PDT) Lines: 435 Approved: news@gmane.org Message-ID: <94b23f30-9b24-40b2-b89c-6bdaf38c689e@isocpp.org> References: <58370075-8584-4d52-be3a-295aa2c8ce40@isocpp.org> <806f0ee4-776f-43aa-aad8-e439d89892a7@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_34609_1171648708.1531893280231" X-Trace: blaine.gmane.org 1531893156 32109 195.159.176.226 (18 Jul 2018 05:52:36 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 18 Jul 2018 05:52:36 +0000 (UTC) Cc: rmbeer2@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDI6L6W3SYLBBINMXPNAKGQEYRU2XGI@isocpp.org Wed Jul 18 07:52:32 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yw0-f197.google.com ([209.85.161.197]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fffO3-0008Gv-La for gclcip-std-proposals@m.gmane.org; Wed, 18 Jul 2018 07:52:31 +0200 Original-Received: by mail-yw0-f197.google.com with SMTP id p8-v6sf1903000ywl.14 for ; Tue, 17 Jul 2018 22:54:42 -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=a8jsRPWJAeFEHVLTvNgsAVO7L9YKkTry7WY1uDjzlzU=; b=gLf7dwZ4yrs8m3gfpzVzFdTskr/ISvJJDlFIltQIPmvIL3aWjmosDZ+CqNno7z+7WF 1NvTYncPPfhA+bTbMFiA3kpz5v3hoXlQM9mWflWClR2YIIaAvLkqdce9wJDBxa9cE2NB zrTV9MrxtOwP3kn+605I7akWVkjSSxp9otUKcgWzZXNu7g3MFWsTeEIb+sA8+JWKOV7V JkXTIs1b4M8Bx31CgFMMgCNXre17jO1GC+JlOOZzm4baPfksjTVvDp9hC3tXO4LQ/Bpb lVdQmmqa3Wp+H42jpMxNyVwkX6vFqUtG+OZCJNTroXoWHwCGflOuOq/FNPY1gJm8zFS1 ocDQ== 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=a8jsRPWJAeFEHVLTvNgsAVO7L9YKkTry7WY1uDjzlzU=; b=EDT25NI2cMDCCkybWeLA9qyScPicW22d/Sf2qSLvNH5B4QYINisGwIxDn8Hyu0iURP tV4cKTWZOJxOLRPt/FcF5TRJEphfYUaN/4tX3yrP2bJ6aQZ4u+7F9H1XHro1oPOlbOFH DyYkKmPUkchvOyAkm+h9KFyASiELJJzlsGZxT/jE53Z9yfJrVtO4605NnInQFrHtMMs+ AXbocEAF6NyXHi4eEf0+sJKByfBoQpxZFAdwEqX1MfrysLteTqCY+6acyfDCTx/9ZcRa 1W6LWh9VVD22pVRWF3G+TRfYCrKdRa4rD1ZXjGK4NOa9loBkAfqjSNV63XM9pS9IB78D aL1A== 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=a8jsRPWJAeFEHVLTvNgsAVO7L9YKkTry7WY1uDjzlzU=; b=p10zDSiq2F6r905WDc7qq1XcnvKfiUvexBzGTD9MDDYMB0Bd05ztOktS2qV0fJ12ef v52OJH+4hL2TzVbgsDbBHXAPow6CP9skUgGM1CxxA3z0Cej+tPfMRvDqlXX/OUZTwhMx WKskHjqEIh4a0n5S6WZ0R6txRKTqSoba1+hw5UatCfsgkWRwrxTi1kGi+fGz+Aae/SJu FPml2DZLtkIvdXy5QGPFJzW+3EJEjVnNcOS/4e6PLfdFChMZLdLh/Lx0OGCFFfKGIB/V Fbu35P1/pjTmWmrYSgHayJSkj8i0dkAlEuls0msotAXVEK6Vpow+d0lLwYL+Zni7qGUs 3YCw== X-Gm-Message-State: AOUpUlHJJRxcwdDnPtH1Beq0Vc2rjDF/vt2H+RI5ws3/mrntmJwrTpBC bgwG9FRRqUvS+Fi5Ewo3f/mi6g== X-Google-Smtp-Source: AAOMgpe5MefiTUhtPpbxjfQipa0QPv2xOHrZ9iqeZT7BGF8ISFhyzGI1UMSan5hD6qsCHN4RVSTpVA== X-Received: by 2002:a0d:db15:: with SMTP id d21-v6mr1353465ywe.140.1531893282123; Tue, 17 Jul 2018 22:54:42 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a25:b912:: with SMTP id x18-v6ls796438ybj.17.gmail; Tue, 17 Jul 2018 22:54:40 -0700 (PDT) X-Received: by 2002:a25:8486:: with SMTP id v6-v6mr556327ybk.3.1531893280636; Tue, 17 Jul 2018 22:54:40 -0700 (PDT) In-Reply-To: <806f0ee4-776f-43aa-aad8-e439d89892a7@isocpp.org> X-Original-Sender: rmbeer2@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:39187 Archived-At: ------=_Part_34609_1171648708.1531893280231 Content-Type: multipart/alternative; boundary="----=_Part_34610_1702305938.1531893280232" ------=_Part_34610_1702305938.1531893280232 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The value it provides is as high as the inheritances. This idea applies an= =20 inheritance with simultaneous classes. Solve many of the problems of coding= =20 interrelated classes, obviously I will not be collecting signatures or=20 creating a community around this idea, it is just very useful and you must= =20 accept it. Nobody will come to complain about the impossibilities, in fact= =20 I'm just seeing that many users prefer to move to another language than to= =20 improve C++. As you apply the inheritance for some reason, you need to apply the=20 inheritance in multiple classes at the same time. In this thread example I have never mentioned sizeof(). The values =E2=80= =8B=E2=80=8Bset=20 for the classes will be static after compilation, so a member class=20 declared as virtual should not be reserved beyond the last class declared.= =20 Thus D will have as member (C+A), while B will have as a member only (A).= =20 In fact this feature uses less space than normal as opposed to (C+A,A). I think you're confusing things. How are the data stacked? Mira esto: (gdb) print b $1 =3D {a =3D {z =3D 1}} (gdb) print d $2 =3D { =3D {a =3D {z =3D 1}}, a =3D { =3D {z =3D 3}, y =3D 3}} By using 'virtual' on a variable you can simplify ' =3D {z =3D 3}' with = 'a =3D=20 {z =3D 1}', I do not know if I explain it, every time a call is made to the= =20 function of class A is only covering the use of this data and no other, so= =20 you can easily point to only one memory space. And another thing, when calling from any function from B/D to A/C, the A/C= =20 function forgets the data of B/D, it is not covering it. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D El valor que proporciona es tan alta como las herencias. Esta idea aplica= =20 una herencia con clases simultaneas. Resuelve muchos de los problemas de=20 codificaci=C3=B3n de clases interrelacionadas, obviamente no voy a estar=20 juntando firmas o creando una comunidad alrededor de esta idea, simplemente= =20 es muy util y debes aceptarlo. Nadie te va a venir a quejarse de las=20 imposibilidades, de hecho solo estoy viendo que muchos usuarios prefieren= =20 mudarse a otro lenguaje que mejorar C++. Asi como aplicas la herencia por algun motivo, necesitas aplicar la=20 herencia en multiples clases al mismo tiempo. En este ejemplo del hilo nunca he mencionado a sizeof(). Los valores=20 fijados para las clases seran estaticos luego de la compilaci=C3=B3n, por l= o que=20 una clase miembro declarada como virtual no deberia reservarse mas alla que= =20 en la ultima clase declarada. Asi D tendra como miembro (C+A), mientras que= =20 B tendra como miembro solo (A). De hecho esta caracteristica usa menos=20 espacio de lo normal al contrario de (C+A,A). Creo que estas confundiendo las cosas. Como se apilan los datos? Mira esto: (gdb) print b $1 =3D {a =3D {z =3D 1}} (gdb) print d $2 =3D { =3D {a =3D {z =3D 1}}, a =3D { =3D {z =3D 3}, y =3D 3}} Con utilizar 'virtual' sobre una variable se puede simplificar ' =3D {z = =3D=20 3}' con 'a =3D {z =3D 1}', no se si me explico, cada vez que se hace un lla= mado=20 a la funcion de la clase A solo esta abarcando el uso a estos datos y a=20 ningun otro, por lo que facilmente se puede apuntar a solo un espacio de=20 memoria. Y otra cosa, cuando se llama desde cualquier funcion de B/D a A/C, la=20 funcion de A/C se olvida de los datos de B/D, no la esta abarcando. El domingo, 15 de julio de 2018, 13:19:49 (UTC-3), Nicol Bolas escribi=C3= =B3: > > On Sunday, July 15, 2018 at 2:25:44 AM UTC-4, rmb...@gmail.com wrote: >> >> This is based on the other thread:=20 >> 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, sinc= e=20 >> 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=20 > understood what you were asking for just fine. We get it. > > The solution simply does not provide enough value. The problem it purport= s=20 > to solve is not encountered by a significant number of C++ coders. And th= e=20 > code examples you've provided as motivation represent coding styles that= =20 > are incoherent or otherwise are things we would rather people not be doin= g.=20 > That is, this problem is mainly encountered in badly designed systems; it= 's=20 > 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= =20 > that the primary question I have is "why are you writing your code that= =20 > way? Why is D inheriting from these things? What is this saying about the= =20 > relationships between these objects?" Providing an example culled from a= =20 > real program would make for a more convincing argument than this=20 > hypothetical A/B/C/D example. > > There are also implementation questions to consider. Using your A/B/C/D= =20 > example, how exactly does this work? This seems like a virtual base class= =20 > kind of thing, only with members. > > So... what is `sizeof(B)`? That has to be a static value, fixed at compil= e=20 > time. `B` obviously has a vtable pointer or whatever other machinery is= =20 > needed to implement virtual functionality. But does `B` reserve sufficien= t=20 > space to store an `A` within it? Because if it does, then *every* `B`=20 > must have that space. Even `D::B` still must have enough space to store a= n=20 > `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`=20 > starts pointing to `D::a::A` starts becoming relevant. For example, with= =20 > normal `virtual` functions, in `B`'s constructor, calling virtual functio= ns=20 > will only call overrides in `B`; if `D` overrode any virtuals from `B`,= =20 > they would not be called from `B`'s constructors. > > Presumably, virtual members would work the same way. This reinforces the= =20 > fact that `B` must always have sufficient storage for `B::a` within itsel= f.=20 > Why? Because `B`'s constructor does not know that it was called as a base= =20 > class. Therefore, it must initialize its member subobjects, so it will=20 > always initialize `B::a`. And it will never actually use it (unless someo= ne=20 > 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= =20 > of them is much more difficult to access. > > At the end of the day, this would be more efficiently done *manually*=20 > than with a `virtual` value system. That is, you do this: > > class B_base > { > public: > virtual A& get_a() =3D 0; > virtual const A& get_a() const =3D 0; > }; > > class B : public B_base > { > public: > A a =3D 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 =3D 3; > }; > > `B` is for standalone usage (which is why its overrides are `final`);=20 > `B_base` is what you use when you're deriving a class. And `B_base` is wh= at=20 > most functions should take as arguments if they want polymorphism. > > So what is the motivation for your proposal? The above code is more=20 > efficient. So why would you not do it? Because you have to type `get_a` t= o=20 > get at the variable? > --=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/94b23f30-9b24-40b2-b89c-6bdaf38c689e%40isocpp.or= g. ------=_Part_34610_1702305938.1531893280232 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The value it provides is as high as the inheritances. This= idea applies an inheritance with simultaneous classes. Solve many of the p= roblems of coding interrelated classes, obviously I will not be collecting = signatures or creating a community around this idea, it is just very useful= and you must accept it. Nobody will come to complain about the impossibili= ties, in fact I'm just seeing that many users prefer to move to another= language than to improve C++.
As you apply the inheritance for some rea= son, you need to apply the inheritance in multiple classes at the same time= ..

In this thread example I have never mentioned sizeof(). The values= =E2=80=8B=E2=80=8Bset for the classes will be static after compilation, so= a member class declared as virtual should not be reserved beyond the last = class declared. Thus D will have as member (C+A), while B will have as a me= mber only (A). In fact this feature uses less space than normal as opposed = to (C+A,A).

I think you're confusing things. How are the data st= acked?

Mira esto:
(gdb) print b
$1 =3D {a =3D {z =3D 1}}
(g= db) print d
$2 =3D {<B> =3D {a =3D {z =3D 1}}, a =3D {<A> = =3D {z =3D 3}, y =3D 3}}

By using 'virtual' on a variable yo= u can simplify '<A> =3D {z =3D 3}' with 'a =3D {z =3D 1}&= #39;, I do not know if I explain it, every time a call is made to the funct= ion of class A is only covering the use of this data and no other, so you c= an easily point to only one memory space.
And another thing, when callin= g from any function from B/D to A/C, the A/C function forgets the data of B= /D, it is not covering it.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

El valor que pro= porciona es tan alta como las herencias. Esta idea aplica una herencia con = clases simultaneas. Resuelve muchos de los problemas de codificaci=C3=B3n d= e clases interrelacionadas, obviamente no voy a estar juntando firmas o cre= ando una comunidad alrededor de esta idea, simplemente es muy util y debes = aceptarlo. Nadie te va a venir a quejarse de las imposibilidades, de hecho = solo estoy viendo que muchos usuarios prefieren mudarse a otro lenguaje que= mejorar C++.
Asi como aplicas la herencia por algun motivo, necesitas a= plicar la herencia en multiples clases al mismo tiempo.

En este ejem= plo del hilo nunca he mencionado a sizeof(). Los valores fijados para las c= lases seran estaticos luego de la compilaci=C3=B3n, por lo que una clase mi= embro declarada como virtual no deberia reservarse mas alla que en la ultim= a clase declarada. Asi D tendra como miembro (C+A), mientras que B tendra c= omo miembro solo (A). De hecho esta caracteristica usa menos espacio de lo = normal al contrario de (C+A,A).

Creo que estas confundiendo las cosa= s. Como se apilan los datos?

Mira esto:
(gdb) print b
$1 =3D {= a =3D {z =3D 1}}
(gdb) print d
$2 =3D {<B> =3D {a =3D {z =3D 1}= }, a =3D {<A> =3D {z =3D 3}, y =3D 3}}

Con utilizar 'virtu= al' sobre una variable se puede simplificar '<A> =3D {z =3D 3= }' con 'a =3D {z =3D 1}', no se si me explico, cada vez que se = hace un llamado a la funcion de la clase A solo esta abarcando el uso a est= os datos y a ningun otro, por lo que facilmente se puede apuntar a solo un = espacio de memoria.
Y otra cosa, cuando se llama desde cualquier funcion= de B/D a A/C, la funcion de A/C se olvida de los datos de B/D, no la esta = abarcando.


El domingo, 15 de julio de 2018, 13:19:49 (UTC-3), Ni= col Bolas escribi=C3=B3:
On Sunday, July 15, 2018 at 2:25:44 AM UTC-4, rmb...@gmail.co= m wrote:
This i= s based on the other thread: https://groups.google.com/a/isocpp= ..org/forum/#!topic/std-proposals/dSAu_sbyEXA

I want to star= t 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 i= t.

The solution simply does not provide enough val= ue. The problem it purports to solve is not encountered by a significant nu= mber of C++ coders. And the code examples you've provided as motivation= represent coding styles that are incoherent or otherwise are things we wou= ld 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 primar= y 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 progra= m would make for a more convincing argument than this hypothetical A/B/C/D = example.

There are also implementation questions t= o consider. Using your A/B/C/D example, how exactly does this work? This se= ems like a virtual base class kind of thing, only with members.
<= br>
So... what is `sizeof(B)`? That has to be a static value, fix= ed at compile time. `B` obviously has a vtable pointer or whatever other ma= chinery is needed to implement virtual functionality. But does `B` reserve = sufficient space to store an `A` within it? Because if it does, then eve= ry `B` must have that space. Even `D::B` still must have enough space t= o store an `A`, even though `D::B::a` doesn't access that space.
<= div>
That's not a good thing.

Fu= rthermore, like virtual inheritance, the question of when `D::B::a` starts = pointing to `D::a::A` starts becoming relevant. For example, with normal `v= irtual` functions, in `B`'s constructor, calling virtual functions will= only call overrides in `B`; if `D` overrode any virtuals from `B`, they wo= uld not be called from `B`'s constructors.

Pre= sumably, 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 c= lass. Therefore, it must initialize its member subobjects, so it will alway= s initialize `B::a`. And it will never actually use it (unless someone uses= `this->B::a`, just as with calling a specific virtual function).
<= div>
So your `D` class will indeed have two `a` subobjects. I= t's just that one of them is much more difficult to access.

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

class B_base
<= /span>{
public:
=C2=A0 virtual A& get_a() =3D = 0;
= =C2=A0 virtual const A& get_a() const =3D 0;<= /span>
};

c= lass B = : publi= c B_base
{
public:
=C2=A0 A a =3D 1;

=C2=A0 virtual A& get_a<= span style=3D"color:#660">() override final {return a;}
=C2=A0 virtual const A& get_a() const override final {return a;}
};=

class D : public B_base
{
public:
=C2=A0 virtual A& get_a() override {return a;}
=C2=A0 virtual const= A&= get_a() const= override {return a;}

=C2=A0= C a =3D 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 a= s 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 variabl= e?

--
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/94b23f30-9b24-40b2-b89c-6bdaf38c689e= %40isocpp.org.
------=_Part_34610_1702305938.1531893280232-- ------=_Part_34609_1171648708.1531893280231-- .