Topic: I propose that they add the concept of a "bump
Author: Tony V E <tvaneerd@gmail.com>
Date: Sat, 18 Aug 2018 17:31:58 -0400
Raw View
<html><head></head><body lang=3D"en-US" style=3D"background-color: rgb(255,=
255, 255); line-height: initial;"> =
<div style=3D"width: 100%; fo=
nt-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif=
; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, =
255, 255);">Why would this be called 'bump'?</div> =
=
<div style=3D"width: 100%; font-size: init=
ial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(=
31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);"><=
br style=3D"display:initial"></div> =
=
=
<div style=3D"font-size: initial; font-family: Calibri, 'Slate Pro', s=
ans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; backgr=
ound-color: rgb(255, 255, 255);">Sent from my BlackBerry&nbs=
p;portable Babbage Device</div> =
=
<table=
width=3D"100%" style=3D"background-color:white;border-spacing:0px;"> <tbod=
y><tr><td colspan=3D"2" style=3D"font-size: initial; text-align: initial; b=
ackground-color: rgb(255, 255, 255);"> <div style=
=3D"border-style: solid none none; border-top-color: rgb(181, 196, 223); bo=
rder-top-width: 1pt; padding: 3pt 0in 0in; font-family: Tahoma, 'BB Alpha S=
ans', 'Slate Pro'; font-size: 10pt;"> <div><b>From: </b>wm2015email@gmail.=
com</div><div><b>Sent: </b>Saturday, August 18, 2018 5:24 PM</div><div><b>T=
o: </b>ISO C++ Standard - Future Proposals</div><div><b>Reply To: </b>std-p=
roposals@isocpp.org</div><div><b>Subject: </b>[std-proposals] I propose tha=
t they add the concept of a "bump" to C++.</div></div></td></tr></tbody></t=
able><div style=3D"border-style: solid none none; border-top-color: rgb(186=
, 188, 209); border-top-width: 1pt; font-size: initial; text-align: initial=
; background-color: rgb(255, 255, 255);"></div><br><div id=3D"_originalCont=
ent" style=3D""><div dir=3D"ltr"><div><br></div><div>I propose that they ad=
d the concept of a "bump" to modern C++. You want a integer type that=
's treated like a restricted bit width integer... but you don't want the co=
mplexity of messing around with picking the correct uint size and setting u=
p a bit field.. and you don't want the slowness of packing and unpacking bi=
t fields together that the compiler does behind the scenes... thus, the con=
cept of a "Bump" integer type:</div><div><br></div><div><b> bu=
mp<2> x; =3D> maps to =3D> uint8_t:0; uint8=
_t x : 2;</b></div><div><div style=3D"margin: 0px; padding: 0px; border: 0p=
x rgb(34, 34, 34); border-image: none; text-align: left; color: rgb(34, 34,=
34); text-transform: none; text-indent: 0px; letter-spacing: normal; font-=
size: 13px; font-style: normal; font-variant: normal; text-decoration: none=
; word-spacing: 0px; white-space: normal; orphans: 2; -webkit-text-stroke-w=
idth: 0px; background-color: transparent;"><b> bump<7>&n=
bsp; x; =3D> maps to =3D> uint8_t:0; uint8_t x : 7;</b>=
</div><i></i><u></u><sub></sub><sup></sup><strike></strike><div style=3D"ma=
rgin: 0px; padding: 0px; border: 0px rgb(34, 34, 34); border-image: none; t=
ext-align: left; color: rgb(34, 34, 34); text-transform: none; text-indent:=
0px; letter-spacing: normal; font-size: 13px; font-style: normal; font-var=
iant: normal; text-decoration: none; word-spacing: 0px; white-space: normal=
; orphans: 2; -webkit-text-stroke-width: 0px; background-color: transparent=
;"><b> bump<18> x; =3D> maps to =3D> =
uint16_t:0; uint16_t x : 18; </b></div><i style=3D"background: none; =
margin: 0px; padding: 0px; border: 0px rgb(34, 34, 34); border-image: none;=
height: auto; text-align: left; color: rgb(34, 34, 34); text-transform: no=
ne; text-indent: 0px; letter-spacing: normal; overflow: visible; font-size:=
13px; font-style: italic; font-variant: normal; text-decoration: none; wor=
d-spacing: 0px; white-space: normal; overflow-x: visible; overflow-y: visib=
le; min-width: 0px; orphans: 2; -webkit-text-stroke-width: 0px;"></i><u sty=
le=3D"background: none; margin: 0px; padding: 0px; border: 0px rgb(34, 34, =
34); border-image: none; height: auto; text-align: left; color: rgb(34, 34,=
34); text-transform: none; text-indent: 0px; letter-spacing: normal; overf=
low: visible; font-size: 13px; font-style: normal; font-variant: normal; te=
xt-decoration: underline; word-spacing: 0px; white-space: normal; overflow-=
x: visible; overflow-y: visible; min-width: 0px; orphans: 2; -webkit-text-s=
troke-width: 0px;"></u><sub style=3D"margin: 0px; padding: 0px; border: 0px=
rgb(34, 34, 34); border-image: none; text-align: left; color: rgb(34, 34, =
34); text-transform: none; text-indent: 0px; letter-spacing: normal; font-s=
ize: 9px; font-style: normal; font-variant: normal; text-decoration: none; =
word-spacing: 0px; white-space: normal; orphans: 2; -webkit-text-stroke-wid=
th: 0px; background-color: transparent;"></sub><sup style=3D"margin: 0px; p=
adding: 0px; border: 0px rgb(34, 34, 34); border-image: none; text-align: l=
eft; color: rgb(34, 34, 34); text-transform: none; text-indent: 0px; letter=
-spacing: normal; font-size: 9px; font-style: normal; font-variant: normal;=
text-decoration: none; word-spacing: 0px; white-space: normal; orphans: 2;=
-webkit-text-stroke-width: 0px; background-color: transparent;"></sup><str=
ike style=3D"margin: 0px; padding: 0px; border: 0px rgb(34, 34, 34); border=
-image: none; text-align: left; color: rgb(34, 34, 34); text-transform: non=
e; text-indent: 0px; letter-spacing: normal; font-size: 13px; font-style: n=
ormal; font-variant: normal; text-decoration: line-through; word-spacing: 0=
px; white-space: normal; orphans: 2; -webkit-text-stroke-width: 0px; backgr=
ound-color: transparent;"></strike><i></i><u></u><sub></sub><sup></sup><str=
ike></strike><div style=3D"margin: 0px; padding: 0px; border: 0px rgb(34, 3=
4, 34); border-image: none; text-align: left; color: rgb(34, 34, 34); text-=
transform: none; text-indent: 0px; letter-spacing: normal; font-size: 13px;=
font-style: normal; font-variant: normal; text-decoration: none; word-spac=
ing: 0px; white-space: normal; orphans: 2; -webkit-text-stroke-width: 0px; =
background-color: transparent;"><b> bump<35> x; =
=3D> maps to =3D> uint32_t:0; uint32_t x : 35; </b></div=
><div style=3D"margin: 0px; padding: 0px; border: 0px rgb(34, 34, 34); bord=
er-image: none; text-align: left; color: rgb(34, 34, 34); text-transform: n=
one; text-indent: 0px; letter-spacing: normal; font-size: 13px; font-varian=
t: normal; word-spacing: 0px; white-space: normal; orphans: 2; -webkit-text=
-stroke-width: 0px; background-color: transparent;"><div style=3D"margin: 0=
px; padding: 0px; border: 0px rgb(34, 34, 34); border-image: none; text-ali=
gn: left; color: rgb(34, 34, 34); text-transform: none; text-indent: 0px; l=
etter-spacing: normal; font-size: 13px; font-style: normal; font-variant: n=
ormal; text-decoration: none; word-spacing: 0px; white-space: normal; orpha=
ns: 2; -webkit-text-stroke-width: 0px; background-color: transparent;"><b>&=
nbsp; bump<66> x; =3D> maps to =3D> uin64_t=
:0; uint64_t x : 66;</b></div><div style=3D"background-color: transparent; =
border-bottom-color: rgb(34, 34, 34); border-bottom-style: none; border-bot=
tom-width: 0px; border-image-outset: 0; border-image-repeat: stretch; borde=
r-image-slice: 100%; border-image-source: none; border-image-width: 1; bord=
er-left-color: rgb(34, 34, 34); border-left-style: none; border-left-width:=
0px; border-right-color: rgb(34, 34, 34); border-right-style: none; border=
-right-width: 0px; border-top-color: rgb(34, 34, 34); border-top-style: non=
e; border-top-width: 0px; color: rgb(34, 34, 34); font-family: &quot;Ar=
ial&quot;,&quot;Helvetica&quot;,sans-serif; font-size: 13px; fo=
nt-style: normal; font-variant: normal; font-weight: 400; letter-spacing: n=
ormal; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top:=
0px; orphans: 2; padding-bottom: 0px; padding-left: 0px; padding-right: 0p=
x; padding-top: 0px; text-align: left; text-decoration: none; text-indent: =
0px; text-transform: none; -webkit-text-stroke-width: 0px; white-space: nor=
mal; word-spacing: 0px;"><b></b><br></div><div style=3D"background-color: t=
ransparent; border-bottom-color: rgb(34, 34, 34); border-bottom-style: none=
; border-bottom-width: 0px; border-image-outset: 0; border-image-repeat: st=
retch; border-image-slice: 100%; border-image-source: none; border-image-wi=
dth: 1; border-left-color: rgb(34, 34, 34); border-left-style: none; border=
-left-width: 0px; border-right-color: rgb(34, 34, 34); border-right-style: =
none; border-right-width: 0px; border-top-color: rgb(34, 34, 34); border-to=
p-style: none; border-top-width: 0px; color: rgb(34, 34, 34); font-family: =
&quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif; font-si=
ze: 13px; font-style: normal; font-variant: normal; font-weight: 400; lette=
r-spacing: normal; margin-bottom: 0px; margin-left: 0px; margin-right: 0px;=
margin-top: 0px; orphans: 2; padding-bottom: 0px; padding-left: 0px; paddi=
ng-right: 0px; padding-top: 0px; text-align: left; text-decoration: none; t=
ext-indent: 0px; text-transform: none; -webkit-text-stroke-width: 0px; whit=
e-space: normal; word-spacing: 0px;">uint8_t:0 <=3D ensures that bit fie=
ld starts over in a new integer word each time rather than packing them in =
the same integer... </div><div style=3D"background-color: transparent;=
border-bottom-color: rgb(34, 34, 34); border-bottom-style: none; border-bo=
ttom-width: 0px; border-image-outset: 0; border-image-repeat: stretch; bord=
er-image-slice: 100%; border-image-source: none; border-image-width: 1; bor=
der-left-color: rgb(34, 34, 34); border-left-style: none; border-left-width=
: 0px; border-right-color: rgb(34, 34, 34); border-right-style: none; borde=
r-right-width: 0px; border-top-color: rgb(34, 34, 34); border-top-style: no=
ne; border-top-width: 0px; color: rgb(34, 34, 34); font-family: &quot;A=
rial&quot;,&quot;Helvetica&quot;,sans-serif; font-size: 13px; f=
ont-style: normal; font-variant: normal; font-weight: 400; letter-spacing: =
normal; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top=
: 0px; orphans: 2; padding-bottom: 0px; padding-left: 0px; padding-right: 0=
px; padding-top: 0px; text-align: left; text-decoration: none; text-indent:=
0px; text-transform: none; -webkit-text-stroke-width: 0px; white-space: no=
rmal; word-spacing: 0px;"><br></div><div style=3D"background-color: transpa=
rent; border-bottom-color: rgb(34, 34, 34); border-bottom-style: none; bord=
er-bottom-width: 0px; border-image-outset: 0; border-image-repeat: stretch;=
border-image-slice: 100%; border-image-source: none; border-image-width: 1=
; border-left-color: rgb(34, 34, 34); border-left-style: none; border-left-=
width: 0px; border-right-color: rgb(34, 34, 34); border-right-style: none; =
border-right-width: 0px; border-top-color: rgb(34, 34, 34); border-top-styl=
e: none; border-top-width: 0px; color: rgb(34, 34, 34); font-family: &q=
uot;Arial&quot;,&quot;Helvetica&quot;,sans-serif; font-size: 13=
px; font-style: normal; font-variant: normal; font-weight: 400; letter-spac=
ing: normal; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margi=
n-top: 0px; orphans: 2; padding-bottom: 0px; padding-left: 0px; padding-rig=
ht: 0px; padding-top: 0px; text-align: left; text-decoration: none; text-in=
dent: 0px; text-transform: none; -webkit-text-stroke-width: 0px; white-spac=
e: normal; word-spacing: 0px;">I means serious... c++ already support bit f=
ield widths of up 64 bits... why not make "bit fields" an officially suppor=
ted integer type?</div><div style=3D"background-color: transparent; border-=
bottom-color: rgb(34, 34, 34); border-bottom-style: none; border-bottom-wid=
th: 0px; border-image-outset: 0; border-image-repeat: stretch; border-image=
-slice: 100%; border-image-source: none; border-image-width: 1; border-left=
-color: rgb(34, 34, 34); border-left-style: none; border-left-width: 0px; b=
order-right-color: rgb(34, 34, 34); border-right-style: none; border-right-=
width: 0px; border-top-color: rgb(34, 34, 34); border-top-style: none; bord=
er-top-width: 0px; color: rgb(34, 34, 34); font-family: &quot;Arial&=
;quot;,&quot;Helvetica&quot;,sans-serif; font-size: 13px; font-styl=
e: normal; font-variant: normal; font-weight: 400; letter-spacing: normal; =
margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; o=
rphans: 2; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padd=
ing-top: 0px; text-align: left; text-decoration: none; text-indent: 0px; te=
xt-transform: none; -webkit-text-stroke-width: 0px; white-space: normal; wo=
rd-spacing: 0px;"><br></div><div style=3D"background-color: transparent; bo=
rder-bottom-color: rgb(34, 34, 34); border-bottom-style: none; border-botto=
m-width: 0px; border-image-outset: 0; border-image-repeat: stretch; border-=
image-slice: 100%; border-image-source: none; border-image-width: 1; border=
-left-color: rgb(34, 34, 34); border-left-style: none; border-left-width: 0=
px; border-right-color: rgb(34, 34, 34); border-right-style: none; border-r=
ight-width: 0px; border-top-color: rgb(34, 34, 34); border-top-style: none;=
border-top-width: 0px; color: rgb(34, 34, 34); font-family: &quot;Aria=
l&quot;,&quot;Helvetica&quot;,sans-serif; font-size: 13px; font=
-style: normal; font-variant: normal; font-weight: 400; letter-spacing: nor=
mal; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0=
px; orphans: 2; padding-bottom: 0px; padding-left: 0px; padding-right: 0px;=
padding-top: 0px; text-align: left; text-decoration: none; text-indent: 0p=
x; text-transform: none; -webkit-text-stroke-width: 0px; white-space: norma=
l; word-spacing: 0px;">Every single time you instantiate a bump it automati=
cally picked the correct integer size and resets the bit field back to star=
ting at bit zero... thus you can have a fully unpacked struct of bit =
fields without worrying about alignment issues...and its just as fast as us=
ing an integer directly but is restricted in bit width without a mask. =E2=
=80=A6</div><div style=3D"background-color: transparent; border-bottom-colo=
r: rgb(34, 34, 34); border-bottom-style: none; border-bottom-width: 0px; bo=
rder-image-outset: 0; border-image-repeat: stretch; border-image-slice: 100=
%; border-image-source: none; border-image-width: 1; border-left-color: rgb=
(34, 34, 34); border-left-style: none; border-left-width: 0px; border-right=
-color: rgb(34, 34, 34); border-right-style: none; border-right-width: 0px;=
border-top-color: rgb(34, 34, 34); border-top-style: none; border-top-widt=
h: 0px; color: rgb(34, 34, 34); font-family: &quot;Arial&quot;,&=
;quot;Helvetica&quot;,sans-serif; font-size: 13px; font-style: normal; =
font-variant: normal; font-weight: 400; letter-spacing: normal; margin-bott=
om: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; orphans: 2; =
padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0p=
x; text-align: left; text-decoration: none; text-indent: 0px; text-transfor=
m: none; -webkit-text-stroke-width: 0px; white-space: normal; word-spacing:=
0px;"><br></div><div style=3D"margin: 0px; padding: 0px; border: 0px rgb(3=
4, 34, 34); border-image: none; text-align: left; color: rgb(34, 34, 34); t=
ext-transform: none; text-indent: 0px; letter-spacing: normal; font-size: 1=
3px; font-style: normal; font-variant: normal; text-decoration: none; word-=
spacing: 0px; white-space: normal; orphans: 2; -webkit-text-stroke-width: 0=
px; background-color: transparent;"><b> struct mystruct {</b><=
/div><div style=3D"margin: 0px; padding: 0px; border: 0px rgb(34, 34, 34); =
border-image: none; text-align: left; color: rgb(34, 34, 34); text-transfor=
m: none; text-indent: 0px; letter-spacing: normal; font-size: 13px; font-st=
yle: normal; font-variant: normal; text-decoration: none; word-spacing: 0px=
; white-space: normal; orphans: 2; -webkit-text-stroke-width: 0px; backgrou=
nd-color: transparent;"><b> bump<4> =
fieldx;</b></div><div style=3D"margin: 0px; padding: 0px; border: 0px rgb(=
34, 34, 34); border-image: none; text-align: left; color: rgb(34, 34, 34); =
text-transform: none; text-indent: 0px; letter-spacing: normal; font-size: =
13px; font-style: normal; font-variant: normal; text-decoration: none; word=
-spacing: 0px; white-space: normal; orphans: 2; -webkit-text-stroke-width: =
0px; background-color: transparent;"><b> bump<=
;62> fieldy;</b></div><div style=3D"margin: 0px; padding: 0px; border: 0=
px rgb(34, 34, 34); border-image: none; text-align: left; color: rgb(34, 34=
, 34); text-transform: none; text-indent: 0px; letter-spacing: normal; font=
-size: 13px; font-style: normal; font-variant: normal; text-decoration: non=
e; word-spacing: 0px; white-space: normal; orphans: 2; -webkit-text-stroke-=
width: 0px; background-color: transparent;"><b> =
bump<22> fieldz; </b></div><div style=3D"margin: 0px; padding: 0=
px; border: 0px rgb(34, 34, 34); border-image: none; text-align: left; colo=
r: rgb(34, 34, 34); text-transform: none; text-indent: 0px; letter-spacing:=
normal; font-size: 13px; font-style: normal; font-variant: normal; text-de=
coration: none; word-spacing: 0px; white-space: normal; orphans: 2; -webkit=
-text-stroke-width: 0px; background-color: transparent;"><b> &=
nbsp; uint32_t etcetc;</b></div><div style=3D"mar=
gin: 0px; padding: 0px; border: 0px rgb(34, 34, 34); border-image: none; te=
xt-align: left; color: rgb(34, 34, 34); text-transform: none; text-indent: =
0px; letter-spacing: normal; font-size: 13px; font-style: normal; font-vari=
ant: normal; text-decoration: none; word-spacing: 0px; white-space: normal;=
orphans: 2; -webkit-text-stroke-width: 0px; background-color: transparent;=
"><b> }</b></div><div style=3D"background-color: transparent; =
border-bottom-color: rgb(34, 34, 34); border-bottom-style: none; border-bot=
tom-width: 0px; border-image-outset: 0; border-image-repeat: stretch; borde=
r-image-slice: 100%; border-image-source: none; border-image-width: 1; bord=
er-left-color: rgb(34, 34, 34); border-left-style: none; border-left-width:=
0px; border-right-color: rgb(34, 34, 34); border-right-style: none; border=
-right-width: 0px; border-top-color: rgb(34, 34, 34); border-top-style: non=
e; border-top-width: 0px; color: rgb(34, 34, 34); font-family: &quot;Ar=
ial&quot;,&quot;Helvetica&quot;,sans-serif; font-size: 13px; fo=
nt-style: normal; font-variant: normal; font-weight: 400; letter-spacing: n=
ormal; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top:=
0px; orphans: 2; padding-bottom: 0px; padding-left: 0px; padding-right: 0p=
x; padding-top: 0px; text-align: left; text-decoration: none; text-indent: =
0px; text-transform: none; -webkit-text-stroke-width: 0px; white-space: nor=
mal; word-spacing: 0px;"><b></b><br></div><div style=3D"background-color: t=
ransparent; border-bottom-color: rgb(34, 34, 34); border-bottom-style: none=
; border-bottom-width: 0px; border-image-outset: 0; border-image-repeat: st=
retch; border-image-slice: 100%; border-image-source: none; border-image-wi=
dth: 1; border-left-color: rgb(34, 34, 34); border-left-style: none; border=
-left-width: 0px; border-right-color: rgb(34, 34, 34); border-right-style: =
none; border-right-width: 0px; border-top-color: rgb(34, 34, 34); border-to=
p-style: none; border-top-width: 0px; color: rgb(34, 34, 34); font-family: =
&quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif; font-si=
ze: 13px; font-style: normal; font-variant: normal; font-weight: 400; lette=
r-spacing: normal; margin-bottom: 0px; margin-left: 0px; margin-right: 0px;=
margin-top: 0px; orphans: 2; padding-bottom: 0px; padding-left: 0px; paddi=
ng-right: 0px; padding-top: 0px; text-align: left; text-decoration: none; t=
ext-indent: 0px; text-transform: none; -webkit-text-stroke-width: 0px; whit=
e-space: normal; word-spacing: 0px;"><br></div><b></b><i></i><u></u><sub></=
sub><sup></sup><strike></strike>I could do this now using some messy macros=
:</div><div style=3D"margin: 0px; padding: 0px; border: 0px rgb(34, 34, 34)=
; border-image: none; text-align: left; color: rgb(34, 34, 34); text-transf=
orm: none; text-indent: 0px; letter-spacing: normal; font-size: 13px; font-=
variant: normal; word-spacing: 0px; white-space: normal; orphans: 2; -webki=
t-text-stroke-width: 0px; background-color: transparent;"><br></div><div st=
yle=3D"margin: 0px; padding: 0px; border: 0px rgb(34, 34, 34); border-image=
: none; text-align: left; color: rgb(34, 34, 34); text-transform: none; tex=
t-indent: 0px; letter-spacing: normal; font-size: 13px; font-variant: norma=
l; word-spacing: 0px; white-space: normal; orphans: 2; -webkit-text-stroke-=
width: 0px; background-color: transparent;"> #define bump(T, N=
AME, WIDTH) T :0; T NAME : WIDTH;<br></div><div style=3D"margin: 0px=
; padding: 0px; border: 0px rgb(34, 34, 34); border-image: none; text-align=
: left; color: rgb(34, 34, 34); text-transform: none; text-indent: 0px; let=
ter-spacing: normal; font-size: 13px; font-variant: normal; word-spacing: 0=
px; white-space: normal; orphans: 2; -webkit-text-stroke-width: 0px; backgr=
ound-color: transparent;"><br></div><div style=3D"margin: 0px; padding: 0px=
; border: 0px rgb(34, 34, 34); border-image: none; text-align: left; color:=
rgb(34, 34, 34); text-transform: none; text-indent: 0px; letter-spacing: n=
ormal; font-size: 13px; font-variant: normal; word-spacing: 0px; white-spac=
e: normal; orphans: 2; -webkit-text-stroke-width: 0px; background-color: tr=
ansparent;"> struct mystruct {</div><div style=3D"margin: 0px; =
padding: 0px; border: 0px rgb(34, 34, 34); border-image: none; text-align: =
left; color: rgb(34, 34, 34); text-transform: none; text-indent: 0px; lette=
r-spacing: normal; font-size: 13px; font-variant: normal; word-spacing: 0px=
; white-space: normal; orphans: 2; -webkit-text-stroke-width: 0px; backgrou=
nd-color: transparent;"> bump(uint8_t, fie=
ldx, 4);</div><div style=3D"margin: 0px; padding: 0px; border: 0px rgb(34, =
34, 34); border-image: none; text-align: left; color: rgb(34, 34, 34); text=
-transform: none; text-indent: 0px; letter-spacing: normal; font-size: 13px=
; font-variant: normal; word-spacing: 0px; white-space: normal; orphans: 2;=
-webkit-text-stroke-width: 0px; background-color: transparent;"> &nb=
sp; bump(uint64_t, fieldy, 62);</div><div style=3D"margin: 0px=
; padding: 0px; border: 0px rgb(34, 34, 34); border-image: none; text-align=
: left; color: rgb(34, 34, 34); text-transform: none; text-indent: 0px; let=
ter-spacing: normal; font-size: 13px; font-variant: normal; word-spacing: 0=
px; white-space: normal; orphans: 2; -webkit-text-stroke-width: 0px; backgr=
ound-color: transparent;"> bump(uint32_t, fieldz,=
22);</div><div style=3D"margin: 0px; padding: 0px; border: 0px rgb(34, 34,=
34); border-image: none; text-align: left; color: rgb(34, 34, 34); text-tr=
ansform: none; text-indent: 0px; letter-spacing: normal; font-size: 13px; f=
ont-variant: normal; word-spacing: 0px; white-space: normal; orphans: 2; -w=
ebkit-text-stroke-width: 0px; background-color: transparent;"> =
uint32_t etcetc;</div><div style=3D"margin: 0px; paddin=
g: 0px; border: 0px rgb(34, 34, 34); border-image: none; text-align: left; =
color: rgb(34, 34, 34); text-transform: none; text-indent: 0px; letter-spac=
ing: normal; font-size: 13px; font-variant: normal; word-spacing: 0px; whit=
e-space: normal; orphans: 2; -webkit-text-stroke-width: 0px; background-col=
or: transparent;"> }</div><div style=3D"margin: 0px; padding: 0=
px; border: 0px rgb(34, 34, 34); border-image: none; text-align: left; colo=
r: rgb(34, 34, 34); text-transform: none; text-indent: 0px; letter-spacing:=
normal; font-size: 13px; font-variant: normal; word-spacing: 0px; white-sp=
ace: normal; orphans: 2; -webkit-text-stroke-width: 0px; background-color: =
transparent;"><br></div><div style=3D"margin: 0px; padding: 0px; border: 0p=
x rgb(34, 34, 34); border-image: none; text-align: left; color: rgb(34, 34,=
34); text-transform: none; text-indent: 0px; letter-spacing: normal; font-=
size: 13px; font-variant: normal; word-spacing: 0px; white-space: normal; o=
rphans: 2; -webkit-text-stroke-width: 0px; background-color: transparent;">=
<br></div><b style=3D"background-attachment: scroll; background-clip: borde=
r-box; background-color: transparent; background-image: none; background-or=
igin: padding-box; background-position-x: 0%; background-position-y: 0%; ba=
ckground-repeat: repeat; background-size: auto; border-bottom-color: rgb(34=
, 34, 34); border-bottom-style: none; border-bottom-width: 0px; border-imag=
e-outset: 0; border-image-repeat: stretch; border-image-slice: 100%; border=
-image-source: none; border-image-width: 1; border-left-color: rgb(34, 34, =
34); border-left-style: none; border-left-width: 0px; border-right-color: r=
gb(34, 34, 34); border-right-style: none; border-right-width: 0px; border-t=
op-color: rgb(34, 34, 34); border-top-style: none; border-top-width: 0px; c=
olor: rgb(34, 34, 34); font-family: &quot;Arial&quot;,&quot;Hel=
vetica&quot;,sans-serif; font-size: 13px; font-style: normal; font-vari=
ant: normal; font-weight: 700; height: auto; letter-spacing: normal; margin=
-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; min-wid=
th: 0px; orphans: 2; overflow: visible; overflow-x: visible; overflow-y: vi=
sible; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-=
top: 0px; text-align: left; text-decoration: none; text-indent: 0px; text-t=
ransform: none; -webkit-text-stroke-width: 0px; white-space: normal; word-s=
pacing: 0px;"></b><i style=3D"background-attachment: scroll; background-cli=
p: border-box; background-color: transparent; background-image: none; backg=
round-origin: padding-box; background-position-x: 0%; background-position-y=
: 0%; background-repeat: repeat; background-size: auto; border-bottom-color=
: rgb(34, 34, 34); border-bottom-style: none; border-bottom-width: 0px; bor=
der-image-outset: 0; border-image-repeat: stretch; border-image-slice: 100%=
; border-image-source: none; border-image-width: 1; border-left-color: rgb(=
34, 34, 34); border-left-style: none; border-left-width: 0px; border-right-=
color: rgb(34, 34, 34); border-right-style: none; border-right-width: 0px; =
border-top-color: rgb(34, 34, 34); border-top-style: none; border-top-width=
: 0px; color: rgb(34, 34, 34); font-family: &quot;Arial&quot;,&=
quot;Helvetica&quot;,sans-serif; font-size: 13px; font-style: italic; f=
ont-variant: normal; font-weight: 400; height: auto; letter-spacing: normal=
; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;=
min-width: 0px; orphans: 2; overflow: visible; overflow-x: visible; overfl=
ow-y: visible; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; =
padding-top: 0px; text-align: left; text-decoration: none; text-indent: 0px=
; text-transform: none; -webkit-text-stroke-width: 0px; white-space: normal=
; word-spacing: 0px;"></i><u style=3D"background-attachment: scroll; backgr=
ound-clip: border-box; background-color: transparent; background-image: non=
e; background-origin: padding-box; background-position-x: 0%; background-po=
sition-y: 0%; background-repeat: repeat; background-size: auto; border-bott=
om-color: rgb(34, 34, 34); border-bottom-style: none; border-bottom-width: =
0px; border-image-outset: 0; border-image-repeat: stretch; border-image-sli=
ce: 100%; border-image-source: none; border-image-width: 1; border-left-col=
or: rgb(34, 34, 34); border-left-style: none; border-left-width: 0px; borde=
r-right-color: rgb(34, 34, 34); border-right-style: none; border-right-widt=
h: 0px; border-top-color: rgb(34, 34, 34); border-top-style: none; border-t=
op-width: 0px; color: rgb(34, 34, 34); font-family: &quot;Arial&quo=
t;,&quot;Helvetica&quot;,sans-serif; font-size: 13px; font-style: n=
ormal; font-variant: normal; font-weight: 400; height: auto; letter-spacing=
: normal; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-t=
op: 0px; min-width: 0px; orphans: 2; overflow: visible; overflow-x: visible=
; overflow-y: visible; padding-bottom: 0px; padding-left: 0px; padding-righ=
t: 0px; padding-top: 0px; text-align: left; text-decoration: underline; tex=
t-indent: 0px; text-transform: none; -webkit-text-stroke-width: 0px; white-=
space: normal; word-spacing: 0px;"></u><sub style=3D"background-color: tran=
sparent; border-bottom-color: rgb(34, 34, 34); border-bottom-style: none; b=
order-bottom-width: 0px; border-image-outset: 0; border-image-repeat: stret=
ch; border-image-slice: 100%; border-image-source: none; border-image-width=
: 1; border-left-color: rgb(34, 34, 34); border-left-style: none; border-le=
ft-width: 0px; border-right-color: rgb(34, 34, 34); border-right-style: non=
e; border-right-width: 0px; border-top-color: rgb(34, 34, 34); border-top-s=
tyle: none; border-top-width: 0px; color: rgb(34, 34, 34); font-family: &am=
p;quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif; font-size:=
9px; font-style: normal; font-variant: normal; font-weight: 400; letter-sp=
acing: normal; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; mar=
gin-top: 0px; orphans: 2; padding-bottom: 0px; padding-left: 0px; padding-r=
ight: 0px; padding-top: 0px; text-align: left; text-decoration: none; text-=
indent: 0px; text-transform: none; -webkit-text-stroke-width: 0px; white-sp=
ace: normal; word-spacing: 0px;"></sub><sup style=3D"background-color: tran=
sparent; border-bottom-color: rgb(34, 34, 34); border-bottom-style: none; b=
order-bottom-width: 0px; border-image-outset: 0; border-image-repeat: stret=
ch; border-image-slice: 100%; border-image-source: none; border-image-width=
: 1; border-left-color: rgb(34, 34, 34); border-left-style: none; border-le=
ft-width: 0px; border-right-color: rgb(34, 34, 34); border-right-style: non=
e; border-right-width: 0px; border-top-color: rgb(34, 34, 34); border-top-s=
tyle: none; border-top-width: 0px; color: rgb(34, 34, 34); font-family: &am=
p;quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif; font-size:=
9px; font-style: normal; font-variant: normal; font-weight: 400; letter-sp=
acing: normal; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; mar=
gin-top: 0px; orphans: 2; padding-bottom: 0px; padding-left: 0px; padding-r=
ight: 0px; padding-top: 0px; text-align: left; text-decoration: none; text-=
indent: 0px; text-transform: none; -webkit-text-stroke-width: 0px; white-sp=
ace: normal; word-spacing: 0px;"></sup><strike style=3D"background-color: t=
ransparent; border-bottom-color: rgb(34, 34, 34); border-bottom-style: none=
; border-bottom-width: 0px; border-image-outset: 0; border-image-repeat: st=
retch; border-image-slice: 100%; border-image-source: none; border-image-wi=
dth: 1; border-left-color: rgb(34, 34, 34); border-left-style: none; border=
-left-width: 0px; border-right-color: rgb(34, 34, 34); border-right-style: =
none; border-right-width: 0px; border-top-color: rgb(34, 34, 34); border-to=
p-style: none; border-top-width: 0px; color: rgb(34, 34, 34); font-family: =
&quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif; font-si=
ze: 13px; font-style: normal; font-variant: normal; font-weight: 400; lette=
r-spacing: normal; margin-bottom: 0px; margin-left: 0px; margin-right: 0px;=
margin-top: 0px; orphans: 2; padding-bottom: 0px; padding-left: 0px; paddi=
ng-right: 0px; padding-top: 0px; text-align: left; text-decoration: line-th=
rough; text-indent: 0px; text-transform: none; -webkit-text-stroke-width: 0=
px; white-space: normal; word-spacing: 0px;"></strike><b style=3D"backgroun=
d-attachment: scroll; background-clip: border-box; background-color: transp=
arent; background-image: none; background-origin: padding-box; background-p=
osition-x: 0%; background-position-y: 0%; background-repeat: repeat; backgr=
ound-size: auto; border-bottom-color: rgb(34, 34, 34); border-bottom-style:=
none; border-bottom-width: 0px; border-image-outset: 0; border-image-repea=
t: stretch; border-image-slice: 100%; border-image-source: none; border-ima=
ge-width: 1; border-left-color: rgb(34, 34, 34); border-left-style: none; b=
order-left-width: 0px; border-right-color: rgb(34, 34, 34); border-right-st=
yle: none; border-right-width: 0px; border-top-color: rgb(34, 34, 34); bord=
er-top-style: none; border-top-width: 0px; color: rgb(34, 34, 34); font-fam=
ily: &quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif; fo=
nt-size: 13px; font-style: normal; font-variant: normal; font-weight: 700; =
height: auto; letter-spacing: normal; margin-bottom: 0px; margin-left: 0px;=
margin-right: 0px; margin-top: 0px; min-width: 0px; orphans: 2; overflow: =
visible; overflow-x: visible; overflow-y: visible; padding-bottom: 0px; pad=
ding-left: 0px; padding-right: 0px; padding-top: 0px; text-align: left; tex=
t-decoration: none; text-indent: 0px; text-transform: none; -webkit-text-st=
roke-width: 0px; white-space: normal; word-spacing: 0px;"></b><i style=3D"b=
ackground-attachment: scroll; background-clip: border-box; background-color=
: transparent; background-image: none; background-origin: padding-box; back=
ground-position-x: 0%; background-position-y: 0%; background-repeat: repeat=
; background-size: auto; border-bottom-color: rgb(34, 34, 34); border-botto=
m-style: none; border-bottom-width: 0px; border-image-outset: 0; border-ima=
ge-repeat: stretch; border-image-slice: 100%; border-image-source: none; bo=
rder-image-width: 1; border-left-color: rgb(34, 34, 34); border-left-style:=
none; border-left-width: 0px; border-right-color: rgb(34, 34, 34); border-=
right-style: none; border-right-width: 0px; border-top-color: rgb(34, 34, 3=
4); border-top-style: none; border-top-width: 0px; color: rgb(34, 34, 34); =
font-family: &quot;Arial&quot;,&quot;Helvetica&quot;,sans-s=
erif; font-size: 13px; font-style: italic; font-variant: normal; font-weigh=
t: 400; height: auto; letter-spacing: normal; margin-bottom: 0px; margin-le=
ft: 0px; margin-right: 0px; margin-top: 0px; min-width: 0px; orphans: 2; ov=
erflow: visible; overflow-x: visible; overflow-y: visible; padding-bottom: =
0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; text-align: l=
eft; text-decoration: none; text-indent: 0px; text-transform: none; -webkit=
-text-stroke-width: 0px; white-space: normal; word-spacing: 0px;"></i><u st=
yle=3D"background-attachment: scroll; background-clip: border-box; backgrou=
nd-color: transparent; background-image: none; background-origin: padding-b=
ox; background-position-x: 0%; background-position-y: 0%; background-repeat=
: repeat; background-size: auto; border-bottom-color: rgb(34, 34, 34); bord=
er-bottom-style: none; border-bottom-width: 0px; border-image-outset: 0; bo=
rder-image-repeat: stretch; border-image-slice: 100%; border-image-source: =
none; border-image-width: 1; border-left-color: rgb(34, 34, 34); border-lef=
t-style: none; border-left-width: 0px; border-right-color: rgb(34, 34, 34);=
border-right-style: none; border-right-width: 0px; border-top-color: rgb(3=
4, 34, 34); border-top-style: none; border-top-width: 0px; color: rgb(34, 3=
4, 34); font-family: &quot;Arial&quot;,&quot;Helvetica&quot=
;,sans-serif; font-size: 13px; font-style: normal; font-variant: normal; fo=
nt-weight: 400; height: auto; letter-spacing: normal; margin-bottom: 0px; m=
argin-left: 0px; margin-right: 0px; margin-top: 0px; min-width: 0px; orphan=
s: 2; overflow: visible; overflow-x: visible; overflow-y: visible; padding-=
bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; text-=
align: left; text-decoration: underline; text-indent: 0px; text-transform: =
none; -webkit-text-stroke-width: 0px; white-space: normal; word-spacing: 0p=
x;"></u><sub style=3D"background-color: transparent; border-bottom-color: r=
gb(34, 34, 34); border-bottom-style: none; border-bottom-width: 0px; border=
-image-outset: 0; border-image-repeat: stretch; border-image-slice: 100%; b=
order-image-source: none; border-image-width: 1; border-left-color: rgb(34,=
34, 34); border-left-style: none; border-left-width: 0px; border-right-col=
or: rgb(34, 34, 34); border-right-style: none; border-right-width: 0px; bor=
der-top-color: rgb(34, 34, 34); border-top-style: none; border-top-width: 0=
px; color: rgb(34, 34, 34); font-family: &quot;Arial&quot;,&quo=
t;Helvetica&quot;,sans-serif; font-size: 9px; font-style: normal; font-=
variant: normal; font-weight: 400; letter-spacing: normal; margin-bottom: 0=
px; margin-left: 0px; margin-right: 0px; margin-top: 0px; orphans: 2; paddi=
ng-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; te=
xt-align: left; text-decoration: none; text-indent: 0px; text-transform: no=
ne; -webkit-text-stroke-width: 0px; white-space: normal; word-spacing: 0px;=
"></sub><sup style=3D"background-color: transparent; border-bottom-color: r=
gb(34, 34, 34); border-bottom-style: none; border-bottom-width: 0px; border=
-image-outset: 0; border-image-repeat: stretch; border-image-slice: 100%; b=
order-image-source: none; border-image-width: 1; border-left-color: rgb(34,=
34, 34); border-left-style: none; border-left-width: 0px; border-right-col=
or: rgb(34, 34, 34); border-right-style: none; border-right-width: 0px; bor=
der-top-color: rgb(34, 34, 34); border-top-style: none; border-top-width: 0=
px; color: rgb(34, 34, 34); font-family: &quot;Arial&quot;,&quo=
t;Helvetica&quot;,sans-serif; font-size: 9px; font-style: normal; font-=
variant: normal; font-weight: 400; letter-spacing: normal; margin-bottom: 0=
px; margin-left: 0px; margin-right: 0px; margin-top: 0px; orphans: 2; paddi=
ng-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; te=
xt-align: left; text-decoration: none; text-indent: 0px; text-transform: no=
ne; -webkit-text-stroke-width: 0px; white-space: normal; word-spacing: 0px;=
"></sup><strike style=3D"background-color: transparent; border-bottom-color=
: rgb(34, 34, 34); border-bottom-style: none; border-bottom-width: 0px; bor=
der-image-outset: 0; border-image-repeat: stretch; border-image-slice: 100%=
; border-image-source: none; border-image-width: 1; border-left-color: rgb(=
34, 34, 34); border-left-style: none; border-left-width: 0px; border-right-=
color: rgb(34, 34, 34); border-right-style: none; border-right-width: 0px; =
border-top-color: rgb(34, 34, 34); border-top-style: none; border-top-width=
: 0px; color: rgb(34, 34, 34); font-family: &quot;Arial&quot;,&=
quot;Helvetica&quot;,sans-serif; font-size: 13px; font-style: normal; f=
ont-variant: normal; font-weight: 400; letter-spacing: normal; margin-botto=
m: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; orphans: 2; p=
adding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px=
; text-align: left; text-decoration: line-through; text-indent: 0px; text-t=
ransform: none; -webkit-text-stroke-width: 0px; white-space: normal; word-s=
pacing: 0px;"></strike><b></b><i></i><u></u><sub></sub><sup></sup><strike><=
/strike><b></b><i></i><u></u><sub></sub><sup></sup><strike></strike>Further=
.... you could maps a struct implicitly around a bump if not provided allowi=
ng you to remove a "bump" from the struct and use it directly as a integer =
variable....</div><div>example:</div><div><br></div><div> main() {</d=
iv><div><div style=3D"background-color: transparent; border-bottom-color: r=
gb(34, 34, 34); border-bottom-style: none; border-bottom-width: 0px; border=
-image-outset: 0; border-image-repeat: stretch; border-image-slice: 100%; b=
order-image-source: none; border-image-width: 1; border-left-color: rgb(34,=
34, 34); border-left-style: none; border-left-width: 0px; border-right-col=
or: rgb(34, 34, 34); border-right-style: none; border-right-width: 0px; bor=
der-top-color: rgb(34, 34, 34); border-top-style: none; border-top-width: 0=
px; color: rgb(34, 34, 34); font-family: &quot;Arial&quot;,&quo=
t;Helvetica&quot;,sans-serif; font-size: 13px; font-style: normal; font=
-variant: normal; font-weight: 400; letter-spacing: normal; margin-bottom: =
0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; orphans: 2; padd=
ing-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; t=
ext-align: left; text-decoration: none; text-indent: 0px; text-transform: n=
one; -webkit-text-stroke-width: 0px; white-space: normal; word-spacing: 0px=
;"> bump<4> x; // =3D> maps to: s=
truct x_implicit { uint8_t :0 ix; uint8_t ix : 4}; x_implicit x;</div=
> bump<34> y; // =3D> maps to:=
struct y_implicit { uint64_t :0 iy; uint64_t iy : 4}; y_impli=
cit y;</div><div><br></div><div> // and it does modulus math c=
orrecly </div><div> x =3D 0xF;</div><div><br></div>=
<div> // modulus rollover</div><div> =
x +=3D 1;</div><div> cout << "x: " << x;</di=
v><div> // prints 0</div><div><br></div><div><div style=
=3D"background-color: transparent; border-bottom-color: rgb(34, 34, 34); bo=
rder-bottom-style: none; border-bottom-width: 0px; border-image-outset: 0; =
border-image-repeat: stretch; border-image-slice: 100%; border-image-source=
: none; border-image-width: 1; border-left-color: rgb(34, 34, 34); border-l=
eft-style: none; border-left-width: 0px; border-right-color: rgb(34, 34, 34=
); border-right-style: none; border-right-width: 0px; border-top-color: rgb=
(34, 34, 34); border-top-style: none; border-top-width: 0px; color: rgb(34,=
34, 34); font-family: &quot;Arial&quot;,&quot;Helvetica&qu=
ot;,sans-serif; font-size: 13px; font-style: normal; font-variant: normal; =
font-weight: 400; letter-spacing: normal; margin-bottom: 0px; margin-left: =
0px; margin-right: 0px; margin-top: 0px; orphans: 2; padding-bottom: 0px; p=
adding-left: 0px; padding-right: 0px; padding-top: 0px; text-align: left; t=
ext-decoration: none; text-indent: 0px; text-transform: none; -webkit-text-=
stroke-width: 0px; white-space: normal; word-spacing: 0px;"> &n=
bsp; x +=3D 1;</div><div style=3D"background-color: transparent; border-bot=
tom-color: rgb(34, 34, 34); border-bottom-style: none; border-bottom-width:=
0px; border-image-outset: 0; border-image-repeat: stretch; border-image-sl=
ice: 100%; border-image-source: none; border-image-width: 1; border-left-co=
lor: rgb(34, 34, 34); border-left-style: none; border-left-width: 0px; bord=
er-right-color: rgb(34, 34, 34); border-right-style: none; border-right-wid=
th: 0px; border-top-color: rgb(34, 34, 34); border-top-style: none; border-=
top-width: 0px; color: rgb(34, 34, 34); font-family: &quot;Arial&qu=
ot;,&quot;Helvetica&quot;,sans-serif; font-size: 13px; font-style: =
normal; font-variant: normal; font-weight: 400; letter-spacing: normal; mar=
gin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; orph=
ans: 2; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding=
-top: 0px; text-align: left; text-decoration: none; text-indent: 0px; text-=
transform: none; -webkit-text-stroke-width: 0px; white-space: normal; word-=
spacing: 0px;"> cout << "x: " << x;</div><di=
v style=3D"background-color: transparent; border-bottom-color: rgb(34, 34, =
34); border-bottom-style: none; border-bottom-width: 0px; border-image-outs=
et: 0; border-image-repeat: stretch; border-image-slice: 100%; border-image=
-source: none; border-image-width: 1; border-left-color: rgb(34, 34, 34); b=
order-left-style: none; border-left-width: 0px; border-right-color: rgb(34,=
34, 34); border-right-style: none; border-right-width: 0px; border-top-col=
or: rgb(34, 34, 34); border-top-style: none; border-top-width: 0px; color: =
rgb(34, 34, 34); font-family: &quot;Arial&quot;,&quot;Helvetica=
&quot;,sans-serif; font-size: 13px; font-style: normal; font-variant: n=
ormal; font-weight: 400; letter-spacing: normal; margin-bottom: 0px; margin=
-left: 0px; margin-right: 0px; margin-top: 0px; orphans: 2; padding-bottom:=
0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; text-align: =
left; text-decoration: none; text-indent: 0px; text-transform: none; -webki=
t-text-stroke-width: 0px; white-space: normal; word-spacing: 0px;"> &=
nbsp; // prints 1<br></div></div><div> }</div><div><br></div><d=
iv>Anyways... just my 2 cents... </div><div><br></div><div><br></div><=
/div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/fbb22a41-e253-4155-b3ce-02b1c97df4a5%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.goo=
gle.com/a/isocpp.org/d/msgid/std-proposals/fbb22a41-e253-4155-b3ce-02b1c97d=
f4a5%40isocpp.org</a>.<br>
<br><!--end of _originalContent --></div></body></html>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/20180818213158.5206092.84443.60653%40=
gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com=
/a/isocpp.org/d/msgid/std-proposals/20180818213158.5206092.84443.60653%40gm=
ail.com</a>.<br />
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sat, 18 Aug 2018 15:33:08 -0700 (PDT)
Raw View
------=_Part_127_992500351.1534631588697
Content-Type: multipart/alternative;
boundary="----=_Part_128_2085400552.1534631588698"
------=_Part_128_2085400552.1534631588698
Content-Type: text/plain; charset="UTF-8"
On Saturday, August 18, 2018 at 5:24:54 PM UTC-4, wm201...@gmail.com wrote:
>
>
> I propose that they add the concept of a "bump" to modern C++. You want a
> integer type that's treated like a restricted bit width integer... but you
> don't want the complexity of messing around with picking the correct uint
> size and setting up a bit field.. and you don't want the slowness of
> packing and unpacking bit fields together that the compiler does behind the
> scenes... thus, the concept of a "Bump" integer type:
>
> * bump<2> x; => maps to => uint8_t:0; uint8_t x : 2;*
> * bump<7> x; => maps to => uint8_t:0; uint8_t x : 7;*
> * bump<18> x; => maps to => uint16_t:0; uint16_t x : 18; *
> * bump<35> x; => maps to => uint32_t:0; uint32_t x : 35; *
> * bump<66> x; => maps to => uin64_t:0; uint64_t x : 66;*
>
> uint8_t:0 <= ensures that bit field starts over in a new integer word each
> time rather than packing them in the same integer...
>
> I means serious... c++ already support bit field widths of up 64 bits...
> why not make "bit fields" an officially supported integer type?
>
Because you have to be able to get a pointer to an object, and addresses
are byte oriented in C++. Oh sure, you can make a `bitset`-style type
easily enough, but a sequence of them in an aggregate would not be able to
share the same "integer word".
The only way to make this work is to have an object which represents the
entire consecutive set of bitfields. Which is not necessarily a bad idea
for a type; it would look something like:
std::bit_fields<std::uint8_t, 4, 62, 22> fields;
Each of those numbers represents some integer count of bits, which says how
many bits are taken for that bitfield. This object would provide access to
the individual bitfields entries as a kind of "bit span": a sequence of
bits within a contiguous array of unsigned integers of some sort. It would
provide structured binding machinery (unqualified `get` and such), but it
would also have a range interface.
--
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/b34626c4-3dfe-4f70-8572-5528e4ff4c07%40isocpp.org.
------=_Part_128_2085400552.1534631588698
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Saturday, August 18, 2018 at 5:24:54 PM UTC-4, =
wm201...@gmail.com 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"><div><br></div><div>I propose that they add the concept of a &q=
uot;bump" to modern C++.=C2=A0 You want a integer type that's trea=
ted like a restricted bit width integer... but you don't want the compl=
exity of messing around with picking the correct uint size and setting up a=
bit field.. and you don't want the slowness of packing and unpacking b=
it fields together that the compiler does behind the scenes... thus, the co=
ncept of a "Bump" integer type:</div><div><br></div><div><b>=C2=
=A0 =C2=A0 bump<2>=C2=A0 x; =C2=A0 =3D> maps to =3D> =C2=A0 uin=
t8_t:0; uint8_t x : 2;</b></div><div><div style=3D"margin:0px;padding:0px;b=
order:0px rgb(34,34,34);text-align:left;color:rgb(34,34,34);text-transform:=
none;text-indent:0px;letter-spacing:normal;font-size:13px;font-style:normal=
;font-variant:normal;text-decoration:none;word-spacing:0px;white-space:norm=
al;background-color:transparent"><b>=C2=A0 =C2=A0 bump<7>=C2=A0 x; =
=C2=A0 =3D> maps to =3D> =C2=A0 uint8_t:0; uint8_t x : 7;</b></div><i=
></i><u></u><sub></sub><sup></sup><strike></strike><div style=3D"margin:0px=
;padding:0px;border:0px rgb(34,34,34);text-align:left;color:rgb(34,34,34);t=
ext-transform:none;text-indent:0px;letter-spacing:normal;font-size:13px;fon=
t-style:normal;font-variant:normal;text-decoration:none;word-spacing:0px;wh=
ite-space:normal;background-color:transparent"><b>=C2=A0 =C2=A0 bump<18&=
gt; x;=C2=A0 =3D> maps to =3D> =C2=A0 uint16_t:0; uint16_t x : 18; =
=C2=A0</b></div><i style=3D"background:none;margin:0px;padding:0px;border:0=
px rgb(34,34,34);min-height:auto;text-align:left;color:rgb(34,34,34);text-t=
ransform:none;text-indent:0px;letter-spacing:normal;overflow:visible;font-s=
ize:13px;font-style:italic;font-variant:normal;text-decoration:none;word-sp=
acing:0px;white-space:normal;overflow-x:visible;overflow-y:visible;min-widt=
h:0px"></i><u style=3D"background:none;margin:0px;padding:0px;border:0px rg=
b(34,34,34);min-height:auto;text-align:left;color:rgb(34,34,34);text-transf=
orm:none;text-indent:0px;letter-spacing:normal;overflow:visible;font-size:1=
3px;font-style:normal;font-variant:normal;text-decoration:underline;word-sp=
acing:0px;white-space:normal;overflow-x:visible;overflow-y:visible;min-widt=
h:0px"></u><sub style=3D"margin:0px;padding:0px;border:0px rgb(34,34,34);te=
xt-align:left;color:rgb(34,34,34);text-transform:none;text-indent:0px;lette=
r-spacing:normal;font-size:9px;font-style:normal;font-variant:normal;text-d=
ecoration:none;word-spacing:0px;white-space:normal;background-color:transpa=
rent"></sub><sup style=3D"margin:0px;padding:0px;border:0px rgb(34,34,34);t=
ext-align:left;color:rgb(34,34,34);text-transform:none;text-indent:0px;lett=
er-spacing:normal;font-size:9px;font-style:normal;font-variant:normal;text-=
decoration:none;word-spacing:0px;white-space:normal;background-color:transp=
arent"></sup><strike style=3D"margin:0px;padding:0px;border:0px rgb(34,34,3=
4);text-align:left;color:rgb(34,34,34);text-transform:none;text-indent:0px;=
letter-spacing:normal;font-size:13px;font-style:normal;font-variant:normal;=
text-decoration:line-through;word-spacing:0px;white-space:normal;background=
-color:transparent"></strike><i></i><u></u><sub></sub><sup></sup><strike></=
strike><div style=3D"margin:0px;padding:0px;border:0px rgb(34,34,34);text-a=
lign:left;color:rgb(34,34,34);text-transform:none;text-indent:0px;letter-sp=
acing:normal;font-size:13px;font-style:normal;font-variant:normal;text-deco=
ration:none;word-spacing:0px;white-space:normal;background-color:transparen=
t"><b>=C2=A0 =C2=A0 bump<35> x;=C2=A0 =3D> maps to =3D> =C2=A0 =
uint32_t:0; uint32_t x : 35; =C2=A0</b></div><div style=3D"margin:0px;paddi=
ng:0px;border:0px rgb(34,34,34);text-align:left;color:rgb(34,34,34);text-tr=
ansform:none;text-indent:0px;letter-spacing:normal;font-size:13px;font-vari=
ant:normal;word-spacing:0px;white-space:normal;background-color:transparent=
"><div style=3D"margin:0px;padding:0px;border:0px rgb(34,34,34);text-align:=
left;color:rgb(34,34,34);text-transform:none;text-indent:0px;letter-spacing=
:normal;font-size:13px;font-style:normal;font-variant:normal;text-decoratio=
n:none;word-spacing:0px;white-space:normal;background-color:transparent"><b=
>=C2=A0 =C2=A0 bump<66> x;=C2=A0 =3D> maps to =3D> =C2=A0 uin64=
_t:0; uint64_t x : 66;</b></div><div><b></b><br></div><div>uint8_t:0 <=
=3D ensures that bit field starts over in a new integer word each time rath=
er than packing them in the same integer...=C2=A0</div><div><br></div><div>=
I means serious... c++ already support bit field widths of up 64 bits... wh=
y not make "bit fields" an officially supported integer type?</di=
v></div></div></div></blockquote><div><br></div><div>Because you have to be=
able to get a pointer to an object, and addresses are byte oriented in C++=
.. Oh sure, you can make a `bitset`-style type easily enough, but a sequence=
of them in an aggregate would not be able to share the same "integer =
word".</div><div><br></div><div>The only way to make this work is to h=
ave an object which represents the entire consecutive set of bitfields. Whi=
ch is not necessarily a bad idea for a type; it would look something like:<=
/div><div><br></div><div><div style=3D"background-color: rgb(250, 250, 250)=
; border-color: rgb(187, 187, 187); border-style: solid; border-width: 1px;=
overflow-wrap: break-word;" class=3D"prettyprint"><code class=3D"prettypri=
nt"><div class=3D"subprettyprint"><span style=3D"color: #000;" class=3D"sty=
led-by-prettify">std</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
">bit_fields</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
"><</span><span style=3D"color: #000;" class=3D"styled-by-prettify">std<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify">uint8_t</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: #=
066;" class=3D"styled-by-prettify">4</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #066;" class=3D"styled-by-pr=
ettify">62</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: #066;" class=3D"styled-by-prettify">22</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">></span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> fields</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">;</span></div></code></div></div><d=
iv><br></div><div>Each of those numbers represents some integer count of bi=
ts, which says how many bits are taken for that bitfield. This object would=
provide access to the individual bitfields entries as a kind of "bit =
span": a sequence of bits within a contiguous array of unsigned intege=
rs of some sort. It would provide structured binding machinery (unqualified=
`get` and such), but it would also have a range interface.</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/b34626c4-3dfe-4f70-8572-5528e4ff4c07%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b34626c4-3dfe-4f70-8572-5528e4ff4c07=
%40isocpp.org</a>.<br />
------=_Part_128_2085400552.1534631588698--
------=_Part_127_992500351.1534631588697--
.
Author: Jake Arkinstall <jake.arkinstall@gmail.com>
Date: Sun, 19 Aug 2018 00:32:11 +0100
Raw View
--00000000000055a6a20573be16b5
Content-Type: text/plain; charset="UTF-8"
On Sat, 18 Aug 2018, 22:24 , <wm2015email@gmail.com> wrote:
>
> I propose that they add the concept of a "bump" to modern C++. You want a
> integer type that's treated like a restricted bit width integer... but you
> don't want the complexity of messing around with picking the correct uint
> size and setting up a bit field.. and you don't want the slowness of
> packing and unpacking bit fields together that the compiler does behind the
> scenes
>
But that allows the bit field to be treated properly. We have well defined
ways of handling those fundamental types at the assembly level, and I guess
it just made sense to be able to specify how the number is to be treated
during a calculation. At least, that's how I have always assumed bit fields
are implemented. It isnt something I had considered, and they aren't
something I find myself using very often (... okay, ever). I definitely
agree that it would make more sense to make the compiler figure the type
out inside bit fields. I don't think it makes sense to have these things as
freestanding types - it seems a little too artificial. It would still be
represented as the larger type... unless (and this is where Im going to
sound like a crackpot) we had a way of handling and box-fitting abnormally
sized variables, and some access management step making sure they don't
interact unexpectedly. I can't think of any practical use for this other
than when you have low available memory and a lot of time to waste.
On Sat, 18 Aug 2018, 22:32 Tony V E, <tvaneerd@gmail.com> wrote:
Why would this be called 'bump'?
I first guessed there was a bad insect joke in there - a little byte can
give you a bump. But then I realised that very few people have a sense of
humour as terrible as mine.
>
--
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/CAC%2B0CCP-Ls27XOHTxXn0W%2B0pbTFqfA5f3Pp5Oi56pRzo4wSofw%40mail.gmail.com.
--00000000000055a6a20573be16b5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div><div class=3D"gmail_quote"><div dir=3D"ltr">On Sat, =
18 Aug 2018, 22:24 , <<a href=3D"mailto:wm2015email@gmail.com" target=3D=
"_blank" rel=3D"noreferrer">wm2015email@gmail.com</a>> wrote:<br></div><=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
#ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><br></div><div>I propos=
e that they add the concept of a "bump" to modern C++.=C2=A0 You =
want a integer type that's treated like a restricted bit width integer.=
... but you don't want the complexity of messing around with picking the=
correct uint size and setting up a bit field.. and you don't want the =
slowness of packing and unpacking bit fields together that the compiler doe=
s behind the scenes</div></div></blockquote></div></div><div dir=3D"auto"><=
br></div><div dir=3D"auto">But that allows the bit field to be treated prop=
erly. We have well defined ways of handling those fundamental types at the =
assembly level, and I guess it just made sense to be able to specify how th=
e number is to be treated during a calculation. At least, that's how I =
have always assumed bit fields are implemented. It isnt something I had con=
sidered, and they aren't something I find myself using very often (... =
okay, ever). I definitely agree that it would make more sense to make the c=
ompiler figure the type out inside bit fields. I don't think it makes s=
ense to have these things as freestanding types - it seems a little too art=
ificial. It would still be represented as the larger type...=C2=A0 unless (=
and this is where Im going to sound like a crackpot) we had a way of handli=
ng and box-fitting abnormally sized variables, and some access management s=
tep making sure they don't interact unexpectedly. I can't think of =
any practical use for this other than when you have low available memory an=
d a lot of time to waste.</div><div dir=3D"auto"><br></div><div dir=3D"auto=
"><div style=3D"font-family:sans-serif" dir=3D"auto"><div class=3D"m_-15300=
43465216516634elided-text"><div dir=3D"ltr">On Sat, 18 Aug 2018, 22:32 Tony=
V E, <<a href=3D"mailto:tvaneerd@gmail.com" target=3D"_blank" rel=3D"no=
referrer">tvaneerd@gmail.com</a>> wrote:<br></div><blockquote style=3D"m=
argin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left=
:1ex"><div style=3D"background-color:rgb(255,255,255)"><div style=3D"width:=
361.906px;font-family:calibri,"slate pro",sans-serif,sans-serif;c=
olor:rgb(31,73,125)">Why would this be called 'bump'?</div></div></=
blockquote></div></div><div dir=3D"auto" style=3D"font-family:sans-serif"><=
br></div><div dir=3D"auto" style=3D"font-family:sans-serif">I first guessed=
there was a bad insect joke in there - a little byte can give you a bump. =
But then I realised that very few people have a sense of humour as terrible=
as mine.</div></div><div dir=3D"auto"><div class=3D"gmail_quote"><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex">
</blockquote></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCP-Ls27XOHTxXn0W%2B0pbTFqfA5f=
3Pp5Oi56pRzo4wSofw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCP-Ls=
27XOHTxXn0W%2B0pbTFqfA5f3Pp5Oi56pRzo4wSofw%40mail.gmail.com</a>.<br />
--00000000000055a6a20573be16b5--
.
Author: staffan.tjernstrom@sig.com
Date: Tue, 21 Aug 2018 05:30:48 -0700 (PDT)
Raw View
------=_Part_2046_1737741923.1534854648163
Content-Type: multipart/alternative;
boundary="----=_Part_2047_1290455903.1534854648164"
------=_Part_2047_1290455903.1534854648164
Content-Type: text/plain; charset="UTF-8"
On Saturday, 18 August 2018 19:32:21 UTC-4, Jake Arkinstall wrote:
>
> I can't think of any practical use for this other than when you have low
> available memory and a lot of time to waste.
>
>
> Dealing with programmable hardware gives rise to all sorts of strange
needs. Most FPGAs and other things of that ilk work on bits, not bytes, so
having a 13-bit value representation is not uncommon. And of course the
messages flying across the system busses are aggregates of those types.
It'd be great to be able to reason about those as stricter types (say a
3-bit enum), but how to break the byte-orientation of the current CPUs (and
the abstract machine) is unclear to me.
--
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/f952cb50-2bd2-46ce-9818-8c28855d840b%40isocpp.org.
------=_Part_2047_1290455903.1534854648164
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Saturday, 18 August 2018 19:32:21 UTC-4, Jake A=
rkinstall wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"a=
uto"><div><div class=3D"gmail_quote"><div dir=3D"ltr">I can't think of =
any practical use for this other than when you have low available memory an=
d a lot of time to waste.<br></div></div></div><div dir=3D"auto"><br></div>=
<div dir=3D"auto"><div style=3D"font-family:sans-serif" dir=3D"auto"><div d=
ir=3D"ltr"><br></div></div></div></div></blockquote><div>Dealing with progr=
ammable hardware gives rise to all sorts of strange needs. Most FPGAs and o=
ther things of that ilk work on bits, not bytes, so having a 13-bit value r=
epresentation is not uncommon. And of course the messages flying across the=
system busses are aggregates of those types. It'd be great to be able =
to reason about those as stricter types (say a 3-bit enum), but how to brea=
k the byte-orientation of the current CPUs (and the abstract machine) is un=
clear to me.=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" 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/f952cb50-2bd2-46ce-9818-8c28855d840b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f952cb50-2bd2-46ce-9818-8c28855d840b=
%40isocpp.org</a>.<br />
------=_Part_2047_1290455903.1534854648164--
------=_Part_2046_1737741923.1534854648163--
.
Author: Jake Arkinstall <jake.arkinstall@gmail.com>
Date: Tue, 21 Aug 2018 21:55:49 +0100
Raw View
--000000000000dadec40573f84024
Content-Type: text/plain; charset="UTF-8"
On Tue, 21 Aug 2018, 13:30 , <staffan.tjernstrom@sig.com> wrote:
>
>
> On Saturday, 18 August 2018 19:32:21 UTC-4, Jake Arkinstall wrote:
>>
>> I can't think of any practical use for this other than when you have low
>> available memory and a lot of time to waste.
>>
>>
>> Dealing with programmable hardware gives rise to all sorts of strange
> needs. Most FPGAs and other things of that ilk work on bits, not bytes, so
> having a 13-bit value representation is not uncommon.
>
Perhaps there is good justification for getting it into the standard after
all, then.
And of course the messages flying across the system busses are aggregates
> of those types. It'd be great to be able to reason about those as stricter
> types (say a 3-bit enum), but how to break the byte-orientation of the
> current CPUs (and the abstract machine) is unclear to me.
>
See rant below. Tl;dr: Church and Turing say we can simulate the device. I
just wish I could think of a better way than actually explicitly simulating
the device's memory.
It can be done, but it won't be efficient. It can't be. I don't think
that's reason enough to turn such an idea down, though.
We need people who know compilation for such architectures on-side so we
know where the common denominator is, and how much can be standardised vs
how much must be implementation specific.
I think handling pointers would be easier than it would have been a decade
ago. Developers are used to working with wrappers instead of raw pointers,
and a wrapper approach is perfectly suited to a situation where raw
pointers don't make sense. We'd need to wrap a pointer and a bit offset -
or at least that's how it could be implemented on a byte-oriented CPU.
Whether or not that pointer layout is standardisable depends on how
non-byte devices handle pointers (and whether or not they even have a
standard approach), but at the very least we can demand a pointer-like
object that dereferences to a value. Maybe for ease, it dereferences to a
const value - and setting the value requires a method on the pointer. When
a value is processed, it is handled natively. When done on exotic device X,
the "wrapper" is a thin wrapper around the device's own pointers.
For the heap, we can have a dynamic bitfield-like-entity with a large empty
field (to be filled - size determined by a compiler flag). A
malloc-equivalent can look for empty space of sufficient size and the heap
would be "reinterpreted" as a new type of bitfield with the new field
slotted into place.
So far this can all be done naively with a class holding a static
std::array<char, SIZE> returning a "pointer" struct (holding an
array::iterator, an offset, and a size, with a dereference operator
returning a char array which is allocated by getting the string of chars
between iterator and (iterator + (offset + size)/CHAR_BIT), bitshifting
such that the intended LSB becomes the LSB, and masking away excess bits
from the left if any) and a vector of existing custom pointers so that free
space can be found. The return value from the dereference operator can be
reinterpret casted to a desired type.
For the stack - have a bit field implicitly created at the beginning of a
scope, encompassing the types that are used within the scope. Essentially
the change that brought C out of the stone age, but with bit fields. I have
a feeling that this paragraph alone is what the OP is asking for.
On an architecture which natively handles these types, of course, the
compiler will simply reduce the handling of these types down to a minimal
instruction set. The above is just an idea for devices that can't.
At the very least, we end up making C++ a more serious contender for exotic
devices - and a way of easily simulating them for testing purposes - and we
free the N-bit types from the bit field structs.
--
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/CAC%2B0CCNZJjzVoODErYdbKWn8fOuBou2zEx5336GMDxpCxYbsZQ%40mail.gmail.com.
--000000000000dadec40573f84024
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue, =
21 Aug 2018, 13:30 , <<a href=3D"mailto:staffan.tjernstrom@sig.com" rel=
=3D"noreferrer noreferrer noreferrer" target=3D"_blank">staffan.tjernstrom@=
sig.com</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"=
ltr"><br><br>On Saturday, 18 August 2018 19:32:21 UTC-4, Jake Arkinstall w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"auto"><div><div cl=
ass=3D"gmail_quote"><div dir=3D"ltr">I can't think of any practical use=
for this other than when you have low available memory and a lot of time t=
o waste.<br></div></div></div><div dir=3D"auto"><br></div><div dir=3D"auto"=
><div style=3D"font-family:sans-serif" dir=3D"auto"><div dir=3D"ltr"><br></=
div></div></div></div></blockquote><div>Dealing with programmable hardware =
gives rise to all sorts of strange needs. Most FPGAs and other things of th=
at ilk work on bits, not bytes, so having a 13-bit value representation is =
not uncommon.</div></div></blockquote></div></div><div dir=3D"auto"><br></d=
iv><div dir=3D"auto">Perhaps there is good justification for getting it int=
o the standard after all, then.</div><div dir=3D"auto"><br></div><div dir=
=3D"auto"><div class=3D"gmail_quote"><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"><div>And of course the messages flying across the system busses a=
re aggregates of those types. It'd be great to be able to reason about =
those as stricter types (say a 3-bit enum), but how to break the byte-orien=
tation of the current CPUs (and the abstract machine) is unclear to me.=C2=
=A0</div></div></blockquote></div></div><div dir=3D"auto"><br></div><div di=
r=3D"auto">See rant below. Tl;dr: Church and Turing say we can simulate the=
device. I just wish I could think of a better way than actually explicitly=
simulating the device's memory.</div><div dir=3D"auto"><br></div><div =
dir=3D"auto">It can be done, but it won't be efficient. It can't be=
.. I don't think that's reason enough to turn such an idea down, tho=
ugh.</div><div dir=3D"auto"></div><div dir=3D"auto"><span style=3D"font-fam=
ily:sans-serif"><br></span></div><div dir=3D"auto"><span style=3D"font-fami=
ly:sans-serif">We need people who know compilation for such architectures o=
n-side so we know where the common denominator is, and how much can be stan=
dardised vs how much must be implementation specific.</span></div><div dir=
=3D"auto"><span style=3D"font-family:sans-serif"><br></span></div><div dir=
=3D"auto"><span style=3D"font-family:sans-serif">I think handling pointers =
would be easier than it would have been a decade ago. Developers are used t=
o working with wrappers instead of raw pointers, and a wrapper approach is =
perfectly suited to a situation where raw pointers don't make sense. We=
'd need to wrap a pointer and a bit offset - or at least that's how=
it could be implemented on a byte-oriented CPU. Whether or not that pointe=
r layout is standardisable depends on how non-byte devices handle pointers =
(and whether or not they even have a standard approach), but at the very le=
ast we can demand a pointer-like object that dereferences to a value. Maybe=
for ease, it dereferences to a const value - and setting the value require=
s a method on the pointer. When a value is processed, it is handled nativel=
y. When done on exotic device X, the "wrapper" is a thin wrapper =
around the device's own pointers.</span></div><div dir=3D"auto"><span s=
tyle=3D"font-family:sans-serif"><br></span></div><div dir=3D"auto"><span st=
yle=3D"font-family:sans-serif">For the heap, we can have a dynamic bitfield=
-like-entity with a large empty field (to be filled - size determined by a =
compiler flag). A malloc-equivalent can look for empty space of sufficient =
size and the heap would be "reinterpreted" as a new type of bitfi=
eld with the new field slotted into place.</span></div><div dir=3D"auto"><s=
pan style=3D"font-family:sans-serif"><br></span></div><div dir=3D"auto"><sp=
an style=3D"font-family:sans-serif">So far this can all be done naively wit=
h a class holding a static std::array<char, SIZE> returning a "p=
ointer" struct (holding an array::iterator, an offset, and a size, wit=
h a dereference operator returning a char array which is allocated by getti=
ng the string of chars between iterator and (iterator + (offset + size)/CHA=
R_BIT), bitshifting such that the intended LSB becomes the LSB, and masking=
away excess bits from the left if any) and a vector of existing custom poi=
nters so that free space can be found. The return value from the dereferenc=
e operator can be reinterpret casted to a desired type.</span></div><div di=
r=3D"auto"><span style=3D"font-family:sans-serif"><br></span></div><div dir=
=3D"auto"><span style=3D"font-family:sans-serif">For the stack - have a bit=
field implicitly created at the beginning of a scope, encompassing the typ=
es that are used within the scope. Essentially the change that brought C ou=
t of the stone age, but with bit fields. I have a feeling that this paragra=
ph alone is what the OP is asking for.</span></div><div dir=3D"auto"><span =
style=3D"font-family:sans-serif"><br></span></div><div dir=3D"auto"><span s=
tyle=3D"font-family:sans-serif">On an architecture which natively handles t=
hese types, of course, the compiler will simply reduce the handling of thes=
e types down to a minimal instruction set. The above is just an idea for de=
vices that can't.</span></div><div dir=3D"auto"><span style=3D"font-fam=
ily:sans-serif"><br></span></div><div dir=3D"auto"><span style=3D"font-fami=
ly:sans-serif">At the very least, we end up making C++ a more serious conte=
nder for exotic devices - and a way of easily simulating them for testing p=
urposes - and we free the N-bit types from the bit field structs.</span></d=
iv></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCNZJjzVoODErYdbKWn8fOuBou2zEx=
5336GMDxpCxYbsZQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCNZJjzV=
oODErYdbKWn8fOuBou2zEx5336GMDxpCxYbsZQ%40mail.gmail.com</a>.<br />
--000000000000dadec40573f84024--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 21 Aug 2018 15:32:36 -0700 (PDT)
Raw View
------=_Part_1243_1961985350.1534890756210
Content-Type: multipart/alternative;
boundary="----=_Part_1244_187829569.1534890756210"
------=_Part_1244_187829569.1534890756210
Content-Type: text/plain; charset="UTF-8"
On Tuesday, August 21, 2018 at 4:56:02 PM UTC-4, Jake Arkinstall wrote:
>
> On Tue, 21 Aug 2018, 13:30 , <staffan.t...@sig.com <javascript:>> wrote:
>
>>
>>
>> On Saturday, 18 August 2018 19:32:21 UTC-4, Jake Arkinstall wrote:
>>>
>>> I can't think of any practical use for this other than when you have low
>>> available memory and a lot of time to waste.
>>>
>>>
>>> Dealing with programmable hardware gives rise to all sorts of strange
>> needs. Most FPGAs and other things of that ilk work on bits, not bytes, so
>> having a 13-bit value representation is not uncommon.
>>
>
> Perhaps there is good justification for getting it into the standard after
> all, then.
>
> And of course the messages flying across the system busses are aggregates
>> of those types. It'd be great to be able to reason about those as stricter
>> types (say a 3-bit enum), but how to break the byte-orientation of the
>> current CPUs (and the abstract machine) is unclear to me.
>>
>
> See rant below. Tl;dr: Church and Turing say we can simulate the device. I
> just wish I could think of a better way than actually explicitly simulating
> the device's memory.
>
> It can be done, but it won't be efficient. It can't be. I don't think
> that's reason enough to turn such an idea down, though.
>
> We need people who know compilation for such architectures on-side so we
> know where the common denominator is, and how much can be standardised vs
> how much must be implementation specific.
>
> I think handling pointers would be easier than it would have been a decade
> ago. Developers are used to working with wrappers instead of raw pointers,
> and a wrapper approach is perfectly suited to a situation where raw
> pointers don't make sense. We'd need to wrap a pointer and a bit offset -
> or at least that's how it could be implemented on a byte-oriented CPU.
> Whether or not that pointer layout is standardisable depends on how
> non-byte devices handle pointers (and whether or not they even have a
> standard approach), but at the very least we can demand a pointer-like
> object that dereferences to a value. Maybe for ease, it dereferences to a
> const value - and setting the value requires a method on the pointer. When
> a value is processed, it is handled natively. When done on exotic device X,
> the "wrapper" is a thin wrapper around the device's own pointers.
>
The problem here is that, for that to work, you need a special "bitfield
pointer" type. That can't be like a regular pointer; it'd have to be
something like a member pointer, which is not just an address. `sizeof` for
regular pointers are all required to be equal; `sizeof` for member pointers
may be different from that. And the same would be true of your bitfield
pointer. It's not an address; you cannot round-trip one through `void*` and
back. Just as you can't for member pointers.
Given that this "bitfield pointer" would be some kind of struct
(internally), why does it have to be part of the language? Stick it in a
library and be done with it. Indeed, as a library-defined type, I can take
an `int` and get a "bitfield pointer" to some of its bits, operate on that
"pointer", thus updating the `int` in-situ.
I can't do that if the only way to get a "bitfield pointer" is to start
with a variable declaration. I see no advantage to putting this in the
language. There are enough `constexpr` gymnastics and such that can be
played to make this all work as efficiently as native bit manipulation.
The same goes for the bitfields themselves; do they really *need* to be
part of the language? What do we gain by that, besides some convenience in
accessing them? And can we not get that convenience in some other way?
--
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/fbd46cf8-98ac-45ec-85ab-14faa946697c%40isocpp.org.
------=_Part_1244_187829569.1534890756210
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, August 21, 2018 at 4:56:02 PM UTC-4, Jake Arki=
nstall 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"auto"=
><div><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue, 21 Aug 2018, 13:3=
0 , <<a href=3D"javascript:" rel=3D"nofollow" target=3D"_blank" gdf-obfu=
scated-mailto=3D"I9TQypY1AAAJ" onmousedown=3D"this.href=3D'javascript:&=
#39;;return true;" onclick=3D"this.href=3D'javascript:';return true=
;">staffan.t...@sig.com</a>> wrote:<br></div><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex"><div dir=3D"ltr"><br><br>On Saturday, 18 August 2018 19:32:21 UTC-4, Ja=
ke Arkinstall wrote:<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"au=
to"><div><div class=3D"gmail_quote"><div dir=3D"ltr">I can't think of a=
ny practical use for this other than when you have low available memory and=
a lot of time to waste.<br></div></div></div><div dir=3D"auto"><br></div><=
div dir=3D"auto"><div style=3D"font-family:sans-serif" dir=3D"auto"><div di=
r=3D"ltr"><br></div></div></div></div></blockquote><div>Dealing with progra=
mmable hardware gives rise to all sorts of strange needs. Most FPGAs and ot=
her things of that ilk work on bits, not bytes, so having a 13-bit value re=
presentation is not uncommon.</div></div></blockquote></div></div><div dir=
=3D"auto"><br></div><div dir=3D"auto">Perhaps there is good justification f=
or getting it into the standard after all, then.</div><div dir=3D"auto"><br=
></div><div dir=3D"auto"><div class=3D"gmail_quote"><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div dir=3D"ltr"><div>And of course the messages flying across the =
system busses are aggregates of those types. It'd be great to be able t=
o reason about those as stricter types (say a 3-bit enum), but how to break=
the byte-orientation of the current CPUs (and the abstract machine) is unc=
lear to me.=C2=A0</div></div></blockquote></div></div><div dir=3D"auto"><br=
></div><div dir=3D"auto">See rant below. Tl;dr: Church and Turing say we ca=
n simulate the device. I just wish I could think of a better way than actua=
lly explicitly simulating the device's memory.</div><div dir=3D"auto"><=
br></div><div dir=3D"auto">It can be done, but it won't be efficient. I=
t can't be. I don't think that's reason enough to turn such an =
idea down, though.</div><div dir=3D"auto"></div><div dir=3D"auto"><span sty=
le=3D"font-family:sans-serif"><br></span></div><div dir=3D"auto"><span styl=
e=3D"font-family:sans-serif">We need people who know compilation for such a=
rchitectures on-side so we know where the common denominator is, and how mu=
ch can be standardised vs how much must be implementation specific.</span><=
/div><div dir=3D"auto"><span style=3D"font-family:sans-serif"><br></span></=
div><div dir=3D"auto"><span style=3D"font-family:sans-serif">I think handli=
ng pointers would be easier than it would have been a decade ago. Developer=
s are used to working with wrappers instead of raw pointers, and a wrapper =
approach is perfectly suited to a situation where raw pointers don't ma=
ke sense. We'd need to wrap a pointer and a bit offset - or at least th=
at's how it could be implemented on a byte-oriented CPU. Whether or not=
that pointer layout is standardisable depends on how non-byte devices hand=
le pointers (and whether or not they even have a standard approach), but at=
the very least we can demand a pointer-like object that dereferences to a =
value. Maybe for ease, it dereferences to a const value - and setting the v=
alue requires a method on the pointer. When a value is processed, it is han=
dled natively. When done on exotic device X, the "wrapper" is a t=
hin wrapper around the device's own pointers.<br></span></div></div></b=
lockquote><div>=C2=A0</div><div>The problem here is that, for that to work,=
you need a special "bitfield pointer" type. That can't be li=
ke a regular pointer; it'd have to be something like a member pointer, =
which is not just an address. `sizeof` for regular pointers are all require=
d to be equal; `sizeof` for member pointers may be different from that. And=
the same would be true of your bitfield pointer. It's not an address; =
you cannot round-trip one through `void*` and back. Just as you can't f=
or member pointers.<br></div><div><br></div><div>Given that this "bitf=
ield pointer" would be some kind of struct (internally), why does it h=
ave to be part of the language? Stick it in a library and be done with it. =
Indeed, as a library-defined type, I can take an `int` and get a "bitf=
ield pointer" to some of its bits, operate on that "pointer"=
, thus updating the `int` in-situ.</div><div><br></div><div>I can't do =
that if the only way to get a "bitfield pointer" is to start with=
a variable declaration. I see no advantage to putting this in the language=
.. There are enough `constexpr` gymnastics and such that can be played to ma=
ke this all work as efficiently as native bit manipulation.<br></div><div><=
br></div>The same goes for the bitfields themselves; do they really <i>need=
</i> to be part of the language? What do we gain by that, besides some conv=
enience in accessing them? And can we not get that convenience in some othe=
r way?</div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/fbd46cf8-98ac-45ec-85ab-14faa946697c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/fbd46cf8-98ac-45ec-85ab-14faa946697c=
%40isocpp.org</a>.<br />
------=_Part_1244_187829569.1534890756210--
------=_Part_1243_1961985350.1534890756210--
.
Author: Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
Date: Tue, 21 Aug 2018 16:14:47 -0700 (PDT)
Raw View
------=_Part_2138_163020155.1534893287967
Content-Type: multipart/alternative;
boundary="----=_Part_2139_2064744041.1534893287967"
------=_Part_2139_2064744041.1534893287967
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Tuesday, August 21, 2018 at 3:32:36 PM UTC-7, Nicol Bolas wrote:
>
> =20
> The problem here is that, for that to work, you need a special "bitfield=
=20
> pointer" type. That can't be like a regular pointer; it'd have to be=20
> something like a member pointer, which is not just an address. `sizeof` f=
or=20
> regular pointers are all required to be equal; `sizeof` for member pointe=
rs=20
> may be different from that. And the same would be true of your bitfield=
=20
> pointer. It's not an address; you cannot round-trip one through `void*` a=
nd=20
> back. Just as you can't for member pointers.
>
> Given that this "bitfield pointer" would be some kind of struct=20
> (internally), why does it have to be part of the language? Stick it in a=
=20
> library and be done with it. Indeed, as a library-defined type, I can tak=
e=20
> an `int` and get a "bitfield pointer" to some of its bits, operate on tha=
t=20
> "pointer", thus updating the `int` in-situ.
>
> I can't do that if the only way to get a "bitfield pointer" is to start=
=20
> with a variable declaration. I see no advantage to putting this in the=20
> language. There are enough `constexpr` gymnastics and such that can be=20
> played to make this all work as efficiently as native bit manipulation.
>
Re "bit_pointer" and "bit_iterator", see the <bit> header that will arrive=
=20
in C++2a:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0237r7.pdf=20
"Wording for fundamental bit utilities"
=20
> The same goes for the bitfields themselves; do they really *need* to be=
=20
> part of the language? What do we gain by that, besides some convenience i=
n=20
> accessing them? And can we not get that convenience in some other way?
>
Re "simplifying bit-fields," see a now-dead proposal "Registers for C++"=20
(Klemens Morgenstern) that visited SG14 in June 2017:
https://groups.google.com/a/isocpp.org/d/msg/sg14/E_EKDsAgFq0/oaQP9gKkCQAJ
=E2=80=93Arthur
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/7d76ad61-27b8-4f11-a148-3c4b95b10227%40isocpp.or=
g.
------=_Part_2139_2064744041.1534893287967
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, August 21, 2018 at 3:32:36 PM UTC-7, Nicol Bol=
as 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"><div=
>=C2=A0</div><div>The problem here is that, for that to work, you need a sp=
ecial "bitfield pointer" type. That can't be like a regular p=
ointer; it'd have to be something like a member pointer, which is not j=
ust an address. `sizeof` for regular pointers are all required to be equal;=
`sizeof` for member pointers may be different from that. And the same woul=
d be true of your bitfield pointer. It's not an address; you cannot rou=
nd-trip one through `void*` and back. Just as you can't for member poin=
ters.<br></div><div><br></div><div>Given that this "bitfield pointer&q=
uot; would be some kind of struct (internally), why does it have to be part=
of the language? Stick it in a library and be done with it. Indeed, as a l=
ibrary-defined type, I can take an `int` and get a "bitfield pointer&q=
uot; to some of its bits, operate on that "pointer", thus updatin=
g the `int` in-situ.</div><div><br></div><div>I can't do that if the on=
ly way to get a "bitfield pointer" is to start with a variable de=
claration. I see no advantage to putting this in the language. There are en=
ough `constexpr` gymnastics and such that can be played to make this all wo=
rk as efficiently as native bit manipulation.<br></div></div></blockquote><=
div><br></div><div>Re "bit_pointer" and "bit_iterator",=
see the <bit> header that will arrive in C++2a:</div><div><a href=3D=
"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0237r7.pdf">http:=
//www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0237r7.pdf</a> "Wo=
rding for fundamental bit utilities"<br></div><div><br></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 dir=3D"ltr"><div=
></div><div>The same goes for the bitfields themselves; do they really <i>n=
eed</i> to be part of the language? What do we gain by that, besides some c=
onvenience in accessing them? And can we not get that convenience in some o=
ther way?<br></div></div></blockquote><div><br></div><div>Re "simplify=
ing bit-fields," see a now-dead proposal "Registers for C++"=
(Klemens Morgenstern) that visited SG14 in June 2017:</div><div><a href=3D=
"https://groups.google.com/a/isocpp.org/d/msg/sg14/E_EKDsAgFq0/oaQP9gKkCQAJ=
">https://groups.google.com/a/isocpp.org/d/msg/sg14/E_EKDsAgFq0/oaQP9gKkCQA=
J</a><br></div><div><br></div><div>=E2=80=93Arthur</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/7d76ad61-27b8-4f11-a148-3c4b95b10227%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7d76ad61-27b8-4f11-a148-3c4b95b10227=
%40isocpp.org</a>.<br />
------=_Part_2139_2064744041.1534893287967--
------=_Part_2138_163020155.1534893287967--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 21 Aug 2018 17:10:17 -0700 (PDT)
Raw View
------=_Part_2180_394234759.1534896617635
Content-Type: multipart/alternative;
boundary="----=_Part_2181_1409267274.1534896617636"
------=_Part_2181_1409267274.1534896617636
Content-Type: text/plain; charset="UTF-8"
On Tuesday, August 21, 2018 at 7:14:48 PM UTC-4, Arthur O'Dwyer wrote:
>
> On Tuesday, August 21, 2018 at 3:32:36 PM UTC-7, Nicol Bolas wrote:
>>
>>
>> The problem here is that, for that to work, you need a special "bitfield
>> pointer" type. That can't be like a regular pointer; it'd have to be
>> something like a member pointer, which is not just an address. `sizeof` for
>> regular pointers are all required to be equal; `sizeof` for member pointers
>> may be different from that. And the same would be true of your bitfield
>> pointer. It's not an address; you cannot round-trip one through `void*` and
>> back. Just as you can't for member pointers.
>>
>> Given that this "bitfield pointer" would be some kind of struct
>> (internally), why does it have to be part of the language? Stick it in a
>> library and be done with it. Indeed, as a library-defined type, I can take
>> an `int` and get a "bitfield pointer" to some of its bits, operate on that
>> "pointer", thus updating the `int` in-situ.
>>
>> I can't do that if the only way to get a "bitfield pointer" is to start
>> with a variable declaration. I see no advantage to putting this in the
>> language. There are enough `constexpr` gymnastics and such that can be
>> played to make this all work as efficiently as native bit manipulation.
>>
>
> Re "bit_pointer" and "bit_iterator", see the <bit> header that will arrive
> in C++2a:
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0237r7.pdf
> "Wording for fundamental bit utilities"
>
That's close to what we're talking about, but those only manipulate
individual bits. What we're talking about are essentially bit-ranges/spans,
and particularly the ability to manipulate such a span as if it were an
integer value.
So you could have a 6-bit range [3, 9), and do a binary `|=` with the lower
6 bits of a given `int`. Or just assign to it with a given `int`, which
takes the lower 6 bits of the integer. And so forth.
--
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/5c60f59e-ae46-4ded-ae77-084d8e188701%40isocpp.org.
------=_Part_2181_1409267274.1534896617636
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, August 21, 2018 at 7:14:48 PM UTC-4, Arthur O&=
#39;Dwyer 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 Tuesday, August 21, 2018 at 3:32:36 PM UTC-7, Nicol Bolas wrote:<bloc=
kquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>=C2=A0</div><div>T=
he problem here is that, for that to work, you need a special "bitfiel=
d pointer" type. That can't be like a regular pointer; it'd ha=
ve to be something like a member pointer, which is not just an address. `si=
zeof` for regular pointers are all required to be equal; `sizeof` for membe=
r pointers may be different from that. And the same would be true of your b=
itfield pointer. It's not an address; you cannot round-trip one through=
`void*` and back. Just as you can't for member pointers.<br></div><div=
><br></div><div>Given that this "bitfield pointer" would be some =
kind of struct (internally), why does it have to be part of the language? S=
tick it in a library and be done with it. Indeed, as a library-defined type=
, I can take an `int` and get a "bitfield pointer" to some of its=
bits, operate on that "pointer", thus updating the `int` in-situ=
..</div><div><br></div><div>I can't do that if the only way to get a &qu=
ot;bitfield pointer" is to start with a variable declaration. I see no=
advantage to putting this in the language. There are enough `constexpr` gy=
mnastics and such that can be played to make this all work as efficiently a=
s native bit manipulation.<br></div></div></blockquote><div><br></div><div>=
Re "bit_pointer" and "bit_iterator", see the <bit>=
; header that will arrive in C++2a:</div><div><a href=3D"http://www.open-st=
d.org/jtc1/sc22/wg21/docs/papers/2017/p0237r7.pdf" target=3D"_blank" rel=3D=
"nofollow" onmousedown=3D"this.href=3D'http://www.google.com/url?q\x3dh=
ttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2017%2F=
p0237r7.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNF1tO2aZ04A8X3_dYGBBCv7O=
tZDcQ';return true;" onclick=3D"this.href=3D'http://www.google.com/=
url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers=
%2F2017%2Fp0237r7.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNF1tO2aZ04A8X3=
_dYGBBCv7OtZDcQ';return true;">http://www.open-std.org/jtc1/<wbr>sc22/w=
g21/docs/papers/2017/<wbr>p0237r7.pdf</a> "Wording for fundamental bit=
utilities"<br></div></div></blockquote><div><br></div><div>That's=
close to what we're talking about, but those only manipulate individua=
l bits. What we're talking about are essentially bit-ranges/spans, and =
particularly the ability to manipulate such a span as if it were an integer=
value.</div><div><br></div><div>So you could have a 6-bit range [3, 9), an=
d do a binary `|=3D` with the lower 6 bits of a given `int`. Or just assign=
to it with a given `int`, which takes the lower 6 bits of the integer. And=
so forth.</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/5c60f59e-ae46-4ded-ae77-084d8e188701%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5c60f59e-ae46-4ded-ae77-084d8e188701=
%40isocpp.org</a>.<br />
------=_Part_2181_1409267274.1534896617636--
------=_Part_2180_394234759.1534896617635--
.
Author: "Arthur O'Dwyer" <arthur.j.odwyer@gmail.com>
Date: Tue, 21 Aug 2018 17:32:11 -0700
Raw View
--0000000000000640770573fb46f7
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Tue, Aug 21, 2018 at 5:10 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> On Tuesday, August 21, 2018 at 7:14:48 PM UTC-4, Arthur O'Dwyer wrote:
>>
>> On Tuesday, August 21, 2018 at 3:32:36 PM UTC-7, Nicol Bolas wrote:
>>>
>>>
>>> The problem here is that, for that to work, you need a special "bitfiel=
d
>>> pointer" type. That can't be like a regular pointer; it'd have to be
>>> something like a member pointer, which is not just an address. `sizeof`=
for
>>> regular pointers are all required to be equal; `sizeof` for member poin=
ters
>>> may be different from that. And the same would be true of your bitfield
>>> pointer. It's not an address; you cannot round-trip one through `void*`=
and
>>> back. Just as you can't for member pointers.
>>>
>>> Given that this "bitfield pointer" would be some kind of struct
>>> (internally), why does it have to be part of the language? Stick it in =
a
>>> library and be done with it. Indeed, as a library-defined type, I can t=
ake
>>> an `int` and get a "bitfield pointer" to some of its bits, operate on t=
hat
>>> "pointer", thus updating the `int` in-situ.
>>>
>>> I can't do that if the only way to get a "bitfield pointer" is to start
>>> with a variable declaration. I see no advantage to putting this in the
>>> language. There are enough `constexpr` gymnastics and such that can be
>>> played to make this all work as efficiently as native bit manipulation.
>>>
>>
>> Re "bit_pointer" and "bit_iterator", see the <bit> header that will
>> arrive in C++2a:
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0237r7.pdf
>> "Wording for fundamental bit utilities"
>>
>
> That's close to what we're talking about, but those only manipulate
> individual bits. What we're talking about are essentially bit-ranges/span=
s,
> and particularly the ability to manipulate such a span as if it were an
> integer value.
>
> So you could have a 6-bit range [3, 9), and do a binary `|=3D` with the
> lower 6 bits of a given `int`. Or just assign to it with a given `int`,
> which takes the lower 6 bits of the integer. And so forth.
>
I think that's the intent of bit_iterator, although its usability might not
be there yet.
int i1 =3D 0x1234;
int i2 =3D 0x5678;
auto source_begin =3D std::bit_iterator<int*>(&i1, 3);
auto source_end =3D std::bit_iterator<int*>(&i1, 9);
auto dest_begin =3D std::bit_iterator<int*>(&i2);
while (source_begin !=3D source_end) {
*dest_begin++ ^=3D *source_begin++;
}
int expected_result =3D (0x5678 & ~0x003F) | ((0x1234 >> 3) & 0x003F);
assert(i2 =3D=3D expected_result);
The above code is legal C++11-plus-the-<bit>-header. (C++17 CTAD can make
it look even more magical, but I didn't want to confuse matters.)
Given a couple of non-standard but obvious helper functions, you can get
that down to just
int i1 =3D 0x1234;
int i2 =3D 0x5678;
auto source =3D nonstd::make_bit_range(&i1, 3, 9);
nonstd::xor_copy(source.begin(), source.end(),
std::bit_iterator<int*>(&i2));
int expected_result =3D (0x5678 & ~0x003F) | ((0x1234 >> 3) & 0x003F);
assert(i2 =3D=3D expected_result);
Overloading
void operator^=3D(nonstd::bit_range dst, nonstd::bit_range src) {
assert(dst.size() =3D=3D src.size());
nonstd::xor_copy(src.begin(), src.end(), dst.begin());
}
is left as an exercise for the reader... oh no, wait, I've already written
it out. :)
=E2=80=93Arthur
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CADvuK0JCcFVZ181VL6Q728NTgOhQydXm2e2zYEBgrXgkr1G=
O_A%40mail.gmail.com.
--0000000000000640770573fb46f7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tue, Aug 21, 2018 at 5:10 PM, Nicol Bolas <span dir=3D"=
ltr"><<a href=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson=
@gmail.com</a>></span> wrote:<br><div class=3D"gmail_extra"><div class=
=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:r=
gb(204,204,204);padding-left:1ex"><div dir=3D"ltr">On Tuesday, August 21, 2=
018 at 7:14:48 PM UTC-4, Arthur O'Dwyer wrote:<blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-lef=
t-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=
=3D"ltr">On Tuesday, August 21, 2018 at 3:32:36 PM UTC-7, Nicol Bolas wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border=
-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);=
padding-left:1ex"><div dir=3D"ltr"><div>=C2=A0</div><div>The problem here i=
s that, for that to work, you need a special "bitfield pointer" t=
ype. That can't be like a regular pointer; it'd have to be somethin=
g like a member pointer, which is not just an address. `sizeof` for regular=
pointers are all required to be equal; `sizeof` for member pointers may be=
different from that. And the same would be true of your bitfield pointer. =
It's not an address; you cannot round-trip one through `void*` and back=
.. Just as you can't for member pointers.<br></div><div><br></div><div>G=
iven that this "bitfield pointer" would be some kind of struct (i=
nternally), why does it have to be part of the language? Stick it in a libr=
ary and be done with it. Indeed, as a library-defined type, I can take an `=
int` and get a "bitfield pointer" to some of its bits, operate on=
that "pointer", thus updating the `int` in-situ.</div><div><br><=
/div><div>I can't do that if the only way to get a "bitfield point=
er" is to start with a variable declaration. I see no advantage to put=
ting this in the language. There are enough `constexpr` gymnastics and such=
that can be played to make this all work as efficiently as native bit mani=
pulation.<br></div></div></blockquote><div><br></div><div>Re "bit_poin=
ter" and "bit_iterator", see the <bit> header that wil=
l arrive in C++2a:</div><div><a href=3D"http://www.open-std.org/jtc1/sc22/w=
g21/docs/papers/2017/p0237r7.pdf" rel=3D"nofollow" target=3D"_blank">http:/=
/www.open-std.org/jtc1/s<wbr>c22/wg21/docs/papers/2017/p023<wbr>7r7.pdf</a>=
"Wording for fundamental bit utilities"<br></div></div></blockqu=
ote><div><br></div><div>That's close to what we're talking about, b=
ut those only manipulate individual bits. What we're talking about are =
essentially bit-ranges/spans, and particularly the ability to manipulate su=
ch a span as if it were an integer value.</div><div><br></div><div>So you c=
ould have a 6-bit range [3, 9), and do a binary `|=3D` with the lower 6 bit=
s of a given `int`. Or just assign to it with a given `int`, which takes th=
e lower 6 bits of the integer. And so forth.</div></div></blockquote><div><=
br></div><div>I think that's the intent of bit_iterator, although its u=
sability might not be there yet.</div><div><br></div><div>int i1 =3D 0x1234=
;</div><div>int i2 =3D 0x5678;</div><div><div>auto source_begin =3D std::bi=
t_iterator<int*>(&i1, 3);</div></div><div><div>auto source_end =
=3D std::bit_iterator<int*>(&i1, 9);</div></div><div>auto dest_be=
gin =3D std::bit_iterator<int*>(&i2);</div><div>while (source_beg=
in !=3D source_end) {</div><div>=C2=A0 =C2=A0 *dest_begin++ ^=3D *source_be=
gin++;<br></div><div>}</div><div>int expected_result =3D (0x5678 & ~0x0=
03F) | ((0x1234 >> 3) & 0x003F);</div><div>assert(i2 =3D=3D expec=
ted_result);</div><div><br></div><div>The above code is legal C++11-plus-th=
e-<bit>-header. (C++17 CTAD can make it look even more magical, but I=
didn't want to confuse matters.)</div><div>Given a couple of non-stand=
ard but obvious helper functions, you can get that down to just</div><div><=
br></div><div><div><font color=3D"#666666">int i1 =3D 0x1234;</font></div><=
div><font color=3D"#666666">int i2 =3D 0x5678;</font></div><div>auto source=
=3D nonstd::make_bit_range(&i1, 3, 9);</div><div>nonstd::xor_copy(sour=
ce.begin(), source.end(), std::bit_iterator<int*>(&i2));<br></div=
><div><font color=3D"#666666">int expected_result =3D (0x5678 & ~0x003F=
) | ((0x1234 >> 3) & 0x003F);<br></font></div><div><font color=3D=
"#666666">assert(i2 =3D=3D expected_result);</font></div></div><div><br></d=
iv><div>Overloading</div><div>=C2=A0 =C2=A0 void operator^=3D(nonstd::bit_r=
ange dst, nonstd::bit_range src) {</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 as=
sert(dst.size() =3D=3D src.size());</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 n=
onstd::xor_copy(src.begin(), src.end(), dst.begin());</div><div>=C2=A0 =C2=
=A0 }</div><div>is left as an exercise for the reader... oh no, wait, I'=
;ve already written it out. :)</div><div><br></div><div>=E2=80=93Arthur</di=
v></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CADvuK0JCcFVZ181VL6Q728NTgOhQydXm2e2z=
YEBgrXgkr1GO_A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADvuK0JCcFVZ181V=
L6Q728NTgOhQydXm2e2zYEBgrXgkr1GO_A%40mail.gmail.com</a>.<br />
--0000000000000640770573fb46f7--
.
Author: Jake Arkinstall <jake.arkinstall@gmail.com>
Date: Wed, 22 Aug 2018 01:51:28 +0100
Raw View
--000000000000962d9d0573fb8b8d
Content-Type: text/plain; charset="UTF-8"
On Tue, 21 Aug 2018, 23:32 Nicol Bolas, <jmckesson@gmail.com> wrote:
> The problem here is that, for that to work, you need a special "bitfield
> pointer" type. That can't be like a regular pointer; it'd have to be
> something like a member pointer, which is not just an address. `sizeof` for
> regular pointers are all required to be equal; `sizeof` for member pointers
> may be different from that. And the same would be true of your bitfield
> pointer. It's not an address; you cannot round-trip one through `void*` and
> back. Just as you can't for member pointers.
>
> Given that this "bitfield pointer" would be some kind of struct
> (internally), why does it have to be part of the language?
>
That's what I was going for when I did a mock-up using the char array
approach. The pointer isn't a pointer in the language sense, but it just
acts as a common wrapper for whatever is appropriate for the target device,
be it a CPU, a device that uses 9 bit integers, or a device that is capable
of arbitrary type sizes and has some exotic version of pointers to access
them.
Stick it in a library and be done with it. Indeed, as a library-defined
> type, I can take an `int` and get a "bitfield pointer" to some of its bits,
> operate on that "pointer", thus updating the `int` in-situ.
>
> I see no advantage to putting this in the language. There are enough
> `constexpr` gymnastics and such that can be played to make this all work as
> efficiently as native bit manipulation.
>
> The same goes for the bitfields themselves; do they really *need* to be
> part of the language? What do we gain by that, besides some convenience in
> accessing them? And can we not get that convenience in some other way?
>
One use case I can think of is a dynamic array. Say I have a small 6-bit
char with the limited alphabet a-z, A-Z, 0-9, space and null, and I want to
hold a dynamically allocated string of such chars, which works out at a
memory reduction of 1/3 against a normal char string. If we want to do some
processing on that string - e.g. convert to lower case, or search for a
character, it cant just be handled as a blob of data.
It could be possible to do this in the language if we created a bit field
struct with 8 elements (or possibly LCM(N,8)/8). Then a dynamic array could
be implemented as a vector of these bit fields, and we could easily access
individual elements via with a function that provides it (i%8)th member of
vec[i/8].
As for whether all this is worth it, especially worth language changes -
probably not, unless there is any real call for C++ to handle peculiar data
types, or to natively support exotic devices in this way (I'd assume that
the problems go far further than memory access). I don't know enough about
such devices - but figuring out how to handle dynamic allocation of (and
manipulation of) N-bit types is at least an interesting exercise.
--
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/CAC%2B0CCNzT3bvH_C7Ey2-%3D1zER%3Ds%3DzX51fSs36_9QQrn6smanyg%40mail.gmail.com.
--000000000000962d9d0573fb8b8d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div class=3D"gmail_quote" dir=3D"auto"><div dir=3D"ltr">=
On Tue, 21 Aug 2018, 23:32 Nicol Bolas, <<a href=3D"mailto:jmckesson@gma=
il.com">jmckesson@gmail.com</a>> wrote:=C2=A0</div><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex"><div dir=3D"ltr"><div>The problem here is that, for that to work,=
you need a special "bitfield pointer" type. That can't be li=
ke a regular pointer; it'd have to be something like a member pointer, =
which is not just an address. `sizeof` for regular pointers are all require=
d to be equal; `sizeof` for member pointers may be different from that. And=
the same would be true of your bitfield pointer. It's not an address; =
you cannot round-trip one through `void*` and back. Just as you can't f=
or member pointers.</div></div></blockquote></div><div class=3D"gmail_quote=
" dir=3D"auto"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div></div><=
div><br></div><div>Given that this "bitfield pointer" would be so=
me kind of struct (internally), why does it have to be part of the language=
?</div></div></blockquote></div><div dir=3D"auto"><br></div><div dir=3D"aut=
o"><div dir=3D"auto" style=3D"font-family:sans-serif">That's what I was=
going for when I did a mock-up using the char array approach. The pointer =
isn't a pointer in the language sense, but it just acts as a common wra=
pper for whatever is appropriate for the target device, be it a CPU, a devi=
ce that uses 9 bit integers, or a device that is capable of arbitrary type =
sizes and has some exotic version of pointers to access them.</div></div><d=
iv dir=3D"auto"><br></div><div class=3D"gmail_quote" dir=3D"auto"><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex"><div dir=3D"ltr"><div>Stick it in a library and be do=
ne with it. Indeed, as a library-defined type, I can take an `int` and get =
a "bitfield pointer" to some of its bits, operate on that "p=
ointer", thus updating the `int` in-situ.</div></div></blockquote></di=
v><div class=3D"gmail_quote" dir=3D"auto"><blockquote class=3D"gmail_quote"=
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv dir=3D"ltr"><br></div></blockquote></div><div class=3D"gmail_quote" dir=
=3D"auto"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>I see no adv=
antage to putting this in the language. There are enough `constexpr` gymnas=
tics and such that can be played to make this all work as efficiently as na=
tive bit manipulation.</div></div></blockquote></div><div class=3D"gmail_qu=
ote" dir=3D"auto"></div><div class=3D"gmail_quote" dir=3D"auto"></div><div =
class=3D"gmail_quote" dir=3D"auto"><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><div></div><div><br></div></div></blockquote></div><div class=3D"g=
mail_quote" dir=3D"auto"><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><d=
iv>The same goes for the bitfields themselves; do they really <i>need</i> t=
o be part of the language? What do we gain by that, besides some convenienc=
e in accessing them? And can we not get that convenience in some other way?=
<br></div></div></blockquote></div><div dir=3D"auto"><span style=3D"font-fa=
mily:sans-serif"><br></span></div><div dir=3D"auto"><span style=3D"font-fam=
ily:sans-serif">One use case I can think of is a dynamic array. Say I have =
a small 6-bit char with the limited alphabet a-z, A-Z, 0-9, space and null,=
and I want to hold a dynamically allocated string of such chars, which wor=
ks out at a memory reduction of 1/3 against a normal char string. If we wan=
t to do some processing on that string - e.g. convert to lower case, or sea=
rch for a character, it cant just be handled as a blob of data.</span></div=
><div dir=3D"auto"><span style=3D"font-family:sans-serif"><br></span></div>=
<div dir=3D"auto"><span style=3D"font-family:sans-serif">It could be possib=
le to do this in the language if we created a bit field struct with 8 eleme=
nts (or possibly LCM(N,8)/8). Then a dynamic array could be implemented as =
a vector of these bit fields, and we could easily access individual element=
s via with a function that provides it (i%8)th member of vec[i/8].</span></=
div><div dir=3D"auto"><span style=3D"font-family:sans-serif"><br></span></d=
iv><div dir=3D"auto"><span style=3D"font-family:sans-serif">As for whether =
all this is worth it, especially worth language changes - probably not, unl=
ess there is any real call for C++ to handle peculiar data types, or to nat=
ively support exotic devices in this way (I'd assume that the problems =
go far further than memory access). I don't know enough about such devi=
ces - but figuring out how to handle dynamic allocation of (and manipulatio=
n of) N-bit types is at least an interesting exercise.</span></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCNzT3bvH_C7Ey2-%3D1zER%3Ds%3D=
zX51fSs36_9QQrn6smanyg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CC=
NzT3bvH_C7Ey2-%3D1zER%3Ds%3DzX51fSs36_9QQrn6smanyg%40mail.gmail.com</a>.<br=
/>
--000000000000962d9d0573fb8b8d--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 21 Aug 2018 18:22:11 -0700 (PDT)
Raw View
------=_Part_2222_504544555.1534900931771
Content-Type: multipart/alternative;
boundary="----=_Part_2223_550265090.1534900931771"
------=_Part_2223_550265090.1534900931771
Content-Type: text/plain; charset="UTF-8"
On Tuesday, August 21, 2018 at 8:32:14 PM UTC-4, Arthur O'Dwyer wrote:
>
> On Tue, Aug 21, 2018 at 5:10 PM, Nicol Bolas <jmck...@gmail.com
> <javascript:>> wrote:
>
>> On Tuesday, August 21, 2018 at 7:14:48 PM UTC-4, Arthur O'Dwyer wrote:
>>>
>>> On Tuesday, August 21, 2018 at 3:32:36 PM UTC-7, Nicol Bolas wrote:
>>>>
>>>>
>>>> The problem here is that, for that to work, you need a special
>>>> "bitfield pointer" type. That can't be like a regular pointer; it'd have to
>>>> be something like a member pointer, which is not just an address. `sizeof`
>>>> for regular pointers are all required to be equal; `sizeof` for member
>>>> pointers may be different from that. And the same would be true of your
>>>> bitfield pointer. It's not an address; you cannot round-trip one through
>>>> `void*` and back. Just as you can't for member pointers.
>>>>
>>>> Given that this "bitfield pointer" would be some kind of struct
>>>> (internally), why does it have to be part of the language? Stick it in a
>>>> library and be done with it. Indeed, as a library-defined type, I can take
>>>> an `int` and get a "bitfield pointer" to some of its bits, operate on that
>>>> "pointer", thus updating the `int` in-situ.
>>>>
>>>> I can't do that if the only way to get a "bitfield pointer" is to start
>>>> with a variable declaration. I see no advantage to putting this in the
>>>> language. There are enough `constexpr` gymnastics and such that can be
>>>> played to make this all work as efficiently as native bit manipulation.
>>>>
>>>
>>> Re "bit_pointer" and "bit_iterator", see the <bit> header that will
>>> arrive in C++2a:
>>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0237r7.pdf
>>> "Wording for fundamental bit utilities"
>>>
>>
>> That's close to what we're talking about, but those only manipulate
>> individual bits. What we're talking about are essentially bit-ranges/spans,
>> and particularly the ability to manipulate such a span as if it were an
>> integer value.
>>
>> So you could have a 6-bit range [3, 9), and do a binary `|=` with the
>> lower 6 bits of a given `int`. Or just assign to it with a given `int`,
>> which takes the lower 6 bits of the integer. And so forth.
>>
>
> I think that's the intent of bit_iterator, although its usability might
> not be there yet.
>
> int i1 = 0x1234;
> int i2 = 0x5678;
> auto source_begin = std::bit_iterator<int*>(&i1, 3);
> auto source_end = std::bit_iterator<int*>(&i1, 9);
> auto dest_begin = std::bit_iterator<int*>(&i2);
> while (source_begin != source_end) {
> *dest_begin++ ^= *source_begin++;
> }
> int expected_result = (0x5678 & ~0x003F) | ((0x1234 >> 3) & 0x003F);
> assert(i2 == expected_result);
>
> The above code is legal C++11-plus-the-<bit>-header. (C++17 CTAD can make
> it look even more magical, but I didn't want to confuse matters.)
> Given a couple of non-standard but obvious helper functions, you can get
> that down to just
>
> int i1 = 0x1234;
> int i2 = 0x5678;
> auto source = nonstd::make_bit_range(&i1, 3, 9);
> nonstd::xor_copy(source.begin(), source.end(),
> std::bit_iterator<int*>(&i2));
> int expected_result = (0x5678 & ~0x003F) | ((0x1234 >> 3) & 0x003F);
> assert(i2 == expected_result);
>
> Overloading
> void operator^=(nonstd::bit_range dst, nonstd::bit_range src) {
> assert(dst.size() == src.size());
> nonstd::xor_copy(src.begin(), src.end(), dst.begin());
> }
> is left as an exercise for the reader... oh no, wait, I've already written
> it out. :)
>
Except that this would be terribly slow. If you start with "bit_range" as
the fundamental type, and you know you're performing operations on ranges
(or a range and an implicit integer range), you don't have to loop over
some sequence of bits and perform a slow operation that extracts each bit,
manipulates it, and puts it back. You can do the operation on the actual
range of bits.
That is, if you have a bit-range, doing an `xor` with another bit-range
should be O(1), so long as neither range spans beyond the boundaries of
their underlying integer types.
To put it another way, while `bit_iterator` and so forth are nice, and
would be any part of a complete `bit_range` type, `bit_range` as a concept
has value beyond those tools. It's much like the relationship between `T*`
and `std::array` or `std::span`. Yes, `T*` is good to have, but knowing
that you're operating on a `span` is important too.
--
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/b67ed2d5-9a97-4f1d-91c5-17542aaefcd2%40isocpp.org.
------=_Part_2223_550265090.1534900931771
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, August 21, 2018 at 8:32:14 PM UTC-4, Arthur O&=
#39;Dwyer 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 Tue, Aug 21, 2018 at 5:10 PM, Nicol Bolas <span dir=3D"ltr"><<a hr=
ef=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"pZ-_FWNBAAAJ"=
rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';return t=
rue;" onclick=3D"this.href=3D'javascript:';return true;">jmck...@gm=
ail.com</a>></span> wrote:<br><div><div class=3D"gmail_quote"><blockquot=
e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width=
:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-lef=
t:1ex"><div dir=3D"ltr">On Tuesday, August 21, 2018 at 7:14:48 PM UTC-4, Ar=
thur O'Dwyer wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-c=
olor:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">On Tuesday, August=
21, 2018 at 3:32:36 PM UTC-7, Nicol Bolas wrote:<blockquote class=3D"gmail=
_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left=
-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=
=3D"ltr"><div>=C2=A0</div><div>The problem here is that, for that to work, =
you need a special "bitfield pointer" type. That can't be lik=
e a regular pointer; it'd have to be something like a member pointer, w=
hich is not just an address. `sizeof` for regular pointers are all required=
to be equal; `sizeof` for member pointers may be different from that. And =
the same would be true of your bitfield pointer. It's not an address; y=
ou cannot round-trip one through `void*` and back. Just as you can't fo=
r member pointers.<br></div><div><br></div><div>Given that this "bitfi=
eld pointer" would be some kind of struct (internally), why does it ha=
ve to be part of the language? Stick it in a library and be done with it. I=
ndeed, as a library-defined type, I can take an `int` and get a "bitfi=
eld pointer" to some of its bits, operate on that "pointer",=
thus updating the `int` in-situ.</div><div><br></div><div>I can't do t=
hat if the only way to get a "bitfield pointer" is to start with =
a variable declaration. I see no advantage to putting this in the language.=
There are enough `constexpr` gymnastics and such that can be played to mak=
e this all work as efficiently as native bit manipulation.<br></div></div><=
/blockquote><div><br></div><div>Re "bit_pointer" and "bit_it=
erator", see the <bit> header that will arrive in C++2a:</div><d=
iv><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0237=
r7.pdf" rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=3D'=
http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%=
2Fwg21%2Fdocs%2Fpapers%2F2017%2Fp0237r7.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\=
x3dAFQjCNF1tO2aZ04A8X3_dYGBBCv7OtZDcQ';return true;" onclick=3D"this.hr=
ef=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjt=
c1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2017%2Fp0237r7.pdf\x26sa\x3dD\x26sntz\x3=
d1\x26usg\x3dAFQjCNF1tO2aZ04A8X3_dYGBBCv7OtZDcQ';return true;">http://w=
ww.open-std.org/jtc1/<wbr>sc22/wg21/docs/papers/2017/<wbr>p0237r7.pdf</a> &=
quot;Wording for fundamental bit utilities"<br></div></div></blockquot=
e><div><br></div><div>That's close to what we're talking about, but=
those only manipulate individual bits. What we're talking about are es=
sentially bit-ranges/spans, and particularly the ability to manipulate such=
a span as if it were an integer value.</div><div><br></div><div>So you cou=
ld have a 6-bit range [3, 9), and do a binary `|=3D` with the lower 6 bits =
of a given `int`. Or just assign to it with a given `int`, which takes the =
lower 6 bits of the integer. And so forth.</div></div></blockquote><div><br=
></div><div>I think that's the intent of bit_iterator, although its usa=
bility might not be there yet.</div><div><br></div><div>int i1 =3D 0x1234;<=
/div><div>int i2 =3D 0x5678;</div><div><div>auto source_begin =3D std::bit_=
iterator<int*>(&i1, 3);</div></div><div><div>auto source_end =3D =
std::bit_iterator<int*>(&i1, 9);</div></div><div>auto dest_begin =
=3D std::bit_iterator<int*>(&i2);</div><div>while (source_begin !=
=3D source_end) {</div><div>=C2=A0 =C2=A0 *dest_begin++ ^=3D *source_begin+=
+;<br></div><div>}</div><div>int expected_result =3D (0x5678 & ~0x003F)=
| ((0x1234 >> 3) & 0x003F);</div><div>assert(i2 =3D=3D expected_=
result);</div><div><br></div><div>The above code is legal C++11-plus-the-&l=
t;bit>-header. (C++17 CTAD can make it look even more magical, but I did=
n't want to confuse matters.)</div><div>Given a couple of non-standard =
but obvious helper functions, you can get that down to just</div><div><br><=
/div><div><div><font color=3D"#666666">int i1 =3D 0x1234;</font></div><div>=
<font color=3D"#666666">int i2 =3D 0x5678;</font></div><div>auto source =3D=
nonstd::make_bit_range(&i1, 3, 9);</div><div>nonstd::xor_copy(source.b=
egin(<wbr>), source.end(), std::bit_iterator<int*>(&i2));<br></di=
v><div><font color=3D"#666666">int expected_result =3D (0x5678 & ~0x003=
F) | ((0x1234 >> 3) & 0x003F);<br></font></div><div><font color=
=3D"#666666">assert(i2 =3D=3D expected_result);</font></div></div><div><br>=
</div><div>Overloading</div><div>=C2=A0 =C2=A0 void operator^=3D(nonstd::bi=
t_range dst, nonstd::bit_range src) {</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0=
assert(dst.size() =3D=3D src.size());</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 nonstd::xor_copy(src.begin(), src.end(), dst.begin());</div><div>=C2=A0=
=C2=A0 }</div><div>is left as an exercise for the reader... oh no, wait, I=
've already written it out. :)</div></div></div></div></blockquote><div=
><br></div><div>Except that this would be terribly slow. If you start with =
"bit_range" as the fundamental type, and you know you're perf=
orming operations on ranges (or a range and an implicit integer range), you=
don't have to loop over some sequence of bits and perform a slow opera=
tion that extracts each bit, manipulates it, and puts it back. You can do t=
he operation on the actual range of bits.</div><div><br></div><div>That is,=
if you have a bit-range, doing an `xor` with another bit-range should be O=
(1), so long as neither range spans beyond the boundaries of their underlyi=
ng integer types.</div><div><br></div><div>To put it another way, while `bi=
t_iterator` and so forth are nice, and would be any part of a complete `bit=
_range` type, `bit_range` as a concept has value beyond those tools. It'=
;s much like the relationship between `T*` and `std::array` or `std::span`.=
Yes, `T*` is good to have, but knowing that you're operating on a `spa=
n` is important too.<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/b67ed2d5-9a97-4f1d-91c5-17542aaefcd2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b67ed2d5-9a97-4f1d-91c5-17542aaefcd2=
%40isocpp.org</a>.<br />
------=_Part_2223_550265090.1534900931771--
------=_Part_2222_504544555.1534900931771--
.
Author: "Arthur O'Dwyer" <arthur.j.odwyer@gmail.com>
Date: Wed, 22 Aug 2018 16:37:29 -0700
Raw View
--0000000000003d791a05740ea0d1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Tue, Aug 21, 2018 at 6:22 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> On Tuesday, August 21, 2018 at 8:32:14 PM UTC-4, Arthur O'Dwyer wrote:
>>
>> On Tue, Aug 21, 2018 at 5:10 PM, Nicol Bolas <jmck...@gmail.com> wrote:
>>
>>> On Tuesday, August 21, 2018 at 7:14:48 PM UTC-4, Arthur O'Dwyer wrote:
>>>>
>>>>
>>>> Re "bit_pointer" and "bit_iterator", see the <bit> header that will
>>>> arrive in C++2a:
>>>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0237r7.pdf
>>>> "Wording for fundamental bit utilities"
>>>>
>>>
>>> That's close to what we're talking about, but those only manipulate
>>> individual bits. What we're talking about are essentially bit-ranges/sp=
ans,
>>> and particularly the ability to manipulate such a span as if it were an
>>> integer value.
>>>
>>> So you could have a 6-bit range [3, 9), and do a binary `|=3D` with the
>>> lower 6 bits of a given `int`. Or just assign to it with a given `int`,
>>> which takes the lower 6 bits of the integer. And so forth.
>>>
>>
>> I think that's the intent of bit_iterator, although its usability might
>> not be there yet.
>>
>> int i1 =3D 0x1234;
>> int i2 =3D 0x5678;
>> auto source_begin =3D std::bit_iterator<int*>(&i1, 3);
>> auto source_end =3D std::bit_iterator<int*>(&i1, 9);
>> auto dest_begin =3D std::bit_iterator<int*>(&i2);
>> while (source_begin !=3D source_end) {
>> *dest_begin++ ^=3D *source_begin++;
>> }
>> int expected_result =3D (0x5678 & ~0x003F) | ((0x1234 >> 3) & 0x003F);
>> assert(i2 =3D=3D expected_result);
>>
>> The above code is legal C++11-plus-the-<bit>-header. (C++17 CTAD can mak=
e
>> it look even more magical, but I didn't want to confuse matters.)
>> Given a couple of non-standard but obvious helper functions, you can get
>> that down to just
>>
>> int i1 =3D 0x1234;
>> int i2 =3D 0x5678;
>> auto source =3D nonstd::make_bit_range(&i1, 3, 9);
>> nonstd::xor_copy(source.begin(), source.end(),
>> std::bit_iterator<int*>(&i2));
>> int expected_result =3D (0x5678 & ~0x003F) | ((0x1234 >> 3) & 0x003F);
>> assert(i2 =3D=3D expected_result);
>>
>> Overloading
>> void operator^=3D(nonstd::bit_range dst, nonstd::bit_range src) {
>> assert(dst.size() =3D=3D src.size());
>> nonstd::xor_copy(src.begin(), src.end(), dst.begin());
>> }
>> is left as an exercise for the reader... oh no, wait, I've already
>> written it out. :)
>>
>
> Except that this would be terribly slow. If you start with "bit_range" as
> the fundamental type, and you know you're performing operations on ranges
> (or a range and an implicit integer range), you don't have to loop over
> some sequence of bits and perform a slow operation that extracts each bit=
,
> manipulates it, and puts it back. You can do the operation on the actual
> range of bits.
>
> That is, if you have a bit-range, doing an `xor` with another bit-range
> should be O(1), so long as neither range spans beyond the boundaries of
> their underlying integer types.
>
Agreed: in a perfect world, we want `xor_copy` to give us perfect codegen.
Like you, I suspect that the naive implementation of `xor_copy` as a loop
over `bit_reference::operator^=3D` will never give perfect codegen (and if =
it
ever does, it will be due to heroics by the compiler, which cannot be
trusted at -O0).
However, the implementor of `xor_copy` (whether that's the working
programmer or the STL vendor) might provide a special
overload/dispatch/constrained version of `xor_copy` that Does The Right
Thing whenever its template type parameter is `std::bit_iterator<T*>`.
> To put it another way, while `bit_iterator` and so forth are nice, and
> would be any part of a complete `bit_range` type, `bit_range` as a concep=
t
> has value beyond those tools. It's much like the relationship between `T*=
`
> and `std::array` or `std::span`. Yes, `T*` is good to have, but knowing
> that you're operating on a `span` is important too.
>
I'm not sure I grok this paragraph. If I have two bit_iterators `first` and
`last`, then *by definition* they form a "bit range" (or else I'll have UB
when I try to iterate from one to the other). The same thing is true of
native pointers: if I have pointers `first` and `last`, then by definition
they form a "contiguous range."
I'd be 100% on board with you if you said that just as the C++17 STL has
the concrete type `T*` but lacks a concept "ContiguousIterator," the C++2a
STL will have the concrete type `bit_iterator<T*>` but lack the concept
"ContiguousBitIterator."
Regardless, the implementor of `xor_copy` will have to do some hard work if
they want to overload/dispatch/constrain a version of `xor_copy` that Does
The Right Thing for `reverse_iterator<bit_iterator<T*>>`,
`reverse_iterator<reverse_iterator<bit_iterator<T*>>>`, etc. etc.
Lack of ContiguousIterator is an ongoing pain point, and the current
https://xkcd.com/927 proposed for Ranges (iterator_concept) will probably
just make the pain worse. I don't think this is necessarily a problem for
bit-iterator operations, any more than it is for the existing std::copy and
other such algorithms that optimize based on contiguity.
=E2=80=93Arthur
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CADvuK0JNHwnt8Fvg-P7h5udSGSNOpN56i-4W9JA6faC%3D3=
XpQJQ%40mail.gmail.com.
--0000000000003d791a05740ea0d1
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tue, Aug 21, 2018 at 6:22 PM, Nicol Bolas <span dir=3D"=
ltr"><<a href=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson=
@gmail.com</a>></span> wrote:<br><div class=3D"gmail_extra"><div class=
=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:r=
gb(204,204,204);padding-left:1ex"><div dir=3D"ltr">On Tuesday, August 21, 2=
018 at 8:32:14 PM UTC-4, Arthur O'Dwyer wrote:<blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-lef=
t-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=
=3D"ltr">On Tue, Aug 21, 2018 at 5:10 PM, Nicol Bolas <span dir=3D"ltr"><=
;<a rel=3D"nofollow">jmck...@gmail.com</a>></span> wrote:<br><div><div c=
lass=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-col=
or:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">On Tuesday, August 2=
1, 2018 at 7:14:48 PM UTC-4, Arthur O'Dwyer wrote:<blockquote class=3D"=
gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border=
-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div=
dir=3D"ltr"><div><br></div><div>Re "bit_pointer" and "bit_i=
terator", see the <bit> header that will arrive in C++2a:</div><=
div><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p023=
7r7.pdf" rel=3D"nofollow" target=3D"_blank">http://www.open-std.org/jtc1/s<=
wbr>c22/wg21/docs/papers/2017/p023<wbr>7r7.pdf</a> "Wording for fundam=
ental bit utilities"<br></div></div></blockquote><div><br></div><div>T=
hat's close to what we're talking about, but those only manipulate =
individual bits. What we're talking about are essentially bit-ranges/sp=
ans, and particularly the ability to manipulate such a span as if it were a=
n integer value.</div><div><br></div><div>So you could have a 6-bit range [=
3, 9), and do a binary `|=3D` with the lower 6 bits of a given `int`. Or ju=
st assign to it with a given `int`, which takes the lower 6 bits of the int=
eger. And so forth.</div></div></blockquote><div><br></div><div>I think tha=
t's the intent of bit_iterator, although its usability might not be the=
re yet.</div><div><br></div><div>int i1 =3D 0x1234;</div><div>int i2 =3D 0x=
5678;</div><div><div>auto source_begin =3D std::bit_iterator<int*>(&a=
mp;i1, 3);</div></div><div><div>auto source_end =3D std::bit_iterator<in=
t*>(&i1, 9);</div></div><div>auto dest_begin =3D std::bit_iterator&l=
t;int*>(&i2);</div><div>while (source_begin !=3D source_end) {</div>=
<div>=C2=A0 =C2=A0 *dest_begin++ ^=3D *source_begin++;<br></div><div>}</div=
><div>int expected_result =3D (0x5678 & ~0x003F) | ((0x1234 >> 3)=
& 0x003F);</div><div>assert(i2 =3D=3D expected_result);</div><div><br>=
</div><div>The above code is legal C++11-plus-the-<bit>-header. (C++1=
7 CTAD can make it look even more magical, but I didn't want to confuse=
matters.)</div><div>Given a couple of non-standard but obvious helper func=
tions, you can get that down to just</div><div><br></div><div><div><font co=
lor=3D"#666666">int i1 =3D 0x1234;</font></div><div><font color=3D"#666666"=
>int i2 =3D 0x5678;</font></div><div>auto source =3D nonstd::make_bit_range=
(&i1, 3, 9);</div><div>nonstd::xor_copy(source.begin(<wbr>), source.end=
(), std::bit_iterator<int*>(&i2));<br></div><div><font color=3D"#=
666666">int expected_result =3D (0x5678 & ~0x003F) | ((0x1234 >> =
3) & 0x003F);<br></font></div><div><font color=3D"#666666">assert(i2 =
=3D=3D expected_result);</font></div></div><div><br></div><div>Overloading<=
/div><div>=C2=A0 =C2=A0 void operator^=3D(nonstd::bit_range dst, nonstd::bi=
t_range src) {</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 assert(dst.size() =3D=
=3D src.size());</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 nonstd::xor_copy(src=
..begin(), src.end(), dst.begin());</div><div>=C2=A0 =C2=A0 }</div><div>is l=
eft as an exercise for the reader... oh no, wait, I've already written =
it out. :)</div></div></div></div></blockquote><div><br></div><div>Except t=
hat this would be terribly slow. If you start with "bit_range" as=
the fundamental type, and you know you're performing operations on ran=
ges (or a range and an implicit integer range), you don't have to loop =
over some sequence of bits and perform a slow operation that extracts each =
bit, manipulates it, and puts it back. You can do the operation on the actu=
al range of bits.</div><div><br></div><div>That is, if you have a bit-range=
, doing an `xor` with another bit-range should be O(1), so long as neither =
range spans beyond the boundaries of their underlying integer types.</div><=
/div></blockquote><div><br></div><div>Agreed: in a perfect world, we want `=
xor_copy` to give us perfect codegen.</div><div>Like you, I suspect that th=
e naive implementation of `xor_copy` as a loop over `bit_reference::operato=
r^=3D` will never give perfect codegen (and if it ever does, it will be due=
to heroics by the compiler, which cannot be trusted at -O0).<br></div><div=
>However, the implementor of `xor_copy` (whether that's the working pro=
grammer or the STL vendor) might provide a special overload/dispatch/constr=
ained version of `xor_copy` that Does The Right Thing whenever its template=
type parameter is `std::bit_iterator<T*>`.</div><div><br></div><div>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
..8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(20=
4,204,204);padding-left:1ex"><div dir=3D"ltr"><div>To put it another way, w=
hile `bit_iterator` and so forth are nice, and would be any part of a compl=
ete `bit_range` type, `bit_range` as a concept has value beyond those tools=
.. It's much like the relationship between `T*` and `std::array` or `std=
::span`. Yes, `T*` is good to have, but knowing that you're operating o=
n a `span` is important too.</div></div></blockquote><div><br></div><div>I&=
#39;m not sure I grok this paragraph. If I have two bit_iterators `first` a=
nd `last`, then <i>by definition</i> they form a "bit range" (or =
else I'll have UB when I try to iterate from one to the other).=C2=A0 T=
he same thing is true of native pointers: if I have pointers `first` and `l=
ast`, then by definition they form a "contiguous range."</div><di=
v>I'd be 100% on board with you if you said that just as the C++17 STL =
has the concrete type `T*` but lacks a concept "ContiguousIterator,&qu=
ot; the C++2a STL will have the concrete type `bit_iterator<T*>` but =
lack the concept "ContiguousBitIterator."</div><div><br></div><di=
v>Regardless, the implementor of `xor_copy` will have to do some hard work =
if they want to overload/dispatch/constrain a version of `xor_copy` that Do=
es The Right Thing for `reverse_iterator<bit_iterator<T*>>`, `r=
everse_iterator<reverse_iterator<bit_iterator<T*>>>`, etc=
.. etc.</div><div><br></div><div>Lack of ContiguousIterator is an ongoing pa=
in point, and the current <a href=3D"https://xkcd.com/927">https://xkcd.com=
/927</a>=C2=A0proposed for Ranges (iterator_concept) will probably just mak=
e the pain worse. I don't think this is necessarily a problem for bit-i=
terator operations, any more than it is for the existing std::copy and othe=
r such algorithms that optimize based on contiguity.</div><div><br></div><d=
iv>=E2=80=93Arthur</div></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CADvuK0JNHwnt8Fvg-P7h5udSGSNOpN56i-4W=
9JA6faC%3D3XpQJQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADvuK0JNHwnt8F=
vg-P7h5udSGSNOpN56i-4W9JA6faC%3D3XpQJQ%40mail.gmail.com</a>.<br />
--0000000000003d791a05740ea0d1--
.
Author: "Arthur O'Dwyer" <arthur.j.odwyer@gmail.com>
Date: Wed, 22 Aug 2018 17:57:39 -0700
Raw View
--000000000000f8899005740fbe5f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Wed, Aug 22, 2018 at 4:37 PM, Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
wrote:
> On Tue, Aug 21, 2018 at 6:22 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
>
>> On Tuesday, August 21, 2018 at 8:32:14 PM UTC-4, Arthur O'Dwyer wrote:
>>>
>>> On Tue, Aug 21, 2018 at 5:10 PM, Nicol Bolas <jmck...@gmail.com> wrote:
>>>
>>>> On Tuesday, August 21, 2018 at 7:14:48 PM UTC-4, Arthur O'Dwyer wrote:
>>>>
>>>>>
>>>>> Re "bit_pointer" and "bit_iterator", see the <bit> header that will
>>>>> arrive in C++2a:
>>>>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0237r7.pdf
>>>>> "Wording for fundamental bit utilities"
>>>>>
>>>>
>>>> That's close to what we're talking about, but those only manipulate
>>>> individual bits. What we're talking about are essentially bit-ranges/s=
pans,
>>>> and particularly the ability to manipulate such a span as if it were a=
n
>>>> integer value.
>>>>
>>>> So you could have a 6-bit range [3, 9), and do a binary `|=3D` with th=
e
>>>> lower 6 bits of a given `int`. Or just assign to it with a given `int`=
,
>>>> which takes the lower 6 bits of the integer. And so forth.
>>>>
>>>
>>> I think that's the intent of bit_iterator, although its usability might
>>> not be there yet.
>>>
>>> int i1 =3D 0x1234;
>>> int i2 =3D 0x5678;
>>> auto source_begin =3D std::bit_iterator<int*>(&i1, 3);
>>> auto source_end =3D std::bit_iterator<int*>(&i1, 9);
>>> auto dest_begin =3D std::bit_iterator<int*>(&i2);
>>> while (source_begin !=3D source_end) {
>>> *dest_begin++ ^=3D *source_begin++;
>>> }
>>> int expected_result =3D (0x5678 & ~0x003F) | ((0x1234 >> 3) & 0x003F);
>>> assert(i2 =3D=3D expected_result);
>>>
>>> The above code is legal C++11-plus-the-<bit>-header. (C++17 CTAD can
>>> make it look even more magical, but I didn't want to confuse matters.)
>>> Given a couple of non-standard but obvious helper functions, you can ge=
t
>>> that down to just
>>>
>>> int i1 =3D 0x1234;
>>> int i2 =3D 0x5678;
>>> auto source =3D nonstd::make_bit_range(&i1, 3, 9);
>>> nonstd::xor_copy(source.begin(), source.end(),
>>> std::bit_iterator<int*>(&i2));
>>> int expected_result =3D (0x5678 & ~0x003F) | ((0x1234 >> 3) & 0x003F);
>>> assert(i2 =3D=3D expected_result);
>>>
>>> Overloading
>>> void operator^=3D(nonstd::bit_range dst, nonstd::bit_range src) {
>>> assert(dst.size() =3D=3D src.size());
>>> nonstd::xor_copy(src.begin(), src.end(), dst.begin());
>>> }
>>> is left as an exercise for the reader... oh no, wait, I've already
>>> written it out. :)
>>>
>>
>> Except that this would be terribly slow. If you start with "bit_range" a=
s
>> the fundamental type, and you know you're performing operations on range=
s
>> (or a range and an implicit integer range), you don't have to loop over
>> some sequence of bits and perform a slow operation that extracts each bi=
t,
>> manipulates it, and puts it back. You can do the operation on the actual
>> range of bits.
>>
>> That is, if you have a bit-range, doing an `xor` with another bit-range
>> should be O(1), so long as neither range spans beyond the boundaries of
>> their underlying integer types.
>>
>
> Agreed: in a perfect world, we want `xor_copy` to give us perfect codegen=
..
> Like you, I suspect that the naive implementation of `xor_copy` as a loop
> over `bit_reference::operator^=3D` will never give perfect codegen (and i=
f it
> ever does, it will be due to heroics by the compiler, which cannot be
> trusted at -O0).
> However, the implementor of `xor_copy` (whether that's the working
> programmer or the STL vendor) might provide a special
> overload/dispatch/constrained version of `xor_copy` that Does The Right
> Thing whenever its template type parameter is `std::bit_iterator<T*>`.
>
Example of getting perfect codegen out of a generic `xor_copy` with a super
quick-and-dirty fast path. I do not claim this code is production-ready. :)
https://godbolt.org/z/ZZD453
Thanks to Vincent Reverdy for https://github.com/vreverdy/bit!
=E2=80=93Arthur
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CADvuK0Ld-7Eej9B7BLjT60qUM-evN5kWRzV5L4Gwg7pKNGk=
fSA%40mail.gmail.com.
--000000000000f8899005740fbe5f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wed, Aug 22, 2018 at 4:37 PM, Arthur O'Dwyer <span =
dir=3D"ltr"><<a href=3D"mailto:arthur.j.odwyer@gmail.com" target=3D"_bla=
nk">arthur.j.odwyer@gmail.com</a>></span> wrote:<br><div class=3D"gmail_=
extra"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;=
border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><span=
class=3D"gmail-">On Tue, Aug 21, 2018 at 6:22 PM, Nicol Bolas <span dir=3D=
"ltr"><<a href=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesso=
n@gmail.com</a>></span> wrote:<br></span><div class=3D"gmail_extra"><div=
class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-c=
olor:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><span class=3D"gma=
il-">On Tuesday, August 21, 2018 at 8:32:14 PM UTC-4, Arthur O'Dwyer wr=
ote:</span><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.=
8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204=
,204,204);padding-left:1ex"><div dir=3D"ltr"><span class=3D"gmail-">On Tue,=
Aug 21, 2018 at 5:10 PM, Nicol Bolas <span dir=3D"ltr"><<a rel=3D"nofol=
low">jmck...@gmail.com</a>></span> wrote:<br></span><div><div class=3D"g=
mail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
..8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(20=
4,204,204);padding-left:1ex"><div dir=3D"ltr"><span class=3D"gmail-">On Tue=
sday, August 21, 2018 at 7:14:48 PM UTC-4, Arthur O'Dwyer wrote:</span>=
<div><div class=3D"gmail-h5"><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-=
left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div><br></d=
iv><div>Re "bit_pointer" and "bit_iterator", see the &l=
t;bit> header that will arrive in C++2a:</div><div><a href=3D"http://www=
..open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0237r7.pdf" rel=3D"nofollow"=
target=3D"_blank">http://www.open-std.org/jtc1/s<wbr>c22/wg21/docs/papers/=
2017/p023<wbr>7r7.pdf</a> "Wording for fundamental bit utilities"=
<br></div></div></blockquote><div><br></div><div>That's close to what w=
e're talking about, but those only manipulate individual bits. What we&=
#39;re talking about are essentially bit-ranges/spans, and particularly the=
ability to manipulate such a span as if it were an integer value.</div><di=
v><br></div><div>So you could have a 6-bit range [3, 9), and do a binary `|=
=3D` with the lower 6 bits of a given `int`. Or just assign to it with a gi=
ven `int`, which takes the lower 6 bits of the integer. And so forth.</div>=
</div></div></div></blockquote><div><div class=3D"gmail-h5"><div><br></div>=
<div>I think that's the intent of bit_iterator, although its usability =
might not be there yet.</div><div><br></div><div>int i1 =3D 0x1234;</div><d=
iv>int i2 =3D 0x5678;</div><div><div>auto source_begin =3D std::bit_iterato=
r<int*>(&i1, 3);</div></div><div><div>auto source_end =3D std::bi=
t_iterator<int*>(&i1, 9);</div></div><div>auto dest_begin =3D std=
::bit_iterator<int*>(&i2);</div><div>while (source_begin !=3D sou=
rce_end) {</div><div>=C2=A0 =C2=A0 *dest_begin++ ^=3D *source_begin++;<br><=
/div><div>}</div><div>int expected_result =3D (0x5678 & ~0x003F) | ((0x=
1234 >> 3) & 0x003F);</div><div>assert(i2 =3D=3D expected_result)=
;</div><div><br></div><div>The above code is legal C++11-plus-the-<bit&g=
t;-header. (C++17 CTAD can make it look even more magical, but I didn't=
want to confuse matters.)</div><div>Given a couple of non-standard but obv=
ious helper functions, you can get that down to just</div><div><br></div><d=
iv><div><font color=3D"#666666">int i1 =3D 0x1234;</font></div><div><font c=
olor=3D"#666666">int i2 =3D 0x5678;</font></div><div>auto source =3D nonstd=
::make_bit_range(&i1, 3, 9);</div><div>nonstd::xor_copy(source.begin(<w=
br>), source.end(), std::bit_iterator<int*>(&i2));<br></div><div>=
<font color=3D"#666666">int expected_result =3D (0x5678 & ~0x003F) | ((=
0x1234 >> 3) & 0x003F);<br></font></div><div><font color=3D"#6666=
66">assert(i2 =3D=3D expected_result);</font></div></div><div><br></div><di=
v>Overloading</div><div>=C2=A0 =C2=A0 void operator^=3D(nonstd::bit_range d=
st, nonstd::bit_range src) {</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 assert(d=
st.size() =3D=3D src.size());</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 nonstd:=
:xor_copy(src.begin(), src.end(), dst.begin());</div><div>=C2=A0 =C2=A0 }</=
div><div>is left as an exercise for the reader... oh no, wait, I've alr=
eady written it out. :)</div></div></div></div></div></div></blockquote><di=
v><div class=3D"gmail-h5"><div><br></div><div>Except that this would be ter=
ribly slow. If you start with "bit_range" as the fundamental type=
, and you know you're performing operations on ranges (or a range and a=
n implicit integer range), you don't have to loop over some sequence of=
bits and perform a slow operation that extracts each bit, manipulates it, =
and puts it back. You can do the operation on the actual range of bits.</di=
v><div><br></div><div>That is, if you have a bit-range, doing an `xor` with=
another bit-range should be O(1), so long as neither range spans beyond th=
e boundaries of their underlying integer types.</div></div></div></div></bl=
ockquote><div><br></div><div>Agreed: in a perfect world, we want `xor_copy`=
to give us perfect codegen.</div><div>Like you, I suspect that the naive i=
mplementation of `xor_copy` as a loop over `bit_reference::operator^=3D` wi=
ll never give perfect codegen (and if it ever does, it will be due to heroi=
cs by the compiler, which cannot be trusted at -O0).<br></div><div>However,=
the implementor of `xor_copy` (whether that's the working programmer o=
r the STL vendor) might provide a special overload/dispatch/constrained ver=
sion of `xor_copy` that Does The Right Thing whenever its template type par=
ameter is `std::bit_iterator<T*>`.</div></div></div></div></blockquot=
e><div><br></div><div>Example of getting perfect codegen out of a generic `=
xor_copy` with a super quick-and-dirty fast path. I do not claim this code =
is production-ready. :)</div><div><a href=3D"https://godbolt.org/z/ZZD453">=
https://godbolt.org/z/ZZD453</a></div><div>Thanks to Vincent Reverdy for=C2=
=A0<a href=3D"https://github.com/vreverdy/bit">https://github.com/vreverdy/=
bit</a>!</div><div><br></div><div>=E2=80=93Arthur</div></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CADvuK0Ld-7Eej9B7BLjT60qUM-evN5kWRzV5=
L4Gwg7pKNGkfSA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADvuK0Ld-7Eej9B7=
BLjT60qUM-evN5kWRzV5L4Gwg7pKNGkfSA%40mail.gmail.com</a>.<br />
--000000000000f8899005740fbe5f--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Thu, 23 Aug 2018 08:18:01 -0700 (PDT)
Raw View
------=_Part_3024_285891722.1535037481193
Content-Type: multipart/alternative;
boundary="----=_Part_3025_728246992.1535037481194"
------=_Part_3025_728246992.1535037481194
Content-Type: text/plain; charset="UTF-8"
On Wednesday, August 22, 2018 at 7:37:32 PM UTC-4, Arthur O'Dwyer wrote:
>
> On Tue, Aug 21, 2018 at 6:22 PM, Nicol Bolas <jmck...@gmail.com
> <javascript:>> wrote:
>
>> On Tuesday, August 21, 2018 at 8:32:14 PM UTC-4, Arthur O'Dwyer wrote:
>>>
>>> On Tue, Aug 21, 2018 at 5:10 PM, Nicol Bolas <jmck...@gmail.com> wrote:
>>>
>>>> On Tuesday, August 21, 2018 at 7:14:48 PM UTC-4, Arthur O'Dwyer wrote:
>>>>>
>>>>>
>>>>> Re "bit_pointer" and "bit_iterator", see the <bit> header that will
>>>>> arrive in C++2a:
>>>>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0237r7.pdf
>>>>> "Wording for fundamental bit utilities"
>>>>>
>>>>
>>>> That's close to what we're talking about, but those only manipulate
>>>> individual bits. What we're talking about are essentially bit-ranges/spans,
>>>> and particularly the ability to manipulate such a span as if it were an
>>>> integer value.
>>>>
>>>> So you could have a 6-bit range [3, 9), and do a binary `|=` with the
>>>> lower 6 bits of a given `int`. Or just assign to it with a given `int`,
>>>> which takes the lower 6 bits of the integer. And so forth.
>>>>
>>>
>>> I think that's the intent of bit_iterator, although its usability might
>>> not be there yet.
>>>
>>> int i1 = 0x1234;
>>> int i2 = 0x5678;
>>> auto source_begin = std::bit_iterator<int*>(&i1, 3);
>>> auto source_end = std::bit_iterator<int*>(&i1, 9);
>>> auto dest_begin = std::bit_iterator<int*>(&i2);
>>> while (source_begin != source_end) {
>>> *dest_begin++ ^= *source_begin++;
>>> }
>>> int expected_result = (0x5678 & ~0x003F) | ((0x1234 >> 3) & 0x003F);
>>> assert(i2 == expected_result);
>>>
>>> The above code is legal C++11-plus-the-<bit>-header. (C++17 CTAD can
>>> make it look even more magical, but I didn't want to confuse matters.)
>>> Given a couple of non-standard but obvious helper functions, you can get
>>> that down to just
>>>
>>> int i1 = 0x1234;
>>> int i2 = 0x5678;
>>> auto source = nonstd::make_bit_range(&i1, 3, 9);
>>> nonstd::xor_copy(source.begin(), source.end(),
>>> std::bit_iterator<int*>(&i2));
>>> int expected_result = (0x5678 & ~0x003F) | ((0x1234 >> 3) & 0x003F);
>>> assert(i2 == expected_result);
>>>
>>> Overloading
>>> void operator^=(nonstd::bit_range dst, nonstd::bit_range src) {
>>> assert(dst.size() == src.size());
>>> nonstd::xor_copy(src.begin(), src.end(), dst.begin());
>>> }
>>> is left as an exercise for the reader... oh no, wait, I've already
>>> written it out. :)
>>>
>>
>> Except that this would be terribly slow. If you start with "bit_range" as
>> the fundamental type, and you know you're performing operations on ranges
>> (or a range and an implicit integer range), you don't have to loop over
>> some sequence of bits and perform a slow operation that extracts each bit,
>> manipulates it, and puts it back. You can do the operation on the actual
>> range of bits.
>>
>> That is, if you have a bit-range, doing an `xor` with another bit-range
>> should be O(1), so long as neither range spans beyond the boundaries of
>> their underlying integer types.
>>
>
> Agreed: in a perfect world, we want `xor_copy` to give us perfect codegen.
> Like you, I suspect that the naive implementation of `xor_copy` as a loop
> over `bit_reference::operator^=` will never give perfect codegen (and if it
> ever does, it will be due to heroics by the compiler, which cannot be
> trusted at -O0).
> However, the implementor of `xor_copy` (whether that's the working
> programmer or the STL vendor) might provide a special
> overload/dispatch/constrained version of `xor_copy` that Does The Right
> Thing whenever its template type parameter is `std::bit_iterator<T*>`.
>
>
>
>> To put it another way, while `bit_iterator` and so forth are nice, and
>> would be any part of a complete `bit_range` type, `bit_range` as a concept
>> has value beyond those tools. It's much like the relationship between `T*`
>> and `std::array` or `std::span`. Yes, `T*` is good to have, but knowing
>> that you're operating on a `span` is important too.
>>
>
> I'm not sure I grok this paragraph. If I have two bit_iterators `first`
> and `last`, then *by definition* they form a "bit range" (or else I'll
> have UB when I try to iterate from one to the other). The same thing is
> true of native pointers: if I have pointers `first` and `last`, then by
> definition they form a "contiguous range."
> I'd be 100% on board with you if you said that just as the C++17 STL has
> the concrete type `T*` but lacks a concept "ContiguousIterator," the C++2a
> STL will have the concrete type `bit_iterator<T*>` but lack the concept
> "ContiguousBitIterator."
>
> Regardless, the implementor of `xor_copy` will have to do some hard work
> if they want to overload/dispatch/constrain a version of `xor_copy` that
> Does The Right Thing for `reverse_iterator<bit_iterator<T*>>`,
> `reverse_iterator<reverse_iterator<bit_iterator<T*>>>`, etc. etc.
>
> Lack of ContiguousIterator is an ongoing pain point, and the current
> https://xkcd.com/927 proposed for Ranges (iterator_concept) will probably
> just make the pain worse. I don't think this is necessarily a problem for
> bit-iterator operations, any more than it is for the existing std::copy and
> other such algorithms that optimize based on contiguity.
>
I think this discussion has veered somewhat off the point of the thread.
The point of this proposal was to have a way to declare bitfields, then get
a field from the bitfield and manipulate it like an integer of some number
of bits.
Iterators can't do that in the same way that an `int*` cannot replace
`int`. Iterators are useful, but you need a *range* for this purpose. That
is, a bitfield reference is conceptually a range of bits within one or more
contiguous integers.
But just because it is conceptually a range doesn't mean it has to be
implemented as a pair of `bit_iterators`. It can *provide* those, but it
shouldn't literally *be* those. Why? Because the range itself has meaning.
It needs to be able to do things like this:
uint32_t val = 0;
bitfield_reference<uint32_t, 4, 20> ref(val);
ref = 0xFFFF; //Sets all of the bits.
ref &= 0xF0F0; //Clears some of the bits, preserving others.
uint32_t val2 = ref;
std::cout << val2 << std::endl; //prints 0xF0F0.
std::cout << val << std::endl; //prints 0xF0F00.
--
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/68d97df3-8bf3-49e3-84d6-5bc9fa6b2def%40isocpp.org.
------=_Part_3025_728246992.1535037481194
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Wednesday, August 22, 2018 at 7:37:32 PM UTC-4,=
Arthur O'Dwyer 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 Tue, Aug 21, 2018 at 6:22 PM, Nicol Bolas <span dir=3D"ltr"=
><<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"iex=
zf_uMAAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:'=
;;return true;" onclick=3D"this.href=3D'javascript:';return true;">=
jmck...@gmail.com</a>></span> wrote:<br><div><div class=3D"gmail_quote">=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);p=
adding-left:1ex"><div dir=3D"ltr">On Tuesday, August 21, 2018 at 8:32:14 PM=
UTC-4, Arthur O'Dwyer wrote:<blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;bor=
der-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">On Tue, =
Aug 21, 2018 at 5:10 PM, Nicol Bolas <span dir=3D"ltr"><<a rel=3D"nofoll=
ow">jmck...@gmail.com</a>></span> wrote:<br><div><div class=3D"gmail_quo=
te"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,20=
4);padding-left:1ex"><div dir=3D"ltr">On Tuesday, August 21, 2018 at 7:14:4=
8 PM UTC-4, Arthur O'Dwyer wrote:<blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid=
;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div=
><br></div><div>Re "bit_pointer" and "bit_iterator", se=
e the <bit> header that will arrive in C++2a:</div><div><a href=3D"ht=
tp://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0237r7.pdf" rel=3D"n=
ofollow" target=3D"_blank" onmousedown=3D"this.href=3D'http://www.googl=
e.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2F=
papers%2F2017%2Fp0237r7.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNF1tO2aZ=
04A8X3_dYGBBCv7OtZDcQ';return true;" onclick=3D"this.href=3D'http:/=
/www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21=
%2Fdocs%2Fpapers%2F2017%2Fp0237r7.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQ=
jCNF1tO2aZ04A8X3_dYGBBCv7OtZDcQ';return true;">http://www.open-std.org/=
jtc1/<wbr>sc22/wg21/docs/papers/2017/<wbr>p0237r7.pdf</a> "Wording for=
fundamental bit utilities"<br></div></div></blockquote><div><br></div=
><div>That's close to what we're talking about, but those only mani=
pulate individual bits. What we're talking about are essentially bit-ra=
nges/spans, and particularly the ability to manipulate such a span as if it=
were an integer value.</div><div><br></div><div>So you could have a 6-bit =
range [3, 9), and do a binary `|=3D` with the lower 6 bits of a given `int`=
.. Or just assign to it with a given `int`, which takes the lower 6 bits of =
the integer. And so forth.</div></div></blockquote><div><br></div><div>I th=
ink that's the intent of bit_iterator, although its usability might not=
be there yet.</div><div><br></div><div>int i1 =3D 0x1234;</div><div>int i2=
=3D 0x5678;</div><div><div>auto source_begin =3D std::bit_iterator<int*=
>(&i1, 3);</div></div><div><div>auto source_end =3D std::bit_iterato=
r<int*>(&i1, 9);</div></div><div>auto dest_begin =3D std::bit_ite=
rator<int*>(&i2);</div><div>while (source_begin !=3D source_end) =
{</div><div>=C2=A0 =C2=A0 *dest_begin++ ^=3D *source_begin++;<br></div><div=
>}</div><div>int expected_result =3D (0x5678 & ~0x003F) | ((0x1234 >=
> 3) & 0x003F);</div><div>assert(i2 =3D=3D expected_result);</div><d=
iv><br></div><div>The above code is legal C++11-plus-the-<bit>-header=
.. (C++17 CTAD can make it look even more magical, but I didn't want to =
confuse matters.)</div><div>Given a couple of non-standard but obvious help=
er functions, you can get that down to just</div><div><br></div><div><div><=
font color=3D"#666666">int i1 =3D 0x1234;</font></div><div><font color=3D"#=
666666">int i2 =3D 0x5678;</font></div><div>auto source =3D nonstd::make_bi=
t_range(&i1, 3, 9);</div><div>nonstd::xor_copy(source.begin(<wbr>), sou=
rce.end(), std::bit_iterator<int*>(&i2));<br></div><div><font col=
or=3D"#666666">int expected_result =3D (0x5678 & ~0x003F) | ((0x1234 &g=
t;> 3) & 0x003F);<br></font></div><div><font color=3D"#666666">asser=
t(i2 =3D=3D expected_result);</font></div></div><div><br></div><div>Overloa=
ding</div><div>=C2=A0 =C2=A0 void operator^=3D(nonstd::bit_range dst, nonst=
d::bit_range src) {</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 assert(dst.size()=
=3D=3D src.size());</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 nonstd::xor_copy=
(src.begin(), src.end(), dst.begin());</div><div>=C2=A0 =C2=A0 }</div><div>=
is left as an exercise for the reader... oh no, wait, I've already writ=
ten it out. :)</div></div></div></div></blockquote><div><br></div><div>Exce=
pt that this would be terribly slow. If you start with "bit_range"=
; as the fundamental type, and you know you're performing operations on=
ranges (or a range and an implicit integer range), you don't have to l=
oop over some sequence of bits and perform a slow operation that extracts e=
ach bit, manipulates it, and puts it back. You can do the operation on the =
actual range of bits.</div><div><br></div><div>That is, if you have a bit-r=
ange, doing an `xor` with another bit-range should be O(1), so long as neit=
her range spans beyond the boundaries of their underlying integer types.</d=
iv></div></blockquote><div><br></div><div>Agreed: in a perfect world, we wa=
nt `xor_copy` to give us perfect codegen.</div><div>Like you, I suspect tha=
t the naive implementation of `xor_copy` as a loop over `bit_reference::ope=
rator^=3D` will never give perfect codegen (and if it ever does, it will be=
due to heroics by the compiler, which cannot be trusted at -O0).<br></div>=
<div>However, the implementor of `xor_copy` (whether that's the working=
programmer or the STL vendor) might provide a special overload/dispatch/co=
nstrained version of `xor_copy` that Does The Right Thing whenever its temp=
late type parameter is `std::bit_iterator<T*>`.</div><div><br></div><=
div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rg=
b(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>To put it another wa=
y, while `bit_iterator` and so forth are nice, and would be any part of a c=
omplete `bit_range` type, `bit_range` as a concept has value beyond those t=
ools. It's much like the relationship between `T*` and `std::array` or =
`std::span`. Yes, `T*` is good to have, but knowing that you're operati=
ng on a `span` is important too.</div></div></blockquote><div><br></div><di=
v>I'm not sure I grok this paragraph. If I have two bit_iterators `firs=
t` and `last`, then <i>by definition</i> they form a "bit range" =
(or else I'll have UB when I try to iterate from one to the other).=C2=
=A0 The same thing is true of native pointers: if I have pointers `first` a=
nd `last`, then by definition they form a "contiguous range."</di=
v><div>I'd be 100% on board with you if you said that just as the C++17=
STL has the concrete type `T*` but lacks a concept "ContiguousIterato=
r," the C++2a STL will have the concrete type `bit_iterator<T*>`=
but lack the concept "ContiguousBitIterator."</div><div><br></di=
v><div>Regardless, the implementor of `xor_copy` will have to do some hard =
work if they want to overload/dispatch/constrain a version of `xor_copy` th=
at Does The Right Thing for `reverse_iterator<bit_<wbr>iterator<T*>=
;>`, `reverse_iterator<reverse_<wbr>iterator<bit_iterator<T*>=
;>>`, etc. etc.</div><div><br></div><div>Lack of ContiguousIterator i=
s an ongoing pain point, and the current <a href=3D"https://xkcd.com/927" t=
arget=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'https://w=
ww.google.com/url?q\x3dhttps%3A%2F%2Fxkcd.com%2F927\x26sa\x3dD\x26sntz\x3d1=
\x26usg\x3dAFQjCNEBS0UxzYblCNKm1Aq59s9bTgLmxw';return true;" onclick=3D=
"this.href=3D'https://www.google.com/url?q\x3dhttps%3A%2F%2Fxkcd.com%2F=
927\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEBS0UxzYblCNKm1Aq59s9bTgLmxw=
9;;return true;">https://xkcd.com/927</a>=C2=A0proposed for Ranges (iterato=
r_concept) will probably just make the pain worse. I don't think this i=
s necessarily a problem for bit-iterator operations, any more than it is fo=
r the existing std::copy and other such algorithms that optimize based on c=
ontiguity.</div></div></div></div></blockquote><div><br></div><div>I think =
this discussion has veered somewhat off the point of the thread. The point =
of this proposal was to have a way to declare bitfields, then get a=20
field from the bitfield and manipulate it like an integer of some number
of bits.</div><div><br></div><div>Iterators can't do that in the same =
way that an `int*` cannot replace `int`. Iterators are useful, but you need=
a <i>range</i> for this purpose. That is, a bitfield reference is conceptu=
ally a range of bits within one or more contiguous integers.</div><div><br>=
</div><div>But just because it is conceptually a range doesn't mean it =
has to be implemented as a pair of `bit_iterators`. It can <i>provide</i> t=
hose, but it shouldn't literally <i>be</i> those. Why? Because the rang=
e itself has meaning. It needs to be able to do things like this:</div><div=
><br></div><div style=3D"background-color: rgb(250, 250, 250); border-color=
: rgb(187, 187, 187); border-style: solid; border-width: 1px; overflow-wrap=
: break-word;" class=3D"prettyprint"><code class=3D"prettyprint"><div class=
=3D"subprettyprint"><span style=3D"color: #000;" class=3D"styled-by-prettif=
y">uint32_t val </span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
</span><span style=3D"color: #066;" class=3D"styled-by-prettify">0</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>bitfield_reference</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify"><</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify">uint32_t</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #06=
6;" class=3D"styled-by-prettify">4</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #066;" class=3D"styled-by-pret=
tify">20</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&g=
t;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span>=
<span style=3D"color: #008;" class=3D"styled-by-prettify">ref</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify">val</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">);</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" class=3D=
"styled-by-prettify">ref</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
/span><span style=3D"color: #066;" class=3D"styled-by-prettify">0xFFFF</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #800;" class=3D"styled-by-prettify">//Sets all of the bits.</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span sty=
le=3D"color: #008;" class=3D"styled-by-prettify">ref</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">&=3D</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> </span><span style=3D"color: #066;" class=
=3D"styled-by-prettify">0xF0F0</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: #800;" class=3D"styled-by-prettify=
">//Clears some of the bits, preserving others.</span><span style=3D"color:=
#000;" class=3D"styled-by-prettify"><br>uint32_t val2 </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">ref</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br>std</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy">cout </span><span style=3D"color: #660;" class=3D"styled-by-prettify">&=
lt;<</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> va=
l2 </span><span style=3D"color: #660;" class=3D"styled-by-prettify"><<=
;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> std</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify">endl</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: #800;" =
class=3D"styled-by-prettify">//prints 0xF0F0.</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"><br>std</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">cout </span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify"><<</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> val </span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify"><<</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> std</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">endl=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #800;" class=3D"styled-by-prettify">//prints 0xF0F00.</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div></co=
de></div><div><br></div><div><br></div><div><br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/68d97df3-8bf3-49e3-84d6-5bc9fa6b2def%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/68d97df3-8bf3-49e3-84d6-5bc9fa6b2def=
%40isocpp.org</a>.<br />
------=_Part_3025_728246992.1535037481194--
------=_Part_3024_285891722.1535037481193--
.
Author: "Arthur O'Dwyer" <arthur.j.odwyer@gmail.com>
Date: Thu, 23 Aug 2018 10:24:54 -0700
Raw View
--0000000000009e538d05741d8953
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Thu, Aug 23, 2018 at 8:18 AM, Nicol Bolas <jmckesson@gmail.com> wrote:
> On Wednesday, August 22, 2018 at 7:37:32 PM UTC-4, Arthur O'Dwyer wrote:
>
>> On Tue, Aug 21, 2018 at 6:22 PM, Nicol Bolas <jmck...@gmail.com> wrote:
>>
>>> On Tuesday, August 21, 2018 at 8:32:14 PM UTC-4, Arthur O'Dwyer wrote:
>>>>
>>>> On Tue, Aug 21, 2018 at 5:10 PM, Nicol Bolas <jmck...@gmail.com> wrote=
:
>>>>
>>>>> On Tuesday, August 21, 2018 at 7:14:48 PM UTC-4, Arthur O'Dwyer wrote=
:
>>>>>>
>>>>>>
>>>>>> Re "bit_pointer" and "bit_iterator", see the <bit> header that will
>>>>>> arrive in C++2a:
>>>>>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0237r7.pdf
>>>>>> "Wording for fundamental bit utilities"
>>>>>>
>>>>>
>>>>> That's close to what we're talking about, but those only manipulate
>>>>> individual bits. What we're talking about are essentially bit-ranges/=
spans,
>>>>> and particularly the ability to manipulate such a span as if it were =
an
>>>>> integer value.
>>>>>
>>>>> So you could have a 6-bit range [3, 9), and do a binary `|=3D` with t=
he
>>>>> lower 6 bits of a given `int`. Or just assign to it with a given `int=
`,
>>>>> which takes the lower 6 bits of the integer. And so forth.
>>>>>
>>>>
>>>> I think that's the intent of bit_iterator, although its usability migh=
t
>>>> not be there yet.
>>>>
>>>
>> [...] the implementor of `xor_copy` (whether that's the working
>> programmer or the STL vendor) might provide a special
>> overload/dispatch/constrained version of `xor_copy` that Does The Right
>> Thing whenever its template type parameter is `std::bit_iterator<T*>`.
>>
>>
>>> To put it another way, while `bit_iterator` and so forth are nice, and
>>> would be any part of a complete `bit_range` type, `bit_range` as a conc=
ept
>>> has value beyond those tools. It's much like the relationship between `=
T*`
>>> and `std::array` or `std::span`. Yes, `T*` is good to have, but knowing
>>> that you're operating on a `span` is important too.
>>>
>>
>> I'm not sure I grok this paragraph. If I have two bit_iterators `first`
>> and `last`, then *by definition* they form a "bit range" (or else I'll
>> have UB when I try to iterate from one to the other). The same thing is
>> true of native pointers: if I have pointers `first` and `last`, then by
>> definition they form a "contiguous range." [...]
>>
>
> I think this discussion has veered somewhat off the point of the thread.
> The point of this proposal was to have a way to declare bitfields, then g=
et
> a field from the bitfield and manipulate it like an integer of some numbe=
r
> of bits.
>
> Iterators can't do that in the same way that an `int*` cannot replace
> `int`. Iterators are useful, but you need a *range* for this purpose.
> That is, a bitfield reference is conceptually a range of bits within one =
or
> more contiguous integers.
>
> But just because it is conceptually a range doesn't mean it has to be
> implemented as a pair of `bit_iterators`. It can *provide* those, but it
> shouldn't literally *be* those. Why? Because the range itself has
> meaning. It needs to be able to do things like this:
>
> uint32_t val =3D 0;
> bitfield_reference<uint32_t, 4, 20> ref(val);
> ref =3D 0xFFFF; //Sets all of the bits.
> ref &=3D 0xF0F0; //Clears some of the bits, preserving others.
> uint32_t val2 =3D ref;
> std::cout << val2 << std::endl; //prints 0xF0F0.
> std::cout << val << std::endl; //prints 0xF0F00.
>
Ah, I see what you mean now, I think.
I wouldn't call your "ref" either a "range" or a "span" =E2=80=94 conceptua=
lly
you're treating it not as a *sequence* of elementary bits, but as a *single=
*
elementary thing of its own, with an `operator=3D` and so on. We can
definitely implement that using bit_iterator under the hood (or vice versa
implement it as its own thing and then expose a bit_iterator interface if
we feel like it), but you're right, conceptually it's different from a
two-iterator range.
I'd like to see someone make a GitHub repo for a library like this. :)
=E2=80=93Arthur
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CADvuK0Jx067WdNohsZudGpfqDyfWdeXns7D5LEwuPRCCs1_=
5Qw%40mail.gmail.com.
--0000000000009e538d05741d8953
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thu, Aug 23, 2018 at 8:18 AM, Nicol Bolas <span dir=3D"=
ltr"><<a href=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson=
@gmail.com</a>></span> wrote:<div class=3D"gmail_extra"><div class=3D"gm=
ail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Wednesday, Au=
gust 22, 2018 at 7:37:32 PM UTC-4, Arthur O'Dwyer wrote:<div><div class=
=3D"h5"><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">On Tue, Au=
g 21, 2018 at 6:22 PM, Nicol Bolas <span dir=3D"ltr"><<a rel=3D"nofollow=
">jmck...@gmail.com</a>></span> wrote:<br><div><div class=3D"gmail_quote=
"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204)=
;padding-left:1ex"><div dir=3D"ltr">On Tuesday, August 21, 2018 at 8:32:14 =
PM UTC-4, Arthur O'Dwyer wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;=
border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">On Tu=
e, Aug 21, 2018 at 5:10 PM, Nicol Bolas <span dir=3D"ltr"><<a rel=3D"nof=
ollow">jmck...@gmail.com</a>></span> wrote:<br><div><div class=3D"gmail_=
quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;=
border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204=
,204);padding-left:1ex"><div dir=3D"ltr">On Tuesday, August 21, 2018 at 7:1=
4:48 PM UTC-4, Arthur O'Dwyer wrote:<blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:so=
lid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><=
div><br></div><div>Re "bit_pointer" and "bit_iterator",=
see the <bit> header that will arrive in C++2a:</div><div><a href=3D=
"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0237r7.pdf" rel=
=3D"nofollow" target=3D"_blank">http://www.open-std.org/jtc1/s<wbr>c22/wg21=
/docs/papers/2017/p023<wbr>7r7.pdf</a> "Wording for fundamental bit ut=
ilities"<br></div></div></blockquote><div><br></div><div>That's cl=
ose to what we're talking about, but those only manipulate individual b=
its. What we're talking about are essentially bit-ranges/spans, and par=
ticularly the ability to manipulate such a span as if it were an integer va=
lue.</div><div><br></div><div>So you could have a 6-bit range [3, 9), and d=
o a binary `|=3D` with the lower 6 bits of a given `int`. Or just assign to=
it with a given `int`, which takes the lower 6 bits of the integer. And so=
forth.</div></div></blockquote><div><br></div><div>I think that's the =
intent of bit_iterator, although its usability might not be there yet.</div=
></div></div></div></blockquote></div></blockquote><div><br></div><div>[...=
] the implementor of `xor_copy` (whether that's the working programmer =
or the STL vendor) might provide a special overload/dispatch/constrained ve=
rsion of `xor_copy` that Does The Right Thing whenever its template type pa=
rameter is `std::bit_iterator<T*>`.<br></div><div>=C2=A0</div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-wi=
dth:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-=
left:1ex"><div dir=3D"ltr"><div>To put it another way, while `bit_iterator`=
and so forth are nice, and would be any part of a complete `bit_range` typ=
e, `bit_range` as a concept has value beyond those tools. It's much lik=
e the relationship between `T*` and `std::array` or `std::span`. Yes, `T*` =
is good to have, but knowing that you're operating on a `span` is impor=
tant too.</div></div></blockquote><div><br></div><div>I'm not sure I gr=
ok this paragraph. If I have two bit_iterators `first` and `last`, then <i>=
by definition</i> they form a "bit range" (or else I'll have =
UB when I try to iterate from one to the other).=C2=A0 The same thing is tr=
ue of native pointers: if I have pointers `first` and `last`, then by defin=
ition they form a "contiguous range." [...]</div></div></div></di=
v></blockquote><div><br></div></div></div><div>I think this discussion has =
veered somewhat off the point of the thread. The point of this proposal was=
to have a way to declare bitfields, then get a=20
field from the bitfield and manipulate it like an integer of some number
of bits.</div><div><br></div><div>Iterators can't do that in the same =
way that an `int*` cannot replace `int`. Iterators are useful, but you need=
a <i>range</i> for this purpose. That is, a bitfield reference is conceptu=
ally a range of bits within one or more contiguous integers.</div><div><br>=
</div><div>But just because it is conceptually a range doesn't mean it =
has to be implemented as a pair of `bit_iterators`. It can <i>provide</i> t=
hose, but it shouldn't literally <i>be</i> those. Why? Because the rang=
e itself has meaning. It needs to be able to do things like this:</div><div=
><br></div><div style=3D"background-color:rgb(250,250,250);border-color:rgb=
(187,187,187);border-style:solid;border-width:1px" class=3D"m_4160469174397=
258077prettyprint"><code class=3D"m_4160469174397258077prettyprint"><div cl=
ass=3D"m_4160469174397258077subprettyprint"><span style=3D"color:#000" clas=
s=3D"m_4160469174397258077styled-by-prettify">uint32_t val </span><span sty=
le=3D"color:#660" class=3D"m_4160469174397258077styled-by-prettify">=3D</sp=
an><span style=3D"color:#000" class=3D"m_4160469174397258077styled-by-prett=
ify"> </span><span style=3D"color:#066" class=3D"m_4160469174397258077style=
d-by-prettify">0</span><span style=3D"color:#660" class=3D"m_41604691743972=
58077styled-by-prettify">;</span><span style=3D"color:#000" class=3D"m_4160=
469174397258077styled-by-prettify"><br>bitfield_reference</span><span style=
=3D"color:#660" class=3D"m_4160469174397258077styled-by-prettify"><</spa=
n><span style=3D"color:#000" class=3D"m_4160469174397258077styled-by-pretti=
fy">uint32_t</span><span style=3D"color:#660" class=3D"m_416046917439725807=
7styled-by-prettify">,</span><span style=3D"color:#000" class=3D"m_41604691=
74397258077styled-by-prettify"> </span><span style=3D"color:#066" class=3D"=
m_4160469174397258077styled-by-prettify">4</span><span style=3D"color:#660"=
class=3D"m_4160469174397258077styled-by-prettify">,</span><span style=3D"c=
olor:#000" class=3D"m_4160469174397258077styled-by-prettify"> </span><span =
style=3D"color:#066" class=3D"m_4160469174397258077styled-by-prettify">20</=
span><span style=3D"color:#660" class=3D"m_4160469174397258077styled-by-pre=
ttify">></span><span style=3D"color:#000" class=3D"m_4160469174397258077=
styled-by-prettify"> </span><span style=3D"color:#008" class=3D"m_416046917=
4397258077styled-by-prettify">ref</span><span style=3D"color:#660" class=3D=
"m_4160469174397258077styled-by-prettify">(</span><span style=3D"color:#000=
" class=3D"m_4160469174397258077styled-by-prettify">val</span><span style=
=3D"color:#660" class=3D"m_4160469174397258077styled-by-prettify">);</span>=
<span style=3D"color:#000" class=3D"m_4160469174397258077styled-by-prettify=
"><br></span><span style=3D"color:#008" class=3D"m_4160469174397258077style=
d-by-prettify">ref</span><span style=3D"color:#000" class=3D"m_416046917439=
7258077styled-by-prettify"> </span><span style=3D"color:#660" class=3D"m_41=
60469174397258077styled-by-prettify">=3D</span><span style=3D"color:#000" c=
lass=3D"m_4160469174397258077styled-by-prettify"> </span><span style=3D"col=
or:#066" class=3D"m_4160469174397258077styled-by-prettify">0xFFFF</span><sp=
an style=3D"color:#660" class=3D"m_4160469174397258077styled-by-prettify">;=
</span><span style=3D"color:#000" class=3D"m_4160469174397258077styled-by-p=
rettify"> </span><span style=3D"color:#800" class=3D"m_4160469174397258077s=
tyled-by-prettify">//Sets all of the bits.</span><span style=3D"color:#000"=
class=3D"m_4160469174397258077styled-by-prettify"><br></span><span style=
=3D"color:#008" class=3D"m_4160469174397258077styled-by-prettify">ref</span=
><span style=3D"color:#000" class=3D"m_4160469174397258077styled-by-prettif=
y"> </span><span style=3D"color:#660" class=3D"m_4160469174397258077styled-=
by-prettify">&=3D</span><span style=3D"color:#000" class=3D"m_416046917=
4397258077styled-by-prettify"> </span><span style=3D"color:#066" class=3D"m=
_4160469174397258077styled-by-prettify">0xF0F0</span><span style=3D"color:#=
660" class=3D"m_4160469174397258077styled-by-prettify">;</span><span style=
=3D"color:#000" class=3D"m_4160469174397258077styled-by-prettify"> </span><=
span style=3D"color:#800" class=3D"m_4160469174397258077styled-by-prettify"=
>//Clears some of the bits, preserving others.</span><span style=3D"color:#=
000" class=3D"m_4160469174397258077styled-by-prettify"><br>uint32_t val2 </=
span><span style=3D"color:#660" class=3D"m_4160469174397258077styled-by-pre=
ttify">=3D</span><span style=3D"color:#000" class=3D"m_4160469174397258077s=
tyled-by-prettify"> </span><span style=3D"color:#008" class=3D"m_4160469174=
397258077styled-by-prettify">ref</span><span style=3D"color:#660" class=3D"=
m_4160469174397258077styled-by-prettify">;</span><span style=3D"color:#000"=
class=3D"m_4160469174397258077styled-by-prettify"><br>std</span><span styl=
e=3D"color:#660" class=3D"m_4160469174397258077styled-by-prettify">::</span=
><span style=3D"color:#000" class=3D"m_4160469174397258077styled-by-prettif=
y">cout </span><span style=3D"color:#660" class=3D"m_4160469174397258077sty=
led-by-prettify"><<</span><span style=3D"color:#000" class=3D"m_41604=
69174397258077styled-by-prettify"> val2 </span><span style=3D"color:#660" c=
lass=3D"m_4160469174397258077styled-by-prettify"><<</span><span style=
=3D"color:#000" class=3D"m_4160469174397258077styled-by-prettify"> std</spa=
n><span style=3D"color:#660" class=3D"m_4160469174397258077styled-by-pretti=
fy">::</span><span style=3D"color:#000" class=3D"m_4160469174397258077style=
d-by-prettify">endl</span><span style=3D"color:#660" class=3D"m_41604691743=
97258077styled-by-prettify">;</span><span style=3D"color:#000" class=3D"m_4=
160469174397258077styled-by-prettify"> </span><span style=3D"color:#800" cl=
ass=3D"m_4160469174397258077styled-by-prettify">//prints 0xF0F0.</span><spa=
n style=3D"color:#000" class=3D"m_4160469174397258077styled-by-prettify"><b=
r>std</span><span style=3D"color:#660" class=3D"m_4160469174397258077styled=
-by-prettify">::</span><span style=3D"color:#000" class=3D"m_41604691743972=
58077styled-by-prettify">cout </span><span style=3D"color:#660" class=3D"m_=
4160469174397258077styled-by-prettify"><<</span><span style=3D"color:=
#000" class=3D"m_4160469174397258077styled-by-prettify"> val </span><span s=
tyle=3D"color:#660" class=3D"m_4160469174397258077styled-by-prettify"><&=
lt;</span><span style=3D"color:#000" class=3D"m_4160469174397258077styled-b=
y-prettify"> std</span><span style=3D"color:#660" class=3D"m_41604691743972=
58077styled-by-prettify">::</span><span style=3D"color:#000" class=3D"m_416=
0469174397258077styled-by-prettify">endl</span><span style=3D"color:#660" c=
lass=3D"m_4160469174397258077styled-by-prettify">;</span><span style=3D"col=
or:#000" class=3D"m_4160469174397258077styled-by-prettify"> </span><span st=
yle=3D"color:#800" class=3D"m_4160469174397258077styled-by-prettify">//prin=
ts 0xF0F00.</span></div></code></div></div></blockquote><div><br></div><div=
>Ah, I see what you mean now, I think.</div><div>I wouldn't call your &=
quot;ref" either a "range" or a "span" =E2=80=94 c=
onceptually you're treating it not as a <i>sequence</i> of elementary b=
its, but as a <i>single</i> elementary thing of its own, with an `operator=
=3D` and so on.=C2=A0 We can definitely implement that using bit_iterator u=
nder the hood (or vice versa implement it as its own thing and then expose =
a bit_iterator interface if we feel like it), but you're right, concept=
ually it's different from a two-iterator range.</div><div><br></div><di=
v>I'd like to see someone make a GitHub repo for a library like this. :=
)</div><div><br></div><div>=E2=80=93Arthur</div></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CADvuK0Jx067WdNohsZudGpfqDyfWdeXns7D5=
LEwuPRCCs1_5Qw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADvuK0Jx067WdNoh=
sZudGpfqDyfWdeXns7D5LEwuPRCCs1_5Qw%40mail.gmail.com</a>.<br />
--0000000000009e538d05741d8953--
.