------=_Part_158_2134069775.1423820288016
Content-Type: multipart/alternative;
 boundary="----=_Part_159_38836231.1423820288016"

------=_Part_159_38836231.1423820288016
Content-Type: text/plain; charset=UTF-8

Hello everyone,

in the past few days I have started working on a proposal for a new
language feature that I call "pointers to members of unknown class".
I would like some feedback on the proposal as well as the idea itself.

https://docs.google.com/document/d/1B4zWiym1twufigKA4RSXYR5xU4g32EJ8XNl_bzFtX08/edit?usp=sharing

I have not looked into providing a standard wording yet.

Markus

--

---
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_159_38836231.1423820288016
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hello everyone,<div><br></div><div>in the past few days I =
have started working on a proposal for a new language feature that I call "=
pointers to members of unknown class".</div><div>I would like some feedback=
 on the proposal as well as the idea itself.</div><div><br></div><div><a hr=
ef=3D"https://docs.google.com/document/d/1B4zWiym1twufigKA4RSXYR5xU4g32EJ8X=
Nl_bzFtX08/edit?usp=3Dsharing">https://docs.google.com/document/d/1B4zWiym1=
twufigKA4RSXYR5xU4g32EJ8XNl_bzFtX08/edit?usp=3Dsharing</a><br></div><div><b=
r></div><div>I have not looked into providing a standard wording yet.</div>=
<div><br></div><div>Markus</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&quot; 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_159_38836231.1423820288016--
------=_Part_158_2134069775.1423820288016--

.

> On 2015=E2=80=9302=E2=80=9313, at 5:38 PM, Markus Grech <markus.grech@gma=
il.com> wrote:
>=20
> Hello everyone,
>=20
> in the past few days I have started working on a proposal for a new langu=
age feature that I call "pointers to members of unknown class".
> I would like some feedback on the proposal as well as the idea itself.

The motivation section needs to cut to the chase. Start off with something =
like,

=E2=80=9CMSVC optimizes certain member pointer types, but this is not confo=
rming as some functionality is sacrificed. The optimization should be allow=
ed by the standard. A new type is proposed to make up the difference in fun=
ctionality, which has only niche use-cases.=E2=80=9D

> I have not looked into providing a standard wording yet.

Just focus on human readability first, and completeness of your specificati=
on second. There=E2=80=99s a long way to go before it needs standardese.

--=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/.

.

--001a11354faae0e5cf050efa1657
Content-Type: text/plain; charset=UTF-8

>> This requirement - conversion from one MP to another of the same kind
and back to be well defined - implies that any two MPs of the same kind
must be of the same size.

The requirement that you mention is one of 'reinterpret_cast', although the
casts that you use in the rest of the document are 'static_cast'.  There is
an important difference there, since for the case of 'static_cast' you
don't need to change anything, it is a semantically correct cast and the
compiler can (and currently does in the case of VS) narrow/extend the value
as needed.

The requirement above is not "fixed" with the proposal, that basically
creates the equivalent of 'void*' for pointer-to-member, but does not
remove the issue (as mentioned in the "open questions").

A different solution would be to introduce a new generic
'void-pointer-to-member' kind of type and change the requirements in
'reinterpret_cast' so that the roundtrip "original-pointer-to-member ->
generic-pointer-to-member -> original-pointer-to-member" is guaranteed,
without the stricter guarantee of the intermediate step being "any" pointer
to member, and possibly leaving that alternative as implementation
defined.  This could be either a single 'generic-pointer-to-member' or two
of them, one for pointers to data members and another for pointer to member
functions. I don't think we need 'T void::*' for every possible 'T', a
single alternative:
'void void::*' [or 'auto auto::*', although this has a different meaning in
the concepts TS, IIRC, but it could also be spelled completely differently
as 'std::ptrmbr'].

The impact would be that certain programs that are now well defined (in the
standard, but would fail in VS implementation) would become "implementation
defined", which is kind of fine anyway --they will still work where they
worked before and fail where they would currently fail.

Should conversions to that generic pointer type be implicit? Not sure.
Should 'static_cast' allow the opposite conversion? Not sure either. I
don't love the idea of 'static_cast<int*>(static_cast<void*>(&i))' in the
first place, that screams "reinterpret_cast" and I believe it should be
typed as such. On the other hand the evolution of the language has moved in
the direction of strengthening that conversion sequence
'static_cast<int*>(static_cast<void*>(&aFloat))' is well defined in C++14
(although uses of the resulting pointer are a violation of the strict
aliasing rules, but what address is pointed to is guaranteed). So allowing
the conversion through 'static_cast' is just consistent with that behavior.

On the question of whether applying a PMU directly should be allowed, I
tend to fall on the safe side: I would not allow it.

One additional concern I have is that currently that the application of
unary & to qualified-id that refers to a non-static member of a class
yields a type that might not be obvious to the user [I personally would
like that changed, but could not defend N3772(*) in the committee and have
not found anyone to do it]:

struct base { int x; };
struct derived : virtual base { virtual void f(); };
PMU pmu = &derived::x; // PMU according to proposal's syntax
auto pm = static_cast<int derived::*>(pmu); // undefined behavior

The problem here is that the expression '&derived::x' is of type 'int
base::*', which is converted to the universal pointer to member 'pmu', the
immediate cast to 'int derived::*' is thus not forming a round trip, but
the equivalent of 'reinterpret_cast<int derived::*>(&base::x)' which is
most probably not going to yield anything sane.

This is not something newly introduced in this proposal, but the proposal
might make it worse in the sense that the implicit conversion from the
pointer-to-member to PMU makes it simpler to make that family of mistakes,
which currently can only be hit through 'reinterpret_cast'.

    David

[*] N3772 mistakenly misrepresents the problem with the templates making it
look like there is a workaround for the template problem where there isn't.
The first example's workaround is illegal:

struct A { int i; };
struct B : A {};
template <typename T, int T::*MPTR> struct example1 {};
example1<B, static_cast<int B::*>(&B::i)> x; // error


On Fri Feb 13 2015 at 4:38:08 AM Markus Grech <markus.grech@gmail.com>
wrote:

> Hello everyone,
>
> in the past few days I have started working on a proposal for a new
> language feature that I call "pointers to members of unknown class".
> I would like some feedback on the proposal as well as the idea itself.
>
>
> https://docs.google.com/document/d/1B4zWiym1twufigKA4RSXYR5xU4g32EJ8XNl_bzFtX08/edit?usp=sharing
>
> I have not looked into providing a standard wording yet.
>
> Markus
>
> --
>
> ---
> 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/.

--001a11354faae0e5cf050efa1657
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">&gt;&gt;=C2=A0This requirement - conversion from one MP to=
 another of the same kind and back to be well defined - implies that any tw=
o MPs of the same kind must be of the same size.<br><br>The requirement tha=
t you mention is one of &#39;reinterpret_cast&#39;, although the casts that=
 you use in the rest of the document are &#39;static_cast&#39;.=C2=A0 There=
 is an important difference there, since for the case of &#39;static_cast&#=
39; you don&#39;t need to change anything, it is a semantically correct cas=
t and the compiler can (and currently does in the case of VS) narrow/extend=
 the value as needed.<br><br>The requirement above is not &quot;fixed&quot;=
 with the proposal, that basically creates the equivalent of &#39;void*&#39=
; for pointer-to-member, but does not remove the issue (as mentioned in the=
 &quot;open questions&quot;). =C2=A0<br><br>A different solution would be t=
o introduce a new generic &#39;void-pointer-to-member&#39; kind of type and=
 change the requirements in &#39;reinterpret_cast&#39; so that the roundtri=
p &quot;original-pointer-to-member -&gt; generic-pointer-to-member -&gt; or=
iginal-pointer-to-member&quot; is guaranteed, without the stricter guarante=
e of the intermediate step being &quot;any&quot; pointer to member, and pos=
sibly leaving that alternative as implementation defined.=C2=A0 This could =
be either a single &#39;generic-pointer-to-member&#39; or two of them, one =
for pointers to data members and another for pointer to member functions. I=
 don&#39;t think we need &#39;T void::*&#39; for every possible &#39;T&#39;=
, a single alternative:<br>&#39;void void::*&#39; [or &#39;auto auto::*&#39=
;, although this has a different meaning in the concepts TS, IIRC, but it c=
ould also be spelled completely differently as &#39;std::ptrmbr&#39;].<br><=
br>The impact would be that certain programs that are now well defined (in =
the standard, but would fail in VS implementation) would become &quot;imple=
mentation defined&quot;, which is kind of fine anyway --they will still wor=
k where they worked before and fail where they would currently fail.<br><br=
>Should conversions to that generic pointer type be implicit? Not sure. Sho=
uld &#39;static_cast&#39; allow the opposite conversion? Not sure either. I=
 don&#39;t love the idea of &#39;static_cast&lt;int*&gt;(static_cast&lt;voi=
