------=_Part_5792_1397706334.1467385055303
Content-Type: multipart/alternative;
 boundary="----=_Part_5793_2001347739.1467385055310"

------=_Part_5793_2001347739.1467385055310
Content-Type: text/plain; charset=UTF-8

This prototype could be used as a starting point:

https://github.com/wkaras/C-plus-plus-library-bit-fields

I think the use of macros and reinterpret_cast could be eliminated with
some tweaks to member pointers in the base language:

o  Allow static_cast<size_t>(mp) where mp is a pointer to a data member of
a Standard Layout Class.

o  Eliminate the need for boilerplate & and class name prefix when the
context implies them.  So:

int Cls::*p = &x.i;

could be written simply as:

int Cls::*p = i;

o  Allow member pointers to members of members and base classes.  Possible
syntax (showing boiler plate):

mp1 = &Cls::x.y; // member of member
mp2 = &Cls::Base; // base
mp3 = &Cls::Base::SubBase; // sub-base

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7d635ed8-e567-4515-b51b-137e46b2b203%40isocpp.org.

------=_Part_5793_2001347739.1467385055310
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">This prototype could be used as a starting point:<div><br>=
</div><div>https://github.com/wkaras/C-plus-plus-library-bit-fields<br></di=
v><div><br></div><div>I think the use of macros and reinterpret_cast could =
be eliminated with some tweaks to member pointers in the base language:</di=
v><div><br></div><div>o =C2=A0Allow static_cast&lt;size_t&gt;(mp) where mp =
is a pointer to a data member of a Standard Layout Class.</div><div><br></d=
iv><div>o =C2=A0Eliminate the need for boilerplate &amp; and class name pre=
fix when the context implies them. =C2=A0So:</div><div><br></div><div>int C=
ls::*p =3D &amp;x.i;</div><div><br></div><div>could be written simply as:</=
div><div><br></div><div>int Cls::*p =3D i;</div><div><br></div><div>o =C2=
=A0Allow member pointers to members of members and base classes. =C2=A0Poss=
ible syntax (showing boiler plate):</div><div><br></div><div>mp1 =3D &amp;C=
ls::x.y; // member of member</div><div>mp2 =3D &amp;Cls::Base; // base</div=
><div>mp3 =3D &amp;Cls::Base::SubBase; // sub-base<br></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/7d635ed8-e567-4515-b51b-137e46b2b203%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7d635ed8-e567-4515-b51b-137e46b2b203=
%40isocpp.org</a>.<br />

------=_Part_5793_2001347739.1467385055310--

------=_Part_5792_1397706334.1467385055303--

.

------=_Part_8_36983604.1467419984255
Content-Type: multipart/alternative;
 boundary="----=_Part_9_2135695268.1467419984255"

------=_Part_9_2135695268.1467419984255
Content-Type: text/plain; charset=UTF-8

On Friday, July 1, 2016 at 10:57:35 AM UTC-4, Walt Karas wrote:
>
> This prototype could be used as a starting point:
>
> https://github.com/wkaras/C-plus-plus-library-bit-fields
>
> I think the use of macros and reinterpret_cast could be eliminated with
> some tweaks to member pointers in the base language:
>

I don't think we should change the language to legitimize this particular
library. If your suggested features have broader uses than your library,
then you should explain what they are.

o  Allow static_cast<size_t>(mp) where mp is a pointer to a data member of
> a Standard Layout Class.
>

And... what would that do? What does it mean to convert a member pointer
into a number? What does this number mean, and why does it matter if the
class is standard layout or not?

o  Eliminate the need for boilerplate & and class name prefix when the
> context implies them.  So:
>
> int Cls::*p = &x.i;
>
> could be written simply as:
>
> int Cls::*p = i;
>

What "context" creates this implication? How do you know which `x` you're
talking about, if there are multiple variables of type `Cls` (assuming that
`x` is supposed to be of type `Cls`)?

