Topic: pointer to member of class C of type reference to T
Author: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Thu, 13 Mar 2014 07:39:41 -0700 (PDT)
Raw View
------=_Part_489_25797324.1394721581790
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Currently:
struct C
{
int v;
int& r;
};
int C::* pmv =3D &C::v; // OK
int& C::* pmr =3D &C::r; // ERROR
error: cannot declare pointer to =E2=80=98int&=E2=80=99
error: cannot create pointer to reference member =E2=80=98C::r=E2=80=99
One of the things we want to do in SG7 reflection is to provide=20
pointer-to-members to each non-static data member of a class type.
This doesn't work for data members of reference type. (Consequently, my=20
current design has class types with reference data members ill-formed for=
=20
reflection, leaving room for a future solution.)
I am considering proposing the introduction of the family of types "pointer=
=20
to member of class C of type reference to T" and removal of the following=
=20
requirement:
[dcl.mptr]/3 A pointer to member shall not point to a member with reference=
=20
type
This would mean that:
int& C::* pmr =3D &C::r; // OK
My questions are:
Why was this family of types prohibited in the first place?
What are the ramifications in the rest of the language, and for=20
implementations, of introducing them?
Thanks,
Andrew.
--=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_489_25797324.1394721581790
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Currently:<div><font face=3D"courier new, monospace"><br><=
/font></div><div><div><font face=3D"courier new, monospace"> s=
truct C</font></div><div><font face=3D"courier new, monospace">  =
; {</font></div><div><font face=3D"courier new, monospace"> &n=
bsp; int v;</font></div><div><font face=3D"courier new, monospace">&=
nbsp; int& r;</font></div><div><font face=3D"couri=
er new, monospace"> };</font></div><div><font face=3D"courier =
new, monospace"><br></font></div><div><font face=3D"courier new, monospace"=
> int C::* pmv =3D &C::v; // OK</font></div><div><font fac=
e=3D"courier new, monospace"> int& C::* pmr =3D &C::r;=
// ERROR</font></div></div><div><br></div><div><font face=3D"courier new, =
monospace"> error: cannot declare pointer to =E2=80=98int&=
=E2=80=99<br></font></div><div><font face=3D"courier new, monospace"> =
error: cannot create pointer to reference member =E2=80=98C::r=E2=
=80=99<br></font></div><div><br></div><div>One of the things we want to do =
in SG7 reflection is to provide pointer-to-members to each non-static data =
member of a class type.</div><div><br></div><div>This doesn't work for data=
members of reference type. (Consequently, my current design has clas=
s types with reference data members ill-formed for reflection, leaving room=
for a future solution.)</div><div><br></div><div>I am considering proposin=
g the introduction of the family of types "pointer to member of class C of =
type reference to T" and removal of the following requirement:</div><div><b=
r></div><div><div>[dcl.mptr]/3 A pointer to member shall not point to a mem=
ber with reference type</div><div><br></div></div><div>This would mean that=
:</div><div><br></div><div><div><font face=3D"courier new, monospace"> =
; int& C::* pmr =3D &C::r; // OK</font></div></div><div><fon=
t face=3D"courier new, monospace"><br></font></div><div><font face=3D"arial=
, sans-serif">My questions are:</font></div><div><font face=3D"arial, sans-=
serif"><br></font></div><div><font face=3D"arial, sans-serif">Why was this =
family of types prohibited in the first place?</font></div><div><font face=
=3D"arial, sans-serif"><br></font></div><div><font face=3D"arial, sans-seri=
f">What are the ramifications in the rest of the language, and for implemen=
tations, of introducing them?</font></div><div><font face=3D"arial, sans-se=
rif"><br></font></div><div><font face=3D"arial, sans-serif">Thanks,</font><=
/div><div><font face=3D"arial, sans-serif">Andrew.</font></div><div><font f=
ace=3D"arial, sans-serif"><br></font></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_489_25797324.1394721581790--
.
Author: =?ISO-8859-1?Q?David_Rodr=EDguez_Ibeas?= <dibeas@ieee.org>
Date: Thu, 13 Mar 2014 10:55:50 -0400
Raw View
--001a11c0e088369a5304f47e2616
Content-Type: text/plain; charset=ISO-8859-1
I imagine that the reason is that after initialization, a reference is
designed to be an alias. All of the operations applied to the "reference"
are really applied to the referred type.
How would you want to use 'pmr' in code? What should 'C(x).*pmr' represent,
the reference? the referred object? What operations could be done through
the application of that member pointer to an object?
On Thu, Mar 13, 2014 at 10:39 AM, Andrew Tomazos <andrewtomazos@gmail.com>wrote:
> Currently:
>
> struct C
> {
> int v;
> int& r;
> };
>
> int C::* pmv = &C::v; // OK
> int& C::* pmr = &C::r; // ERROR
>
> error: cannot declare pointer to 'int&'
> error: cannot create pointer to reference member 'C::r'
>
> One of the things we want to do in SG7 reflection is to provide
> pointer-to-members to each non-static data member of a class type.
>
> This doesn't work for data members of reference type. (Consequently, my
> current design has class types with reference data members ill-formed for
> reflection, leaving room for a future solution.)
>
> I am considering proposing the introduction of the family of types
> "pointer to member of class C of type reference to T" and removal of the
> following requirement:
>
> [dcl.mptr]/3 A pointer to member shall not point to a member with
> reference type
>
> This would mean that:
>
> int& C::* pmr = &C::r; // OK
>
> My questions are:
>
> Why was this family of types prohibited in the first place?
>
> What are the ramifications in the rest of the language, and for
> implementations, of introducing them?
>
> Thanks,
> Andrew.
>
> --
>
> ---
> 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.
> 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 "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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a11c0e088369a5304f47e2616
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I imagine that the reason is that after initialization, a =
reference is designed to be an alias. All of the operations applied to the =
"reference" are really applied to the referred type.<br><br>How w=
ould you want to use 'pmr' in code? What should 'C(x).*pmr'=
represent, the reference? the referred object? What operations could be do=
ne through the application of that member pointer to an object?<br>
</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Thu,=
Mar 13, 2014 at 10:39 AM, Andrew Tomazos <span dir=3D"ltr"><<a href=3D"=
mailto:andrewtomazos@gmail.com" target=3D"_blank">andrewtomazos@gmail.com</=
a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Currently:<div><font face=
=3D"courier new, monospace"><br></font></div><div><div><font face=3D"courie=
r new, monospace"> struct C</font></div>
<div><font face=3D"courier new, monospace"> {</font></div><div=
><font face=3D"courier new, monospace"> int v;</=
font></div><div><font face=3D"courier new, monospace"> =
int& r;</font></div><div><font face=3D"courier new, monospace">&=
nbsp; };</font></div>
<div><font face=3D"courier new, monospace"><br></font></div><div><font face=
=3D"courier new, monospace"> int C::* pmv =3D &C::v; // OK=
</font></div><div><font face=3D"courier new, monospace"> int&a=
mp; C::* pmr =3D &C::r; // ERROR</font></div>
</div><div><br></div><div><font face=3D"courier new, monospace"> &nbs=
p; error: cannot declare pointer to ‘int&’<br></font></div>=
<div><font face=3D"courier new, monospace"> error: cannot crea=
te pointer to reference member ‘C::r’<br>
</font></div><div><br></div><div>One of the things we want to do in SG7 ref=
lection is to provide pointer-to-members to each non-static data member of =
a class type.</div><div><br></div><div>This doesn't work for data membe=
rs of reference type. (Consequently, my current design has class type=
s with reference data members ill-formed for reflection, leaving room for a=
future solution.)</div>
<div><br></div><div>I am considering proposing the introduction of the fami=
ly of types "pointer to member of class C of type reference to T"=
and removal of the following requirement:</div><div><br></div><div><div>
[dcl.mptr]/3 A pointer to member shall not point to a member with reference=
type</div><div><br></div></div><div>This would mean that:</div><div><br></=
div><div><div><font face=3D"courier new, monospace"> int& =
C::* pmr =3D &C::r; // OK</font></div>
</div><div><font face=3D"courier new, monospace"><br></font></div><div><fon=
t face=3D"arial, sans-serif">My questions are:</font></div><div><font face=
=3D"arial, sans-serif"><br></font></div><div><font face=3D"arial, sans-seri=
f">Why was this family of types prohibited in the first place?</font></div>
<div><font face=3D"arial, sans-serif"><br></font></div><div><font face=3D"a=
rial, sans-serif">What are the ramifications in the rest of the language, a=
nd for implementations, of introducing them?</font></div><div><font face=3D=
"arial, sans-serif"><br>
</font></div><div><font face=3D"arial, sans-serif">Thanks,</font></div><div=
><font face=3D"arial, sans-serif">Andrew.</font></div><span class=3D"HOEnZb=
"><font color=3D"#888888"><div><font face=3D"arial, sans-serif"><br></font>=
</div>
</font></span></div><span class=3D"HOEnZb"><font color=3D"#888888">
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</font></span></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a11c0e088369a5304f47e2616--
.
Author: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Thu, 13 Mar 2014 08:33:45 -0700 (PDT)
Raw View
------=_Part_525_11505506.1394724825318
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Thursday, March 13, 2014 3:55:50 PM UTC+1, David Rodr=C3=ADguez Ibeas wr=
ote:
>
> I imagine that the reason is that after initialization, a reference is=20
> designed to be an alias. All of the operations applied to the "reference"=
=20
> are really applied to the referred type.
>
> How would you want to use 'pmr' in code? What should 'C(x).*pmr'=20
> represent, the reference? the referred object? What operations could be=
=20
> done through the application of that member pointer to an object?
>
The expression C(x).*pmr would be an lvalue of type int. The same as the=
=20
id-expression r, where r is declared int& r =3D .... As per [expr]/5:
If an expression initially has the type =E2=80=9Creference to T=E2=80=9D (8=
..3.2, 8.5.3),=20
the type is adjusted to T prior to
any further analysis. The expression designates the object or function=20
denoted by the reference, and the
expression is an lvalue or an xvalue, depending on the expression.
Apart from application of the pointer-to-member operators, an identifier of=
=20
type "pointer to member of class C of type reference to T" could be the=20
subject of decltype or participate in type deduction. This allows an=20
application of reflection to differentiate between a data member of type=20
reference to T and a data member of non-reference type T, and take=20
appropriate action for the application.
--=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_525_11505506.1394724825318
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thursday, March 13, 2014 3:55:50 PM UTC+1, David Rodr=
=C3=ADguez Ibeas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, =
204); border-left-style: solid; padding-left: 1ex;"><div dir=3D"ltr">I imag=
ine that the reason is that after initialization, a reference is designed t=
o be an alias. All of the operations applied to the "reference" are really =
applied to the referred type.<br><br>How would you want to use 'pmr' in cod=
e? What should 'C(x).*pmr' represent, the reference? the referred object? W=
hat operations could be done through the application of that member pointer=
to an object?</div></blockquote><div><br></div><div>The expression <f=
ont face=3D"courier new, monospace">C(x).*pmr</font> would be an lvalu=
e of type int. The same as the id-expression <font face=3D"couri=
er new, monospace">r,</font> where <font face=3D"courier new, mon=
ospace">r</font> is declared <font face=3D"courier new, monospace=
">int& r =3D ...</font>. As per [expr]/5:</div><div><br></div><bl=
ockquote style=3D"margin: 0px 0px 0px 40px; border: none; padding: 0px;"><d=
iv>If an expression initially has the type =E2=80=9Creference to T=E2=80=9D=
(8.3.2, 8.5.3), the type is adjusted to T prior to</div><div>any further a=
nalysis. The expression designates the object or function denoted by the re=
ference, and the</div><div>expression is an lvalue or an xvalue, depending =
on the expression.</div></blockquote><div><br></div><div>Apart from applica=
tion of the pointer-to-member operators, an identifier of type "pointer to =
member of class C of type reference to T" could be the subject of <fon=
t face=3D"courier new, monospace">decltype </font><font face=3D"arial,=
sans-serif">or participate in type deduction</font><font face=3D"courier n=
ew, monospace">. </font><font face=3D"arial, sans-serif">This allows =
an application of reflection to differentiate between a data member of type=
reference to T and a data member of non-reference type T, and take appropr=
iate action for the application.</font></div><div><font face=3D"arial, sans=
-serif"><br></font></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_525_11505506.1394724825318--
.
Author: Cleiton Santoia <cleitonsantoia@gmail.com>
Date: Thu, 13 Mar 2014 14:17:24 -0700 (PDT)
Raw View
------=_Part_2103_10273440.1394745444322
Content-Type: text/plain; charset=UTF-8
We got the same problem on N3951 as Tiago Macieira pointed and remains the
doubt why "int& X::*" not allowed ? I think i should have a const
somewhere, since you cannot reassign the refererence. But other than that
references are pointer in disguise.
>
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_2103_10273440.1394745444322
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>We got the same problem on N3951 as Tiago Macieira po=
inted and remains the doubt why "int& X::*" not allowed ? I think i sho=
uld have a const somewhere, since you cannot reassign the refererence. But =
other than that references are pointer in disguise.</div><div><br></div><di=
v><br></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr"><div><font face=3D"arial, sans-serif"> </font></div></di=
v></blockquote></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_2103_10273440.1394745444322--
.
Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Thu, 13 Mar 2014 18:16:44 -0400
Raw View
On 2014-03-13 17:39, Richard Smith wrote:
> On Thu, Mar 13, 2014 at 2:17 PM, Cleiton Santoia wrote:
>> references are pointer in disguise.
>
> No, they aren't (no matter how any particular implementation chooses to
> represent them). A reference isn't required to occupy storage or have an
> address (see 8.3.2/4). For instance, given:
>
> int n;
> struct X {
> X() {}
> int &r = n;
> };
>
> ... an implementation could choose to not allocate any storage for the 'r'
> member in X, and instead rewrite all uses of it to directly reference ::n.
That's such an interesting thought that I'd like to offer a real example:
class Data
{
public:
T const& value = mutable_value;
protected:
T mutable_value;
};
What we have there is a class with a member variable which should be
public but can only be mutated by the class itself or subclasses. The
above is a simplification from an actual project of mine.
I'd love to hope that the compiler is clever enough to rewrite all
accesses to 'value' as accesses of mutable_value directly. Although I
suspect it can't, as a ctor in some TU could bind something else to the
reference. (Maybe if all of the ctors are inline?)
The "problem" w.r.t. class members is that the language allows for the
value to which the reference is bound to be determined by run time
conditions, which makes it difficult for the compiler to treat them as
other than pointers. (And strengthens the case for taking addresses of
the same, at least for non-static class members, if not references in
general.)
--
Matthew
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Thu, 13 Mar 2014 16:06:00 -0700 (PDT)
Raw View
------=_Part_2456_27506782.1394751960541
Content-Type: text/plain; charset=UTF-8
On Thursday, March 13, 2014 11:16:44 PM UTC+1, Matthew Woehlke wrote:
>
> That's such an interesting thought that I'd like to offer a real example:
>
> class Data
> {
> public:
> T const& value = mutable_value;
>
> protected:
> T mutable_value;
> };
>
> What we have there is a class with a member variable which should be
> public but can only be mutated by the class itself or subclasses. The
> above is a simplification from an actual project of mine.
>
The copy constructor of Data will bind the reference to the sources
mutable_value, and not its own. This is probably not what you want. You
should use a function returning a reference instead:
class Data
{
public:
T const& value() { return mutable_value; }
protected:
T mutable_value;
};
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_2456_27506782.1394751960541
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thursday, March 13, 2014 11:16:44 PM UTC+1, Matthew Woe=
hlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">That's such an inte=
resting thought that I'd like to offer a real example:
<br>
<br> class Data
<br> {
<br> public:
<br> T const& value =3D mutable_value;
<br>
<br> protected:
<br> T mutable_value;
<br> };
<br>
<br>What we have there is a class with a member variable which should be=20
<br>public but can only be mutated by the class itself or subclasses. The=
=20
<br>above is a simplification from an actual project of mine.
<br></blockquote><div><br></div><div>The copy constructor of Data will bind=
the reference to the sources mutable_value, and not its own. This is=
probably not what you want. You should use a function returning a re=
ference instead:<br></div><div><br></div><div> class Data =
<br></div><div> { <br> public: <br> =
T const& value() { return mutable_value; }<br=
><br> protected: <br> T mutable_=
value; <br> }; <br></div><div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_2456_27506782.1394751960541--
.
Author: David Krauss <potswa@gmail.com>
Date: Fri, 14 Mar 2014 10:42:08 +0800
Raw View
On 2014-03-14, at 5:39 AM, Richard Smith <richard@metafoo.co.uk> wrote:
> ... an implementation could choose to not allocate any storage for the 'r=
' member in X, and instead rewrite all uses of it to directly reference ::n=
..
>=20
> That said, as far as I'm aware no implementation does anything remotely l=
ike this for class members of reference type, and in practice this extensio=
n seems feasible (even though it weakens the conceptual model for reference=
s).
The optimization involves adjusting a class layout and sidestepping the ABI=
, so it's a whole-program optimization. This is an area of active developme=
nt. It would be a shame to cut it off for a feature as obscure and unessent=
ial as pointer-to-members.
Also, lambda captures by reference may be implemented by copying only the f=
rame pointer and accessing the referenced variables relative to it, as "loc=
als." This allows unlimited captures within pass-by-register calling conven=
tions. This might still work in the presence of pointers to reference membe=
rs, but it would be a divergence.
Why not just model the pointer to member reference as a hidden member funct=
ion? I don't know whether it's worthwhile to add this to the type system as=
a member reference pointer, or just to let it appear as a member function,=
PTMF, or functor.
The conceptual decay alone is concerning. If we have pointer to reference m=
embers, why not pointers to other references? References are not objects.
--=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/.
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Thu, 13 Mar 2014 20:08:52 -0700
Raw View
--047d7bdc9e02b1eb8104f48863c7
Content-Type: text/plain; charset=ISO-8859-1
On Thu, Mar 13, 2014 at 7:42 PM, David Krauss <potswa@gmail.com> wrote:
>
> On 2014-03-14, at 5:39 AM, Richard Smith <richard@metafoo.co.uk> wrote:
>
> > ... an implementation could choose to not allocate any storage for the
> 'r' member in X, and instead rewrite all uses of it to directly reference
> ::n.
> >
> > That said, as far as I'm aware no implementation does anything remotely
> like this for class members of reference type, and in practice this
> extension seems feasible (even though it weakens the conceptual model for
> references).
>
> The optimization involves adjusting a class layout and sidestepping the
> ABI, so it's a whole-program optimization. This is an area of active
> development. It would be a shame to cut it off for a feature as obscure and
> unessential as pointer-to-members.
>
I don't really agree. A whole-program optimizer doesn't really need to care
about the language rules here; it can do the same transformation under
as-if, if the reference member is never accessed via a pointer-to-member
(and it should be able to do the same thing for members of any type,
reference or not).
The example I gave didn't require any whole-program optimization; an ABI
could incorporate a rule to remove the reference member in the case I gave,
but none of the existing ABIs are crazy enough to do so.
Also, lambda captures by reference may be implemented by copying only the
> frame pointer and accessing the referenced variables relative to it, as
> "locals." This allows unlimited captures within pass-by-register calling
> conventions. This might still work in the presence of pointers to reference
> members, but it would be a divergence.
>
I don't immediately see that pointers-to-members have any impact here --
it's not possible to form a pointer-to-member to a lambda capture. Doubly
not for reference captures, where there is not even any guarantee that
there *is* a reference member.
Also, this lambda reference capture optimization is mostly only theoretical
-- for instance, lambda layout is already part of the ABI in various ways,
and is becoming increasingly so (due to deduced return types), and an ABI
is unlikely to specify stack layout for local variables.
Why not just model the pointer to member reference as a hidden member
> function? I don't know whether it's worthwhile to add this to the type
> system as a member reference pointer, or just to let it appear as a member
> function, PTMF, or functor.
>
> The conceptual decay alone is concerning. If we have pointer to reference
> members, why not pointers to other references? References are not objects.
Conversely, pointers-to-members are not pointers, and don't refer to
storage, so having a pointer-to-member to a reference member isn't
obviously a problem. If you view a pointer-to-data-member as though it
implicitly generated a wrapper function performing member access (the kind
of function you describe above), there is no theoretical problem with
forming a pointer to a data member.
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--047d7bdc9e02b1eb8104f48863c7
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Mar 13, 2014 at 7:42 PM, David Krauss <span dir=3D"ltr"><<a href=3D"=
mailto:potswa@gmail.com" target=3D"_blank">potswa@gmail.com</a>></span> =
wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D""><br>
On 2014-03-14, at 5:39 AM, Richard Smith <<a href=3D"mailto:richard@meta=
foo.co.uk">richard@metafoo.co.uk</a>> wrote:<br>
<br>
> ... an implementation could choose to not allocate any storage for the=
'r' member in X, and instead rewrite all uses of it to directly re=
ference ::n.<br>
><br>
> That said, as far as I'm aware no implementation does anything rem=
otely like this for class members of reference type, and in practice this e=
xtension seems feasible (even though it weakens the conceptual model for re=
ferences).<br>
<br>
</div>The optimization involves adjusting a class layout and sidestepping t=
he ABI, so it's a whole-program optimization. This is an area of active=
development. It would be a shame to cut it off for a feature as obscure an=
d unessential as pointer-to-members.<br>
</blockquote><div><br></div><div>I don't really agree. A whole-program =
optimizer doesn't really need to care about the language rules here; it=
can do the same transformation under as-if, if the reference member is nev=
er accessed via a pointer-to-member (and it should be able to do the same t=
hing for members of any type, reference or not).</div>
<div><br></div><div>The example I gave didn't require any whole-program=
optimization; an ABI could incorporate a rule to remove the reference memb=
er in the case I gave, but none of the existing ABIs are crazy enough to do=
so.</div>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex">
Also, lambda captures by reference may be implemented by copying only the f=
rame pointer and accessing the referenced variables relative to it, as &quo=
t;locals." This allows unlimited captures within pass-by-register call=
ing conventions. This might still work in the presence of pointers to refer=
ence members, but it would be a divergence.<br>
</blockquote><div><br></div><div>I don't immediately see that pointers-=
to-members have any impact here -- it's not possible to form a pointer-=
to-member to a lambda capture. Doubly not for reference captures, where the=
re is not even any guarantee that there *is* a reference member.</div>
<div><br></div><div>Also, this lambda reference capture optimization is mos=
tly only theoretical -- for instance, lambda layout is already part of the =
ABI in various ways, and is becoming increasingly so (due to deduced return=
types), and an ABI is unlikely to specify stack layout for local variables=
..</div>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex">
Why not just model the pointer to member reference as a hidden member funct=
ion? I don't know whether it's worthwhile to add this to the type s=
ystem as a member reference pointer, or just to let it appear as a member f=
unction, PTMF, or functor.<br>
<br>
The conceptual decay alone is concerning. If we have pointer to reference m=
embers, why not pointers to other references? References are not objects.</=
blockquote><div><br></div><div>Conversely, pointers-to-members are not poin=
ters, and don't refer to storage, so having a pointer-to-member to a re=
ference member isn't obviously a problem. If you view a pointer-to-data=
-member as though it implicitly generated a wrapper function performing mem=
ber access (the kind of function you describe above), there is no theoretic=
al problem with forming a pointer to a data member.</div>
</div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--047d7bdc9e02b1eb8104f48863c7--
.
Author: Christian Kaeser <christiankaeser87@googlemail.com>
Date: Fri, 14 Mar 2014 06:45:56 -0700 (PDT)
Raw View
------=_Part_2999_2841395.1394804756477
Content-Type: text/plain; charset=UTF-8
On Friday, 14 March 2014 04:08:52 UTC+1, Richard Smith wrote:
> Why not just model the pointer to member reference as a hidden member
>> function? I don't know whether it's worthwhile to add this to the type
>> system as a member reference pointer, or just to let it appear as a member
>> function, PTMF, or functor.
>>
>> The conceptual decay alone is concerning. If we have pointer to reference
>> members, why not pointers to other references? References are not objects.
>
>
> Conversely, pointers-to-members are not pointers, and don't refer to
> storage, so having a pointer-to-member to a reference member isn't
> obviously a problem. If you view a pointer-to-data-member as though it
> implicitly generated a wrapper function performing member access (the kind
> of function you describe above), there is no theoretical problem with
> forming a pointer to a data member.
>
One other problem area are bit-fields, which also currently can not be
referred to by a pointer-to-member.
I think that any pointer-to-member extension should also look into that
case, as it poses a similar problem for reflection (although bit-fields
could be argued to be a lot rarer than reference fields).
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_2999_2841395.1394804756477
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, 14 March 2014 04:08:52 UTC+1, Richard Smith wr=
ote:<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>=
<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Why not just model the pointer to member reference as a hidden member funct=
ion? I don't know whether it's worthwhile to add this to the type system as=
a member reference pointer, or just to let it appear as a member function,=
PTMF, or functor.<br>
<br>
The conceptual decay alone is concerning. If we have pointer to reference m=
embers, why not pointers to other references? References are not objects.</=
blockquote><div><br></div><div>Conversely, pointers-to-members are not poin=
ters, and don't refer to storage, so having a pointer-to-member to a refere=
nce member isn't obviously a problem. If you view a pointer-to-data-member =
as though it implicitly generated a wrapper function performing member acce=
ss (the kind of function you describe above), there is no theoretical probl=
em with forming a pointer to a data member.</div></div></div></div></blockq=
uote><div><br>One other problem area are bit-fields, which also currently c=
an not be referred to by a pointer-to-member. <br>I think that any pointer-=
to-member extension should also look into that case, as it poses a similar =
problem for reflection (although bit-fields could be argued to be a lot rar=
er than reference fields).<br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_2999_2841395.1394804756477--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Fri, 14 Mar 2014 08:57:53 -0700
Raw View
Em sex 14 mar 2014, =E0s 06:45:56, Christian Kaeser escreveu:
> One other problem area are bit-fields, which also currently can not be=20
> referred to by a pointer-to-member.=20
> I think that any pointer-to-member extension should also look into that=
=20
> case, as it poses a similar problem for reflection (although bit-fields=
=20
> could be argued to be a lot rarer than reference fields).
But if we're talking about the use-case of reflection, bitfields and refere=
nces=20
can be wrapped by a class in std::.
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--=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/.
.
Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Fri, 14 Mar 2014 12:04:35 -0400
Raw View
On 2014-03-13 19:06, Andrew Tomazos wrote:
> On Thursday, March 13, 2014 11:16:44 PM UTC+1, Matthew Woehlke wrote:
>>
>> That's such an interesting thought that I'd like to offer a real example:
>>
>> class Data
>> {
>> public:
>> T const& value = mutable_value;
>>
>> protected:
>> T mutable_value;
>> };
>>
>> What we have there is a class with a member variable which should be
>> public but can only be mutated by the class itself or subclasses. The
>> above is a simplification from an actual project of mine.
>>
>
> The copy constructor of Data will bind the reference to the sources
> mutable_value, and not its own.
Given a default ctor, yes, that would make sense. Would an explicit copy
ctor do that, though? (I would think not?)
(It occurred to me that what I "really" want is e.g. 'public: using m_v
= const m_mv'...)
--
Matthew
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: David Krauss <potswa@gmail.com>
Date: Sat, 15 Mar 2014 00:37:52 +0800
Raw View
On 2014-03-14, at 11:08 AM, Richard Smith <richard@metafoo.co.uk> wrote:
> I don't really agree. A whole-program optimizer doesn't really need to ca=
re about the language rules here; it can do the same transformation under a=
s-if, if the reference member is never accessed via a pointer-to-member (an=
d it should be able to do the same thing for members of any type, reference=
or not).
Yeah... you're right on all accounts.
No matter how the implementation handles references, it can handle pointer =
to reference members the same way. If the reference is actually a function,=
then so is the pointer to member reference.
I do have an idea for references that capture an initializer and re-evaluat=
e it at each use. As members, these would need to be implemented as functio=
ns, so that is the only model that would work for forming pointer-to-member=
s to them. Perhaps now is the last chance to pursue that.
> The example I gave didn't require any whole-program optimization; an ABI =
could incorporate a rule to remove the reference member in the case I gave,=
but none of the existing ABIs are crazy enough to do so.
Doing this with an ABI, as opposed to a whole program optimization which ac=
tivates when the ABI doesn't apply, would still require allocating a storag=
e slot in the class if the layout cannot depend on the initializer. (For mi=
nimal sanity and/or applicability.) But even then, it should still save an =
indirection.
I'd like to try, at some point :) . Actually, it could perhaps be done as a=
somewhat compatible extension, preserving existing libraries that use refe=
rences internally but do not access reference members of classes defined in=
the new ABI.
--=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/.
.
Author: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Thu, 13 Mar 2014 08:20:45 -0700 (PDT)
Raw View
------=_Part_396_22584532.1394724045131
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Thursday, March 13, 2014 3:55:50 PM UTC+1, David Rodr=C3=ADguez Ibeas wr=
ote:
>
> I imagine that the reason is that after initialization, a reference is=20
> designed to be an alias. All of the operations applied to the "reference"=
=20
> are really applied to the referred type.
>
> How would you want to use 'pmr' in code? What should 'C(x).*pmr'=20
> represent, the reference? the referred object? What operations could be=
=20
> done through the application of that member pointer to an object?
>
The expression C(x).*pmr would be an lvalue of type int. The same as the=
=20
id-expression r, where r is declared int& r =3D .... As per [expr]/5:
If an expression initially has the type =E2=80=9Creference to T=E2=80=9D (8=
..3.2, 8.5.3),=20
the type is adjusted to T prior to
any further analysis. The expression designates the object or function=20
denoted by the reference, and the
expression is an lvalue or an xvalue, depending on the expression.
Apart from application of the pointer-to-member operators, an identifier of=
=20
type "pointer to member of class C of type reference to T" could be the=20
subject of decltype or participate in type deduction. This allows an=20
application of reflection to differentiate between a data member of type=20
reference to T and a data member of non-reference type T, and take=20
appropriate action for the application.
--=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_396_22584532.1394724045131
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thursday, March 13, 2014 3:55:50 PM UTC+1, David Rodr=
=C3=ADguez Ibeas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div di=
r=3D"ltr">I imagine that the reason is that after initialization, a referen=
ce is designed to be an alias. All of the operations applied to the "refere=
nce" are really applied to the referred type.<br><br>How would you want to =
use 'pmr' in code? What should 'C(x).*pmr' represent, the reference? the re=
ferred object? What operations could be done through the application of tha=
t member pointer to an object?</div></blockquote><div><br></div><div>The ex=
pression <font face=3D"courier new, monospace">C(x).*pmr</font> would =
be an lvalue of type int. The same as the id-expression <font face=3D=
"courier new, monospace">r,</font> where <font face=3D"courier new, mo=
nospace">r</font> is declared <font face=3D"courier new, monospace">in=
t& r =3D ...</font>. As per [expr]/5:</div><div><br></div><blockq=
uote style=3D"margin: 0 0 0 40px; border: none; padding: 0px;"><div>If an e=
xpression initially has the type =E2=80=9Creference to T=E2=80=9D (8.3.2, 8=
..5.3), the type is adjusted to T prior to</div><div>any further analysis. T=
he expression designates the object or function denoted by the reference, a=
nd the</div><div>expression is an lvalue or an xvalue, depending on the exp=
ression.</div></blockquote><div><br></div><div>Apart from application of th=
e pointer-to-member operators, an identifier of type "pointer to member of =
class C of type reference to T" could be the subject of <font face=3D"couri=
er new, monospace">decltype </font><font face=3D"arial, sans-serif">or=
participate in type deduction</font><font face=3D"courier new, monospace">=
.. </font><font face=3D"arial, sans-serif">This allows an application =
of reflection to differentiate between a data member of type reference to T=
and a data member of non-reference type T, and take appropriate action for=
the application.</font></div><div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_396_22584532.1394724045131--
.