d*&gt;(&amp;i))&#39; in the first place, that screams &quot;reinterpret_cas=
t&quot; and I believe it should be typed as such. On the other hand the evo=
lution of the language has moved in the direction of strengthening that con=
version sequence &#39;static_cast&lt;int*&gt;(static_cast&lt;void*&gt;(&amp=
;aFloat))&#39; is well defined in C++14 (although uses of the resulting poi=
nter are a violation of the strict aliasing rules, but what address is poin=
ted to is guaranteed). So allowing the conversion through &#39;static_cast&=
#39; is just consistent with that behavior.<br><br>On the question of wheth=
er applying a PMU directly should be allowed, I tend to fall on the safe si=
de: I would not allow it.<br><br>One additional concern I have is that curr=
ently that the application of unary &amp; to qualified-id that refers to a =
non-static member of a class yields a type that might not be obvious to the=
 user [I personally would like that changed, but could not defend N3772(*) =
in the committee and have not found anyone to do it]:<br><br>struct base { =
int x; };<br>struct derived : virtual base { virtual void f(); };<br>PMU pm=
u =3D &amp;derived::x; // PMU according to proposal&#39;s syntax<br>auto pm=
 =3D static_cast&lt;int derived::*&gt;(pmu); // undefined behavior<br><br>T=
he problem here is that the expression &#39;&amp;derived::x&#39; is of type=
 &#39;int base::*&#39;, which is converted to the universal pointer to memb=
er &#39;pmu&#39;, the immediate cast to &#39;int derived::*&#39; is thus no=
t forming a round trip, but the equivalent of &#39;reinterpret_cast&lt;int =
derived::*&gt;(&amp;base::x)&#39; which is most probably not going to yield=
 anything sane.<br><br>This is not something newly introduced in this propo=
sal, but the proposal might make it worse in the sense that the implicit co=
nversion from the pointer-to-member to PMU makes it simpler to make that fa=
mily of mistakes, which currently can only be hit through &#39;reinterpret_=
cast&#39;.<br><br>=C2=A0 =C2=A0 David<br><br>[*] N3772 mistakenly misrepres=
ents the problem with the templates making it look like there is a workarou=
nd for the template problem where there isn&#39;t. The first example&#39;s =
workaround is illegal:<br><br>struct A { int i; };<br>struct B : A {};<br>t=
emplate &lt;typename T, int T::*MPTR&gt; struct example1 {};<br>example1&lt=
;B, static_cast&lt;int B::*&gt;(&amp;B::i)&gt; x; // error<br><br><br><div =
class=3D"gmail_quote">On Fri Feb 13 2015 at 4:38:08 AM Markus Grech &lt;<a =
href=3D"mailto:markus.grech@gmail.com">markus.grech@gmail.com</a>&gt; wrote=
:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Hello everyone,<div><b=
r></div><div>in the past few days I have started working on a proposal for =
a new language feature that I call &quot;pointers to members of unknown cla=
ss&quot;.</div><div>I would like some feedback on the proposal as well as t=
he idea itself.</div><div><br></div><div><a href=3D"https://docs.google.com=
/document/d/1B4zWiym1twufigKA4RSXYR5xU4g32EJ8XNl_bzFtX08/edit?usp=3Dsharing=
" target=3D"_blank">https://docs.google.com/document/d/1B4zWiym1twufigKA4RS=
XYR5xU4g32EJ8XNl_bzFtX08/edit?usp=3Dsharing</a><br></div><div><br></div><di=
v>I have not looked into providing a standard wording yet.</div><div><br></=
div><div>Markus</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&quot; 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>
</blockquote></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&quot; 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 />

--001a11354faae0e5cf050efa1657--

.

------=_Part_2_480592810.1423849337960
Content-Type: multipart/alternative;
 boundary="----=_Part_3_637361303.1423849337960"

------=_Part_3_637361303.1423849337960
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



On Friday, February 13, 2015 at 4:42:53 PM UTC+1, David Rodr=C3=ADguez Ibea=
s=20
wrote:
>
> >> This requirement - conversion from one MP to another of the same kind=
=20
> and back to be well defined - implies that any two MPs of the same kind=
=20
> must be of the same size.
>
> The requirement that you mention is one of 'reinterpret_cast', although=
=20
> the casts that you use in the rest of the document are 'static_cast'. =20
> There is an important difference there, since for the case of 'static_cas=
t'=20
> you don't need to change anything, it is a semantically correct cast and=
=20
> the compiler can (and currently does in the case of VS) narrow/extend the=
=20
> value as needed.
>
I use static_cast in my examples because I don't cast between unrelated=20
MPs. The example is trying to show usage of this new feature.
static_cast<PM2>(static_cast<PMU>(some PM1)) would result in UB under the=
=20
new rules, while reinterpret_cast would give whatever behaviour is decided=
=20
on. In the case of static_cast, the PM2 object would be constructed from=20
the bits that happened to be at the location of the PMU when it was created=
=20
from a PM1, which could be using an entirely different representation than=
=20
PM2. That's the core issue: PMs of different classes need not have the same=
=20
representation.
=20

> The requirement above is not "fixed" with the proposal, that basically=20
> creates the equivalent of 'void*' for pointer-to-member, but does not=20
> remove the issue (as mentioned in the "open questions"). =20
>
It does fix the issue, because you should never have to cast MPs to another=
=20
unrelated one in the first place (see above). And with this proposal you=20
don't, you get a better solution, which is a PMU.
=20

> One additional concern I have is that currently that the application of=
=20
> unary & to qualified-id that refers to a non-static member of a class=20
> yields a type that might not be obvious to the user [I personally would=
=20
> like that changed, but could not defend N3772(*) in the committee and hav=
e=20
> not found anyone to do it]:
>
> struct base { int x; };
> struct derived : virtual base { virtual void f(); };
> PMU pmu =3D &derived::x; // PMU according to proposal's syntax
> auto pm =3D static_cast<int derived::*>(pmu); // undefined behavior
>
> The problem here is that the expression '&derived::x' is of type 'int=20
> base::*', which is converted to the universal pointer to member 'pmu', th=
e=20
> immediate cast to 'int derived::*' is thus not forming a round trip, but=
=20
> the equivalent of 'reinterpret_cast<int derived::*>(&base::x)' which is=
=20
> most probably not going to yield anything sane.
>
> This is not something newly introduced in this proposal, but the proposal=
=20
> might make it worse in the sense that the implicit conversion from the=20
> pointer-to-member to PMU makes it simpler to make that family of mistakes=
,=20
> which currently can only be hit through 'reinterpret_cast'.
>
I think you misunderstood my example. The expression &derived::x is=20
unchanged, but the implicit conversion is triggered by giving the variable=
=20
a PMU type.

Thanks to both of you, I now realize the proposal could be way more clear=
=20
and I will try to incorporate your feedback.

--=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_3_637361303.1423849337960
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Friday, February 13, 2015 at 4:42:53 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 dir=3D"ltr">&gt;&gt;&nbsp;This
 requirement - conversion from one MP to another of the same kind and=20
back to be well defined - implies that any two MPs of the same kind must
 be of the same size.<br><br>The requirement that you mention is one of=20
'reinterpret_cast', although the casts that you use in the rest of the=20
document are 'static_cast'.&nbsp; There is an important difference there,=
=20
since for the case of 'static_cast' you don't need to change anything,=20
it is a semantically correct cast and the compiler can (and currently=20
does in the case of VS) narrow/extend the value as needed.<br></div></block=
quote><div>I use static_cast in my examples because I don't cast between un=
related MPs. The example is trying to show usage of this new feature.<br>st=
atic_cast&lt;PM2&gt;(static_cast&lt;PMU&gt;(some PM1)) would result in UB u=
nder the new rules, while reinterpret_cast would give whatever behaviour is=
 decided on. In the case of static_cast, the PM2 object would be constructe=
d from the bits that happened to be at the location of the PMU when it was =
created from a PM1, which could be using an entirely different representati=
on than PM2. That's the core issue: PMs of different classes need not have =
the same representation.<br>&nbsp;</div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-le=
ft: 1ex;"><div dir=3D"ltr">The
 requirement above is not "fixed" with the proposal, that basically=20
creates the equivalent of 'void*' for pointer-to-member, but does not=20
remove the issue (as mentioned in the "open questions").&nbsp; <br></div></=
blockquote><div>It
 does fix the issue, because you should never have to cast MPs to=20
another unrelated one in the first place (see above). And with this proposa=
l you=20
don't, you get a better solution, which is a PMU.<br>&nbsp;<br></div><block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">One
 additional concern I have is that currently that the application of=20
unary &amp; to qualified-id that refers to a non-static member of a=20
class yields a type that might not be obvious to the user [I personally=20
would like that changed, but could not defend N3772(*) in the committee=20
and have not found anyone to do it]:<br><br>struct base { int x; };<br>stru=
ct derived : virtual base { virtual void f(); };<br>PMU pmu =3D &amp;derive=
d::x; // PMU according to proposal's syntax<br>auto pm =3D static_cast&lt;i=
nt derived::*&gt;(pmu); // undefined behavior<br><br>The
 problem here is that the expression '&amp;derived::x' is of type 'int=20
base::*', which is converted to the universal pointer to member 'pmu',=20
the immediate cast to 'int derived::*' is thus not forming a round trip,
 but the equivalent of 'reinterpret_cast&lt;int=20