o  Allow member pointers to members of members and base classes.  Possible
> syntax (showing boiler plate):
>
> mp1 = &Cls::x.y; // member of member
> mp2 = &Cls::Base; // base
> mp3 = &Cls::Base::SubBase; // sub-base
>

.... no. Just... no.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/bae85a90-2e5a-47b5-ae12-d3578a455a2c%40isocpp.org.

------=_Part_9_2135695268.1467419984255
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Friday, July 1, 2016 at 10:57:35 AM UTC-4, Walt Karas w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">This pro=
totype could be used as a starting point:<div><br></div><div><a href=3D"htt=
ps://github.com/wkaras/C-plus-plus-library-bit-fields" target=3D"_blank" re=
l=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://www.google.com/url?q=
\x3dhttps%3A%2F%2Fgithub.com%2Fwkaras%2FC-plus-plus-library-bit-fields\x26s=
a\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGjN1MHxlfN_ip1k-50c3-j_5nljA&#39;;retur=
n true;" onclick=3D"this.href=3D&#39;https://www.google.com/url?q\x3dhttps%=
3A%2F%2Fgithub.com%2Fwkaras%2FC-plus-plus-library-bit-fields\x26sa\x3dD\x26=
sntz\x3d1\x26usg\x3dAFQjCNGjN1MHxlfN_ip1k-50c3-j_5nljA&#39;;return true;">h=
ttps://github.com/wkaras/C-<wbr>plus-plus-library-bit-fields</a><br></div><=
div><br></div><div>I think the use of macros and reinterpret_cast could be =
eliminated with some tweaks to member pointers in the base language:</div><=
/div></blockquote><div><br>I don&#39;t think we should change the language =
to legitimize this particular library. If your suggested features have broa=
der uses than your library, then you should explain what they are.<br><br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div></d=
iv><div>o =C2=A0Allow static_cast&lt;size_t&gt;(mp) where mp is a pointer t=
o a data member of a Standard Layout Class.</div></div></blockquote><div><b=
r>And... what would that do? What does it mean to convert a member pointer =
into a number? What does this number mean, and why does it matter if the cl=
ass is standard layout or not?<br><br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddin=
g-left: 1ex;"><div dir=3D"ltr"><div></div><div>o =C2=A0Eliminate the need f=
or boilerplate &amp; and class name prefix when the context implies them. =
=C2=A0So:</div><div><br></div><div>int Cls::*p =3D &amp;x.i;</div><div><br>=
</div><div>could be written simply as:</div><div><br></div><div>int Cls::*p=
 =3D i;</div></div></blockquote><div><br>What &quot;context&quot; creates t=
his implication? How do you know which `x` you&#39;re talking about, if the=
re are multiple variables of type `Cls` (assuming that `x` is supposed to b=
e of type `Cls`)?<br><br></div><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"><div>o =C2=A0Allow member pointers to members of members =
and base classes. =C2=A0Possible syntax (showing boiler plate):</div><div><=
br></div><div>mp1 =3D &amp;Cls::x.y; // member of member</div><div>mp2 =3D =
&amp;Cls::Base; // base</div><div>mp3 =3D &amp;Cls::Base::SubBase; // sub-b=
ase<br></div></div></blockquote><div><br>... no. Just... no.<br></div></div=
>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/bae85a90-2e5a-47b5-ae12-d3578a455a2c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/bae85a90-2e5a-47b5-ae12-d3578a455a2c=
%40isocpp.org</a>.<br />

------=_Part_9_2135695268.1467419984255--

------=_Part_8_36983604.1467419984255--

.

------=_Part_3501_880540368.1467431159696
Content-Type: multipart/alternative;
 boundary="----=_Part_3502_85103169.1467431159702"

------=_Part_3502_85103169.1467431159702
Content-Type: text/plain; charset=UTF-8



On Friday, July 1, 2016 at 10:57:35 AM UTC-4, Walt Karas wrote:
>
> This prototype could be used as a starting point:
>
> https://github.com/wkaras/C-plus-plus-library-bit-fields
>
> I think the use of macros and reinterpret_cast could be eliminated with
> some tweaks to member pointers in the base language:
>
> o  Allow static_cast<size_t>(mp) where mp is a pointer to a data member of
> a Standard Layout Class.
>
> o  Eliminate the need for boilerplate & and class name prefix when the
> context implies them.  So:
>
> int Cls::*p = &x.i;
>

