Topic: alias_ptr, restrict_ptr, unaligned_ptr
Author: Myriachan <myriachan@gmail.com>
Date: Tue, 6 Oct 2015 13:46:49 -0700 (PDT)
Raw View
------=_Part_3117_204775915.1444164409066
Content-Type: multipart/alternative;
boundary="----=_Part_3118_1327568840.1444164409067"
------=_Part_3118_1327568840.1444164409067
Content-Type: text/plain; charset=UTF-8
I think that there should be ways to request pointer aliasing, the inverse
(restricted pointers), and unaligned pointers.
For alias_ptr, you'd tell it the type being pointed to, and maybe the types
it could alias. The latter is an optimization, but not really necessary.
int main()
{
float f = 2.0f;
std::alias_ptr<unsigned, float> alias = reinterpret_cast<unsigned *>(f);
*alias = 0x3F800000u;
std::printf("%f\n", f); // prints 1.0 on typical architectures.
}
For restrict_ptr, it would essentially be the same as C99's restrict
keyword, just in a pseudo-library form.
int restrict_demo(std::restrict_ptr<int> x, std::restrict_ptr<int> y)
{
*x = 1;
*y = 2;
return *x + *y;
}
int main()
{
int z;
std::printf("%d\n", restrict_demo(&z, &z)); // undefined behavior
}
For unaligned_ptr, it would allow access to misaligned objects on hardware
for which this matters.
int main()
{
alignas(int) char buffer[sizeof(int) * 2];
int t = 2;
std::memcpy(&buffer[1], &t, sizeof(t));
std::unaligned_ptr<int> p = reinterpret_cast<int *>(&buffer[1]);
std::printf("%d\n", *p);
}
Note that this could only be supported on platforms for which
reinterpret_cast can be done to any pointer/reference type without being
aligned. Though undefined in the Standard, most platforms are like this.
unaligned_ptr could have implementation-specific extensions, such as for
SSE on x86:
void add(__m128i *px, std::unaligned_ptr<__m128i> py)
{
__m128i x = *px; // movdqa
__m128i y = *py; // movdqu
...
}
I personally think that unaligned pointers would be better off as a
CV-qualifier, like Microsoft's __unaligned, but that probably would be even
less popular than this.
Melissa
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_3118_1327568840.1444164409067
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I think that there should be ways to request pointer alias=
ing, the inverse (restricted pointers), and unaligned pointers.<br><br>For =
<span style=3D"font-family: courier new,monospace;">alias_ptr</span>, you&#=
39;d tell it the type being pointed to, and maybe the types it could alias.=
=C2=A0 The latter is an optimization, but not really necessary.<br><br><div=
class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); borde=
r-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-w=
rap: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"=
><span style=3D"color: #008;" class=3D"styled-by-prettify">int</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> main</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">()</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #008=
;" class=3D"styled-by-prettify">float</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> f </span><span style=3D"color: #660;" 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-pretti=
fy">2.0f</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =
=C2=A0 std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">alias_pt=
r</span><span style=3D"color: #660;" class=3D"styled-by-prettify"><</spa=
n><span style=3D"color: #008;" class=3D"styled-by-prettify">unsigned</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"col=
or: #008;" class=3D"styled-by-prettify">float</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: #008;" class=3D"=
styled-by-prettify">alias</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </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: #008;" class=3D"styled-by-prettify">reinterpre=
t_cast</span><span style=3D"color: #660;" class=3D"styled-by-prettify"><=
</span><span style=3D"color: #008;" class=3D"styled-by-prettify">unsigned</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">*>(</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify">f</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">);</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">*</span><span style=3D"color: #008=
;" class=3D"styled-by-prettify">alias</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"st=
yled-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=
">0x3F800000u</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
=C2=A0 =C2=A0 std</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">p=
rintf</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</sp=
an><span style=3D"color: #080;" class=3D"styled-by-prettify">"%f\n&quo=
t;</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> f</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> =C2=A0</span><span style=3D"colo=
r: #800;" class=3D"styled-by-prettify">// prints 1.0 on typical architectur=
es.</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span></div=
></code></div><br><br>For <span style=3D"font-family: courier new,monospace=
;">restrict_ptr</span>, it would essentially be the same as C99's restr=
ict keyword, just in a pseudo-library form.<br><br><div class=3D"prettyprin=
t" style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 18=
7, 187); border-style: solid; border-width: 1px; word-wrap: break-word;"><c=
ode class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"colo=
r: #008;" class=3D"styled-by-prettify">int</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> restrict_demo</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify">std</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify">restrict_ptr</span><span style=3D"color: #080;" class=3D"styled=
-by-prettify"><int></span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> x</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> s=
td</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify">restrict_ptr</sp=
an><span style=3D"color: #080;" class=3D"styled-by-prettify"><int></s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> y</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">*</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify">x </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #066;" class=3D"styled-by-pr=
ettify">1</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0=
=C2=A0 </span><span style=3D"color: #660;" class=3D"styled-by-prettify">*<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify">y </span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"col=
or: #066;" class=3D"styled-by-prettify">2</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #008=
;" class=3D"styled-by-prettify">return</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">*</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify">x </span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">+</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">*</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify">y</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br><br></span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">int</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> main</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">()</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </=
span><span style=3D"color: #008;" class=3D"styled-by-prettify">int</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> z</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 std</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify">printf</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #080;" =
class=3D"styled-by-prettify">"%d\n"</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> restrict_demo</span><span style=3D"color: #660;"=
class=3D"styled-by-prettify">(&</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify">z</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">&=
amp;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">z</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">));</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify"> =C2=A0</span><span st=
yle=3D"color: #800;" class=3D"styled-by-prettify">// undefined behavior</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">}</span></div></code=
></div><br><br>For <span style=3D"font-family: courier new,monospace;">unal=
igned_ptr</span>, it would allow access to misaligned objects on hardware f=
or which this matters.<br><br><span style=3D"font-family: courier new,monos=
pace;"><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, =
250); border-color: rgb(187, 187, 187); border-style: solid; border-width: =
1px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subp=
rettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">int</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> main</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">()</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 alignas</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">int</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styl=
ed-by-prettify">char</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> buffer</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">[</span><span style=3D"color: #008;" class=3D"styled-by-prettify">si=
zeof</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</spa=
n><span style=3D"color: #008;" class=3D"styled-by-prettify">int</span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">*</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #066;" class=3D"sty=
led-by-prettify">2</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">];</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br>=C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify">int</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> t </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
style=3D"color: #066;" class=3D"styled-by-prettify">2</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 std</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify">memcpy</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">(&</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify">buffer</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">[</span><span style=3D"color: #066;" class=3D"st=
yled-by-prettify">1</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">],</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">&</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify">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: #=
008;" class=3D"styled-by-prettify">sizeof</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">t</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">));</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"><br>=C2=A0 =C2=A0 std</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify">unaligned_ptr</span><span style=3D"color: #080;" class=3D"styled=
-by-prettify"><int></span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> p </span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">reinterp=
ret_cast</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&l=
t;</span><span style=3D"color: #008;" class=3D"styled-by-prettify">int</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">*>(&</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify">buffer</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">[</span><span style=3D"colo=
r: #066;" class=3D"styled-by-prettify">1</span><span style=3D"color: #660;"=
class=3D"styled-by-prettify">]);</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 std</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify">printf</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">(</span><span style=3D"color: #080;" class=3D"style=
d-by-prettify">"%d\n"</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">*</span><span style=3D"color: #000;" class=3D"styled-by-prettify">p</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">}</span></div></code></div><=
/span><br><br>Note that this could only be supported on platforms for which=
<span style=3D"font-family: courier new,monospace;">reinterpret_cast</span=
> can be done to any pointer/reference type without being aligned.=C2=A0 Th=
ough undefined in the Standard, most platforms are like this.<br><br><span =
style=3D"font-family: courier new,monospace;">unaligned_ptr</span> could ha=
ve implementation-specific extensions, such as for SSE on x86:<br><br><div =
class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border=
-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wr=
ap: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint">=
<span style=3D"color: #008;" class=3D"styled-by-prettify">void</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> add</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">__m128i </span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">*</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify">px</span><span style=3D"color: #660;" class=3D"s=
tyled-by-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">unal=
igned_ptr</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&=
lt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">__m128i=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">></span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> py</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color:=
#660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 __m128i x </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: #660;=
" class=3D"styled-by-prettify">*</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">px</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> =C2=A0</span><span style=3D"color: #800;" class=3D"styled-by-pretti=
fy">// movdqa</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"><br>=C2=A0 =C2=A0 __m128i y </span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">*</span><span style=3D"color: #000;" class=3D"styled-by-prettify">py</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> =C2=A0</span><span s=
tyle=3D"color: #800;" class=3D"styled-by-prettify">// movdqu</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">...</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">}</span></div></code></div><=
br><br>I personally think that unaligned pointers would be better off as a =
CV-qualifier, like Microsoft's __unaligned, but that probably would be =
even less popular than this.<br><br>Melissa<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_3118_1327568840.1444164409067--
------=_Part_3117_204775915.1444164409066--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 6 Oct 2015 15:30:43 -0700 (PDT)
Raw View
------=_Part_5523_2084150407.1444170644013
Content-Type: multipart/alternative;
boundary="----=_Part_5524_1889809589.1444170644013"
------=_Part_5524_1889809589.1444170644013
Content-Type: text/plain; charset=UTF-8
On Tuesday, October 6, 2015 at 4:46:49 PM UTC-4, Myriachan wrote:
>
> I think that there should be ways to request pointer aliasing, the inverse
> (restricted pointers), and unaligned pointers.
>
> For alias_ptr, you'd tell it the type being pointed to, and maybe the
> types it could alias. The latter is an optimization, but not really
> necessary.
>
> int main()
> {
> float f = 2.0f;
> std::alias_ptr<unsigned, float> alias = reinterpret_cast<unsigned *>(f
> );
> *alias = 0x3F800000u;
> std::printf("%f\n", f); // prints 1.0 on typical architectures.
> }
>
>
The Standard For Programming Language C++ exists for one purpose: to define
*behavior*. Not behavior "on typical architectures"; behavior *everywhere*.
You have three options:
1) The standard mandates what this code will return.
2) The standard considers it valid, but the value will be
implementation-defined.
3) The standard considers this undefined behavior.
Creating a feature who's *only purpose* is to trigger undefined behavior is
not acceptable. Creating a feature who's only purpose is to trigger
implementation-defined behavior is... of dubious merit.
And #1 is not reasonably implementable across the broad spectrum of
C++-capable hardware. You'd basically be preferring some platforms over
others.
I would much rather see this provided as some kind of platform-specific
functionality, rather than an actual part of the standard. Maybe a
technical specification or somesuch, something that is conditionally
implemented on platforms where it can be defined.
For unaligned_ptr, it would allow access to misaligned objects on hardware
> for which this matters.
>
It's not clear that some platforms could even really implement this. So
this has the same problems as your `alias_ptr` idea.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_5524_1889809589.1444170644013
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<br><br>On Tuesday, October 6, 2015 at 4:46:49 PM UTC-4, Myriachan wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">I think that th=
ere should be ways to request pointer aliasing, the inverse (restricted poi=
nters), and unaligned pointers.<br><br>For <span style=3D"font-family:couri=
er new,monospace">alias_ptr</span>, you'd tell it the type being pointe=
d to, and maybe the types it could alias.=C2=A0 The latter is an optimizati=
on, but not really necessary.<br><br><div style=3D"background-color:rgb(250=
,250,250);border-color:rgb(187,187,187);border-style:solid;border-width:1px=
;word-wrap:break-word"><code><div><span style=3D"color:#008">int</span><spa=
n style=3D"color:#000"> main</span><span style=3D"color:#660">()</span><spa=
n style=3D"color:#000"><br></span><span style=3D"color:#660">{</span><span =
style=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"color:#008">fl=
oat</span><span style=3D"color:#000"> f </span><span style=3D"color:#660">=
=3D</span><span style=3D"color:#000"> </span><span style=3D"color:#066">2.0=
f</span><span style=3D"color:#660">;</span><span style=3D"color:#000"><br>=
=C2=A0 =C2=A0 std</span><span style=3D"color:#660">::</span><span style=3D"=
color:#000">alias_ptr</span><span style=3D"color:#660"><</span><span sty=
le=3D"color:#008">unsigned</span><span style=3D"color:#660">,</span><span s=
tyle=3D"color:#000"> </span><span style=3D"color:#008">float</span><span st=
yle=3D"color:#660">></span><span style=3D"color:#000"> </span><span styl=
e=3D"color:#008">alias</span><span style=3D"color:#000"> </span><span style=
=3D"color:#660">=3D</span><span style=3D"color:#000"> </span><span style=3D=
"color:#008">reinterpret_cast</span><span style=3D"color:#660"><</span><=
span style=3D"color:#008">unsigned</span><span style=3D"color:#000"> </span=
><span style=3D"color:#660">*>(</span><span style=3D"color:#000">f</span=
><span style=3D"color:#660">);</span><span style=3D"color:#000"><br>=C2=A0 =
=C2=A0 </span><span style=3D"color:#660">*</span><span style=3D"color:#008"=
>alias</span><span style=3D"color:#000"> </span><span style=3D"color:#660">=
=3D</span><span style=3D"color:#000"> </span><span style=3D"color:#066">0x3=
F800000u</span><span style=3D"color:#660">;</span><span style=3D"color:#000=
"><br>=C2=A0 =C2=A0 std</span><span style=3D"color:#660">::</span><span sty=
le=3D"color:#000">printf</span><span style=3D"color:#660">(</span><span sty=
le=3D"color:#080">"%f\n"</span><span style=3D"color:#660">,</span=
><span style=3D"color:#000"> f</span><span style=3D"color:#660">);</span><s=
pan style=3D"color:#000"> =C2=A0</span><span style=3D"color:#800">// prints=
1.0 on typical architectures.</span><span style=3D"color:#000"><br></span>=
<span style=3D"color:#660">}</span></div></code></div><br></div></blockquot=
e><div><br>The Standard For Programming Language C++ exists for one purpose=
: to define <i>behavior</i>. Not behavior "on typical architectures&qu=
ot;; behavior <i>everywhere</i>.<br><br>You have three options:<br><br>1) T=
he standard mandates what this code will return.<br><br>2) The standard con=
siders it valid, but the value will be implementation-defined.<br><br>3) Th=
e standard considers this undefined behavior.<br><br>Creating a feature who=
's <i>only purpose</i> is to trigger undefined behavior is not acceptab=
le. Creating a feature who's only purpose is to trigger implementation-=
defined behavior is... of dubious merit.<br><br>And #1 is not reasonably im=
plementable across the broad spectrum of C++-capable hardware. You'd ba=
sically be preferring some platforms over others.<br><br>I would much rathe=
r see this provided as some kind of platform-specific functionality, rather=
than an actual part of the standard. Maybe a technical specification or so=
mesuch, something that is conditionally implemented on platforms where it c=
an be defined.<br><br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><d=
iv dir=3D"ltr">For <span style=3D"font-family:courier new,monospace">unalig=
ned_ptr</span>, it would allow access to misaligned objects on hardware for=
which this matters.<span style=3D"color:#008"></span></div></blockquote><d=
iv><br>It's not clear that some platforms could even really implement t=
his. So this has the same problems as your `alias_ptr` idea.<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_5524_1889809589.1444170644013--
------=_Part_5523_2084150407.1444170644013--
.
Author: Myriachan <myriachan@gmail.com>
Date: Tue, 6 Oct 2015 16:01:25 -0700 (PDT)
Raw View
------=_Part_6746_2133475646.1444172486068
Content-Type: multipart/alternative;
boundary="----=_Part_6747_560996611.1444172486068"
------=_Part_6747_560996611.1444172486068
Content-Type: text/plain; charset=UTF-8
On Tuesday, October 6, 2015 at 3:30:44 PM UTC-7, Nicol Bolas wrote:
>
>
> The Standard For Programming Language C++ exists for one purpose: to
> define *behavior*. Not behavior "on typical architectures"; behavior
> *everywhere*.
>
>
I was giving examples of use, not a formal definition. The Standardese
version would be quite different.
> You have three options:
>
> 1) The standard mandates what this code will return.
>
> 2) The standard considers it valid, but the value will be
> implementation-defined.
>
> 3) The standard considers this undefined behavior.
>
> Creating a feature who's *only purpose* is to trigger undefined behavior
> is not acceptable. Creating a feature who's only purpose is to trigger
> implementation-defined behavior is... of dubious merit.
>
>
alias_ptr is easily formally defined in terms of copying the object
representation of one type to another, in the same vein as std::memcpying
between dissimilar types. This is implementation-defined behavior.
And #1 is not reasonably implementable across the broad spectrum of
> C++-capable hardware. You'd basically be preferring some platforms over
> others.
>
>
What makes it not possible to implement? float and unsigned int are each
trivially-copyable types; as such, copying their object representation is a
defined operation. The result of interpreting an arbitrary object
representation as a native type is implementation-defined.
I would much rather see this provided as some kind of platform-specific
> functionality, rather than an actual part of the standard. Maybe a
> technical specification or somesuch, something that is conditionally
> implemented on platforms where it can be defined.
>
> For unaligned_ptr, it would allow access to misaligned objects on
>> hardware for which this matters.
>>
>
> It's not clear that some platforms could even really implement this. So
> this has the same problems as your `alias_ptr` idea.
>
The only aspect that prevents unaligned_ptr from working is whether the
implementation supports reinterpret_cast of less-aligned pointers to
more-aligned types. Note that I'm not talking about dereferencing; I'm
referring to whether this is defined in a given implementation:
static_assert(alignof(int) > 1);
alignas(int) char buffer[sizeof(int) * 2];
char *pc = &buffer[1];
int *pi = reinterpret_cast<int *>(pc);
pc = reinterpret_cast<char *>(pi);
It's not defined in the Standard ([expr.reinterpret.cast]/7 sentence 3),
but it is implemented as such in every implementation I've seen. Any of
those could support unaligned_ptr, because of memcpy compatibility.
I would probably restrict these three pointer extensions to types that are
either trivially-copyable or standard-layout.
Melissa
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_6747_560996611.1444172486068
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, October 6, 2015 at 3:30:44 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;"><br><div>The Standard=
For Programming Language C++ exists for one purpose: to define <i>behavior=
</i>. Not behavior "on typical architectures"; behavior <i>everyw=
here</i>.<br><br></div></blockquote><div><br>I was giving examples of use, =
not a formal definition.=C2=A0 The Standardese version would be quite diffe=
rent.<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div>You =
have three options:<br><br>1) The standard mandates what this code will ret=
urn.<br><br>2) The standard considers it valid, but the value will be imple=
mentation-defined.<br><br>3) The standard considers this undefined behavior=
..<br><br>Creating a feature who's <i>only purpose</i> is to trigger und=
efined behavior is not acceptable. Creating a feature who's only purpos=
e is to trigger implementation-defined behavior is... of dubious merit.<br>=
<br></div></blockquote><div><br><span style=3D"font-family: courier new,mon=
ospace;">alias_ptr</span> is easily formally defined in terms of copying th=
e object representation of one type to another, in the same vein as <span s=
tyle=3D"font-family: courier new,monospace;">std::memcpy</span>ing between =
dissimilar types.=C2=A0 This is implementation-defined behavior.<br><br></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;"><div>And #1 is not reasonab=
ly implementable across the broad spectrum of C++-capable hardware. You'=
;d basically be preferring some platforms over others.<br><br></div></block=
quote><div><br>What makes it not possible to implement?=C2=A0 <span style=
=3D"font-family: courier new,monospace;">float</span> and <span style=3D"fo=
nt-family: courier new,monospace;">unsigned int</span> are each trivially-c=
opyable types; as such, copying their object representation is a defined op=
eration.=C2=A0 The result of interpreting an arbitrary object representatio=
n as a native type is implementation-defined.<br><br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #c=
cc solid;padding-left: 1ex;"><div>I would much rather see this provided as =
some kind of platform-specific functionality, rather than an actual part of=
the standard. Maybe a technical specification or somesuch, something that =
is conditionally implemented on platforms where it can be defined.<br><br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">For <span sty=
le=3D"font-family:courier new,monospace">unaligned_ptr</span>, it would all=
ow access to misaligned objects on hardware for which this matters.<span st=
yle=3D"color:#008"></span></div></blockquote><div><br>It's not clear th=
at some platforms could even really implement this. So this has the same pr=
oblems as your `alias_ptr` idea.<br></div></blockquote><div><br>The only as=
pect that prevents <span style=3D"font-family: courier new,monospace;">unal=
igned_ptr</span> from working is whether the implementation supports <span =
style=3D"font-family: courier new,monospace;">reinterpret_cast</span> of le=
ss-aligned pointers to more-aligned types.=C2=A0 Note that I'm not talk=
ing about dereferencing; I'm referring to whether this is defined in a =
given implementation:<br><br><div class=3D"prettyprint" style=3D"background=
-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style:=
solid; border-width: 1px; word-wrap: break-word;"><code class=3D"prettypri=
nt"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">static_assert</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">(</span><span style=3D"color: #008;" class=3D"styled-by=
-prettify">alignof</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">(</span><span style=3D"color: #008;" class=3D"styled-by-prettify">i=
nt</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">></span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #0=
66;" class=3D"styled-by-prettify">1</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">);</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br>alignas</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">(</span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">int</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: #008;" class=3D"styled-by-prettify">char</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify"> buffer</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">[</span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">sizeof</span><span style=3D"color:=
#660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #008;" c=
lass=3D"styled-by-prettify">int</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">*</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #066;" class=3D"styled-by-prettify">2</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">];</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color:=
#008;" class=3D"styled-by-prettify">char</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">*</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify">pc </span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">&</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify">buffer</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">[</span><span sty=
le=3D"color: #066;" class=3D"styled-by-prettify">1</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">];</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">int</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">*</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
>pi </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
style=3D"color: #008;" class=3D"styled-by-prettify">reinterpret_cast</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify"><</span><span=
style=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">*>(</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify">pc</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">);</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"><br>pc </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">r=
einterpret_cast</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify"><</span><span style=3D"color: #008;" class=3D"styled-by-prettify">c=
har</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">*>(</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify">pi</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">);</span></div></code></div>=
<br>It's not defined in the Standard ([expr.reinterpret.cast]/7 sentenc=
e 3), but it is implemented as such in every implementation I've seen.=
=C2=A0 Any of those could support <span style=3D"font-family: courier new,m=
onospace;">unaligned_ptr</span>, because of <span style=3D"font-family: cou=
rier new,monospace;">memcpy</span> compatibility.<br><br>I would probably r=
estrict these three pointer extensions to types that are either trivially-c=
opyable or standard-layout.<br><br>Melissa<br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_6747_560996611.1444172486068--
------=_Part_6746_2133475646.1444172486068--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Wed, 07 Oct 2015 07:59:24 +0200
Raw View
On Tuesday 06 October 2015 15:30:43 Nicol Bolas wrote:
> The Standard For Programming Language C++ exists for one purpose: to define
> *behavior*. Not behavior "on typical architectures"; behavior *everywhere*.
On the other hand, there's something to be said about the 0.01% case holding
the 99.99% case hostage...
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 7 Oct 2015 06:42:52 -0700 (PDT)
Raw View
------=_Part_506_1445251222.1444225372946
Content-Type: multipart/alternative;
boundary="----=_Part_507_1785775368.1444225372946"
------=_Part_507_1785775368.1444225372946
Content-Type: text/plain; charset=UTF-8
On Wednesday, October 7, 2015 at 1:59:31 AM UTC-4, Thiago Macieira wrote:
>
> On Tuesday 06 October 2015 15:30:43 Nicol Bolas wrote:
> > The Standard For Programming Language C++ exists for one purpose: to
> define
> > *behavior*. Not behavior "on typical architectures"; behavior
> *everywhere*.
>
> On the other hand, there's something to be said about the 0.01% case
> holding
> the 99.99% case hostage...
>
That's why I suggested a TS, where we can actually define these sorts of
things. As a TS, it wouldn't be a required part of C++, but it would be
conditionally supported by implementations that could implement it.
That way, all this behavior doesn't have to be "implementation-defined".
You can actually *say* what it means.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_507_1785775368.1444225372946
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, October 7, 2015 at 1:59:31 AM UTC-4, Thiago =
Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Tuesday 06 O=
ctober 2015 15:30:43 Nicol Bolas wrote:
<br>> The Standard For Programming Language C++ exists for one purpose: =
to define=20
<br>> *behavior*. Not behavior "on typical architectures"; beh=
avior *everywhere*.
<br>
<br>On the other hand, there's something to be said about the 0.01% cas=
e holding=20
<br>the 99.99% case hostage...<br></blockquote><div><br>That's why I su=
ggested a TS, where we can actually define these sorts of things. As a TS, =
it wouldn't be a required part of C++, but it would be conditionally su=
pported by implementations that could implement it.<br><br>That way, all th=
is behavior doesn't have to be "implementation-defined". You =
can actually <i>say</i> what it means.<br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_507_1785775368.1444225372946--
------=_Part_506_1445251222.1444225372946--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Wed, 07 Oct 2015 23:55:37 +0200
Raw View
On Wednesday 07 October 2015 06:42:52 Nicol Bolas wrote:
> On Wednesday, October 7, 2015 at 1:59:31 AM UTC-4, Thiago Macieira wrote:
> > On Tuesday 06 October 2015 15:30:43 Nicol Bolas wrote:
> > > The Standard For Programming Language C++ exists for one purpose: to
> >
> > define
> >
> > > *behavior*. Not behavior "on typical architectures"; behavior
> >
> > *everywhere*.
> >
> > On the other hand, there's something to be said about the 0.01% case
> > holding
> > the 99.99% case hostage...
>
> That's why I suggested a TS, where we can actually define these sorts of
> things. As a TS, it wouldn't be a required part of C++, but it would be
> conditionally supported by implementations that could implement it.
>
> That way, all this behavior doesn't have to be "implementation-defined".
> You can actually *say* what it means.
Can we have a TS for "modern computers (two's complement. 8-bit bytes, IEEE
754 floating point)"?
I have to say, if this is successful, it will probably become "de facto"
standard, since it will probably map to over 99.99% of applications written.
The rest will suffer.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Thu, 8 Oct 2015 05:53:31 -0700 (PDT)
Raw View
------=_Part_640_49063952.1444308811610
Content-Type: multipart/alternative;
boundary="----=_Part_641_579785807.1444308811610"
------=_Part_641_579785807.1444308811610
Content-Type: text/plain; charset=UTF-8
On Wednesday, October 7, 2015 at 5:55:45 PM UTC-4, Thiago Macieira wrote:
>
> On Wednesday 07 October 2015 06:42:52 Nicol Bolas wrote:
> > On Wednesday, October 7, 2015 at 1:59:31 AM UTC-4, Thiago Macieira
> wrote:
> > > On Tuesday 06 October 2015 15:30:43 Nicol Bolas wrote:
> > > > The Standard For Programming Language C++ exists for one purpose: to
> > >
> > > define
> > >
> > > > *behavior*. Not behavior "on typical architectures"; behavior
> > >
> > > *everywhere*.
> > >
> > > On the other hand, there's something to be said about the 0.01% case
> > > holding
> > > the 99.99% case hostage...
> >
> > That's why I suggested a TS, where we can actually define these sorts of
> > things. As a TS, it wouldn't be a required part of C++, but it would be
> > conditionally supported by implementations that could implement it.
> >
> > That way, all this behavior doesn't have to be "implementation-defined".
> > You can actually *say* what it means.
>
> Can we have a TS for "modern computers (two's complement. 8-bit bytes,
> IEEE
> 754 floating point)"?
>
That's more-or-less what I was thinking. By taking the TS route, you get to
actually define a lot of behavior, without breaking certain classes of
machines.
However, IEEE-754 would still be a bit... dubious. There are many ARM
platforms that have to emulate floats in software. At the very least, there
should be a way to test whether floats are real IEEE-754 or emulated.
> I have to say, if this is successful, it will probably become "de facto"
> standard, since it will probably map to over 99.99% of applications
> written.
> The rest will suffer.
>
Yes... and?
People write code *all the time* that is not portable to such... irregular
machines. At least this way, they'd be using well-defined behavior, not
relying on what seems to work. And they'll have a way to test whether it's
there or not and fail to compile if it isn't.
I recall a line from the John Adams HBO miniseries: "The question is not
whether, by a declaration of independency, we declare ourselves to be
something we are not, but whether we shall declare a fact something which
already exists."
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_641_579785807.1444308811610
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<br><br>On Wednesday, October 7, 2015 at 5:55:45 PM UTC-4, Thiago Macieira =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Wednesday 07 October =
2015 06:42:52 Nicol Bolas wrote:
<br>> On Wednesday, October 7, 2015 at 1:59:31 AM UTC-4, Thiago Macieira=
wrote:
<br>> > On Tuesday 06 October 2015 15:30:43 Nicol Bolas wrote:
<br>> > > The Standard For Programming Language C++ exists for one=
purpose: to
<br>> >=20
<br>> > define
<br>> >=20
<br>> > > *behavior*. Not behavior "on typical architectures&=
quot;; behavior
<br>> >=20
<br>> > *everywhere*.
<br>> >=20
<br>> > On the other hand, there's something to be said about the=
0.01% case
<br>> > holding
<br>> > the 99.99% case hostage...
<br>>=20
<br>> That's why I suggested a TS, where we can actually define thes=
e sorts of
<br>> things. As a TS, it wouldn't be a required part of C++, but it=
would be
<br>> conditionally supported by implementations that could implement it=
..
<br>>=20
<br>> That way, all this behavior doesn't have to be "implement=
ation-defined".
<br>> You can actually *say* what it means.
<br>
<br>Can we have a TS for "modern computers (two's complement. 8-bi=
t bytes, IEEE=20
<br>754 floating point)"?
<br></blockquote><div><br>That's more-or-less what I was thinking. By t=
aking the TS route, you get to actually define a lot of behavior, without b=
reaking certain classes of machines.<br><br>However, IEEE-754 would still b=
e a bit... dubious. There are many ARM platforms that have to emulate float=
s in software. At the very least, there should be a way to test whether flo=
ats are real IEEE-754 or emulated.<br>=C2=A0</div><blockquote class=3D"gmai=
l_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;=
padding-left: 1ex;">
I have to say, if this is successful, it will probably become "de fact=
o"=20
<br>standard, since it will probably map to over 99.99% of applications wri=
tten.=20
<br>The rest will suffer.
<br></blockquote><div><br>Yes... and?<br><br>People write code <i>all the t=
ime</i> that is not portable to such... irregular machines. At least this w=
ay, they'd be using well-defined behavior, not relying on what seems to=
work. And they'll have a way to test whether it's there or not and=
fail to compile if it isn't.<br><br>I recall a line from the John Adam=
s HBO miniseries: "The question is not whether, by a declaration of in=
dependency, we declare ourselves to be something we are not, but whether we=
shall declare a fact something which already exists."<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_641_579785807.1444308811610--
------=_Part_640_49063952.1444308811610--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Thu, 08 Oct 2015 10:23:03 -0500
Raw View
On Thursday 08 October 2015 05:53:31 Nicol Bolas wrote:
> However, IEEE-754 would still be a bit... dubious. There are many ARM
> platforms that have to emulate floats in software. At the very least, there
> should be a way to test whether floats are real IEEE-754 or emulated.
I don't think that's a problem. Most emulations do use IEEE 754 too, so they'd
fulfil the requirement.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Thu, 8 Oct 2015 08:29:21 -0700 (PDT)
Raw View
------=_Part_143_60555611.1444318161503
Content-Type: multipart/alternative;
boundary="----=_Part_144_1946915551.1444318161503"
------=_Part_144_1946915551.1444318161503
Content-Type: text/plain; charset=UTF-8
On Thursday, October 8, 2015 at 11:24:39 AM UTC-4, Thiago Macieira wrote:
>
> On Thursday 08 October 2015 05:53:31 Nicol Bolas wrote:
> > However, IEEE-754 would still be a bit... dubious. There are many ARM
> > platforms that have to emulate floats in software. At the very least,
> there
> > should be a way to test whether floats are real IEEE-754 or emulated.
>
> I don't think that's a problem. Most emulations do use IEEE 754 too, so
> they'd
> fulfil the requirement.
>
Yes, but how *exact* are they? Do they provide the exact (within the
tolerances of the spec) precision required for IEEE-754, 32-bit precision?
I imagine most of them cut corners and are willing to burn a digit or 3's
precision to get a faster answer.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_144_1946915551.1444318161503
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Thursday, October 8, 2015 at 11:24:39 AM UTC-4,=
Thiago Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Thur=
sday 08 October 2015 05:53:31 Nicol Bolas wrote:
<br>> However, IEEE-754 would still be a bit... dubious. There are many =
ARM=20
<br>> platforms that have to emulate floats in software. At the very lea=
st, there=20
<br>> should be a way to test whether floats are real IEEE-754 or emulat=
ed.
<br>
<br>I don't think that's a problem. Most emulations do use IEEE 754=
too, so they'd=20
<br>fulfil the requirement.<br></blockquote><div><br>Yes, but how <i>exact<=
/i> are they? Do they provide the exact (within the tolerances of the spec)=
precision required for IEEE-754, 32-bit precision? I imagine most of them =
cut corners and are willing to burn a digit or 3's precision to get a f=
aster answer.<br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_144_1946915551.1444318161503--
------=_Part_143_60555611.1444318161503--
.
Author: John Yates <john@yates-sheets.org>
Date: Thu, 8 Oct 2015 11:30:13 -0400
Raw View
--001a11332d300da4e00521998ad1
Content-Type: text/plain; charset=UTF-8
>
> However, IEEE-754 would still be a bit... dubious.
>
It is one thing to assert that a modern machine uses IEEE-754 data
formats. It is quite another to claim that a language processor supports
all of the baroque details in the standard, especially those involving
NaNs. In particular if huing to IEEE-754 an optimizer's global value
numbering can never treat X == X as true if X could possibly be a NaN.
This is because IEEE-754 says that even when the two NaN bit patterns are
identical NaN == NaN universally returns false.
/john
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a11332d300da4e00521998ad1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;paddi=
ng-left:1ex"><div>However, IEEE-754 would still be a bit... dubious.</div><=
/blockquote><div><br></div><div>It is one thing to assert that a modern mac=
hine uses IEEE-754 data formats.=C2=A0 It is quite another to claim that a =
language processor supports all of the baroque details in the standard, esp=
ecially those involving NaNs.=C2=A0 In particular=C2=A0if huing to IEEE-754=
an optimizer's global value numbering can never treat X =3D=3D X as tr=
ue if X could possibly be a NaN.=C2=A0 This is because IEEE-754 says that e=
ven when the two NaN bit patterns are identical NaN =3D=3D NaN universally =
returns false.</div><div><br></div><div>/john</div></div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a11332d300da4e00521998ad1--
.
Author: Bo Persson <bop@gmb.dk>
Date: Thu, 8 Oct 2015 18:13:23 +0200
Raw View
On 2015-10-07 23:55, Thiago Macieira wrote:
> On Wednesday 07 October 2015 06:42:52 Nicol Bolas wrote:
>> On Wednesday, October 7, 2015 at 1:59:31 AM UTC-4, Thiago Macieira wrote:
>>> On Tuesday 06 October 2015 15:30:43 Nicol Bolas wrote:
>>>> The Standard For Programming Language C++ exists for one purpose: to
>>>
>>> define
>>>
>>>> *behavior*. Not behavior "on typical architectures"; behavior
>>>
>>> *everywhere*.
>>>
>>> On the other hand, there's something to be said about the 0.01% case
>>> holding
>>> the 99.99% case hostage...
>>
>> That's why I suggested a TS, where we can actually define these sorts of
>> things. As a TS, it wouldn't be a required part of C++, but it would be
>> conditionally supported by implementations that could implement it.
>>
>> That way, all this behavior doesn't have to be "implementation-defined".
>> You can actually *say* what it means.
>
> Can we have a TS for "modern computers (two's complement. 8-bit bytes, IEEE
> 754 floating point)"?
>
> I have to say, if this is successful, it will probably become "de facto"
> standard, since it will probably map to over 99.99% of applications written.
> The rest will suffer.
>
That might satisfy a large portion of the VISIBLE software written.
However, a significant amount of inhouse software is written for IBM
hardware.
Remember that IBM voted against removing trigraphs, because they are
really used. Guess what will happen if we try to ban EBCDIC and non-IEEE
floating point.
The mainframe business is OLDER than both ASCII and IEEE-754, and has
one cornerstone in backwards compatibility.
I work for a bank that still uses programs originally written in the
1960's! The business model for some kinds of long term loans doesn't
change for decades.
For example, if you have a 30 year mortgage on your house, would you
like to pay extra so the lender can rewrite their software every 10
years? Without changing anything in the conditions, of course.
Bo Persson
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Myriachan <myriachan@gmail.com>
Date: Thu, 8 Oct 2015 15:40:52 -0700 (PDT)
Raw View
------=_Part_145_946078297.1444344052405
Content-Type: multipart/alternative;
boundary="----=_Part_146_1522848395.1444344052405"
------=_Part_146_1522848395.1444344052405
Content-Type: text/plain; charset=UTF-8
On Thursday, October 8, 2015 at 5:53:32 AM UTC-7, Nicol Bolas wrote:
>
> That's more-or-less what I was thinking. By taking the TS route, you get
> to actually define a lot of behavior, without breaking certain classes of
> machines.
>
>
What is the difference among the proposal types?
> However, IEEE-754 would still be a bit... dubious. There are many ARM
> platforms that have to emulate floats in software. At the very least, there
> should be a way to test whether floats are real IEEE-754 or emulated.
>
>
Isn't that what std::numeric_limits<float>::is_iec559 is for? Also, isn't
what is relevant at this level is whether the *object representation* of
these types is IEEE-754, regardless of implementation?
I'm not asking that the code I gave always work on all implementations; I'm
asking that the code I gave always work on all implementations *in which
float is unpadded IEEE-754 single-precision*.
People write code *all the time* that is not portable to such... irregular
> machines. At least this way, they'd be using well-defined behavior, not
> relying on what seems to work. And they'll have a way to test whether it's
> there or not and fail to compile if it isn't.
>
>
That's what I'm seeking with something like alias_ptr: a well-defined
method of accessing implementation-defined behavior. If the example code I
gave would cause an exception when read back into a float on a given
processor, that's perfectly fine. Invalid object representations are
already undefined behavior, though what defines a valid object
representation is implementation-defined. In all, overwriting a variable
using a wrong-type alias_ptr would be defined as equivalent to std::memcpy.
restrict_ptr and unaligned_ptr, on the other hand, are easier. The only
issue I see with unaligned_ptr is just with my example: that initial
reinterpret_cast of the pointer may itself be invalid. If that's a
problem, an alternative would be to have unaligned_ptr's constructor take a void
* parameter instead of a T *.
unaligned_ptr doesn't otherwise do anything crazy, because you already can
std::memcpy an aligned type to an unaligned position in, say, an unsigned
char array.
Really, alias_ptr and unaligned_ptr are syntactic sugar for std::memcpy, in
a manner that is much like many programmers like myself are unfortunately
used to.
Melissa
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_146_1522848395.1444344052405
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thursday, October 8, 2015 at 5:53:32 AM UTC-7, Nicol Bo=
las wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">That's more-or-l=
ess what I was thinking. By taking the TS route, you get to actually define=
a lot of behavior, without breaking certain classes of machines.<br><div><=
br></div></blockquote><div><br>What is the difference among the proposal ty=
pes?<br>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div>H=
owever, IEEE-754 would still be a bit... dubious. There are many ARM platfo=
rms that have to emulate floats in software. At the very least, there shoul=
d be a way to test whether floats are real IEEE-754 or emulated.<br>=C2=A0<=
/div></blockquote><div><br>Isn't that what <span style=3D"font-family: =
courier new,monospace;">std::numeric_limits<float>::is_iec559</span> =
is for?=C2=A0 Also, isn't what is relevant at this level is whether the=
<i>object representation</i> of these types is IEEE-754, regardless of imp=
lementation?<br><br>I'm not asking that the code I gave always work on =
all implementations; I'm asking that the code I gave always work on all=
implementations <i>in which <span style=3D"font-family: courier new,monosp=
ace;">float</span> is unpadded IEEE-754 single-precision</i>.<br><br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;">People write code <i>all the t=
ime</i> that is not portable to such... irregular machines. At least this w=
ay, they'd be using well-defined behavior, not relying on what seems to=
work. And they'll have a way to test whether it's there or not and=
fail to compile if it isn't.<br><div><br></div></blockquote><div><br>T=
hat's what I'm seeking with something like <span style=3D"font-fami=
ly: courier new,monospace;">alias_ptr</span>: a well-defined method of acce=
ssing implementation-defined behavior.=C2=A0 If the example code I gave wou=
ld cause an exception when read back into a float on a given processor, tha=
t's perfectly fine.=C2=A0 Invalid object representations are already un=
defined behavior, though what defines a valid object representation is impl=
ementation-defined.=C2=A0 In all, overwriting a variable using a wrong-type=
<span style=3D"font-family: courier new,monospace;">alias_ptr</span> would=
be defined as equivalent to <span style=3D"font-family: courier new,monosp=
ace;">std::memcpy</span>.<br><br><span style=3D"font-family: courier new,mo=
nospace;">restrict_ptr</span> and <span style=3D"font-family: courier new,m=
onospace;">unaligned_ptr</span>, on the other hand, are easier.=C2=A0 The o=
nly issue I see with <span style=3D"font-family: courier new,monospace;">un=
aligned_ptr</span> is just with my example: that initial <span style=3D"fon=
t-family: courier new,monospace;">reinterpret_cast</span> of the pointer ma=
y itself be invalid.=C2=A0 If that's a problem, an alternative would be=
to have <span style=3D"font-family: courier new,monospace;">unaligned_ptr<=
/span>'s constructor take a <span style=3D"font-family: courier new,mon=
ospace;">void *</span> parameter instead of a <span style=3D"font-family: c=
ourier new,monospace;">T *</span>.<br><br><span style=3D"font-family: couri=
er new,monospace;">unaligned_ptr</span> doesn't otherwise do anything c=
razy, because you already can <span style=3D"font-family: courier new,monos=
pace;">std::memcpy</span> an aligned type to an unaligned position in, say,=
an <span style=3D"font-family: courier new,monospace;">unsigned char</span=
> array.<br><br>Really, <span style=3D"font-family: courier new,monospace;"=
>alias_ptr</span> and <span style=3D"font-family: courier new,monospace;">u=
naligned_ptr</span> are syntactic sugar for <span style=3D"font-family: cou=
rier new,monospace;">std::memcpy</span>, in a manner that is much like many=
programmers like myself are unfortunately used to.<br><br>Melissa<br></div=
></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_146_1522848395.1444344052405--
------=_Part_145_946078297.1444344052405--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Thu, 08 Oct 2015 16:23:03 -0700
Raw View
On Thursday 08 October 2015 08:29:21 Nicol Bolas wrote:
> On Thursday, October 8, 2015 at 11:24:39 AM UTC-4, Thiago Macieira wrote:
> > On Thursday 08 October 2015 05:53:31 Nicol Bolas wrote:
> > > However, IEEE-754 would still be a bit... dubious. There are many ARM
> > > platforms that have to emulate floats in software. At the very least,
> >
> > there
> >
> > > should be a way to test whether floats are real IEEE-754 or emulated.
> >
> > I don't think that's a problem. Most emulations do use IEEE 754 too, so
> > they'd
> > fulfil the requirement.
>
> Yes, but how *exact* are they? Do they provide the exact (within the
> tolerances of the spec) precision required for IEEE-754, 32-bit precision?
> I imagine most of them cut corners and are willing to burn a digit or 3's
> precision to get a faster answer.
Maybe, but for the purposes of where the discussion started here, this is
mostly about accessing the bits of the float so you can manipulate them more
easily.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.