derived::*&gt;(&amp;base::x)' which is most probably not going to yield=20
anything sane.<br><br>This is not something newly introduced in this=20
proposal, but the proposal might make it worse in the sense that the=20
implicit conversion from the pointer-to-member to PMU makes it simpler=20
to make that family of mistakes, which currently can only be hit through
 'reinterpret_cast'.<br></div></blockquote><div>I think you=20
misunderstood my example. The expression &amp;derived::x is unchanged,=20
but the implicit conversion is triggered by giving the variable a PMU=20
type.<br><br>Thanks to both of you, I now realize the proposal could be way=
 more clear and I will try to incorporate your feedback.<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&quot; 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_3_637361303.1423849337960--
------=_Part_2_480592810.1423849337960--

.

------=_Part_7_108039200.1423850347364
Content-Type: multipart/alternative;
 boundary="----=_Part_8_1191152685.1423850347365"

------=_Part_8_1191152685.1423850347365
Content-Type: text/plain; charset=UTF-8

Ignore what I said about your &derived::x case, I myself read your comment
incorrectly.

--

---
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_8_1191152685.1423850347365
Content-Type: text/html; charset=UTF-8

<div dir="ltr">Ignore what I said about your &amp;derived::x case, I myself read your comment incorrectly.<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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />

------=_Part_8_1191152685.1423850347365--
------=_Part_7_108039200.1423850347364--

.

------=_Part_239_217845914.1424084283345
Content-Type: multipart/alternative;
 boundary="----=_Part_240_2024142110.1424084283345"

------=_Part_240_2024142110.1424084283345
Content-Type: text/plain; charset=UTF-8

I have updated the proposal. Feedback would be very appreciated.

--

---
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_240_2024142110.1424084283345
Content-Type: text/html; charset=UTF-8

<div dir="ltr">I have updated the proposal. Feedback would be very appreciated.</div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />

------=_Part_240_2024142110.1424084283345--
------=_Part_239_217845914.1424084283345--

.

------=_Part_1792_1138702471.1424084331150
Content-Type: multipart/alternative;
 boundary="----=_Part_1793_1945651680.1424084331150"

------=_Part_1793_1945651680.1424084331150
Content-Type: text/plain; charset=UTF-8

I have updated the proposal, feedback would be very appreciated.
https://docs.google.com/document/d/1B4zWiym1twufigKA4RSXYR5xU4g32EJ8XNl_bzFtX08/edit?usp=sharing

--

---
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_1793_1945651680.1424084331150
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><font color=3D"#000000" face=3D"Arial"><span style=3D"font=
-size: 15px; white-space: pre-wrap;">I have updated the proposal, feedback =
would be very appreciated.</span></font><div><a href=3D"https://docs.google=
..com/document/d/1B4zWiym1twufigKA4RSXYR5xU4g32EJ8XNl_bzFtX08/edit?usp=3Dsha=
ring" target=3D"_blank" rel=3D"nofollow">https://docs.google.com/<wbr>docum=
ent/d/<wbr>1B4zWiym1twufigKA4RSXYR5xU4g32<wbr>EJ8XNl_bzFtX08/edit?usp=3D<wb=
r>sharing</a><font color=3D"#000000" face=3D"Arial"><span style=3D"font-siz=
e: 15px; white-space: pre-wrap;"><br></span></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&quot; 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_1793_1945651680.1424084331150--
------=_Part_1792_1138702471.1424084331150--

.

------=_Part_1233_1971991114.1424098737328
Content-Type: multipart/alternative;
 boundary="----=_Part_1234_1139528847.1424098737328"

------=_Part_1234_1139528847.1424098737328
Content-Type: text/plain; charset=UTF-8



On Monday, February 16, 2015 at 5:58:52 AM UTC-5, Markus Grech wrote:
>
> I have updated the proposal, feedback would be very appreciated.
>
> https://docs.google.com/document/d/1B4zWiym1twufigKA4RSXYR5xU4g32EJ8XNl_bzFtX08/edit?usp=sharing
>

One possible use-case that I don't see in this proposal:

struct X { int mem; };
struct Y { int mem; };


int void::* p = X::mem;
auto xp = static_cast<int X::*>(p);  // (1)
auto yp = static_cast<int Y::*>(p);  // (2)


Obviously, *(1) *should be valid, and you describe such a round trip in the
proposal, but what about *(2)*?
Certainly not valid, but I don't see anything prohibiting it.

--

---
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_1234_1139528847.1424098737328
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Monday, February 16, 2015 at 5:58:52 AM UTC-5, =
Markus Grech wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr"><font color=3D"#000000" face=3D"Arial"><span style=3D"font-size:15px;=
white-space:pre-wrap">I have updated the proposal, feedback would be very a=
ppreciated.</span></font><div><a href=3D"https://docs.google.com/document/d=
/1B4zWiym1twufigKA4RSXYR5xU4g32EJ8XNl_bzFtX08/edit?usp=3Dsharing" rel=3D"no=
follow" target=3D"_blank" onmousedown=3D"this.href=3D'https://docs.google.c=
om/document/d/1B4zWiym1twufigKA4RSXYR5xU4g32EJ8XNl_bzFtX08/edit?usp\75shari=
ng';return true;" onclick=3D"this.href=3D'https://docs.google.com/document/=
d/1B4zWiym1twufigKA4RSXYR5xU4g32EJ8XNl_bzFtX08/edit?usp\75sharing';return t=
rue;">https://docs.google.com/<wbr>document/d/<wbr>1B4zWiym1twufigKA4RSXYR5=
xU4g32<wbr>EJ8XNl_bzFtX08/edit?usp=3D<wbr>sharing</a></div></div></blockquo=
te><div><br></div><div>One possible use-case that I don't see in this propo=
sal:</div><div><br></div><div class=3D"prettyprint" style=3D"border: 1px so=
lid rgb(187, 187, 187); word-wrap: break-word; background-color: rgb(250, 2=
50, 250);"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span =
style=3D"color: #008;" class=3D"styled-by-prettify">struct</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> X </span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">int</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> mem</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">};</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><spa=
n style=3D"color: #008;" class=3D"styled-by-prettify">struct</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> Y </span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" clas=
s=3D"styled-by-prettify">int</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> mem</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">};</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br><br></=
span><span style=3D"color: #008;" class=3D"styled-by-prettify">int</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">void</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">::*</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> p </span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> X</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy">mem</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><=
span style=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> xp </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;=
" class=3D"styled-by-prettify">static_cast</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">int</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> X</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">::*&gt;(</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify">p</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
);</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> &nbsp;<=
/span><span style=3D"color: #800;" class=3D"styled-by-prettify">// (1)</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><spa=
n style=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> yp </span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">static_cast</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">&lt;</span><span style=3D"color: #008;" class=3D=
"styled-by-prettify">int</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> Y</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">::*&gt;(</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy">p</span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> &nbsp;</span=
><span style=3D"color: #800;" class=3D"styled-by-prettify">// (2)</span></d=
iv></code></div><div><br></div><div><br></div><div>Obviously, <i>(1) </i>sh=
ould be valid, and you describe such a round trip in the proposal, but what=
 about <i>(2)</i>?</div><div>Certainly not valid, but I don't see anything =
prohibiting it.</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&quot; 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_1234_1139528847.1424098737328--
------=_Part_1233_1971991114.1424098737328--

.

------=_Part_449_1604886013.1424099115171
Content-Type: multipart/alternative;
 boundary="----=_Part_450_924614171.1424099115171"

------=_Part_450_924614171.1424099115171
Content-Type: text/plain; charset=UTF-8



On Monday, February 16, 2015 at 3:58:57 PM UTC+1, Scott Prager wrote:
>
>
>
> On Monday, February 16, 2015 at 5:58:52 AM UTC-5, Markus Grech wrote:
>>
>> I have updated the proposal, feedback would be very appreciated.
>>
>> https://docs.google.com/document/d/1B4zWiym1twufigKA4RSXYR5xU4g32EJ8XNl_bzFtX08/edit?usp=sharing
>>
>
> One possible use-case that I don't see in this proposal:
>
> struct X { int mem; };
> struct Y { int mem; };
>
>
> int void::* p = X::mem;
> auto xp = static_cast<int X::*>(p);  // (1)
> auto yp = static_cast<int Y::*>(p);  // (2)
>
>
> Obviously, *(1) *should be valid, and you describe such a round trip in
> the proposal, but what about *(2)*?
> Certainly not valid, but I don't see anything prohibiting it.
>
This would certainly not have any portably meaningful result, as described
by the second open question. It is however not easily possible to get a
compiletime-error in general. A compiler could possibly emit a warning here
however.

--