Typo, replace with:

int Cls::*p = &Cls::i;



>
> could be written simply as:
>
> int Cls::*p = i;
>
> o  Allow member pointers to members of members and base classes.  Possible
> syntax (showing boiler plate):
>
> mp1 = &Cls::x.y; // member of member
> mp2 = &Cls::Base; // base
> mp3 = &Cls::Base::SubBase; // sub-base
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/43fedeb4-bd0c-4ea9-9d34-13e4325c86fa%40isocpp.org.

------=_Part_3502_85103169.1467431159702
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Friday, July 1, 2016 at 10:57:35 AM UTC-4, Walt=
 Karas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
This prototype could be used as a starting point:<div><br></div><div><a hre=
f=3D"https://github.com/wkaras/C-plus-plus-library-bit-fields" target=3D"_b=
lank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://www.google.c=
om/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fwkaras%2FC-plus-plus-library-bit-fie=
lds\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGjN1MHxlfN_ip1k-50c3-j_5nljA&#3=
9;;return true;" onclick=3D"this.href=3D&#39;https://www.google.com/url?q\x=
3dhttps%3A%2F%2Fgithub.com%2Fwkaras%2FC-plus-plus-library-bit-fields\x26sa\=
x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGjN1MHxlfN_ip1k-50c3-j_5nljA&#39;;return =
true;">https://github.com/wkaras/C-<wbr>plus-plus-library-bit-fields</a><br=
></div><div><br></div><div>I think the use of macros and reinterpret_cast c=
ould be eliminated with some tweaks to member pointers in the base language=
:</div><div><br></div><div>o =C2=A0Allow static_cast&lt;size_t&gt;(mp) wher=
e mp is a pointer to a data member of a Standard Layout Class.</div><div><b=
r></div><div>o =C2=A0Eliminate the need for boilerplate &amp; and class nam=
e prefix when the context implies them. =C2=A0So:</div><div><br></div><div>=
int Cls::*p =3D &amp;x.i;</div></div></blockquote><div><br></div><div>Typo,=
 replace with:</div><div><br></div><div>int Cls::*p =3D &amp;Cls::i;</div><=
div><br></div><div>=C2=A0</div><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"><div><br></div><div>could be written simply as:</div><div=
><br></div><div>int Cls::*p =3D i;</div><div><br></div><div>o =C2=A0Allow m=
ember pointers to members of members and base classes. =C2=A0Possible synta=
x (showing boiler plate):</div><div><br></div><div>mp1 =3D &amp;Cls::x.y; /=
/ member of member</div><div>mp2 =3D &amp;Cls::Base; // base</div><div>mp3 =
=3D &amp;Cls::Base::SubBase; // sub-base<br></div></div></blockquote></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/43fedeb4-bd0c-4ea9-9d34-13e4325c86fa%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/43fedeb4-bd0c-4ea9-9d34-13e4325c86fa=
%40isocpp.org</a>.<br />

------=_Part_3502_85103169.1467431159702--

------=_Part_3501_880540368.1467431159696--

.

------=_Part_10249_507495533.1467474006941
Content-Type: multipart/alternative;
 boundary="----=_Part_10250_816874862.1467474006941"

------=_Part_10250_816874862.1467474006941
Content-Type: text/plain; charset=UTF-8



On Friday, July 1, 2016 at 8:39:44 PM UTC-4, Nicol Bolas wrote:
>
> On Friday, July 1, 2016 at 10:57:35 AM UTC-4, Walt Karas wrote:
>>
>> This prototype could be used as a starting point:
>>
>> https://github.com/wkaras/C-plus-plus-library-bit-fields
>>
>> I think the use of macros and reinterpret_cast could be eliminated with
>> some tweaks to member pointers in the base language:
>>
>
> I don't think we should change the language to legitimize this particular
> library. If your suggested features have broader uses than your library,
> then you should explain what they are.
>

