220 12715 <13fd60e5-2882-48bc-a9df-3c8d38b416eb@isocpp.org> article Path: news.gmane.org!not-for-mail From: Bengt Gustafsson Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Usability extensions to offsetof Date: Sun, 7 Sep 2014 15:57:26 -0700 (PDT) Lines: 266 Approved: news@gmane.org Message-ID: <13fd60e5-2882-48bc-a9df-3c8d38b416eb@isocpp.org> References: <1790122.GP859xiMW3@tjmaciei-mobl4> <3079502.NAEi170Di4@tjmaciei-mobl4> <07066304-6357-4a10-824b-7c0451608996@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_518_1169443003.1410130646690" X-Trace: ger.gmane.org 1410130658 28792 80.91.229.3 (7 Sep 2014 22:57:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 7 Sep 2014 22:57:38 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCRIRSPDTQIRBV6FWOQAKGQENNRSEHI@isocpp.org Mon Sep 08 00:57:30 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pd0-f200.google.com ([209.85.192.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XQlOj-0006ig-9c for gclcip-std-proposals@m.gmane.org; Mon, 08 Sep 2014 00:57:29 +0200 Original-Received: by mail-pd0-f200.google.com with SMTP id ft15sf11383074pdb.7 for ; Sun, 07 Sep 2014 15:57:27 -0700 (PDT) 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:list-post:list-help:list-archive :list-subscribe:list-unsubscribe:content-type; bh=W5eFtMA8f8xo1fuuSwwFN+QO2WB9K+77MvqaAIRU+RI=; b=j9L56wIojw1+36UjMzSSkhdPMh1ckdGf63T/fjOVdbErMyDdvFcyBgPx2KE1aQ92mW n3gvis83QLwKzf2XbVSZtEZ1x1141FhXSLH+5AywfvKJ4j0kpuLhr3Wwr7hNkDq/nr8u rqGvR6yhJP4EPRAnFhgyZbiWw9TLlcNHkob7pIMRf4RcTC5+ityXAMUem19TzjRns4a5 Wzachs0sTDYJV9Fv1Gn17I2dfjvjDlZY2iYQfTO7bjpoV2HuvdECIveQ7fTIWpSKAMJn RBP4ifzRdJyJhSd9d/3Stoizwga/wUQVQyxCgZPKBFIMCsnr9IvkUfAprYcoyWbzvsDI r48Q== X-Gm-Message-State: ALoCoQn9OnP/WBs3k6yJrIVu2sKUobCp3zgmgLKzl4E84H9jghfGriNogl0ApKeAqMzadCQNiNb6 X-Received: by 10.66.65.131 with SMTP id x3mr14319938pas.13.1410130647866; Sun, 07 Sep 2014 15:57:27 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.19.108 with SMTP id 99ls1541688qgg.29.gmail; Sun, 07 Sep 2014 15:57:27 -0700 (PDT) X-Received: by 10.140.19.213 with SMTP id 79mr564582qgh.5.1410130647131; Sun, 07 Sep 2014 15:57:27 -0700 (PDT) In-Reply-To: X-Original-Sender: bengt.gustafsson@beamways.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:12715 Archived-At: ------=_Part_518_1169443003.1410130646690 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Inner classes: If the only instance of the inner class is by value in its= =20 outer class then we could accomplish accessing the outer class's members=20 without any coding: class Outer { int x; class Inner { void f() { int y =3D x; // This is assigning from Outer's x. } } m_inner; }; This is why I ment by "starting out with this particular case", i.e. that= =20 it would be nice if this worked. Of course, once you start creating=20 instances of Inner that are not by value you'd have to handle the hidden pointer issues, which is the sticky part, I assume. It=20 would be possible to state in the standard that "nested classes can access= =20 outer class' members if the only instances are by value in the outer=20 class." which would make code above legal. I understand that this is creating another special case so it would be of= =20 course even better if full inner class functionality was implemented as it= =20 has a wider spectrum of uses. Even this limited possibility would be very= =20 useful though as it is one of the more common patterns and furthermore the only pattern where the inner class would perform better than a=20 non-inner class with an explicit "outer" pointer sent to the constructor.= =20 This performance gain is what CONTAINING_RECORD, offsetof and -PMV is=20 trying to reach at, resulting in rather ugly code in all cases. One problem would be that the compiler would have to check that no illegal= =20 instances are created. One simple trick would be to mandate that such=20 classes are private but I think that it should be possible to do the check= =20 while parsing the class head. Well, if the code bodies were in a cpp file= =20 this would not be possible, so a naive implementation would only get a link error (providing the use of x creates= =20 a name mangling change). This indicates that a "inner" keyword is necessary= =20 (I hoped to get away without one). This may be just as well if an extension= =20 to full inner classes is on the longer term agenda. Den s=C3=B6ndagen den 7:e september 2014 kl. 01:02:42 UTC+2 skrev Richard S= mith: > > On 6 Sep 2014 15:59, "Richard Smith" >= =20 > wrote: > > > > On 6 Sep 2014 01:13, "Bengt Gustafsson" > wrote: > > > > > > To me it seems that the logical extension would be to allow casting o= f=20 > a data member pointer to int to reveal the offset it represents. Isn't th= is=20 > what we're trying to accomplish anyway? > > > > I think we're trying to capture a higher level notion than that. > > > > > Or is the task at hand to get the offset of a member in class A as it= =20 > would be if refferred to via a pointer to class B where virtual and=20 > multiple inheritance complicates matters? > > > > > > I still think that the unary minus on a PMV is wierd as it can't be= =20 > used "for real" only in offset calculations. > > > > What do you mean by "for real"? You would be able to do this: > > > > struct A { > > int n; > > } a; > > int *p =3D &a.n; > > A *pa =3D p->* -&A::n; // pa =3D=3D &a > > Err, A *pa =3D &p->*-&A::n; > > > ... which is as "for real" as any existing use of member pointers, as= =20 > far as I can see. > > > > > If the target for all this is the CONTAINING_RECORD use case, (which= =20 > Itoo have used at times to save an unnecessary indirection level),=20 > wouldn't it be more appropriate to revisit the inner classes discussion,= =20 > maybe starting out with this particular use case. I see some parallels wi= th=20 > lambda capture, an inner class being a little to its outer class as a=20 > lambda is to its containing function. > > > > I don't think that inner classes are relevant here; they're about havin= g=20 > an independent object at an independent address that intrinsically has an= =20 > implicit reference to its parent. This is about having a nested object th= at=20 > is extrinsically known to be at a fixed offset within its parent and bein= g=20 > able to navigate between the two in either direction. > > > > > You received this message because you are subscribed to the Google=20 > Groups "ISO C++ Standard - Future Proposals" group. > > > To unsubscribe from this group and stop receiving emails from it, sen= d=20 > an email to std-proposal...@isocpp.org . > > > To post to this group, send email to std-pr...@isocpp.org=20 > . > > > Visit this group at=20 > http://groups.google.com/a/isocpp.org/group/std-proposals/. > =20 --=20 ---=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. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa= ls/. ------=_Part_518_1169443003.1410130646690 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Inner classes: If the only instance of the inner class is = by value in its outer class then we could accomplish accessing the outer cl= ass's members without any coding:

class Outer {
    int x;

    class Inner {=
        void f() {
    &= nbsp;       int y =3D x; // This is assigning from Outer's x= ..
        }
    } m_inner= ;
};

This is why I ment by "startin= g out with this particular case", i.e. that it would be nice if this worked= .. Of course, once you start creating instances of Inner that are not by val= ue you'd have to
handle the hidden pointer issues, which is the s= ticky part, I assume. It would be possible to state in the standard that "n= ested classes can access outer class' members if the only instances are by = value in the outer class." which would make code above legal.
I understand that this is creating another special case so it w= ould be of course even better if full inner class functionality was impleme= nted as it has a wider spectrum of uses. Even this limited possibility woul= d be very useful though as it is one of the more common patterns and furthe= rmore
the only pattern where the inner class would perform better= than a non-inner class with an explicit "outer" pointer sent to the constr= uctor. This performance gain is what  CONTAINING_RECORD, offsetof and -PMV is trying= to reach at, resulting in rather ugly code in all cases.
=
One problem would be that the compiler would have to check t= hat no illegal instances are created. One simple trick would be to mandate = that such classes are private but I think that it should be possible to do = the check while parsing the class head. Well, if the code bodies were in a = cpp file this would not be possible, so a naive
implementation wo= uld only get a link error (providing the use of x creates a name mangling c= hange). This indicates that a "inner" keyword is necessary (I hoped to get = away without one). This may be just as well if an extension to full inner c= lasses is on the longer term agenda.


Den s=C3=B6ndagen de= n 7:e september 2014 kl. 01:02:42 UTC+2 skrev Richard Smith:

On 6 Sep 2014 15:59, "Richard = Smith" <ric...@metafoo.co.uk&g= t; wrote:
>
> On 6 Sep 2014 01:13, "Bengt Gustafsson" <bengt.gu...@beamways.com> wrote:
> >
> > To me it seems that the logical extension would be to allow casti= ng of a data member pointer to int to reveal the offset it represents. Isn'= t this what we're trying to accomplish anyway?
>
> I think we're trying to capture a higher level notion than that.
>
> > Or is the task at hand to get the offset of a member in class A a= s it would be if refferred to via a pointer to class B where virtual and mu= ltiple inheritance complicates matters?
> >
> > I still think that the unary minus on a PMV is wierd as it can't = be used "for real" only in offset calculations.
>
> What do you mean by "for real"? You would be able to do this:
>
> struct A {
>   int n;
> } a;
> int *p =3D &a.n;
> A *pa =3D p->* -&A::n; // pa =3D=3D &a

Err, A *pa =3D &p->*-&A::n;

> ... which is as "for real" as any existing use of membe= r pointers, as far as I can see.
>
> > If the target for all this is the CONTAINING_RECORD use= case, (which Itoo  have used at times to save an unnecessary indirect= ion level), wouldn't it be more appropriate to revisit the inner classes di= scussion, maybe starting out with this particular use case. I see some para= llels with lambda capture, an inner class being a little to its outer class= as a lambda is to its containing function.
>
> I don't think that inner classes are relevant here; they're about havi= ng an independent object at an independent address that intrinsically has a= n implicit reference to its parent. This is about having a nested object th= at is extrinsically known to be at a fixed offset within its parent and bei= ng able to navigate between the two in either direction.
>
> > You received this message because you are subscribed to the Googl= e Groups "ISO C++ Standard - Future Proposals" group.
> > To unsubscribe from this group and stop receiving emails from it,= send an email to std-proposal...@isocpp.org.
> > To post to this group, send email to std-pr...@isocpp.org.
> > Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
------=_Part_518_1169443003.1410130646690-- .