---
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_450_924614171.1424099115171
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Monday, February 16, 2015 at 3:58:57 PM UTC+1, =
Scott Prager wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr"><br><br>On Monday, February 16, 2015 at 5:58:52 AM UTC-5, Markus Grec=
h wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><font colo=
r=3D"#000000" face=3D"Arial"><span style=3D"font-size:15px;white-space:pre-=
wrap">I have updated the proposal, feedback would be very appreciated.</spa=
n></font><div><a href=3D"https://docs.google.com/document/d/1B4zWiym1twufig=
KA4RSXYR5xU4g32EJ8XNl_bzFtX08/edit?usp=3Dsharing" rel=3D"nofollow" target=
=3D"_blank" onmousedown=3D"this.href=3D'https://docs.google.com/document/d/=
1B4zWiym1twufigKA4RSXYR5xU4g32EJ8XNl_bzFtX08/edit?usp\75sharing';return tru=
e;" onclick=3D"this.href=3D'https://docs.google.com/document/d/1B4zWiym1twu=
figKA4RSXYR5xU4g32EJ8XNl_bzFtX08/edit?usp\75sharing';return true;">https://=
docs.google.com/<wbr>document/d/<wbr>1B4zWiym1twufigKA4RSXYR5xU4g32<wbr>EJ8=
XNl_bzFtX08/edit?usp=3D<wbr>sharing</a></div></div></blockquote><div><br></=
div><div>One possible use-case that I don't see in this proposal:</div><div=
><br></div><div style=3D"border:1px solid rgb(187,187,187);word-wrap:break-=
word;background-color:rgb(250,250,250)"><code><div><span style=3D"color:#00=
8">struct</span><span style=3D"color:#000"> X </span><span style=3D"color:#=
660">{</span><span style=3D"color:#000"> </span><span style=3D"color:#008">=
int</span><span style=3D"color:#000"> mem</span><span style=3D"color:#660">=
;</span><span style=3D"color:#000"> </span><span style=3D"color:#660">};</s=
pan><span style=3D"color:#000"><br></span><span style=3D"color:#008">struct=
</span><span style=3D"color:#000"> Y </span><span style=3D"color:#660">{</s=
pan><span style=3D"color:#000"> </span><span style=3D"color:#008">int</span=
><span style=3D"color:#000"> mem</span><span style=3D"color:#660">;</span><=
span style=3D"color:#000"> </span><span style=3D"color:#660">};</span><span=
 style=3D"color:#000"><br><br><br></span><span style=3D"color:#008">int</sp=
an><span style=3D"color:#000"> </span><span style=3D"color:#008">void</span=
><span style=3D"color:#660">::*</span><span style=3D"color:#000"> p </span>=
<span style=3D"color:#660">=3D</span><span style=3D"color:#000"> X</span><s=
pan style=3D"color:#660">::</span><span style=3D"color:#000">mem</span><spa=
n style=3D"color:#660">;</span><span style=3D"color:#000"><br></span><span =
style=3D"color:#008">auto</span><span style=3D"color:#000"> xp </span><span=
 style=3D"color:#660">=3D</span><span style=3D"color:#000"> </span><span st=
yle=3D"color:#008">static_cast</span><span style=3D"color:#660">&lt;</span>=
<span style=3D"color:#008">int</span><span style=3D"color:#000"> X</span><s=
pan style=3D"color:#660">::*&gt;(</span><span style=3D"color:#000">p</span>=
<span style=3D"color:#660">);</span><span style=3D"color:#000"> &nbsp;</spa=
n><span style=3D"color:#800">// (1)</span><span style=3D"color:#000"><br></=
span><span style=3D"color:#008">auto</span><span style=3D"color:#000"> yp <=
/span><span style=3D"color:#660">=3D</span><span style=3D"color:#000"> </sp=
an><span style=3D"color:#008">static_cast</span><span style=3D"color:#660">=
&lt;</span><span style=3D"color:#008">int</span><span style=3D"color:#000">=
 Y</span><span style=3D"color:#660">::*&gt;(</span><span style=3D"color:#00=
0">p</span><span style=3D"color:#660">);</span><span style=3D"color:#000"> =
&nbsp;</span><span style=3D"color:#800">// (2)</span></div></code></div><di=
v><br></div><div><br></div><div>Obviously, <i>(1) </i>should be valid, and =
you describe such a round trip in the proposal, but what about <i>(2)</i>?<=
/div><div>Certainly not valid, but I don't see anything prohibiting it.</di=
v></div></blockquote><div>This would certainly not have any portably meanin=
gful result, as described by the second open question. It is however not ea=
sily possible to get a compiletime-error in general. A compiler could possi=
bly emit a warning here however.&nbsp;</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&quot; 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_450_924614171.1424099115171--
------=_Part_449_1604886013.1424099115171--

.

------=_Part_593_1451923908.1424102297524
Content-Type: multipart/alternative;
 boundary="----=_Part_594_628440895.1424102297524"

------=_Part_594_628440895.1424102297524
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Le lundi 16 f=C3=A9vrier 2015 15:58:57 UTC+1, Scott Prager a =C3=A9crit :
>
>
>
> On Monday, February 16, 2015 at 5:58:52 AM UTC-5, Markus Grech wrote:
>>
>> I have updated the proposal, feedback would be very appreciated.
>>
>> https://docs.google.com/document/d/1B4zWiym1twufigKA4RSXYR5xU4g32EJ8XNl_=
bzFtX08/edit?usp=3Dsharing
>>
>
> One possible use-case that I don't see in this proposal:
>
> struct X { int mem; };
> struct Y { int mem; };
>
>
> int void::* p =3D X::mem;
> auto xp =3D static_cast<int X::*>(p);  // (1)
> auto yp =3D static_cast<int Y::*>(p);  // (2)
>
>
> Obviously, *(1) *should be valid, and you describe such a round trip in=
=20
> the proposal, but what about *(2)*?
> Certainly not valid, but I don't see anything prohibiting it.
>

As usual, if there is nothing which give it a meaning, it is undefined. And=
=20
UB -- explicit or just by lack of
definition -- looks like the only reasonable thing in general.

In the presented case X and Y are layout-compatible, there is an obvious=20
meaning which we may want
to mandate.

--=20
Jean-Marc

--=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_594_628440895.1424102297524
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Le lundi 16 f=C3=A9vrier 2015 15:58:57 UTC+1, Scott Prager=
 a =C3=A9crit&nbsp;:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><br><br>On Monday, February 16, 2015 at 5:58:52 AM UTC-5, Markus G=
rech wrote:<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"><font c=
olor=3D"#000000" face=3D"Arial"><span style=3D"font-size:15px;white-space:p=
re-wrap">I have updated the proposal, feedback would be very appreciated.</=
span></font><div><a href=3D"https://docs.google.com/document/d/1B4zWiym1twu=
figKA4RSXYR5xU4g32EJ8XNl_bzFtX08/edit?usp=3Dsharing" rel=3D"nofollow" targe=
t=3D"_blank" onmousedown=3D"this.href=3D'https://docs.google.com/document/d=
/1B4zWiym1twufigKA4RSXYR5xU4g32EJ8XNl_bzFtX08/edit?usp\75sharing';return tr=
ue;" onclick=3D"this.href=3D'https://docs.google.com/document/d/1B4zWiym1tw=
ufigKA4RSXYR5xU4g32EJ8XNl_bzFtX08/edit?usp\75sharing';return true;">https:/=
/docs.google.com/<wbr>document/d/<wbr>1B4zWiym1twufigKA4RSXYR5xU4g32<wbr>EJ=
8XNl_bzFtX08/edit?usp=3D<wbr>sharing</a></div></div></blockquote><div><br><=
/div><div>One possible use-case that I don't see in this proposal:</div><di=
v><br></div><div style=3D"border:1px solid rgb(187,187,187);word-wrap:break=
-word;background-color:rgb(250,250,250)"><code><div><span style=3D"color:#0=
08">struct</span><span style=3D"color:#000"> X </span><span style=3D"color:=
#660">{</span><span style=3D"color:#000"> </span><span style=3D"color:#008"=
>int</span><span style=3D"color:#000"> mem</span><span style=3D"color:#660"=
>;</span><span style=3D"color:#000"> </span><span style=3D"color:#660">};</=
span><span style=3D"color:#000"><br></span><span style=3D"color:#008">struc=
t</span><span style=3D"color:#000"> Y </span><span style=3D"color:#660">{</=
span><span style=3D"color:#000"> </span><span style=3D"color:#008">int</spa=
n><span style=3D"color:#000"> mem</span><span style=3D"color:#660">;</span>=
<span style=3D"color:#000"> </span><span style=3D"color:#660">};</span><spa=
n style=3D"color:#000"><br><br><br></span><span style=3D"color:#008">int</s=
pan><span style=3D"color:#000"> </span><span style=3D"color:#008">void</spa=
n><span style=3D"color:#660">::*</span><span style=3D"color:#000"> p </span=
><span style=3D"color:#660">=3D</span><span style=3D"color:#000"> X</span><=
span style=3D"color:#660">::</span><span style=3D"color:#000">mem</span><sp=
an style=3D"color:#660">;</span><span style=3D"color:#000"><br></span><span=
 style=3D"color:#008">auto</span><span style=3D"color:#000"> xp </span><spa=