Removing boilerplate is useful syntactic sugar.  Base classes are members
with different syntax and useful additional properties.  It seems
straightforward that pointers to accessible members of members would have
generally the same uses as pointers to accessible members.


>
> o  Allow static_cast<size_t>(mp) where mp is a pointer to a data member of
>> a Standard Layout Class.
>>
>
> And... what would that do? What does it mean to convert a member pointer
> into a number? What does this number mean, and why does it matter if the
> class is standard layout or not?
>

The cast of a data member pointer to size_t would have the same value as
offsetof the (pointed-to) data member.


--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/3a4e4ad9-d231-4ffe-b213-b1edc1fe5e4d%40isocpp.org.

------=_Part_10250_816874862.1467474006941
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Friday, July 1, 2016 at 8:39:44 PM UTC-4, Nicol=
 Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
On Friday, July 1, 2016 at 10:57:35 AM UTC-4, Walt Karas 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">This prototype could be used a=
s a starting point:<div><br></div><div><a href=3D"https://github.com/wkaras=
/C-plus-plus-library-bit-fields" rel=3D"nofollow" target=3D"_blank" onmouse=
down=3D"this.href=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgith=
ub.com%2Fwkaras%2FC-plus-plus-library-bit-fields\x26sa\x3dD\x26sntz\x3d1\x2=
6usg\x3dAFQjCNGjN1MHxlfN_ip1k-50c3-j_5nljA&#39;;return true;" onclick=3D"th=
is.href=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fw=
karas%2FC-plus-plus-library-bit-fields\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAF=
QjCNGjN1MHxlfN_ip1k-50c3-j_5nljA&#39;;return true;">https://github.com/wkar=
as/C-<wbr>plus-plus-library-bit-fields</a><br></div><div><br></div><div>I t=
hink the use of macros and reinterpret_cast could be eliminated with some t=
weaks to member pointers in the base language:</div></div></blockquote><div=
><br>I don&#39;t think we should change the language to legitimize this par=
ticular library. If your suggested features have broader uses than your lib=
rary, then you should explain what they are.<br></div></div></blockquote><d=
iv><br></div><div>Removing boilerplate is useful syntactic sugar. =C2=A0Bas=
e classes are members with different syntax and useful additional propertie=
s. =C2=A0It seems straightforward that pointers to accessible members of me=
mbers would have generally the same uses as pointers to accessible members.=
</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div di=
r=3D"ltr"><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:=
0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><div></div><div>o =C2=A0Allow static_cast&lt;size_t&gt;(mp) where =
mp is a pointer to a data member of a Standard Layout Class.</div></div></b=
lockquote><div><br>And... what would that do? What does it mean to convert =
a member pointer into a number? What does this number mean, and why does it=
 matter if the class is standard layout or not?<br></div></div></blockquote=
><div><br></div><div>The cast of a data member pointer to size_t would have=
 the same value as offsetof the (pointed-to) data member.</div><div>=C2=A0<=
/div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/3a4e4ad9-d231-4ffe-b213-b1edc1fe5e4d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/3a4e4ad9-d231-4ffe-b213-b1edc1fe5e4d=
%40isocpp.org</a>.<br />

------=_Part_10250_816874862.1467474006941--

------=_Part_10249_507495533.1467474006941--

.

------=_Part_288_182376300.1467474898745
Content-Type: multipart/alternative;
 boundary="----=_Part_289_1396058179.1467474898745"

------=_Part_289_1396058179.1467474898745
Content-Type: text/plain; charset=UTF-8

