220 24882 <209f4408-b229-4d6d-a568-f0d9d9f9d3fb@isocpp.org> article Path: news.gmane.org!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Go-like embedding Date: Wed, 2 Mar 2016 11:33:53 -0800 (PST) Lines: 300 Approved: news@gmane.org Message-ID: <209f4408-b229-4d6d-a568-f0d9d9f9d3fb@isocpp.org> References: <245e65c5-c96d-4366-b616-814606d4ebe9@isocpp.org> <0ee10bc5-b45e-430e-bb08-69a80863cecb@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_6719_1061628349.1456947233712" X-Trace: ger.gmane.org 1456947238 1403 80.91.229.3 (2 Mar 2016 19:33:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 2 Mar 2016 19:33:58 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBIUA3W3AKGQEGMXMWHI@isocpp.org Wed Mar 02 20:33:57 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yk0-f199.google.com ([209.85.160.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1abCWy-0000is-LK for gclcip-std-proposals@m.gmane.org; Wed, 02 Mar 2016 20:33:56 +0100 Original-Received: by mail-yk0-f199.google.com with SMTP id m4sf58571947yke.2 for ; Wed, 02 Mar 2016 11:33:56 -0800 (PST) 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=ZBJpxjsfu817kDqf/vsZyX5oeJ/K9N8hDgMIyQk7DDQ=; b=FDg2qbqFaKDKf/Sr/OXVQSGYVvQ4UiAiV9W9ZfSpdTNdOnKRs6lkI3xDpKGx/mEmda Vxap6AHfQq/v48lKYQ7VbPtFN3lRP09Hl3bHKTXP5CoYVMdGgSjbk6jP+7KVbRrggp6k I/RD4iulsBTtGSU7PZM093vrrPBdE4hmoDqcibm5hNrfplMEQ315ACSjSsxPGx522jWE RDftPBybflat9+/XPIFY2MpI0gu+4jz/SRG14ypZa51KH0QAgV0BlncqnwNCtwUUg8V4 sHK/SlmRe/jIkxSe+7iEuxgsYsM92VZ4xGKSXd1tv78VnkgpRvFyrrgvV3Dx7zhT8lWL Xa+g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; 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=ZBJpxjsfu817kDqf/vsZyX5oeJ/K9N8hDgMIyQk7DDQ=; b=cp/aB0v2eiKB3yplLrNRRzFdlCf97QiN9o6g4XMngmpqc3IpREzq3iD+oCf0oaARtp MWwH2ixIivqnurf2gPrv7uDEwbHl9JbRLlvjnXi/0qQEeGCm252bgUaqPUvfEbCHh+2m 7MrSgseVxWhVGFOh02jqu75MIKFuYMw4OuLadEfGbSGmnbBMdaJpzl4ydUHgvTwxszTT za/lr+8dxkcvTB6YdmQl8p69xfiOKttG5PdURuhvkzsoReGvQoqg+BvBsH1RzHnHhz/h AlPhblic2e8tl4R/FouBTG7xyoeHpFRI7g42oTqX52qSXrKO/99/fbSkwGuamQvfswks 8l1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; 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=ZBJpxjsfu817kDqf/vsZyX5oeJ/K9N8hDgMIyQk7DDQ=; b=K/wUc3mMioUY0brU6Z8HThRJyzAGWrXRRNNuLe95ul6bdRTeNsT8mTWDYnCN0+uhVH 9ahB5wGGD/V2KL0Sx9hsAmfqUKhau/n8o0s+Iczo4380guImGz/zu89P+E45/ES1VQR+ H8iTEnA9GXXK5u4fUcuSTbCJ1WvRhkPKGjjVPGHSMcFDlZI/vgXrr+ysqqOc7lLFGu1F CLdc5dPUqiBCmn8eJZF3DfN7naXVQy8UyyxZoZKvVukKtntFEwx3G0zQoH6jIgt5AxuW F5Z/QvD7nEe+1ejeoeyPYcrgCfNdj8wUWJvhdNlJzfS3Pna2mqA5OYK1V+Ns1p1EN9wO WV1g== X-Gm-Message-State: AD7BkJKSmLDjPjzPk5cK2umRuo79ioB+kBbNtW0IWv8JOSePS9UvR0jYIC8QVS9aSLKUZw== X-Received: by 10.140.95.38 with SMTP id h35mr4205190qge.3.1456947235659; Wed, 02 Mar 2016 11:33:55 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.61.137 with SMTP id p9ls619271igr.28.gmail; Wed, 02 Mar 2016 11:33:54 -0800 (PST) X-Received: by 10.50.111.100 with SMTP id ih4mr74584igb.3.1456947234346; Wed, 02 Mar 2016 11:33:54 -0800 (PST) In-Reply-To: <0ee10bc5-b45e-430e-bb08-69a80863cecb@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:24882 Archived-At: ------=_Part_6719_1061628349.1456947233712 Content-Type: multipart/alternative; boundary="----=_Part_6720_469535419.1456947233713" ------=_Part_6720_469535419.1456947233713 Content-Type: text/plain; charset=UTF-8 On Wednesday, March 2, 2016 at 9:57:51 AM UTC-5, TONGARI J wrote: > > On Wednesday, March 2, 2016 at 9:46:29 PM UTC+8, Nicol Bolas wrote: >> >> On Wednesday, March 2, 2016 at 8:27:30 AM UTC-5, NeoCode wrote: >>> >>> In Go programming language, there is a feature named "emedding", which >>> is used instead of classic c++-like inheritance. >>> For example: >>> >>> type SmallBox struct { >>> a, b, c int >>> } >>> type BigBox struct { >>> Timestamp time.Time >>> SmallBox // <<< embedding >>> Name []string >>> } >>> >>> This is very simple and low-level extension of the concept of >>> inheritance; the programmer explicitly specifies the location of the base >>> object in the successor. It is strange that this simple and obvious >>> opportunity not appeared in the C language. >>> >>> I propose enhanced (compared with Go) feature of such embedding. We can >>> use the existing "inline" keyword (or some other keyword, eg. "embed") to >>> indicate the embedded fields. >>> >>> struct SmallBox { >>> int a, b, c; >>> }; >>> >>> struct BigBox { >>> time_t Timestamp; >>> inline SmallBox inlinedBox; >>> std::string Name; >>> }; >>> >>> As a result, we can access to the fields of SmallBox both directly and >>> through an intermediate name "inlinedBox": >>> >>> BigBox box; >>> box.a = 10; //directly, like inheritance >>> box.inlinedBox.b = 10; // using an intermediate name, like aggregation >>> >>> >>> >> ... what's wrong with inheritance? I know people tend to believe that >> using inheritance for something like this is wrong, but these cases are >> *exactly* why C++ has robust support for multiple inheritance, unlike >> most languages. >> > > I think it's for object layout. Using inheritance would force you to > layout `SmallBox` before `Timestamp` in the example (unless you make > `Timestamp` another base). > > I'm not familiar with Go, but if this is the OP's intent, I'd suggest > taking a step further to make the feature help data packing, e.g. > > struct A > { > uint32_t a1; > char a2; > }; > > struct B > { > uint32_t b1; > inline A; > char b2; > }; > > may allow the size of B to be 12 instead of 16. > So what you want isn't a type `A` at all; it's a named bundle of declarations that could be inserted into some other type. After all, `B` doesn't actually contain the type `A`; it contains some declarations that `A` provided. It seems to me that this is something that ought to be established at the time that `A` is defined. Along with rules about what kinds of things you're allowed and forbidden from putting into them (virtual functions, etc). Personally, I don't see the need for such a thing. Or at least, not in the way you's talking about. -- 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/209f4408-b229-4d6d-a568-f0d9d9f9d3fb%40isocpp.org. ------=_Part_6720_469535419.1456947233713 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wednesday, March 2, 2016 at 9:57:51 AM UTC-5, T= ONGARI J wrote:
On Wednesday, March 2, 2016 at 9:46:29 PM UTC+8, Nicol Bolas wrote:
On Wednesday, March 2, 2= 016 at 8:27:30 AM UTC-5, NeoCode wrote:
In Go programming language,=C2=A0there is a feature na= med "emedding",=C2=A0which is used instead of classic c++-like in= heritance.
For example:

=
type SmallBo= x struct {=
=C2=A0= =C2=A0 =C2=A0 =C2=A0 a, b, c int
= }
type<= /span> BigBox struct {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <= /span>Timestamp time.Time
=C2=A0= =C2=A0 =C2=A0 =C2=A0 SmallBox =C2=A0// <<= < embedding
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 Name []string=
}

This is very simple and low-level extension of the= concept of inheritance;=C2=A0the programmer explicitly specifies the locat= ion of the base object in the successor.=C2=A0It is strange that this simpl= e and obvious opportunity not appeared in the C language.
<= br>
I propose enhanced (compared with Go) feature of such embeddi= ng.=C2=A0We can use the existing "inline" keyword (or some other = keyword, eg. "embed") to indicate the embedded fields.
<= div>
struct= SmallBox {=C2=A0 int a,= b, c;
};

<= /span>struct <= /span>BigBox <= /span>{
=C2= =A0time_t Timestamp;
=C2=A0inline SmallBox inlinedBox;
=C2=A0s= td::str= ing Nam= e;
<= /span>};

As a result, we can access to the fields= of=C2=A0SmallBox=C2=A0both directly and through an intermediate name "= ;inlinedBox":

BigBox box;=
box.a =3D<= span style=3D"color:#000"> 10; //directly, like inheritance
bo= x.inlin= edBox.b= =3D 10; // using an intermediate name, li= ke aggregation



... what's wrong with inheritance? I know people tend to = believe that using inheritance for something like this is wrong, but these = cases are exactly why C++ has robust support for multiple inheritanc= e, unlike most languages.

I think it's for = object layout. Using inheritance would force you to layout `SmallBox` befor= e `Timestamp` in the example (unless you make `Timestamp` another base).

I'm not famil= iar with Go, but if this is the OP's intent, I'd suggest taking a s= tep further to make the feature help data packing, e.g.

struct A=
{=C2=A0 =C2=A0 uint32_t a1;
=C2=A0 =C2=A0 ch= ar a2;<= /span>
};

s= truct B
{
=C2=A0 =C2=A0 uint32_t b1= ;
=C2=A0 = =C2=A0 inline A;
=C2=A0 =C2=A0 char b2;
};

may allow the size of B to be 12 instead of 16.= =C2=A0

So what you want isn't a type `= A` at all; it's a named bundle of declarations that could be inserted i= nto some other type. After all, `B` doesn't actually contain the type `= A`; it contains some declarations that `A` provided.

It seems to me= that this is something that ought to be established at the time that `A` i= s defined. Along with rules about what kinds of things you're allowed a= nd forbidden from putting into them (virtual functions, etc).

Person= ally, I don't see the need for such a thing. Or at least, not in the wa= y you's talking about.

--
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/209f4408-b229-4d6d-a568-f0d9d9f9d3fb= %40isocpp.org.
------=_Part_6720_469535419.1456947233713-- ------=_Part_6719_1061628349.1456947233712-- .