n style=3D"color:#660">=3D</span><span style=3D"color:#000"> </span><span s=
tyle=3D"color:#008">static_cast</span><span style=3D"color:#660">&lt;</span=
><span style=3D"color:#008">int</span><span style=3D"color:#000"> X</span><=
span style=3D"color:#660">::*&gt;(</span><span style=3D"color:#000">p</span=
><span style=3D"color:#660">);</span><span style=3D"color:#000"> &nbsp;</sp=
an><span style=3D"color:#800">// (1)</span><span style=3D"color:#000"><br><=
/span><span style=3D"color:#008">auto</span><span style=3D"color:#000"> yp =
</span><span style=3D"color:#660">=3D</span><span style=3D"color:#000"> </s=
pan><span style=3D"color:#008">static_cast</span><span style=3D"color:#660"=
>&lt;</span><span style=3D"color:#008">int</span><span style=3D"color:#000"=
> Y</span><span style=3D"color:#660">::*&gt;(</span><span style=3D"color:#0=
00">p</span><span style=3D"color:#660">);</span><span style=3D"color:#000">=
 &nbsp;</span><span style=3D"color:#800">// (2)</span></div></code></div><d=
iv><br></div><div><br></div><div>Obviously, <i>(1) </i>should be valid, and=
 you describe such a round trip in the proposal, but what about <i>(2)</i>?=
</div><div>Certainly not valid, but I don't see anything prohibiting it.</d=
iv></div></blockquote><div><br></div><div>As usual, if there is nothing whi=
ch give it a meaning, it is undefined. And UB -- explicit or just by lack o=
f</div><div>definition -- looks like the only reasonable thing in general.<=
/div><div><br></div><div>In the presented case X and Y are layout-compatibl=
e, there is an obvious meaning which we may want</div><div>to mandate.</div=
><div><br></div><div>--&nbsp;</div><div>Jean-Marc</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&quot; 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_594_628440895.1424102297524--
------=_Part_593_1451923908.1424102297524--

.

--001a11354faad22f0a050f48f42f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Sorry for looking like the bad guy here, but I am still unsure of the
feature. Little added value and increased dangers as people don't quite
understand pointers to members.

To be clear, the Itanium ABI does not have the pointer-to-member sizes
described in the document to adhere to the requirement of
'reinterpret_cast', but rather as the result of the design of dynamic
dispatch in that ABI (what value is 'this' on entry to the final
overrider?).

I am fine changing the standard to make VS implementation conformant. For
that a single change needs to be done: remove the requirement that
roundtrip conversions of pointer-to-member are guaranteed (becomes
implementation defined, still works where it works today, doesn't where it
fails today). Another change would then be useful: provide a mechanism to
replace the intermediate point of the roundtrip.  For that you can either
extend the grammar to allow for a "pointer to member of unknown type" or
provide a different facility.  The simplest would be to have a way of
creating a buffer that is "large enough".

With such a buffer, expressions in the form 'T void::*dst =3D src;' become
'memcpy(&dst, &src, sizeof src)' (where 'src' is a pointer to member of
type 'T' in some class 'C').  The conversions in the opposite direction are
the inverse: 'memcpy(&ptr, buffer, sizeof ptr)'.

The two main differences between this design and the proposal is that more
information is lost in this simplified approach, and the syntax for use is
more cumbersome.  The former is something I am willing to accept, the
latter I believe is an advantage, as it forces the user into having a
variable of the correct type before the conversion is done.  In doing so,
the type becomes more obvious to the programmer.  Same example as I
provided before:

struct base { int member; };
struct derived : base { virtual void f(); };

// Proposal
int void::* p =3D &derived::member;
....
int derived::* q =3D p;

// Alternative
std::ptrmbr_buffer buffer;
int derived::* p =3D &derived::member;
std::memcpy(&buffer, &s, sizeof s);
....
int derived::* q;
std::memcpy(&q, &buffer, sizeof q);

Clearly the syntax is harder on the developer, but this is an uncommon
feature so a small amount of developers will be hit with the additional
burden.  On the other hand, while both pieces of code "look" sensible, the
first has undefined behavior and in this particular case undefined behavior
will produce the wrong result when the pointer to member is used to access
the variable. How many developers are able to spot the bug? How many
developers would be able to spot the bug when the definition of the types,
the assignment to the PMU and the extraction of the PMU live in three
separate translation units? Worse even, 'derived' might have started as a
non-polymorphic type where the code above is undefined behavior but "does"
(seems to do) the right thing, so it will escape testing, a later unrelated
change adds a virtual function (or a different base, or makes inheritance
virtual or...) and the sequence of conversions silently breaks.

The burden on the syntax is not that much, in most cases the PMU/buffer
would exist before the conversion/memcpy is done (a member in a
type-erasing object), so it amounts to different syntax for storing into
the PMU/buffer and forcing the separate copy from the buffer into the
destination PM.  The syntax can be improved by allowing 'reinterpret_cast'
directly from the buffer.  The negative impact of this additional syntactic
sugar is that without it, the buffer approach can be implemented as a pure
library extension (the library knows how large the buffer is, a
pointer-to-member is a POD so it can be memcpy-ed in and out of a large
enough buffer without problems.

The buffer approach "erases" more type information, and the simplified
version above would have a higher than needed size (pointers to member
functions are larger than pointers to data members), which could be
improved either by having two different buffer types for MFP vs. MDP, or
turning the buffer into a template that takes the type:

std::ptrmbr_buffer<int> a; // large enough for any int T::*
std::ptrmbr_buffer<int ()> b; // large enough for any int (T::*)()

TL;DR

The proposal aims to ease a niche with a core-language feature where a
library-only feature can get most of the way in a (possibly arguable) safer
way with little syntactic burden.

   David

On Mon, Feb 16, 2015 at 10:58 AM, Jean-Marc Bourguet <jm.bourguet@gmail.com=
>
wrote:

> Le lundi 16 f=C3=A9vrier 2015 15:58:57 UTC+1, Scott Prager a =C3=A9crit :
>>
>>
>>
>> On Monday, February 16, 2015 at 5:58:52 AM UTC-5, Markus Grech wrote:
>>>
>>> I have updated the proposal, feedback would be very appreciated.
>>> https://docs.google.com/document/d/1B4zWiym1twufigKA4RSXYR5xU4g32
>>> EJ8XNl_bzFtX08/edit?usp=3Dsharing
>>>
>>
>> One possible use-case that I don't see in this proposal:
>>
>> struct X { int mem; };
>> struct Y { int mem; };
>>
>>
>> int void::* p =3D X::mem;
>> auto xp =3D static_cast<int X::*>(p);  // (1)
>> auto yp =3D static_cast<int Y::*>(p);  // (2)
>>
>>
>> Obviously, *(1) *should be valid, and you describe such a round trip in
>> the proposal, but what about *(2)*?
>> Certainly not valid, but I don't see anything prohibiting it.
>>
>
> As usual, if there is nothing which give it a meaning, it is undefined.
> And UB -- explicit or just by lack of
> definition -- looks like the only reasonable thing in general.
>
> In the presented case X and Y are layout-compatible, there is an obvious
> meaning which we may want
> to mandate.
>
> --
> Jean-Marc
>
> --
>
> ---
> 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/.
>

--=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/.

--001a11354faad22f0a050f48f42f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Sorry for looking like the bad guy here, but I am still un=
sure of the feature. Little added value and increased dangers as people don=
&#39;t quite understand pointers to members.<br><br>To be clear, the Itaniu=
m ABI does not have the pointer-to-member sizes described in the document t=
o adhere to the requirement of &#39;reinterpret_cast&#39;, but rather as th=
e result of the design of dynamic dispatch in that ABI (what value is &#39;=
this&#39; on entry to the final overrider?).<br><br>I am fine changing the =
standard to make VS implementation conformant. For that a single change nee=
ds to be done: remove the requirement that roundtrip conversions of pointer=
-to-member are guaranteed (becomes implementation defined, still works wher=
e it works today, doesn&#39;t where it fails today). Another change would t=
hen be useful: provide a mechanism to replace the intermediate point of the=
 roundtrip.=C2=A0 For that you can either extend the grammar to allow for a=
 &quot;pointer to member of unknown type&quot; or provide a different facil=
ity.=C2=A0 The simplest would be to have a way of creating a buffer that is=
 &quot;large enough&quot;.=C2=A0<br><br>With such a buffer, expressions in =
the form &#39;T void::*dst =3D src;&#39; become &#39;memcpy(&amp;dst, &amp;=
src, sizeof src)&#39; (where &#39;src&#39; is a pointer to member of type &=
#39;T&#39; in some class &#39;C&#39;).=C2=A0 The conversions in the opposit=
e direction are the inverse: &#39;memcpy(&amp;ptr, buffer, sizeof ptr)&#39;=
..<br><br>The two main differences between this design and the proposal is t=
hat more information is lost in this simplified approach, and the syntax fo=
r use is more cumbersome.=C2=A0 The former is something I am willing to acc=
ept, the latter I believe is an advantage, as it forces the user into havin=
g a variable of the correct type before the conversion is done.=C2=A0 In do=
ing so, the type becomes more obvious to the programmer.=C2=A0 Same example=
 as I provided before:<br><br>struct base { int member; };<br>struct derive=
d : base { virtual void f(); };<br><br>// Proposal<br>int void::* p =3D &am=
p;derived::member;<div>...<br>int derived::* q =3D p;<br><br>// Alternative=
<br>std::ptrmbr_buffer buffer;<div>int derived::* p =3D &amp;derived::membe=
r;<br>std::memcpy(&amp;buffer, &amp;s, sizeof s);</div><div>...</div><div>i=
nt derived::* q;<br>std::memcpy(&amp;q, &amp;buffer, sizeof q);<br><br>Clea=
rly the syntax is harder on the developer, but this is an uncommon feature =
so a small amount of developers will be hit with the additional burden.=C2=
=A0 On the other hand, while both pieces of code &quot;look&quot; sensible,=
 the first has undefined behavior and in this particular case undefined beh=
avior will produce the wrong result when the pointer to member is used to a=
ccess the variable. How many developers are able to spot the bug? How many =
developers would be able to spot the bug when the definition of the types, =
the assignment to the PMU and the extraction of the PMU live in three separ=
ate translation units? Worse even, &#39;derived&#39; might have started as =
a non-polymorphic type where the code above is undefined behavior but &quot=
;does&quot; (seems to do) the right thing, so it will escape testing, a lat=
er unrelated change adds a virtual function (or a different base, or makes =
inheritance virtual or...) and the sequence of conversions silently breaks.=
<br><br>The burden on the syntax is not that much, in most cases the PMU/bu=
ffer would exist before the conversion/memcpy is done (a member in a type-e=
rasing object), so it amounts to different syntax for storing into the PMU/=
buffer and forcing the separate copy from the buffer into the destination P=
M.=C2=A0 The syntax can be improved by allowing &#39;reinterpret_cast&#39; =
directly from the buffer.=C2=A0 The negative impact of this additional synt=
actic sugar is that without it, the buffer approach can be implemented as a=
 pure library extension (the library knows how large the buffer is, a point=
er-to-member is a POD so it can be memcpy-ed in and out of a large enough b=
uffer without problems.<br><br>The buffer approach &quot;erases&quot; more =
type information, and the simplified version above would have a higher than=
 needed size (pointers to member functions are larger than pointers to data=
 members), which could be improved either by having two different buffer ty=
pes for MFP vs. MDP, or turning the buffer into a template that takes the t=
ype:<br><br>std::ptrmbr_buffer&lt;int&gt; a; // large enough for any int T:=
:*<br>std::ptrmbr_buffer&lt;int ()&gt; b; // large enough for any int (T::*=
)()<br><br>TL;DR<br><br>The proposal aims to ease a niche with a core-langu=
age feature where a library-only feature can get most of the way in a (poss=
ibly arguable) safer way with little syntactic burden.<br><br>=C2=A0 =C2=A0=
David</div></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_q=
uote">On Mon, Feb 16, 2015 at 10:58 AM, Jean-Marc Bourguet <span dir=3D"ltr=
">&lt;<a href=3D"mailto:jm.bourguet@gmail.com" target=3D"_blank">jm.bourgue=
t@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div di=
r=3D"ltr">Le lundi 16 f=C3=A9vrier 2015 15:58:57 UTC+1, Scott Prager a =C3=
=A9crit=C2=A0:<span class=3D""><blockquote class=3D"gmail_quote" style=3D"m=
argin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
 dir=3D"ltr"><br><br>On Monday, February 16, 2015 at 5:58:52 AM UTC-5, Mark=
us Grech wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-l=
eft:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><fo=
nt color=3D"#000000" face=3D"Arial"><span style=3D"font-size:15px;white-spa=
ce:pre-wrap">I have updated the proposal, feedback would be very appreciate=
d.</span></font><div><a href=3D"https://docs.google.com/document/d/1B4zWiym=
1twufigKA4RSXYR5xU4g32EJ8XNl_bzFtX08/edit?usp=3Dsharing" rel=3D"nofollow" t=
arget=3D"_blank">https://docs.google.com/<u></u>document/d/<u></u>1B4zWiym1=
twufigKA4RSXYR5xU4g32<u></u>EJ8XNl_bzFtX08/edit?usp=3D<u></u>sharing</a></d=
iv></div></blockquote><div><br></div><div>One possible use-case that I don&=
#39;t see in this proposal:</div><div><br></div><div style=3D"border:1px so=
lid rgb(187,187,187);word-wrap:break-word;background-color:rgb(250,250,250)=
"><code><div><span style=3D"color:#008">struct</span><span style=3D"color:#=
000"> X </span><span style=3D"color:#660">{</span><span style=3D"color:#000=
"> </span><span style=3D"color:#008">int</span><span style=3D"color:#000"> =
mem</span><span style=3D"color:#660">;</span><span style=3D"color:#000"> </=
span><span style=3D"color:#660">};</span><span style=3D"color:#000"><br></s=
pan><span style=3D"color:#008">struct</span><span style=3D"color:#000"> Y <=
/span><span style=3D"color:#660">{</span><span style=3D"color:#000"> </span=
><span style=3D"color:#008">int</span><span style=3D"color:#000"> mem</span=
><span style=3D"color:#660">;</span><span style=3D"color:#000"> </span><spa=
n style=3D"color:#660">};</span><span style=3D"color:#000"><br><br><br></sp=
an><span style=3D"color:#008">int</span><span style=3D"color:#000"> </span>=
<span style=3D"color:#008">void</span><span style=3D"color:#660">::*</span>=
<span style=3D"color:#000"> p </span><span style=3D"color:#660">=3D</span><=
span style=3D"color:#000"> X</span><span style=3D"color:#660">::</span><spa=
n style=3D"color:#000">mem</span><span style=3D"color:#660">;</span><span s=
tyle=3D"color:#000"><br></span><span style=3D"color:#008">auto</span><span =
style=3D"color:#000"> xp </span><span style=3D"color:#660">=3D</span><span =
style=3D"color:#000"> </span><span style=3D"color:#008">static_cast</span><=
span style=3D"color:#660">&lt;</span><span style=3D"color:#008">int</span><=
span style=3D"color:#000"> X</span><span style=3D"color:#660">::*&gt;(</spa=
n><span style=3D"color:#000">p</span><span style=3D"color:#660">);</span><s=
pan style=3D"color:#000"> =C2=A0</span><span style=3D"color:#800">// (1)</s=
pan><span style=3D"color:#000"><br></span><span style=3D"color:#008">auto</=
span><span style=3D"color:#000"> yp </span><span style=3D"color:#660">=3D</=
span><span style=3D"color:#000"> </span><span style=3D"color:#008">static_c=
ast</span><span style=3D"color:#660">&lt;</span><span style=3D"color:#008">=
int</span><span style=3D"color:#000"> Y</span><span style=3D"color:#660">::=
*&gt;(</span><span style=3D"color:#000">p</span><span style=3D"color:#660">=
);</span><span style=3D"color:#000"> =C2=A0</span><span style=3D"color:#800=
">// (2)</span></div></code></div><div><br></div><div><br></div><div>Obviou=
sly, <i>(1) </i>should be valid, and you describe such a round trip in the =
proposal, but what about <i>(2)</i>?</div><div>Certainly not valid, but I d=
on&#39;t see anything prohibiting it.</div></div></blockquote><div><br></di=
v></span><div>As usual, if there is nothing which give it a meaning, it is =
undefined. And UB -- explicit or just by lack of</div><div>definition -- lo=
oks like the only reasonable thing in general.</div><div><br></div><div>In =
the presented case X and Y are layout-compatible, there is an obvious meani=
ng which we may want</div><div>to mandate.</div><span class=3D"HOEnZb"><fon=
t color=3D"#888888"><div><br></div><div>--=C2=A0</div><div>Jean-Marc</div><=
/font></span></div><div class=3D"HOEnZb"><div class=3D"h5">

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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>
</div></div></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&quot; 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 />

--001a11354faad22f0a050f48f42f--

.

------=_Part_3055_416033512.1424183024691
Content-Type: multipart/alternative;
 boundary="----=_Part_3056_68481552.1424183024691"

------=_Part_3056_68481552.1424183024691
Content-Type: text/plain; charset=UTF-8

I like your idea about std::memptr_buffer, not sure why I haven't thought
of that before. But I do not see how it improves safety at all, most people
would just put 'auto' there and get a base::* silently.

--

---
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_3056_68481552.1424183024691
Content-Type: text/html; charset=UTF-8

<div dir="ltr">I like your idea about std::memptr_buffer, not sure why I haven't thought of that before. But I do not see how it improves safety at all, most people would just put 'auto' there and get a base::* silently.</div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />

------=_Part_3056_68481552.1424183024691--
------=_Part_3055_416033512.1424183024691--

.

--001a11351944e694c6050f49c8ca
Content-Type: text/plain; charset=UTF-8

Yes... I am not to fond of the almost-always-auto recommendations.  Also,
I'd really like the language to change and make '&derived::member' a 'T
derived::*', as this is really the source of pain and confusion --the code
as read by the user differs from what the compiler processes.  If that was
to be fixed, it would be one less source of confusion (and would simplify
other parts of the language), but that is a different discussion...

    David

On Tue, Feb 17, 2015 at 9:23 AM, Markus Grech <markus.grech@gmail.com>
wrote:

> I like your idea about std::memptr_buffer, not sure why I haven't thought
> of that before. But I do not see how it improves safety at all, most people
> would just put 'auto' there and get a base::* silently.
>
> --
>
> ---
> 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/.

--001a11351944e694c6050f49c8ca
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Yes... I am not to fond of the almost-always-auto recommen=
dations.=C2=A0 Also, I&#39;d really like the language to change and make &#=
39;&amp;derived::member&#39; a &#39;T derived::*&#39;, as this is really th=
e source of pain and confusion --the code as read by the user differs from =
what the compiler processes.=C2=A0 If that was to be fixed, it would be one=
 less source of confusion (and would simplify other parts of the language),=
 but that is a different discussion...<br><br>=C2=A0 =C2=A0 David</div><div=
 class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Tue, Feb 17, 2015 =
at 9:23 AM, Markus Grech <span dir=3D"ltr">&lt;<a href=3D"mailto:markus.gre=
ch@gmail.com" target=3D"_blank">markus.grech@gmail.com</a>&gt;</span> wrote=
:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">I like your idea about=
 std::memptr_buffer, not sure why I haven&#39;t thought of that before. But=
 I do not see how it improves safety at all, most people would just put &#3=
9;auto&#39; there and get a base::* silently.</div><div class=3D"HOEnZb"><d=
iv class=3D"h5">

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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>
</div></div></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&quot; 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 />

--001a11351944e694c6050f49c8ca--

.

--Apple-Mail=_746C61F7-C9C0-4B75-BA2A-8B2E3D4AC91D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9302=E2=80=9317, at 9:48 PM, David Rodr=C3=ADguez Ibeas <di=
beas@ieee.org> wrote:
>=20
> Sorry for looking like the bad guy here, but I am still unsure of the fea=
ture. Little added value and increased dangers as people don't quite unders=
tand pointers to members.
>=20
> To be clear, the Itanium ABI does not have the pointer-to-member sizes de=
scribed in the document to adhere to the requirement of 'reinterpret_cast',=
 but rather as the result of the design of dynamic dispatch in that ABI (wh=
at value is 'this' on entry to the final overrider?).

Virtual functions and virtual bases set requirements for certain PTM types,=
 causing increased size. The reinterpret_cast requirement causes that size =
to apply to all other PTM types, even for classes without virtual anything.

Looking at the proposal again, I find the incomplete classes troubling. Isn=
=E2=80=99t it inconsistent to retroactively change the size of a class=E2=
=80=99 PTMs at the time it gets completed? Shouldn=E2=80=99t pointers to me=
mbers of incomplete classes be incomplete too?

For that matter, MSVC doesn=E2=80=99t go far enough with this optimization.=
 Most classes are less than 256 bytes, and then ordinary PTMs only need one=
 byte.

> I am fine changing the standard to make VS implementation conformant. For=
 that a single change needs to be done: remove the requirement that roundtr=
ip conversions of pointer-to-member are guaranteed (becomes implementation =
defined, still works where it works today, doesn't where it fails today). A=
nother change would then be useful: provide a mechanism to replace the inte=
rmediate point of the roundtrip.  For that you can either extend the gramma=
r to allow for a "pointer to member of unknown type" or provide a different=
 facility.  The simplest would be to have a way of creating a buffer that i=
s "large enough".=20
>=20
> With such a buffer, expressions in the form 'T void::*dst =3D src;' becom=
e 'memcpy(&dst, &src, sizeof src)' (where 'src' is a pointer to member of t=
ype 'T' in some class 'C').  The conversions in the opposite direction are =
the inverse: 'memcpy(&ptr, buffer, sizeof ptr)=E2=80=99.

Sure, any POD type can be constructed from its object representation, and P=
TMs are POD. No special buffer provision is required. Just let the user cal=
l memcpy directly.

Taken to its bare essentials, the proposal is simple indeed!

--=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/.

--Apple-Mail=_746C61F7-C9C0-4B75-BA2A-8B2E3D4AC91D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9302=
=E2=80=9317, at 9:48 PM, David Rodr=C3=ADguez Ibeas &lt;<a href=3D"mailto:d=
ibeas@ieee.org" class=3D"">dibeas@ieee.org</a>&gt; wrote:</div><br class=3D=
"Apple-interchange-newline"><div class=3D""><div dir=3D"ltr" class=3D"">Sor=
ry for looking like the bad guy here, but I am still unsure of the feature.=
 Little added value and increased dangers as people don't quite understand =
pointers to members.<br class=3D""><br class=3D"">To be clear, the Itanium =
ABI does not have the pointer-to-member sizes described in the document to =
adhere to the requirement of 'reinterpret_cast', but rather as the result o=
f the design of dynamic dispatch in that ABI (what value is 'this' on entry=
 to the final overrider?).<br class=3D""></div></div></blockquote><div><br =
class=3D""></div><div>Virtual functions and virtual bases set requirements =
for certain PTM types, causing increased size. The <font face=3D"Courier" c=
lass=3D"">reinterpret_cast</font> requirement causes that size to apply to =
all other PTM types, even for classes without virtual anything.</div><div><=
br class=3D""></div><div>Looking at the proposal again, I find the incomple=
te classes troubling. Isn=E2=80=99t it inconsistent to retroactively change=
 the size of a class=E2=80=99 PTMs at the time it gets completed? Shouldn=
=E2=80=99t pointers to members of incomplete classes be incomplete too?</di=
v><div><br class=3D""></div><div>For that matter, MSVC doesn=E2=80=99t go f=
ar enough with this optimization. Most classes are less than 256 bytes, and=
 then ordinary PTMs only need one byte.</div><div><br class=3D""></div><blo=
ckquote type=3D"cite" class=3D""><div class=3D""><div dir=3D"ltr" class=3D"=
">I am fine changing the standard to make VS implementation conformant. For=
 that a single change needs to be done: remove the requirement that roundtr=
ip conversions of pointer-to-member are guaranteed (becomes implementation =
defined, still works where it works today, doesn't where it fails today). A=
nother change would then be useful: provide a mechanism to replace the inte=
rmediate point of the roundtrip.&nbsp; For that you can either extend the g=
rammar to allow for a "pointer to member of unknown type" or provide a diff=
erent facility.&nbsp; The simplest would be to have a way of creating a buf=
fer that is "large enough".&nbsp;<br class=3D""><br class=3D"">With such a =
buffer, expressions in the form 'T void::*dst =3D src;' become 'memcpy(&amp=
;dst, &amp;src, sizeof src)' (where 'src' is a pointer to member of type 'T=
' in some class 'C').&nbsp; The conversions in the opposite direction are t=
he inverse: 'memcpy(&amp;ptr, buffer, sizeof ptr)=E2=80=99.<br class=3D""><=
/div></div></blockquote><div><br class=3D""></div><div>Sure, any POD type c=
an be constructed from its object representation, and PTMs are POD. No spec=
ial buffer provision is required. Just let the user call <font face=3D"Cour=
ier" class=3D"">memcpy</font> directly.</div><div><br class=3D""></div><div=
>Taken to its bare essentials, the proposal is simple indeed!</div></div></=
body></html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />

--Apple-Mail=_746C61F7-C9C0-4B75-BA2A-8B2E3D4AC91D--

.

On Wednesday 18 February 2015 01:41:31 David Krauss wrote:
> Looking at the proposal again, I find the incomplete classes troubling.
> Isn=E2=80=99t it inconsistent to retroactively change the size of a class=
=E2=80=99 PTMs at
> the time it gets completed? Shouldn=E2=80=99t pointers to members of inco=
mplete
> classes be incomplete too?

I don't know if the standard says the below code is valid or whether it has=
=20
undefined- or implementation-defined behaviour. It does compile without war=
nings=20
at any level with GCC, Clang and ICC (on OS X and Linux) -- that is, when=
=20
using the IA-64 C++ ABI.

struct S;
typedef int S:: *PTM;
typedef void (S:: *PMF)(int);

void func(S *s, PMF f, PTM v)
{
 (s->*f)(s->*v);
}

I do know that it may not work properly with MSVC because the pointer-to-
member types may change sizes depending on the inheritance diagram of class=
 in=20
question. If the above has implementation-defined behaviour, MSVC is=20
conformant; if the above is legally-valid code, then MSVC ought to fix thei=
r=20
ABI...

<rant>
If MSVC has broken ABI *every* *single* release in the past 15 years, why=
=20
hasn't it fixed the above issue, when there is a clear solution works for=
=20
everyone and, moreover, is available via compile switch (the /vmg option)
https://msdn.microsoft.com/en-us/library/yad46a6z.aspx
</rant>

--=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/.

.

--001a11c3a950a43d7d050f511fa9
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tue, Feb 17, 2015 at 11:52 AM, Thiago Macieira <thiago@macieira.org>
wrote:

> On Wednesday 18 February 2015 01:41:31 David Krauss wrote:
> > Looking at the proposal again, I find the incomplete classes troubling.
> > Isn=E2=80=99t it inconsistent to retroactively change the size of a cla=
ss=E2=80=99 PTMs
> at
> > the time it gets completed? Shouldn=E2=80=99t pointers to members of in=
complete
> > classes be incomplete too?
>
> I don't know if the standard says the below code is valid or whether it h=
as
> undefined- or implementation-defined behaviour. It does compile without
> warnings
> at any level with GCC, Clang and ICC (on OS X and Linux) -- that is, when
> using the IA-64 C++ ABI.
>
> struct S;
> typedef int S:: *PTM;
> typedef void (S:: *PMF)(int);
>
> void func(S *s, PMF f, PTM v)
> {
>         (s->*f)(s->*v);
> }
>
> I do know that it may not work properly with MSVC because the pointer-to-
> member types may change sizes depending on the inheritance diagram of
> class in
> question. If the above has implementation-defined behaviour, MSVC is
> conformant; if the above is legally-valid code, then MSVC ought to fix
> their
> ABI...
>

The above is valid code. (I thought it was generally well-known that MSVC's
implementation of pointers-to-members is non-conforming by default.)

<rant>
> If MSVC has broken ABI *every* *single* release in the past 15 years, why
> hasn't it fixed the above issue, when there is a clear solution works for
> everyone and, moreover, is available via compile switch (the /vmg option)
> https://msdn.microsoft.com/en-us/library/yad46a6z.aspx
> </rant>


The /vmg option makes pointers-to-members quite large (3-4 pointers)
because it gives a "most general" representation for all
pointers-to-members. MSVC's "most general" representation supports (as an
extension) things that the standard does not require, such as converting a
pointer-to-member of a *virtual* base class to a pointer-to-member of a
derived class, and thus cannot be as compact as that of the Itanium C++
ABI. MSVC can't simply switch to a strict, standard-conforming, smaller
pointer-to-member representation without breaking existing code that uses
its extension.

I don't know if that's the reason they've not done anything about this, but
it seems like a possible explanation. You can *almost* get a small and
correct pointer-to-member representation by using the /vmm switch, but
their compiler emits spurious errors if you then take the address of a
member of a class that uses virtual inheritance.

--=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/.

--001a11c3a950a43d7d050f511fa9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Feb 17, 2015 at 11:52 AM, Thiago Macieira <span dir=3D"ltr">&lt;<a href=
=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@macieira.org</a>&g=
t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On Wedn=
esday 18 February 2015 01:41:31 David Krauss wrote:<br>
&gt; Looking at the proposal again, I find the incomplete classes troubling=
..<br>
&gt; Isn=E2=80=99t it inconsistent to retroactively change the size of a cl=
ass=E2=80=99 PTMs at<br>
&gt; the time it gets completed? Shouldn=E2=80=99t pointers to members of i=
ncomplete<br>
&gt; classes be incomplete too?<br>
<br>
</span>I don&#39;t know if the standard says the below code is valid or whe=
ther it has<br>
undefined- or implementation-defined behaviour. It does compile without war=
nings<br>
at any level with GCC, Clang and ICC (on OS X and Linux) -- that is, when<b=
r>
using the IA-64 C++ ABI.<br>
<br>
struct S;<br>
typedef int S:: *PTM;<br>
typedef void (S:: *PMF)(int);<br>
<br>
void func(S *s, PMF f, PTM v)<br>
{<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 (s-&gt;*f)(s-&gt;*v);<br>
}<br>
<br>
I do know that it may not work properly with MSVC because the pointer-to-<b=
r>
member types may change sizes depending on the inheritance diagram of class=
 in<br>
question. If the above has implementation-defined behaviour, MSVC is<br>
conformant; if the above is legally-valid code, then MSVC ought to fix thei=
r<br>
ABI...<br></blockquote><div><br></div><div>The above is valid code. (I thou=
ght it was generally well-known that MSVC&#39;s implementation of pointers-=
to-members is non-conforming by default.)</div><div><br></div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex">
&lt;rant&gt;<br>
If MSVC has broken ABI *every* *single* release in the past 15 years, why<b=
r>
hasn&#39;t it fixed the above issue, when there is a clear solution works f=
or<br>
everyone and, moreover, is available via compile switch (the /vmg option)<b=
r>
<a href=3D"https://msdn.microsoft.com/en-us/library/yad46a6z.aspx" target=
=3D"_blank">https://msdn.microsoft.com/en-us/library/yad46a6z.aspx</a><br>
&lt;/rant&gt;</blockquote><div><br></div><div>The /vmg option makes pointer=
s-to-members quite large (3-4 pointers) because it gives a &quot;most gener=
al&quot; representation for all pointers-to-members. MSVC&#39;s &quot;most =
general&quot; representation supports (as an extension) things that the sta=
ndard does not require, such as converting a pointer-to-member of a *virtua=
l* base class to a pointer-to-member of a derived class, and thus cannot be=
 as compact as that of the Itanium C++ ABI. MSVC can&#39;t simply switch to=
 a strict, standard-conforming, smaller pointer-to-member representation wi=
thout breaking existing code that uses its extension.</div><div><br></div><=
div>I don&#39;t know if that&#39;s the reason they&#39;ve not done anything=
 about this, but it seems like a possible explanation. You can *almost* get=
 a small and correct pointer-to-member representation by using the /vmm swi=
tch, but their compiler emits spurious errors if you then take the address =
of a member of a class that uses virtual inheritance.</div></div></div></di=
v>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />

--001a11c3a950a43d7d050f511fa9--

.

On Tuesday 17 February 2015 15:33:01 Richard Smith wrote:
> <rant>
>
> > If MSVC has broken ABI *every* *single* release in the past 15 years, why
> > hasn't it fixed the above issue, when there is a clear solution works for
> > everyone and, moreover, is available via compile switch (the /vmg option)
> > https://msdn.microsoft.com/en-us/library/yad46a6z.aspx
> > </rant>
>
> The /vmg option makes pointers-to-members quite large (3-4 pointers)
> because it gives a "most general" representation for all
> pointers-to-members. MSVC's "most general" representation supports (as an
> extension) things that the standard does not require, such as converting a
> pointer-to-member of a *virtual* base class to a pointer-to-member of a
> derived class, and thus cannot be as compact as that of the Itanium C++
> ABI. MSVC can't simply switch to a strict, standard-conforming, smaller
> pointer-to-member representation without breaking existing code that uses
> its extension.

I'm not asking to drop the extension. I'm asking that they fix their non-
conforming behaviour. They could introduce a default that is as big as the
Itanium C++ ABI does and provide the even-larger version when necessary. Or
they could use the large one everywhere.

> I don't know if that's the reason they've not done anything about this, but
> it seems like a possible explanation. You can *almost* get a small and
> correct pointer-to-member representation by using the /vmm switch, but
> their compiler emits spurious errors if you then take the address of a
> member of a class that uses virtual inheritance.

So what they need is a "/vmm" that applies to everything except virtual
inheritance, leaving the 3-4 pointer version for classes with virtuals. Since
that is an extension anyway, it doesn't need to support incomplete classes.

--
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

--

---
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_105_1924390055.1430897407899
Content-Type: multipart/alternative;
 boundary="----=_Part_106_2119930565.1430897407899"

------=_Part_106_2119930565.1430897407899
Content-Type: text/plain; charset=UTF-8

Hello again,

I have updated the paper and added a class memptr_buf in favor of a new
core language feature.
https://docs.google.com/document/d/1B4zWiym1twufigKA4RSXYR5xU4g32EJ8XNl_bzFtX08/edit?usp=sharing

Let me know what you think!
Markus

--

---
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_106_2119930565.1430897407899
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hello again,<div><br></div><div>I have updated the paper a=
nd added a class memptr_buf in favor of a new core language feature.</div><=
div><a href=3D"https://docs.google.com/document/d/1B4zWiym1twufigKA4RSXYR5x=
U4g32EJ8XNl_bzFtX08/edit?usp=3Dsharing">https://docs.google.com/document/d/=
1B4zWiym1twufigKA4RSXYR5xU4g32EJ8XNl_bzFtX08/edit?usp=3Dsharing</a><br></di=
v><div><br></div><div>Let me know what you think!</div><div>Markus</div></d=
iv>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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_106_2119930565.1430897407899--
------=_Part_105_1924390055.1430897407899--

.

------=_Part_4627_230039495.1431353507135
Content-Type: multipart/alternative;
 boundary="----=_Part_4628_803227865.1431353507135"

------=_Part_4628_803227865.1431353507135
Content-Type: text/plain; charset=UTF-8

An example implementation of the proposal, as well as usage examples of the
proposed features are now available:
https://bitbucket.org/Paprikachu/std-memptr_buf/

-Markus

--

---
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_4628_803227865.1431353507135
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">An example implementation of the proposal, as well as usag=
e examples of the proposed features are now available:<div><a href=3D"https=
://bitbucket.org/Paprikachu/std-memptr_buf/">https://bitbucket.org/Paprikac=
hu/std-memptr_buf/</a><br></div><div><br></div><div>-Markus</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&quot; 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_4628_803227865.1431353507135--
------=_Part_4627_230039495.1431353507135--

.