On Friday, July 1, 2016 at 11:46:00 PM UTC-4, Walt Karas wrote:
>
>
>
> On Friday, July 1, 2016 at 10:57:35 AM UTC-4, Walt Karas wrote:
>>
>> This prototype could be used as a starting point:
>>
>> https://github.com/wkaras/C-plus-plus-library-bit-fields
>>
>> I think the use of macros and reinterpret_cast could be eliminated with
>> some tweaks to member pointers in the base language:
>>
>> o  Allow static_cast<size_t>(mp) where mp is a pointer to a data member
>> of a Standard Layout Class.
>>
>> o  Eliminate the need for boilerplate & and class name prefix when the
>> context implies them.  So:
>>
>> int Cls::*p = &x.i;
>>
>
> Typo, replace with:
>
> int Cls::*p = &Cls::i;
>
>
>
>>
>> could be written simply as:
>>
>> int Cls::*p = i;
>>
>> o  Allow member pointers to members of members and base classes.
>>  Possible syntax (showing boiler plate):
>>
>> mp1 = &Cls::x.y; // member of member
>> mp2 = &Cls::Base; // base
>> mp3 = &Cls::Base::SubBase; // sub-base
>>
>
My thinking is that, with these changes, bit field structure use could look
something like:

std::bitf<Traits, Format>::mem x;
x[u.v] = 57; // v a member of u, a member of Format, which is a bit field
format structure

Or, with the dot operator overloading proposal, accessing a bit field could
look the same as it currently does.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/222b413d-87f4-4ad6-99a3-9090e5f03289%40isocpp.org.

------=_Part_289_1396058179.1467474898745
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Friday, July 1, 2016 at 11:46:00 PM UTC-4, Walt Karas w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><br><br>=
On Friday, July 1, 2016 at 10:57:35 AM UTC-4, Walt Karas 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">This prototype could be used a=
s a starting point:<div><br></div><div><a href=3D"https://github.com/wkaras=
/C-plus-plus-library-bit-fields" rel=3D"nofollow" target=3D"_blank" onmouse=
down=3D"this.href=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgith=
ub.com%2Fwkaras%2FC-plus-plus-library-bit-fields\x26sa\x3dD\x26sntz\x3d1\x2=
6usg\x3dAFQjCNGjN1MHxlfN_ip1k-50c3-j_5nljA&#39;;return true;" onclick=3D"th=
is.href=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fw=
karas%2FC-plus-plus-library-bit-fields\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAF=
QjCNGjN1MHxlfN_ip1k-50c3-j_5nljA&#39;;return true;">https://github.com/wkar=
as/C-<wbr>plus-plus-library-bit-fields</a><br></div><div><br></div><div>I t=
hink the use of macros and reinterpret_cast could be eliminated with some t=
weaks to member pointers in the base language:</div><div><br></div><div>o =
=C2=A0Allow static_cast&lt;size_t&gt;(mp) where mp is a pointer to a data m=
ember of a Standard Layout Class.</div><div><br></div><div>o =C2=A0Eliminat=
e the need for boilerplate &amp; and class name prefix when the context imp=
lies them. =C2=A0So:</div><div><br></div><div>int Cls::*p =3D &amp;x.i;</di=
v></div></blockquote><div><br></div><div>Typo, replace with:</div><div><br>=
</div><div>int Cls::*p =3D &amp;Cls::i;</div><div><br></div><div>=C2=A0</di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><br></div><=
div>could be written simply as:</div><div><br></div><div>int Cls::*p =3D i;=
</div><div><br></div><div>o =C2=A0Allow member pointers to members of membe=
rs and base classes. =C2=A0Possible syntax (showing boiler plate):</div><di=
v><br></div><div>mp1 =3D &amp;Cls::x.y; // member of member</div><div>mp2 =
=3D &amp;Cls::Base; // base</div><div>mp3 =3D &amp;Cls::Base::SubBase; // s=
ub-base<br></div></div></blockquote></div></blockquote><div><br></div><div>=
My thinking is that, with these changes, bit field structure use could look=
 something like:</div><div><br></div><div>std::bitf&lt;Traits, Format&gt;::=
mem x;</div><div>x[u.v] =3D 57; // v a member of u, a member of Format, whi=
ch is a bit field format structure</div><div><br></div><div>Or, with the do=
t operator overloading proposal, accessing a bit field could look the same =
as it currently does.</div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/222b413d-87f4-4ad6-99a3-9090e5f03289%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/222b413d-87f4-4ad6-99a3-9090e5f03289=
%40isocpp.org</a>.<br />

------=_Part_289_1396058179.1467474898745--

------=_Part_288_182376300.1467474898745--

.

------=_Part_4053_836112599.1467476527627
Content-Type: multipart/alternative;
 boundary="----=_Part_4054_1583245695.1467476527628"

------=_Part_4054_1583245695.1467476527628
Content-Type: text/plain; charset=UTF-8

On Saturday, July 2, 2016 at 11:40:07 AM UTC-4, Walt Karas wrote:
>
> On Friday, July 1, 2016 at 8:39:44 PM UTC-4, Nicol Bolas wrote:
>>
>> On Friday, July 1, 2016 at 10:57:35 AM UTC-4, Walt Karas wrote:
>>>
>>> This prototype could be used as a starting point:
>>>
>>> https://github.com/wkaras/C-plus-plus-library-bit-fields
>>>
>>> I think the use of macros and reinterpret_cast could be eliminated with
>>> some tweaks to member pointers in the base language:
>>>
>>
>> I don't think we should change the language to legitimize this particular
>> library. If your suggested features have broader uses than your library,
>> then you should explain what they are.
>>
>
> Removing boilerplate is useful syntactic sugar.
>

Removing "boilerplate" from rarely used features is not "useful syntactic
sugar".

Also, is there something wrong with `auto x = &Typename::member;`? It seems
to me that the standard means of removing boilerplate works just fine.


> Base classes are members with different syntax and useful additional
> properties.
>

Base classes are not members. Base classes and non-static data members are
both *subobjects*.

It seems straightforward that pointers to accessible members of members
> would have generally the same uses as pointers to accessible members.
>

.... why?

Member pointers aren't exactly the most useful C++ feature in the world
as-is. They serve a function, to be sure. But it's not clear what the point
of getting a member pointer to a base class subobject for a type would be.

o  Allow static_cast<size_t>(mp) where mp is a pointer to a data member of
>>> a Standard Layout Class.
>>>
>>
>> And... what would that do? What does it mean to convert a member pointer
>> into a number? What does this number mean, and why does it matter if the
>> class is standard layout or not?
>>
>
> The cast of a data member pointer to size_t would have the same value as
> offsetof the (pointed-to) data member.
>

I like the idea of having the ability to convert a pointer-to-data-member
into a byte offset without having to employ macro-gymnastics. And the
compiler would detect whether such a conversion is legal based on the type
of the member pointer; if you pass a non-standard layout type, you get a
compile error. That's good.

What I don't like is using a `static_cast` for it. It feels... wrong. At
the very least, `size_t` is the wrong type for using `static_cast`. It
ought to be `ptrdiff_t`, which makes it more clear that you are getting an
offset. Of course, that would require that `ptrdiff_t` be made into a type
which is distinct from all other integer types (a strong alias), which can
still be implicitly converted to other integer types.

Really, I think it would be better to have a standard library function that
will be implemented via compiler magic. The function would be `constexpr`,
and it would take as a parameter a pointer-to-data-member. If you call it
with a non-standard layout type or something that isn't a
pointer-to-data-member, you get a hard error.

At the same time, I'm not sure why it is necessary that the type be
standard layout. `offsetof` only works for those types because it's based
on the rules of C. This new feature can be based on whatever rules we want,
so we could open things up a bit. So long as virtual inheritance boundaries
aren't being crossed, there should be a static, compile-time offset that
can be retrieved. Using that offset requires an object whose dynamic type
is the same as the type of the member pointer, or is one that is layout
compatible with 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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f35af350-a76e-4f5d-9af8-325cab337e4f%40isocpp.org.

------=_Part_4054_1583245695.1467476527628
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Saturday, July 2, 2016 at 11:40:07 AM UTC-4, Walt Karas=
 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">On Fri=
day, July 1, 2016 at 8:39:44 PM UTC-4, Nicol Bolas wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr">On Friday, July 1, 2016 at 10:57:35=
 AM UTC-4, Walt Karas wrote:<blockquote class=3D"gmail_quote" style=3D"marg=
in:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div di=
r=3D"ltr">This prototype could be used as a starting point:<div><br></div><=
div><a href=3D"https://github.com/wkaras/C-plus-plus-library-bit-fields" re=
l=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=3D&#39;https://ww=
w.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fwkaras%2FC-plus-plus-libra=
ry-bit-fields\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGjN1MHxlfN_ip1k-50c3-=
j_5nljA&#39;;return true;" onclick=3D"this.href=3D&#39;https://www.google.c=
om/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fwkaras%2FC-plus-plus-library-bit-fie=
lds\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGjN1MHxlfN_ip1k-50c3-j_5nljA&#3=
9;;return true;">https://github.com/wkaras/C-<wbr>plus-plus-library-bit-fie=
lds</a><br></div><div><br></div><div>I think the use of macros and reinterp=
ret_cast could be eliminated with some tweaks to member pointers in the bas=
e language:</div></div></blockquote><div><br>I don&#39;t think we should ch=
ange the language to legitimize this particular library. If your suggested =
features have broader uses than your library, then you should explain what =
they are.<br></div></div></blockquote><div><br></div><div>Removing boilerpl=
ate is useful syntactic sugar.</div></div></blockquote><div><br>Removing &q=
uot;boilerplate&quot; from rarely used features is not &quot;useful syntact=
ic sugar&quot;.<br><br>Also, is there something wrong with `auto x =3D &amp=
;Typename::member;`? It seems to me that the standard means of removing boi=
lerplate works just fine.<br>=C2=A0</div><blockquote class=3D"gmail_quote" =
style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-l=
eft: 1ex;"><div dir=3D"ltr"><div>Base classes are members with different sy=
ntax and useful additional properties.</div></div></blockquote><div><br>Bas=
e classes are not members. Base classes and non-static data members are bot=
h <i>subobjects</i>.<br><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div dir=3D"ltr"><div>It seems straightforward that pointers to acces=
sible members of members would have generally the same uses as pointers to =
accessible members.</div></div></blockquote><div><br>... why?<br><br>Member=
 pointers aren&#39;t exactly the most useful C++ feature in the world as-is=
.. They serve a function, to be sure. But it&#39;s not clear what the point =
of getting a member pointer to a base class subobject for a type would be.<=
br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
<div></div><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"><blockq=
uote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div></div><div>o =C2=A0A=
llow static_cast&lt;size_t&gt;(mp) where mp is a pointer to a data member o=
f a Standard Layout Class.</div></div></blockquote><div><br>And... what wou=
ld that do? What does it mean to convert a member pointer into a number? Wh=
at does this number mean, and why does it matter if the class is standard l=
ayout or not?<br></div></div></blockquote><div><br></div><div>The cast of a=
 data member pointer to size_t would have the same value as offsetof the (p=
ointed-to) data member.</div></div></blockquote><div><br>I like the idea of=
 having the ability to convert a pointer-to-data-member into a byte offset =
without having to employ macro-gymnastics. And the compiler would detect wh=
ether such a conversion is legal based on the type of the member pointer; i=
f you pass a non-standard layout type, you get a compile error. That&#39;s =
good.<br><br>What I don&#39;t like is using a `static_cast` for it. It feel=
s... wrong. At the very least, `size_t` is the wrong type for using `static=
_cast`.=20
It ought to be `ptrdiff_t`, which makes it more clear that you are=20
getting an offset. Of course, that would require that `ptrdiff_t` be=20
made into a type which is distinct from all other integer types (a=20
strong alias), which can still be implicitly converted to other integer=20
types.<br><br>Really, I think it would be better to have a standard library=
 function that will be implemented via compiler magic. The function would b=
e `constexpr`, and it would take as a parameter a pointer-to-data-member. I=
f you call it with a non-standard layout type or something that isn&#39;t a=
 pointer-to-data-member, you get a hard error.<br><br>At the same time, I&#=
39;m not sure why it is necessary that the type be standard layout. `offset=
of` only works for those types because it&#39;s based on the rules of C. Th=
is new feature can be based on whatever rules we want, so we could open thi=
ngs up a bit. So long as virtual inheritance boundaries aren&#39;t being cr=
ossed, there should be a static, compile-time offset that can be retrieved.=
 Using that offset requires an object whose dynamic type is the same as the=
 type of the member pointer, or is one that is layout compatible with it.<b=
r></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f35af350-a76e-4f5d-9af8-325cab337e4f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f35af350-a76e-4f5d-9af8-325cab337e4f=
%40isocpp.org</a>.<br />

------=_Part_4054_1583245695.1467476527628--

------=_Part_4053_836112599.1467476527627--

.

------=_Part_3084_2011059465.1467478884259
Content-Type: multipart/alternative;
 boundary="----=_Part_3085_1920672626.1467478884259"

------=_Part_3085_1920672626.1467478884259
Content-Type: text/plain; charset=UTF-8



On Saturday, July 2, 2016 at 12:22:07 PM UTC-4, Nicol Bolas wrote:
>
> On Saturday, July 2, 2016 at 11:40:07 AM UTC-4, Walt Karas wrote:
>>
>> It seems straightforward that pointers to accessible members of members
>> would have generally the same uses as pointers to accessible members.
>>
>
> ... why?
>
> Member pointers aren't exactly the most useful C++ feature in the world
> as-is. They serve a function, to be sure. But it's not clear what the point
> of getting a member pointer to a base class subobject for a type would be.
>

If one doesn't consider member pointers to be a worthy feature, it's
unlikely one would see tweeking them as a worthy effort.

I have hopes that people who use bit fields, or wish they were more usable,
will like my library.   And want to see it made more clean with tweeks to
the Standard.

I would think others would like my library because it helps provide grounds
for depricating bit fields in the base language.  But it's understandable
they would not want to put it in the Standard or tweek the Standard to
improve it.  The library has very high de facto portability, so putting it
in the Standard would primarily serve to advertise it.  It might open a
floodgate to start putting (more) libraries in the Standard to advertise
them.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/901ad0a5-1616-4873-80c9-92b34fd592b2%40isocpp.org.

------=_Part_3085_1920672626.1467478884259
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Saturday, July 2, 2016 at 12:22:07 PM UTC-4, Ni=
col Bolas 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"lt=
r">On Saturday, July 2, 2016 at 11:40:07 AM UTC-4, Walt Karas wrote:<blockq=
uote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>It seems straightfor=
ward that pointers to accessible members of members would have generally th=
e same uses as pointers to accessible members.</div></div></blockquote><div=
><br>... why?<br><br>Member pointers aren&#39;t exactly the most useful C++=
 feature in the world as-is. They serve a function, to be sure. But it&#39;=
s not clear what the point of getting a member pointer to a base class subo=
bject for a type would be.<br></div></div></blockquote><div><br></div><div>=
If one doesn&#39;t consider member pointers to be a worthy feature, it&#39;=
s unlikely one would see tweeking them as a worthy effort.</div><div><br></=
div><div>I have hopes that people who use bit fields, or wish they were mor=
e usable, will like my library. =C2=A0 And want to see it made more clean w=
ith tweeks to the Standard.</div><div><br></div><div>I would think others w=
ould like my library because it helps provide grounds for depricating bit f=
ields in the base language. =C2=A0But it&#39;s understandable they would no=
t want to put it in the Standard or tweek the Standard to improve it. =C2=
=A0The library has very high de facto portability, so putting it in the Sta=
ndard would primarily serve to advertise it. =C2=A0It might open a floodgat=
e to start putting (more) libraries in the Standard to advertise them.</div=
></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/901ad0a5-1616-4873-80c9-92b34fd592b2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/901ad0a5-1616-4873-80c9-92b34fd592b2=
%40isocpp.org</a>.<br />

------=_Part_3085_1920672626.1467478884259--

------=_Part_3084_2011059465.1467478884259--

.