------=_Part_2646_528886090.1469434780916
Content-Type: multipart/alternative;
 boundary="----=_Part_2647_2025112958.1469434780917"

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

This is a suggestion to provide pragmas that would make certain operations=
=20
well-defined.  The names of the pragmas are not intended to be the actual=
=20
names, though I did try to make them semi-reasonable.

GCC implements command-line flags that correspond to the all of these=20
except (possibly) the second.  Clang implements the first and third.  The=
=20
first, third, and fourth are used (as command-line options) by at least the=
=20
Linux kernel, albeit in C and not C++ (though the corresponding flags are=
=20
also accepted by C++ compilers).  Microsoft has probably screwed up strict=
=20
aliasing in CoreCLR=E2=80=93 https://github.com/dotnet/coreclr/issues/6454.

These pragmas (with different names) probably make just as much sense in C=
=20
as in C++, and should probably (if they are a reasonable idea) be proposed=
=20
there as well (probably renamed).

This suggestion could be totally off-base.  Nevertheless, I feel like a lot=
=20
of code in the wild depends on these at least some of these behaviors=20
(enforced via non-standard compile-time options). =20

Specifically:

   - Make signed overflow wrap:
   #pragma STDC++ overflow wrap
   This requires the compiler to ensure that signed integer overflow=20
   behaves as unsigned integer overflow =E2=80=93 as 2's complement wrappin=
g=20
   arithmetic.  I suspect that there will be little performance penalty =E2=
=80=93=20
   every non-obsolete computer I know of already provide 2's complement in=
=20
   hardware.
   - Make signed overflow well-defined:
   #pragma STDC++ no-strict-overflow
   This requires that signed overflow either perform according to 2's=20
   complement, or trap with an unspecified exception (that must be fatal if=
=20
   uncaught, but may or may not be a C++ exception).
   - Turn off strict aliasing
   #pragma STDC++ no-strict-aliasing
   This turns off the strict-aliasing rule.  This is very useful for=20
   programs such as garbage collectors and memory allocators =E2=80=93 inde=
ed, I am=20
   not sure if a memory allocator can be written in strictly conforming C++=
 as=20
   it stands today.  It also allows for a C++ implementation of memcpy that=
 is=20
   faster than going 1 byte at a time.
   - Make null pointer dereference implementation defined (at worst)
   #pragma STDC++ no-delete-null-pointer-checks
   This makes dereferencing nullptr have implementation-defined behavior=20
   that is guaranteed to correspond to the behavior of reading from address=
=20
   zero (on platforms where that makes sense).  This is useful for kernels =
and=20
   other programs that interface directly with hardware, since address 0 ma=
y=20
   map to meaningful data.
   - Make accessing of out-of-bounds memory allowed, provided that valid=20
   memory is guaranteed to exist there.
   #pragma STDC++ no-strict-bounds
   This allows for accessing a multi-dimensional array as a one-dimensional=
=20
   array.

--=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/b9f41447-1d5a-4418-8b13-c79c9e293c82%40isocpp.or=
g.

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

<div dir=3D"ltr">This is a suggestion to provide pragmas that would make ce=
rtain=20
operations well-defined.=C2=A0 The names of the pragmas are not intended to=
=20
be the actual names, though I did try to make them semi-reasonable.<br><br>=
GCC
 implements command-line flags that correspond to the all of these=20
except (possibly) the second.=C2=A0 Clang implements the first and third.=
=C2=A0=20
The first, third, and fourth are used (as command-line options) by at=20
least the Linux kernel, albeit in C and not C++ (though the=20
corresponding flags are also accepted by C++ compilers).=C2=A0 Microsoft ha=
s=20
probably screwed up strict aliasing in CoreCLR=E2=80=93<a href=3D"https://g=
ithub.com/dotnet/coreclr/issues/6454" target=3D"_blank" rel=3D"nofollow"> h=
ttps://github.com/dotnet/<wbr>coreclr/issues/6454</a>.<br><br>These
 pragmas (with different names) probably make just as much sense in C as
 in C++, and should probably (if they are a reasonable idea) be proposed
 there as well (probably renamed).<br><br>This suggestion could be=20
totally off-base.=C2=A0 Nevertheless, I feel like a lot of code in the wild=
=20
depends on these at least some of these behaviors (enforced via=20
non-standard compile-time options).=C2=A0 <br><br>Specifically:<br><ul><li>=
Make signed overflow wrap:<span style=3D"color:#660"></span><span style=3D"=
color:#000"></span><br><span style=3D"color:#000"></span><div style=3D"back=
ground-color:rgb(250,250,250);border-color:rgb(187,187,187);border-style:so=
lid;border-width:1px;word-wrap:break-word"><code><div><span style=3D"color:=
#800">#pragma</span><span style=3D"color:#000"> STDC</span><span style=3D"c=
olor:#660">++</span><span style=3D"color:#000"> overflow wrap<br></span></d=
iv></code></div><code><div><span style=3D"color:#000"><font face=3D"arial,s=
ans-serif">This
 requires the compiler to ensure that signed integer overflow behaves as
 unsigned integer overflow =E2=80=93 as 2&#39;s complement wrapping arithme=
tic.=C2=A0 I=20
suspect that there will be little performance penalty =E2=80=93 every=20
non-obsolete computer I know of already provide 2&#39;s complement in=20
hardware.</font></span></div></code></li><li><span style=3D"color:#000"></s=
pan><span style=3D"color:#000"><font face=3D"arial,sans-serif">Make signed =
overflow well-defined:<br><div style=3D"background-color:rgb(250,250,250);b=
order-color:rgb(187,187,187);border-style:solid;border-width:1px;word-wrap:=
break-word"><code><div><font face=3D"arial,sans-serif"><span style=3D"color=
:#800">#pragma</span><span style=3D"color:#000"> STDC</span><span style=3D"=
color:#660">++</span><span style=3D"color:#000"> </span><span style=3D"colo=
r:#008">no</span><span style=3D"color:#660">-</span><span style=3D"color:#0=
00">strict</span><span style=3D"color:#660">-</span><span style=3D"color:#0=
00">overflow<br></span></font></div></code></div>This
 requires that signed overflow either perform according to 2&#39;s=20
complement, or trap with an unspecified exception (that must be fatal if
 uncaught, but may or may not be a C++ exception).</font></span></li><li><s=
pan style=3D"color:#000"></span><span style=3D"color:#000"><font face=3D"ar=
ial,sans-serif">Turn off strict aliasing<br><div style=3D"background-color:=
rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid;border-wi=
dth:1px;word-wrap:break-word"><code><div><span style=3D"color:#800">#pragma=
</span><span style=3D"color:#000"> STDC</span><span style=3D"color:#660">++=
</span><span style=3D"color:#000"> </span><span style=3D"color:#008">no</sp=
an><font face=3D"arial,sans-serif"><span style=3D"color:#660">-</span><span=
 style=3D"color:#000">strict</span><span style=3D"color:#660">-</span><span=
 style=3D"color:#000">aliasing</span></font><span style=3D"color:#000"><br>=
</span></div></code></div>This
 turns off the strict-aliasing rule.=C2=A0 This is very useful for programs=
=20
such as garbage collectors and memory allocators =E2=80=93 indeed, I am not=
 sure
 if a memory allocator can be written in strictly conforming C++ as it=20
stands today.=C2=A0 It also allows for a C++ implementation of memcpy that =
is
 faster than going 1 byte at a time.</font></span></li><li><span style=3D"c=
olor:#000"><font face=3D"arial,sans-serif">Make null pointer dereference im=
plementation defined (at worst)<br><div style=3D"background-color:rgb(250,2=
50,250);border-color:rgb(187,187,187);border-style:solid;border-width:1px;w=
ord-wrap:break-word"><code><div><font face=3D"arial,sans-serif"><span style=
=3D"color:#800">#pragma</span><span style=3D"color:#000"> STDC</span><span =
style=3D"color:#660">++</span><span style=3D"color:#000"> </span><span styl=
e=3D"color:#008">no</span><span style=3D"color:#660">-</span><span style=3D=
"color:#008">delete</span><span style=3D"color:#660">-</span><span style=3D=
"color:#008">null</span><span style=3D"color:#660">-</span><span style=3D"c=
olor:#000">pointer</span><span style=3D"color:#660">-</span><span style=3D"=
color:#000">checks<br></span></font></div></code></div>This
 makes dereferencing nullptr have implementation-defined behavior that=20
is guaranteed to correspond to the behavior of reading from address zero
 (on platforms where that makes sense).=C2=A0 This is useful for kernels an=
d=20
other programs that interface directly with hardware, since address 0=20
may map to meaningful data.</font></span></li><li><span style=3D"color:#000=
"><font face=3D"arial,sans-serif">Make accessing of out-of-bounds memory al=
lowed, provided that valid memory is guaranteed to exist there.<br><div sty=
le=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187);borde=
r-style:solid;border-width:1px;word-wrap:break-word"><code><div><font face=
=3D"arial,sans-serif"><span style=3D"color:#800">#pragma</span><span style=
=3D"color:#000"> STDC</span><span style=3D"color:#660">++</span><span style=
=3D"color:#000"> </span><span style=3D"color:#008">no</span><span style=3D"=
color:#660">-</span><span style=3D"color:#000">strict</span><span style=3D"=
color:#660">-</span><span style=3D"color:#000">bounds<br></span></font></di=
v></code></div>This allows for accessing a multi-dimensional array as a one=
-dimensional array.</font></span></li></ul></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/b9f41447-1d5a-4418-8b13-c79c9e293c82%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b9f41447-1d5a-4418-8b13-c79c9e293c82=
%40isocpp.org</a>.<br />

------=_Part_2647_2025112958.1469434780917--

------=_Part_2646_528886090.1469434780916--

.

------=_Part_20_457155202.1469577175749
Content-Type: multipart/alternative;
 boundary="----=_Part_21_822798592.1469577175750"

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

On Monday, July 25, 2016 at 1:19:41 AM UTC-7, demio...@gmail.com wrote:
>
> This is a suggestion to provide pragmas that would make certain operation=
s=20
> well-defined.  The names of the pragmas are not intended to be the actual=
=20
> names, though I did try to make them semi-reasonable.
>
> GCC implements command-line flags that correspond to the all of these=20
> except (possibly) the second.  Clang implements the first and third.  The=
=20
> first, third, and fourth are used (as command-line options) by at least t=
he=20
> Linux kernel, albeit in C and not C++ (though the corresponding flags are=
=20
> also accepted by C++ compilers).  Microsoft has probably screwed up stric=
t=20
> aliasing in CoreCLR=E2=80=93 https://github.com/dotnet/coreclr/issues/645=
4.
>
>
GCC and clang both have -fwrapv to enable two's-complement wrapping=20
semantics for signed integer types.
=20

> These pragmas (with different names) probably make just as much sense in =
C=20
> as in C++, and should probably (if they are a reasonable idea) be propose=
d=20
> there as well (probably renamed).
>
>
I pretty much would turn them on all the time.  I strongly dislike many of=
=20
the object lifetime rules, particularly in C++.
=20

> This suggestion could be totally off-base.  Nevertheless, I feel like a=
=20
> lot of code in the wild depends on these at least some of these behaviors=
=20
> (enforced via non-standard compile-time options). =20
>
> Specifically:
>
>    - Make signed overflow wrap:
>    #pragma STDC++ overflow wrap
>    This requires the compiler to ensure that signed integer overflow=20
>    behaves as unsigned integer overflow =E2=80=93 as 2's complement wrapp=
ing=20
>    arithmetic.  I suspect that there will be little performance penalty =
=E2=80=93=20
>    every non-obsolete computer I know of already provide 2's complement i=
n=20
>    hardware.
>    - Make signed overflow well-defined:
>    #pragma STDC++ no-strict-overflow
>    This requires that signed overflow either perform according to 2's=20
>    complement, or trap with an unspecified exception (that must be fatal =
if=20
>    uncaught, but may or may not be a C++ exception).
>
> In many similar ideas I have, I've called the acceptable behavior set=20
"snap, trap or wrap": that is, saturate to the largest (or smallest) value,=
=20
trap in an implementation-defined way, or wrap two's complement.  This=20
matches the common hardware behaviors out there, of which wrap is obviously=
=20
the most common.
=20

>
>    - Turn off strict aliasing
>    #pragma STDC++ no-strict-aliasing
>    This turns off the strict-aliasing rule.  This is very useful for=20
>    programs such as garbage collectors and memory allocators =E2=80=93 in=
deed, I am=20
>    not sure if a memory allocator can be written in strictly conforming C=
++ as=20
>    it stands today.  It also allows for a C++ implementation of memcpy th=
at is=20
>    faster than going 1 byte at a time.
>
> I would rather have "restrict" from C99 and a new "may_alias"=20
attribute/keyword to manipulate aliasing.  Permitting type-based alias=20
analysis is an important optimization, but we need a way to suppress or=20
extend this behavior sometimes to accomplish low-level tasks or more=20
strongly optimize.
=20

>
>    - Make null pointer dereference implementation defined (at worst)
>    #pragma STDC++ no-delete-null-pointer-checks
>    This makes dereferencing nullptr have implementation-defined behavior=
=20
>    that is guaranteed to correspond to the behavior of reading from addre=
ss=20
>    zero (on platforms where that makes sense).  This is useful for kernel=
s and=20
>    other programs that interface directly with hardware, since address 0 =
may=20
>    map to meaningful data.
>
> In Windows NT, null pointers can't safely be optimized away, either. =20
Because of the exception handling mechanism, code might rely upon the=20
dereferencing of null pointers triggering an exception, which can be caught=
=20
and handled by several means.  This design is critical to the security=20
system in the kernel to protect against invalid input from user mode.


>    - Make accessing of out-of-bounds memory allowed, provided that valid=
=20
>    memory is guaranteed to exist there.
>    #pragma STDC++ no-strict-bounds
>    This allows for accessing a multi-dimensional array as a=20
>    one-dimensional array.
>
> This also would permit the classic trick of having a 1-element array at=
=20
the end of a struct and referencing past the end when memory follows.  This=
=20
mechanism is used in the APIs of Windows and UNIX, so we've been relying=20
upon this particular undefined behavior since forever.

Melissa

--=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/729cf6a9-a37b-47c4-b51c-1a8b34091ec8%40isocpp.or=
g.

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

<div dir=3D"ltr">On Monday, July 25, 2016 at 1:19:41 AM UTC-7, demio...@gma=
il.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
This is a suggestion to provide pragmas that would make certain=20
operations well-defined.=C2=A0 The names of the pragmas are not intended to=
=20
be the actual names, though I did try to make them semi-reasonable.<br><br>=
GCC
 implements command-line flags that correspond to the all of these=20
except (possibly) the second.=C2=A0 Clang implements the first and third.=
=C2=A0=20
The first, third, and fourth are used (as command-line options) by at=20
least the Linux kernel, albeit in C and not C++ (though the=20
corresponding flags are also accepted by C++ compilers).=C2=A0 Microsoft ha=
s=20
probably screwed up strict aliasing in CoreCLR=E2=80=93<a href=3D"https://g=
ithub.com/dotnet/coreclr/issues/6454" rel=3D"nofollow" target=3D"_blank" on=
mousedown=3D"this.href=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2=
Fgithub.com%2Fdotnet%2Fcoreclr%2Fissues%2F6454\x26sa\x3dD\x26sntz\x3d1\x26u=
sg\x3dAFQjCNHSi7NpQX1ulvC0BMYiC3DEBe9o2Q&#39;;return true;" onclick=3D"this=
..href=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fdot=
net%2Fcoreclr%2Fissues%2F6454\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHSi7N=
pQX1ulvC0BMYiC3DEBe9o2Q&#39;;return true;"> https://github.com/dotnet/<wbr>=
coreclr/issues/6454</a>.<br><br></div></blockquote><div><br>GCC and clang b=
oth have -fwrapv to enable two&#39;s-complement wrapping semantics for sign=
ed integer types.<br>=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">These
 pragmas (with different names) probably make just as much sense in C as
 in C++, and should probably (if they are a reasonable idea) be proposed
 there as well (probably renamed).<br><br></div></blockquote><div><br>I pre=
tty much would turn them on all the time.=C2=A0 I strongly dislike many of =
the object lifetime rules, particularly in C++.<br>=C2=A0</div><blockquote =
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1p=
x #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">This suggestion could be=
=20
totally off-base.=C2=A0 Nevertheless, I feel like a lot of code in the wild=
=20
depends on these at least some of these behaviors (enforced via=20
non-standard compile-time options).=C2=A0 <br><br>Specifically:<br><ul><li>=
Make signed overflow wrap:<span style=3D"color:#660"></span><span style=3D"=
color:#000"></span><br><span style=3D"color:#000"></span><div style=3D"back=
ground-color:rgb(250,250,250);border-color:rgb(187,187,187);border-style:so=
lid;border-width:1px;word-wrap:break-word"><code><div><span style=3D"color:=
#800">#pragma</span><span style=3D"color:#000"> STDC</span><span style=3D"c=
olor:#660">++</span><span style=3D"color:#000"> overflow wrap<br></span></d=
iv></code></div><code><div><span style=3D"color:#000"><font face=3D"arial,s=
ans-serif">This
 requires the compiler to ensure that signed integer overflow behaves as
 unsigned integer overflow =E2=80=93 as 2&#39;s complement wrapping arithme=
tic.=C2=A0 I=20
suspect that there will be little performance penalty =E2=80=93 every=20
non-obsolete computer I know of already provide 2&#39;s complement in=20
hardware.</font></span></div></code></li><li><span style=3D"color:#000"></s=
pan><span style=3D"color:#000"><font face=3D"arial,sans-serif">Make signed =
overflow well-defined:<br><div style=3D"background-color:rgb(250,250,250);b=
order-color:rgb(187,187,187);border-style:solid;border-width:1px;word-wrap:=
break-word"><code><div><font face=3D"arial,sans-serif"><span style=3D"color=
:#800">#pragma</span><span style=3D"color:#000"> STDC</span><span style=3D"=
color:#660">++</span><span style=3D"color:#000"> </span><span style=3D"colo=
r:#008">no</span><span style=3D"color:#660">-</span><span style=3D"color:#0=
00">strict</span><span style=3D"color:#660">-</span><span style=3D"color:#0=
00">overflow<br></span></font></div></code></div>This
 requires that signed overflow either perform according to 2&#39;s=20
complement, or trap with an unspecified exception (that must be fatal if
 uncaught, but may or may not be a C++ exception).</font></span></li></ul><=
/div></blockquote><div>In many similar ideas I have, I&#39;ve called the ac=
ceptable behavior set &quot;snap, trap or wrap&quot;: that is, saturate to =
the largest (or smallest) value, trap in an implementation-defined way, or =
wrap two&#39;s complement.=C2=A0 This matches the common hardware behaviors=
 out there, of which wrap is obviously the most common.<br>=C2=A0</div><blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-=
left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><ul><li><span sty=
le=3D"color:#000"></span><span style=3D"color:#000"><font face=3D"arial,san=
s-serif">Turn off strict aliasing<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:#800">#pragma</span>=
<span style=3D"color:#000"> STDC</span><span style=3D"color:#660">++</span>=
<span style=3D"color:#000"> </span><span style=3D"color:#008">no</span><fon=
t face=3D"arial,sans-serif"><span style=3D"color:#660">-</span><span style=
=3D"color:#000">strict</span><span style=3D"color:#660">-</span><span style=
=3D"color:#000">aliasing</span></font><span style=3D"color:#000"><br></span=
></div></code></div>This
 turns off the strict-aliasing rule.=C2=A0 This is very useful for programs=
=20
such as garbage collectors and memory allocators =E2=80=93 indeed, I am not=
 sure
 if a memory allocator can be written in strictly conforming C++ as it=20
stands today.=C2=A0 It also allows for a C++ implementation of memcpy that =
is
 faster than going 1 byte at a time.</font></span></li></ul></div></blockqu=
ote><div>I would rather have &quot;restrict&quot; from C99 and a new &quot;=
may_alias&quot; attribute/keyword to manipulate aliasing.=C2=A0 Permitting =
type-based alias analysis is an important optimization, but we need a way t=
o suppress or extend this behavior sometimes to accomplish low-level tasks =
or more strongly optimize.<br>=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"><ul><li><span style=3D"color:#000"><font face=
=3D"arial,sans-serif">Make null pointer dereference implementation defined =
(at worst)<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><font face=3D"arial,sans-serif"><span style=3D"color:#800">#prag=
ma</span><span style=3D"color:#000"> STDC</span><span style=3D"color:#660">=
++</span><span style=3D"color:#000"> </span><span style=3D"color:#008">no</=
span><span style=3D"color:#660">-</span><span style=3D"color:#008">delete</=
span><span style=3D"color:#660">-</span><span style=3D"color:#008">null</sp=
an><span style=3D"color:#660">-</span><span style=3D"color:#000">pointer</s=
pan><span style=3D"color:#660">-</span><span style=3D"color:#000">checks<br=
></span></font></div></code></div>This
 makes dereferencing nullptr have implementation-defined behavior that=20
is guaranteed to correspond to the behavior of reading from address zero
 (on platforms where that makes sense).=C2=A0 This is useful for kernels an=
d=20
other programs that interface directly with hardware, since address 0=20
may map to meaningful data.</font></span></li></ul></div></blockquote><div>=
In Windows NT, null pointers can&#39;t safely be optimized away, either.=C2=
=A0 Because of the exception handling mechanism, code might rely upon the d=
ereferencing of null pointers triggering an exception, which can be caught =
and handled by several means.=C2=A0 This design is critical to the security=
 system in the kernel to protect against invalid input from user mode.<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"><ul>=
<li><span style=3D"color:#000"><font face=3D"arial,sans-serif">Make accessi=
ng of out-of-bounds memory allowed, provided that valid memory is guarantee=
d to exist there.<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><font face=3D"arial,sans-serif"><span style=3D"color:#800=
">#pragma</span><span style=3D"color:#000"> STDC</span><span style=3D"color=
:#660">++</span><span style=3D"color:#000"> </span><span style=3D"color:#00=
8">no</span><span style=3D"color:#660">-</span><span style=3D"color:#000">s=
trict</span><span style=3D"color:#660">-</span><span style=3D"color:#000">b=
ounds<br></span></font></div></code></div>This allows for accessing a multi=
-dimensional array as a one-dimensional array.</font></span></li></ul></div=
></blockquote><div>This also would permit the classic trick of having a 1-e=
lement array at the end of a struct and referencing past the end when memor=
y follows.=C2=A0 This mechanism is used in the APIs of Windows and UNIX, so=
 we&#39;ve been relying upon this particular undefined behavior since forev=
er.<br><br>Melissa<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/729cf6a9-a37b-47c4-b51c-1a8b34091ec8%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/729cf6a9-a37b-47c4-b51c-1a8b34091ec8=
%40isocpp.org</a>.<br />

------=_Part_21_822798592.1469577175750--

------=_Part_20_457155202.1469577175749--

.

------=_Part_1069_1355766668.1469578325853
Content-Type: multipart/alternative;
 boundary="----=_Part_1070_1311937593.1469578325853"

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

On Monday, July 25, 2016 at 4:19:41 AM UTC-4, demio...@gmail.com wrote:
>
> This is a suggestion to provide pragmas that would make certain operation=
s=20
> well-defined.  The names of the pragmas are not intended to be the actual=
=20
> names, though I did try to make them semi-reasonable.
>
> GCC implements command-line flags that correspond to the all of these=20
> except (possibly) the second.  Clang implements the first and third.  The=
=20
> first, third, and fourth are used (as command-line options) by at least t=
he=20
> Linux kernel, albeit in C and not C++ (though the corresponding flags are=
=20
> also accepted by C++ compilers).  Microsoft has probably screwed up stric=
t=20
> aliasing in CoreCLR=E2=80=93 https://github.com/dotnet/coreclr/issues/645=
4.
>
> These pragmas (with different names) probably make just as much sense in =
C=20
> as in C++, and should probably (if they are a reasonable idea) be propose=
d=20
> there as well (probably renamed).
>
> This suggestion could be totally off-base.  Nevertheless, I feel like a=
=20
> lot of code in the wild depends on these at least some of these behaviors=
=20
> (enforced via non-standard compile-time options).=20
>

This list contains two kinds of things:

1: Definitions for behavior that a large number of implementations already=
=20
pretty much support.
2: Changing the behavior of existing constructs in ways that=20
implementations don't by default support.

I've always liked the idea of a "regular" profile for C++, one that defines=
=20
a lot of stuff that the vast majority of systems allow, but we leave=20
un/implementation-defined to allow a small percentage of systems to work.=
=20
Since it's constexpr, you can `static_assert` if your code relies on it or=
=20
`if constexpr` around places where you need it to be true.

These would be things like integers being 2's complement (and thus=20
well-defined overflow behavior), 8-bit bytes (and all of the `int*_t`=20
types), perhaps even an endian setting with well-defined behavior for=20
accessing integers via byte arrays, and so forth.

These are things that should be present when the compiler/system can=20
support them. So it wouldn't be something you turn on; it's something you=
=20
query.

I don't much like items from #2. Things like turning off strict aliasing,=
=20
null pointer stuff, etc. That stuff ought to remain the realm of compiler=
=20
switches, rather than standard-supported behavior.

--=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/9d10c35a-5456-4c8e-a123-78eebda4ef51%40isocpp.or=
g.

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

<div dir=3D"ltr">On Monday, July 25, 2016 at 4:19:41 AM UTC-4, demio...@gma=
il.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
This is a suggestion to provide pragmas that would make certain=20
operations well-defined.=C2=A0 The names of the pragmas are not intended to=
=20
be the actual names, though I did try to make them semi-reasonable.<br><br>=
GCC
 implements command-line flags that correspond to the all of these=20
except (possibly) the second.=C2=A0 Clang implements the first and third.=
=C2=A0=20
The first, third, and fourth are used (as command-line options) by at=20
least the Linux kernel, albeit in C and not C++ (though the=20
corresponding flags are also accepted by C++ compilers).=C2=A0 Microsoft ha=
s=20
probably screwed up strict aliasing in CoreCLR=E2=80=93<a href=3D"https://g=
ithub.com/dotnet/coreclr/issues/6454" rel=3D"nofollow" target=3D"_blank" on=
mousedown=3D"this.href=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2=
Fgithub.com%2Fdotnet%2Fcoreclr%2Fissues%2F6454\x26sa\x3dD\x26sntz\x3d1\x26u=
sg\x3dAFQjCNHSi7NpQX1ulvC0BMYiC3DEBe9o2Q&#39;;return true;" onclick=3D"this=
..href=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fdot=
net%2Fcoreclr%2Fissues%2F6454\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHSi7N=
pQX1ulvC0BMYiC3DEBe9o2Q&#39;;return true;"> https://github.com/dotnet/<wbr>=
coreclr/issues/6454</a>.<br><br>These
 pragmas (with different names) probably make just as much sense in C as
 in C++, and should probably (if they are a reasonable idea) be proposed
 there as well (probably renamed).<br><br>This suggestion could be=20
totally off-base.=C2=A0 Nevertheless, I feel like a lot of code in the wild=
=20
depends on these at least some of these behaviors (enforced via=20
non-standard compile-time options). <br></div></blockquote><div><br>This li=
st contains two kinds of things:<br><br>1: Definitions for behavior that a =
large number of implementations already pretty much support.<br>2: Changing=
 the behavior of existing constructs in ways that implementations don&#39;t=
 by default support.<br><br>I&#39;ve always liked the idea of a &quot;regul=
ar&quot; profile for C++, one that defines a lot of stuff that the vast maj=
ority of systems allow, but we leave un/implementation-defined to allow a s=
mall percentage of systems to work. Since it&#39;s constexpr, you can `stat=
ic_assert` if your code relies on it or `if constexpr` around places where =
you need it to be true.<br><br>These would be things like integers being 2&=
#39;s complement (and thus well-defined overflow behavior), 8-bit bytes (an=
d all of the `int*_t` types), perhaps even an endian setting with well-defi=
ned behavior for accessing integers via byte arrays, and so forth.<br><br>T=
hese are things that should be present when the compiler/system can support=
 them. So it wouldn&#39;t be something you turn on; it&#39;s something you =
query.<br><br>I don&#39;t much like items from #2. Things like turning off =
strict aliasing, null pointer stuff, etc.<font face=3D"arial,sans-serif"> T=
hat stuff ought to remain the realm of compiler switches, rather than stand=
ard-supported behavior.<br></font></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/9d10c35a-5456-4c8e-a123-78eebda4ef51%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9d10c35a-5456-4c8e-a123-78eebda4ef51=
%40isocpp.org</a>.<br />

------=_Part_1070_1311937593.1469578325853--

------=_Part_1069_1355766668.1469578325853--

.

On ter=C3=A7a-feira, 26 de julho de 2016 16:52:55 PDT Myriachan wrote:
> > - Make accessing of out-of-bounds memory allowed, provided that valid=
=20
> > memory is guaranteed to exist there.
> > #pragma STDC++ no-strict-bounds
> > This allows for accessing a multi-dimensional array as a=20
> > one-dimensional array.
> >=20
> This also would permit the classic trick of having a 1-element array at=
=20
> the end of a struct and referencing past the end when memory follows.  Th=
is=20
> mechanism is used in the APIs of Windows and UNIX, so we've been relying
> upon this particular undefined behavior since forever.

Which in turn shows this shouldn't be a pragma, but instead should be a per=
-
array setting. There aren't many arrays that can be accessed out-of-bounds,=
=20
but the few that are, are often significant.

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--=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/1730676.UL39yQG8Vk%40tjmaciei-mobl1.

.

------=_Part_3432_1663837183.1469587426216
Content-Type: multipart/alternative;
 boundary="----=_Part_3433_35390141.1469587426216"

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

On Tuesday, July 26, 2016 at 8:12:05 PM UTC-4, Nicol Bolas wrote:
>
> On Monday, July 25, 2016 at 4:19:41 AM UTC-4, demio...@gmail.com wrote:
>>
>> This is a suggestion to provide pragmas that would make certain=20
>> operations well-defined.  The names of the pragmas are not intended to b=
e=20
>> the actual names, though I did try to make them semi-reasonable.
>>
>> GCC implements command-line flags that correspond to the all of these=20
>> except (possibly) the second.  Clang implements the first and third.  Th=
e=20
>> first, third, and fourth are used (as command-line options) by at least =
the=20
>> Linux kernel, albeit in C and not C++ (though the corresponding flags ar=
e=20
>> also accepted by C++ compilers).  Microsoft has probably screwed up stri=
ct=20
>> aliasing in CoreCLR=E2=80=93 https://github.com/dotnet/coreclr/issues/64=
54.
>>
>> These pragmas (with different names) probably make just as much sense in=
=20
>> C as in C++, and should probably (if they are a reasonable idea) be=20
>> proposed there as well (probably renamed).
>>
>> This suggestion could be totally off-base.  Nevertheless, I feel like a=
=20
>> lot of code in the wild depends on these at least some of these behavior=
s=20
>> (enforced via non-standard compile-time options).=20
>>
>
> This list contains two kinds of things:
>
> 1: Definitions for behavior that a large number of implementations alread=
y=20
> pretty much support.
> 2: Changing the behavior of existing constructs in ways that=20
> implementations don't by default support.
>
> I've always liked the idea of a "regular" profile for C++, one that=20
> defines a lot of stuff that the vast majority of systems allow, but we=20
> leave un/implementation-defined to allow a small percentage of systems to=
=20
> work. Since it's constexpr, you can `static_assert` if your code relies o=
n=20
> it or `if constexpr` around places where you need it to be true.
>

OK, that paragraph didn't work out at all. So let me try again.

The idea is that there's a lot of stuff which most of the major=20
compilers/platforms support. But C++ doesn't specify behavior for them,=20
because there are a relatively small number of compilers/platforms which=20
don't support them. So a lot of code gets written that assumes certain=20
things that aren't guaranteed: two's complement signed integers, 8-bit=20
bytes, integers stored in big|little endian formats, etc.

What I'm thinking is permitting a compiler to advertise the fact that it is=
=20
"regular", via a constexpr variable or somesuch. Regular implementations=20
define a number of commonly assumed operations, and should represent the=20
major compilers/platforms behavior in these regards. Since the variable is=
=20
`constexpr`, you can static_assert on it if your code absolutely relies on=
=20
this behavior, or you can `if constexpr` around it if you have an=20
alternative way of doing what you need to do.

--=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/8dc517d0-d56a-4bfa-a2c2-e81134e7d1e9%40isocpp.or=
g.

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

<div dir=3D"ltr">On Tuesday, July 26, 2016 at 8:12:05 PM UTC-4, Nicol Bolas=
 wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">On Mon=
day, July 25, 2016 at 4:19:41 AM UTC-4, <a>demio...@gmail.com</a> wrote:<bl=
ockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">This is a suggestion =
to provide pragmas that would make certain=20
operations well-defined.=C2=A0 The names of the pragmas are not intended to=
=20
be the actual names, though I did try to make them semi-reasonable.<br><br>=
GCC
 implements command-line flags that correspond to the all of these=20
except (possibly) the second.=C2=A0 Clang implements the first and third.=
=C2=A0=20
The first, third, and fourth are used (as command-line options) by at=20
least the Linux kernel, albeit in C and not C++ (though the=20
corresponding flags are also accepted by C++ compilers).=C2=A0 Microsoft ha=
s=20
probably screwed up strict aliasing in CoreCLR=E2=80=93<a href=3D"https://g=
ithub.com/dotnet/coreclr/issues/6454" rel=3D"nofollow" target=3D"_blank" on=
mousedown=3D"this.href=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2=
Fgithub.com%2Fdotnet%2Fcoreclr%2Fissues%2F6454\x26sa\x3dD\x26sntz\x3d1\x26u=
sg\x3dAFQjCNHSi7NpQX1ulvC0BMYiC3DEBe9o2Q&#39;;return true;" onclick=3D"this=
..href=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fdot=
net%2Fcoreclr%2Fissues%2F6454\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHSi7N=
pQX1ulvC0BMYiC3DEBe9o2Q&#39;;return true;"> https://github.com/dotnet/<wbr>=
coreclr/issues/6454</a>.<br><br>These
 pragmas (with different names) probably make just as much sense in C as
 in C++, and should probably (if they are a reasonable idea) be proposed
 there as well (probably renamed).<br><br>This suggestion could be=20
totally off-base.=C2=A0 Nevertheless, I feel like a lot of code in the wild=
=20
depends on these at least some of these behaviors (enforced via=20
non-standard compile-time options). <br></div></blockquote><div><br>This li=
st contains two kinds of things:<br><br>1: Definitions for behavior that a =
large number of implementations already pretty much support.<br>2: Changing=
 the behavior of existing constructs in ways that implementations don&#39;t=
 by default support.<br><br>I&#39;ve always liked the idea of a &quot;regul=
ar&quot; profile for C++, one that defines a lot of stuff that the vast maj=
ority of systems allow, but we leave un/implementation-defined to allow a s=
mall percentage of systems to work. Since it&#39;s constexpr, you can `stat=
ic_assert` if your code relies on it or `if constexpr` around places where =
you need it to be true.<br></div></div></blockquote><div><br>OK, that parag=
raph didn&#39;t work out at all. So let me try again.<br><br>The idea is th=
at there&#39;s a lot of stuff which most of the major compilers/platforms s=
upport. But C++ doesn&#39;t specify behavior for them, because there are a =
relatively small number of compilers/platforms which don&#39;t support them=
.. So a lot of code gets written that assumes certain things that aren&#39;t=
 guaranteed: two&#39;s complement signed integers, 8-bit bytes, integers st=
ored in big|little endian formats, etc.<br><br>What I&#39;m thinking is per=
mitting a compiler to advertise the fact that it is &quot;regular&quot;, vi=
a a constexpr variable or somesuch. Regular implementations define a number=
 of commonly assumed operations, and should represent the major compilers/p=
latforms behavior in these regards. Since the variable is `constexpr`, you =
can static_assert on it if your code absolutely relies on this behavior, or=
 you can `if constexpr` around it if you have an alternative way of doing w=
hat you need to do.<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/8dc517d0-d56a-4bfa-a2c2-e81134e7d1e9%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/8dc517d0-d56a-4bfa-a2c2-e81134e7d1e9=
%40isocpp.org</a>.<br />

------=_Part_3433_35390141.1469587426216--

------=_Part_3432_1663837183.1469587426216--

.

------=_Part_23_1210286909.1469599521199
Content-Type: multipart/alternative;
 boundary="----=_Part_24_1697449412.1469599521199"

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



=E5=9C=A8 2016=E5=B9=B47=E6=9C=8827=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=89 UTC=
+8=E4=B8=8A=E5=8D=888:12:05=EF=BC=8CNicol Bolas=E5=86=99=E9=81=93=EF=BC=9A
>
> On Monday, July 25, 2016 at 4:19:41 AM UTC-4, demio...@gmail.com wrote:
>>
>> This is a suggestion to provide pragmas that would make certain=20
>> operations well-defined.  The names of the pragmas are not intended to b=
e=20
>> the actual names, though I did try to make them semi-reasonable.
>>
>> GCC implements command-line flags that correspond to the all of these=20
>> except (possibly) the second.  Clang implements the first and third.  Th=
e=20
>> first, third, and fourth are used (as command-line options) by at least =
the=20
>> Linux kernel, albeit in C and not C++ (though the corresponding flags ar=
e=20
>> also accepted by C++ compilers).  Microsoft has probably screwed up stri=
ct=20
>> aliasing in CoreCLR=E2=80=93 https://github.com/dotnet/coreclr/issues/64=
54.
>>
>> These pragmas (with different names) probably make just as much sense in=
=20
>> C as in C++, and should probably (if they are a reasonable idea) be=20
>> proposed there as well (probably renamed).
>>
>> This suggestion could be totally off-base.  Nevertheless, I feel like a=
=20
>> lot of code in the wild depends on these at least some of these behavior=
s=20
>> (enforced via non-standard compile-time options).=20
>>
>
> This list contains two kinds of things:
>
> 1: Definitions for behavior that a large number of implementations alread=
y=20
> pretty much support.
> 2: Changing the behavior of existing constructs in ways that=20
> implementations don't by default support.
>
> I've always liked the idea of a "regular" profile for C++, one that=20
> defines a lot of stuff that the vast majority of systems allow, but we=20
> leave un/implementation-defined to allow a small percentage of systems to=
=20
> work. Since it's constexpr, you can `static_assert` if your code relies o=
n=20
> it or `if constexpr` around places where you need it to be true.
>
> These would be things like integers being 2's complement (and thus=20
> well-defined overflow behavior), 8-bit bytes (and all of the `int*_t`=20
> types), perhaps even an endian setting with well-defined behavior for=20
> accessing integers via byte arrays, and so forth.
>
These are things that should be present when the compiler/system can=20
> support them. So it wouldn't be something you turn on; it's something you=
=20
> query.
>
> There are more than one problem domains. First, the language should be=20
able to express all settings of them (with either defined or deliberately=
=20
undefined behavior on some operations), probably better by library=20
extensions (as types) with underlying built-in native support (like=20
`int*_t`), and may even allow different settings work in a same program.=20
Then even explicit query is not need - if the code can't work, it simply=20
does not type check; otherwise it is portable. The second problem is which=
=20
particular set should be mandated.

=20

> I don't much like items from #2. Things like turning off strict aliasing,=
=20
> null pointer stuff, etc. That stuff ought to remain the realm of compiler=
=20
> switches, rather than standard-supported behavior.
>
Agreed.
=20

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/5058423a-1a1c-461a-85b3-1e396d7ac795%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B47=E6=9C=8827=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=B8=89 UTC+8=E4=B8=8A=E5=8D=888:12:05=EF=BC=8CNicol Bolas=E5=
=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div d=
ir=3D"ltr">On Monday, July 25, 2016 at 4:19:41 AM UTC-4, <a>demio...@gmail.=
com</a> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-le=
ft:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">This=
 is a suggestion to provide pragmas that would make certain=20
operations well-defined.=C2=A0 The names of the pragmas are not intended to=
=20
be the actual names, though I did try to make them semi-reasonable.<br><br>=
GCC
 implements command-line flags that correspond to the all of these=20
except (possibly) the second.=C2=A0 Clang implements the first and third.=
=C2=A0=20
The first, third, and fourth are used (as command-line options) by at=20
least the Linux kernel, albeit in C and not C++ (though the=20
corresponding flags are also accepted by C++ compilers).=C2=A0 Microsoft ha=
s=20
probably screwed up strict aliasing in CoreCLR=E2=80=93<a href=3D"https://g=
ithub.com/dotnet/coreclr/issues/6454" rel=3D"nofollow" target=3D"_blank" on=
mousedown=3D"this.href=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2=
Fgithub.com%2Fdotnet%2Fcoreclr%2Fissues%2F6454\x26sa\x3dD\x26sntz\x3d1\x26u=
sg\x3dAFQjCNHSi7NpQX1ulvC0BMYiC3DEBe9o2Q&#39;;return true;" onclick=3D"this=
..href=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fdot=
net%2Fcoreclr%2Fissues%2F6454\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHSi7N=
pQX1ulvC0BMYiC3DEBe9o2Q&#39;;return true;"> https://github.com/dotnet/<wbr>=
coreclr/issues/6454</a>.<br><br>These
 pragmas (with different names) probably make just as much sense in C as
 in C++, and should probably (if they are a reasonable idea) be proposed
 there as well (probably renamed).<br><br>This suggestion could be=20
totally off-base.=C2=A0 Nevertheless, I feel like a lot of code in the wild=
=20
depends on these at least some of these behaviors (enforced via=20
non-standard compile-time options). <br></div></blockquote><div><br>This li=
st contains two kinds of things:<br><br>1: Definitions for behavior that a =
large number of implementations already pretty much support.<br>2: Changing=
 the behavior of existing constructs in ways that implementations don&#39;t=
 by default support.<br><br>I&#39;ve always liked the idea of a &quot;regul=
ar&quot; profile for C++, one that defines a lot of stuff that the vast maj=
ority of systems allow, but we leave un/implementation-defined to allow a s=
mall percentage of systems to work. Since it&#39;s constexpr, you can `stat=
ic_assert` if your code relies on it or `if constexpr` around places where =
you need it to be true.<br><br>These would be things like integers being 2&=
#39;s complement (and thus well-defined overflow behavior), 8-bit bytes (an=
d all of the `int*_t` types), perhaps even an endian setting with well-defi=
ned behavior for accessing integers via byte arrays, and so forth.<br></div=
></div></blockquote><blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div>These are things that should be present when the compiler/sys=
tem can support them. So it wouldn&#39;t be something you turn on; it&#39;s=
 something you query.<br><br></div></div></blockquote><div><div>There are m=
ore than one problem domains. First, the language should be able
 to express all settings of them (with either defined or deliberately undef=
ined behavior on some operations), probably better by library extensions (a=
s types)
with underlying built-in native support (like `int*_t`), and may even=20
allow different settings work in a same program. Then even explicit query i=
s not need - if the code can&#39;t work, it simply does not type check; oth=
erwise it is portable. The second problem is=20
which particular set should be mandated.<br></div><br>=C2=A0</div><blockquo=
te 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>I don&#39;t much =
like items from #2. Things like turning off strict aliasing, null pointer s=
tuff, etc.<font face=3D"arial,sans-serif"> That stuff ought to remain the r=
ealm of compiler switches, rather than standard-supported behavior.<br></fo=
nt></div></div></blockquote><div>Agreed.<br>=C2=A0<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/5058423a-1a1c-461a-85b3-1e396d7ac795%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5058423a-1a1c-461a-85b3-1e396d7ac795=
%40isocpp.org</a>.<br />

------=_Part_24_1697449412.1469599521199--

------=_Part_23_1210286909.1469599521199--

.

------=_Part_8280_1687125696.1469647493655
Content-Type: multipart/alternative;
 boundary="----=_Part_8281_717859956.1469647493655"

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

On Tuesday, July 26, 2016 at 6:06:34 PM UTC-7, Thiago Macieira wrote:
>
> On ter=C3=A7a-feira, 26 de julho de 2016 16:52:55 PDT Myriachan wrote:=20
> > This also would permit the classic trick of having a 1-element array at=
=20
> > the end of a struct and referencing past the end when memory follows.=
=20
>  This=20
> > mechanism is used in the APIs of Windows and UNIX, so we've been relyin=
g=20
> > upon this particular undefined behavior since forever.=20
>
> Which in turn shows this shouldn't be a pragma, but instead should be a=
=20
> per-=20
> array setting. There aren't many arrays that can be accessed=20
> out-of-bounds,=20
> but the few that are, are often significant.=20
>
>
I just noticed that C99 permits this already as "flexible array members",=
=20
where you declare the array at the end of a struct without a size.  It then=
=20
guarantees that sizeof(structname) =3D=3D offsetof(structname, membername).

This would be convenient in C++, even if only permitted for standard-layout=
=20
types.  It's required to interface with many existing APIs, at least=20
without bending over backward.

That said, the original suggestion of being able to access multidimensional=
=20
arrays as if they were single-dimensional arrays would be really nice. =20
Implementing it would require changes to the aliasing rules and to the=20
definition of "pointer to array" types.

Multidimensional arrays would be really nice for programs that have manual=
=20
use of vectors.  It doesn't directly matter for now, because those=20
intrinsics are beyond the Standard, and are implemented in compilers so as=
=20
to be allowed to alias anything.

Melissa

--=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/42422923-778e-4ea6-9b4c-4fe2d0d447e1%40isocpp.or=
g.

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

<div dir=3D"ltr">On Tuesday, July 26, 2016 at 6:06:34 PM UTC-7, Thiago Maci=
eira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On ter=C3=A7a-feira=
, 26 de julho de 2016 16:52:55 PDT Myriachan wrote:
<br>&gt; This also would permit the classic trick of having a 1-element arr=
ay at=20
<br>&gt; the end of a struct and referencing past the end when memory follo=
ws. =C2=A0This=20
<br>&gt; mechanism is used in the APIs of Windows and UNIX, so we&#39;ve be=
en relying
<br>&gt; upon this particular undefined behavior since forever.
<br>
<br>Which in turn shows this shouldn&#39;t be a pragma, but instead should =
be a per-
<br>array setting. There aren&#39;t many arrays that can be accessed out-of=
-bounds,=20
<br>but the few that are, are often significant.
<br>
<br></blockquote><div><br>I just noticed that C99 permits this already as &=
quot;flexible array members&quot;, where you declare the array at the end o=
f a struct without a size.=C2=A0 It then guarantees that sizeof(structname)=
 =3D=3D offsetof(structname, membername).<br><br>This would be convenient i=
n C++, even if only permitted for standard-layout types.=C2=A0 It&#39;s req=
uired to interface with many existing APIs, at least without bending over b=
ackward.<br><br>That said, the original suggestion of being able to access =
multidimensional arrays as if they were single-dimensional arrays would be =
really nice.=C2=A0 Implementing it would require changes to the aliasing ru=
les and to the definition of &quot;pointer to array&quot; types.<br><br>Mul=
tidimensional arrays would be really nice for programs that have manual use=
 of vectors.=C2=A0 It doesn&#39;t directly matter for now, because those in=
trinsics are beyond the Standard, and are implemented in compilers so as to=
 be allowed to alias anything.<br><br>Melissa<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/42422923-778e-4ea6-9b4c-4fe2d0d447e1%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/42422923-778e-4ea6-9b4c-4fe2d0d447e1=
%40isocpp.org</a>.<br />

------=_Part_8281_717859956.1469647493655--

------=_Part_8280_1687125696.1469647493655--

.

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

My personal view is that if a memory access points to memory that has not
been deallocated, and to a valid bit-pattern for the type of the access,
and there are no data races, the access should be well-defined.

Without this, I cannot see how to reasonably implement a garbage collector
that works with heterogeneous objects that it cannot just treat as opaque
bytes (because it needs to follow pointers and possibly invoke tracing
methods).  In the case, the actual type of the object is often unknown, and
may not even exist at compile time =E2=80=94 the GC uses metadata to proces=
s the
object based on its layout at runtime.

On Jul 27, 2016 3:24 PM, "Myriachan" <myriachan@gmail.com> wrote:

> On Tuesday, July 26, 2016 at 6:06:34 PM UTC-7, Thiago Macieira wrote:
>>
>> On ter=C3=A7a-feira, 26 de julho de 2016 16:52:55 PDT Myriachan wrote:
>> > This also would permit the classic trick of having a 1-element array a=
t
>> > the end of a struct and referencing past the end when memory follows.
>> This
>> > mechanism is used in the APIs of Windows and UNIX, so we've been
>> relying
>> > upon this particular undefined behavior since forever.
>>
>> Which in turn shows this shouldn't be a pragma, but instead should be a
>> per-
>> array setting. There aren't many arrays that can be accessed
>> out-of-bounds,
>> but the few that are, are often significant.
>>
>>
> I just noticed that C99 permits this already as "flexible array members",
> where you declare the array at the end of a struct without a size.  It th=
en
> guarantees that sizeof(structname) =3D=3D offsetof(structname, membername=
).
>
> This would be convenient in C++, even if only permitted for
> standard-layout types.  It's required to interface with many existing API=
s,
> at least without bending over backward.
>
> That said, the original suggestion of being able to access
> multidimensional arrays as if they were single-dimensional arrays would b=
e
> really nice.  Implementing it would require changes to the aliasing rules
> and to the definition of "pointer to array" types.
>
> Multidimensional arrays would be really nice for programs that have manua=
l
> use of vectors.  It doesn't directly matter for now, because those
> intrinsics are beyond the Standard, and are implemented in compilers so a=
s
> to be allowed to alias anything.
>
> Melissa
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/h_UoZuTPhZw/=
unsubscribe
> .
> To unsubscribe from this group and all its topics, 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/42422923-778=
e-4ea6-9b4c-4fe2d0d447e1%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/42422923-77=
8e-4ea6-9b4c-4fe2d0d447e1%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>

--=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/CAJEMUN8SBoz6NVCBzrcLmc8L_FyUZxd3gG4QPNEQu5zZ2us=
0kw%40mail.gmail.com.

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

<p dir=3D"ltr">My personal view is that if a memory access points to memory=
 that has not been deallocated, and to a valid bit-pattern for the type of =
the access, and there are no data races, the access should be well-defined.=
</p>
<p dir=3D"ltr">Without this, I cannot see how to reasonably implement a gar=
bage collector that works with heterogeneous objects that it cannot just tr=
eat as opaque bytes (because it needs to follow pointers and possibly invok=
e tracing methods).=C2=A0 In the case, the actual type of the object is oft=
en unknown, and may not even exist at compile time =E2=80=94 the GC uses me=
tadata to process the object based on its layout at runtime.</p>
<div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Jul 27, 2016 3=
:24 PM, &quot;Myriachan&quot; &lt;<a href=3D"mailto:myriachan@gmail.com">my=
riachan@gmail.com</a>&gt; wrote:<br type=3D"attribution"><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr">On Tuesday, July 26, 2016 at 6:06:34 PM UTC-=
7, 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 ter=C3=
=A7a-feira, 26 de julho de 2016 16:52:55 PDT Myriachan wrote:
<br>&gt; This also would permit the classic trick of having a 1-element arr=
ay at=20
<br>&gt; the end of a struct and referencing past the end when memory follo=
ws.=C2=A0 This=20
<br>&gt; mechanism is used in the APIs of Windows and UNIX, so we&#39;ve be=
en relying
<br>&gt; upon this particular undefined behavior since forever.
<br>
<br>Which in turn shows this shouldn&#39;t be a pragma, but instead should =
be a per-
<br>array setting. There aren&#39;t many arrays that can be accessed out-of=
-bounds,=20
<br>but the few that are, are often significant.
<br>
<br></blockquote><div><br>I just noticed that C99 permits this already as &=
quot;flexible array members&quot;, where you declare the array at the end o=
f a struct without a size.=C2=A0 It then guarantees that sizeof(structname)=
 =3D=3D offsetof(structname, membername).<br><br>This would be convenient i=
n C++, even if only permitted for standard-layout types.=C2=A0 It&#39;s req=
uired to interface with many existing APIs, at least without bending over b=
ackward.<br><br>That said, the original suggestion of being able to access =
multidimensional arrays as if they were single-dimensional arrays would be =
really nice.=C2=A0 Implementing it would require changes to the aliasing ru=
les and to the definition of &quot;pointer to array&quot; types.<br><br>Mul=
tidimensional arrays would be really nice for programs that have manual use=
 of vectors.=C2=A0 It doesn&#39;t directly matter for now, because those in=
trinsics are beyond the Standard, and are implemented in compilers so as to=
 be allowed to alias anything.<br><br>Melissa<br></div></div>

<p></p>

-- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/h_UoZuTPhZw/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/h_UoZuTPhZw=
/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/42422923-778e-4ea6-9b4c-4fe2d0d447e1%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/42422923-778e-=
4ea6-9b4c-4fe2d0d447e1%40isocpp.org</a>.<br>
</blockquote></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAJEMUN8SBoz6NVCBzrcLmc8L_FyUZxd3gG4Q=
PNEQu5zZ2us0kw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJEMUN8SBoz6NVCB=
zrcLmc8L_FyUZxd3gG4QPNEQu5zZ2us0kw%40mail.gmail.com</a>.<br />

--94eb2c07be806e9afd0538a82482--

.

------=_Part_62_1351288366.1469746087607
Content-Type: multipart/alternative;
 boundary="----=_Part_63_503149561.1469746087607"

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

On Thursday, 28 July 2016 02:35:02 UTC+1, Demi Obenour wrote:
>
> My personal view is that if a memory access points to memory that has not=
=20
> been deallocated, and to a valid bit-pattern for the type of the access,=
=20
> and there are no data races, the access should be well-defined.
>
> Without this, I cannot see how to reasonably implement a garbage collecto=
r=20
> that works with heterogeneous objects that it cannot just treat as opaque=
=20
> bytes (because it needs to follow pointers and possibly invoke tracing=20
> methods).  In the case, the actual type of the object is often unknown, a=
nd=20
> may not even exist at compile time =E2=80=94 the GC uses metadata to proc=
ess the=20
> object based on its layout at runtime.
>

At the risk of sounding like a broken record, why not memcpy?=20

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/d05d77b7-b9df-4217-bbed-75e4d941f3f3%40isocpp.or=
g.

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

<div dir=3D"ltr">On Thursday, 28 July 2016 02:35:02 UTC+1, Demi Obenour  wr=
ote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;"><p dir=3D"ltr">My personal=
 view is that if a memory access points to memory that has not been dealloc=
ated, and to a valid bit-pattern for the type of the access, and there are =
no data races, the access should be well-defined.</p>
<p dir=3D"ltr">Without this, I cannot see how to reasonably implement a gar=
bage collector that works with heterogeneous objects that it cannot just tr=
eat as opaque bytes (because it needs to follow pointers and possibly invok=
e tracing methods).=C2=A0 In the case, the actual type of the object is oft=
en unknown, and may not even exist at compile time =E2=80=94 the GC uses me=
tadata to process the object based on its layout at runtime.</p></blockquot=
e><div><br></div><div>At the risk of sounding like a broken record, why not=
 memcpy?=C2=A0</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/d05d77b7-b9df-4217-bbed-75e4d941f3f3%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d05d77b7-b9df-4217-bbed-75e4d941f3f3=
%40isocpp.org</a>.<br />

------=_Part_63_503149561.1469746087607--

------=_Part_62_1351288366.1469746087607--

.

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

Because that would require way too much use of memcpy.  The code would be
completely unreadable.

On Jul 28, 2016 6:48 PM, "Edward Catmur" <ed@catmur.co.uk> wrote:

> On Thursday, 28 July 2016 02:35:02 UTC+1, Demi Obenour wrote:
>>
>> My personal view is that if a memory access points to memory that has no=
t
>> been deallocated, and to a valid bit-pattern for the type of the access,
>> and there are no data races, the access should be well-defined.
>>
>> Without this, I cannot see how to reasonably implement a garbage
>> collector that works with heterogeneous objects that it cannot just trea=
t
>> as opaque bytes (because it needs to follow pointers and possibly invoke
>> tracing methods).  In the case, the actual type of the object is often
>> unknown, and may not even exist at compile time =E2=80=94 the GC uses me=
tadata to
>> process the object based on its layout at runtime.
>>
>
> At the risk of sounding like a broken record, why not memcpy?
>

--=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/CAJEMUN9LGPuLJXMFoE5qsO7Pmjxf5AkOrJUnkZjcvn%2B2F=
pU-Yg%40mail.gmail.com.

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

<p dir=3D"ltr">Because that would require way too much use of memcpy.=C2=A0=
 The code would be completely unreadable.<br>
 </p>
<div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Jul 28, 2016 6=
:48 PM, &quot;Edward Catmur&quot; &lt;<a href=3D"mailto:ed@catmur.co.uk">ed=
@catmur.co.uk</a>&gt; wrote:<br type=3D"attribution"><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div dir=3D"ltr">On Thursday, 28 July 2016 02:35:02 UTC+1, Demi Ob=
enour  wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-lef=
t:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir=3D"ltr">My pers=
onal view is that if a memory access points to memory that has not been dea=
llocated, and to a valid bit-pattern for the type of the access, and there =
are no data races, the access should be well-defined.</p>
<p dir=3D"ltr">Without this, I cannot see how to reasonably implement a gar=
bage collector that works with heterogeneous objects that it cannot just tr=
eat as opaque bytes (because it needs to follow pointers and possibly invok=
e tracing methods).=C2=A0 In the case, the actual type of the object is oft=
en unknown, and may not even exist at compile time =E2=80=94 the GC uses me=
tadata to process the object based on its layout at runtime.</p></blockquot=
e><div><br></div><div>At the risk of sounding like a broken record, why not=
 memcpy?=C2=A0</div></div></blockquote></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAJEMUN9LGPuLJXMFoE5qsO7Pmjxf5AkOrJUn=
kZjcvn%2B2FpU-Yg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJEMUN9LGPuLJX=
MFoE5qsO7Pmjxf5AkOrJUnkZjcvn%2B2FpU-Yg%40mail.gmail.com</a>.<br />

--94eb2c121f92d6ce930538c16cde--

.

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

On Fri, Jul 29, 2016 at 8:44 AM, Demi Obenour <demiobenour@gmail.com> wrote=
:

> Because that would require way too much use of memcpy.  The code would be
> completely unreadable.
>
So write a wrapper function. What's more readable, read_memory_as<void*>(p)
or *reinterpret_cast<void**>(p) // I hope the optimizer doesn't notice that
this is illegal?

And in how many source locations does a mark-and-sweep GC read the memory
it is scanning, anyway?

On Jul 28, 2016 6:48 PM, "Edward Catmur" <ed@catmur.co.uk> wrote:
>
>> On Thursday, 28 July 2016 02:35:02 UTC+1, Demi Obenour wrote:
>>>
>>> My personal view is that if a memory access points to memory that has
>>> not been deallocated, and to a valid bit-pattern for the type of the
>>> access, and there are no data races, the access should be well-defined.
>>>
>>> Without this, I cannot see how to reasonably implement a garbage
>>> collector that works with heterogeneous objects that it cannot just tre=
at
>>> as opaque bytes (because it needs to follow pointers and possibly invok=
e
>>> tracing methods).  In the case, the actual type of the object is often
>>> unknown, and may not even exist at compile time =E2=80=94 the GC uses m=
etadata to
>>> process the object based on its layout at runtime.
>>>
>>
>> At the risk of sounding like a broken record, why not memcpy?
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/h_UoZuTPhZw/=
unsubscribe
> .
> To unsubscribe from this group and all its topics, 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/CAJEMUN9LGPu=
LJXMFoE5qsO7Pmjxf5AkOrJUnkZjcvn%2B2FpU-Yg%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJEMUN9LGP=
uLJXMFoE5qsO7Pmjxf5AkOrJUnkZjcvn%2B2FpU-Yg%40mail.gmail.com?utm_medium=3Dem=
ail&utm_source=3Dfooter>
> .
>

--=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/CAJnLdObnqPRu8c%2Bg6WxQvq4t4navAy-%2BfH%2B1hSN4S=
EzPMMbxYw%40mail.gmail.com.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Jul 29, 2016 at 8:44 AM, Demi Obenour <span dir=3D"ltr">&lt;<a href=3D"=
mailto:demiobenour@gmail.com" target=3D"_blank">demiobenour@gmail.com</a>&g=
t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir=3D"ltr">Because t=
hat would require way too much use of memcpy.=C2=A0 The code would be compl=
etely unreadable.</p></blockquote><div>So write a wrapper function. What&#3=
9;s more readable, read_memory_as&lt;void*&gt;(p) or *reinterpret_cast&lt;v=
oid**&gt;(p) // I hope the optimizer doesn&#39;t notice that this is illega=
l?</div><div><br></div><div>And in how many source locations does a mark-an=
d-sweep GC read the memory it is scanning, anyway?</div><div><br></div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div class=3D"gmail_extra"><div class=3D"gmail_q=
uote">On Jul 28, 2016 6:48 PM, &quot;Edward Catmur&quot; &lt;<a href=3D"mai=
lto:ed@catmur.co.uk" target=3D"_blank">ed@catmur.co.uk</a>&gt; wrote:<br ty=
pe=3D"attribution"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
..8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Thurs=
day, 28 July 2016 02:35:02 UTC+1, Demi Obenour  wrote:<blockquote class=3D"=
gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid=
;padding-left:1ex"><p dir=3D"ltr">My personal view is that if a memory acce=
ss points to memory that has not been deallocated, and to a valid bit-patte=
rn for the type of the access, and there are no data races, the access shou=
ld be well-defined.</p>
<p dir=3D"ltr">Without this, I cannot see how to reasonably implement a gar=
bage collector that works with heterogeneous objects that it cannot just tr=
eat as opaque bytes (because it needs to follow pointers and possibly invok=
e tracing methods).=C2=A0 In the case, the actual type of the object is oft=
en unknown, and may not even exist at compile time =E2=80=94 the GC uses me=
tadata to process the object based on its layout at runtime.</p></blockquot=
e><div><br></div><div>At the risk of sounding like a broken record, why not=
 memcpy?=C2=A0</div></div></blockquote></div></div><span class=3D"HOEnZb"><=
font color=3D"#888888">

<p></p>

-- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/h_UoZuTPhZw/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/h_UoZuTPhZw=
/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAJEMUN9LGPuLJXMFoE5qsO7Pmjxf5AkOrJUn=
kZjcvn%2B2FpU-Yg%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-pro=
posals/CAJEMUN9LGPuLJXMFoE5qsO7Pmjxf5AkOrJUnkZjcvn%2B2FpU-Yg%40mail.gmail.c=
om</a>.<br>
</font></span></blockquote></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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAJnLdObnqPRu8c%2Bg6WxQvq4t4navAy-%2B=
fH%2B1hSN4SEzPMMbxYw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdObnqP=
Ru8c%2Bg6WxQvq4t4navAy-%2BfH%2B1hSN4SEzPMMbxYw%40mail.gmail.com</a>.<br />

--001a114c983e5e83350538c2075c--

.

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

The bigger issue is a copying GC.  You really don't want to call move
and/or copy constructors.  Much easier if you can restrict yourself the
types that can be blitted with memcpy.  This almost certainly runs afoul of
object lifetime rules, but is required if you want good performance.

On Jul 29, 2016 04:28, "'Edward Catmur' via ISO C++ Standard - Future
Proposals" <std-proposals@isocpp.org> wrote:

> On Fri, Jul 29, 2016 at 8:44 AM, Demi Obenour <demiobenour@gmail.com>
> wrote:
>
>> Because that would require way too much use of memcpy.  The code would b=
e
>> completely unreadable.
>>
> So write a wrapper function. What's more readable,
> read_memory_as<void*>(p) or *reinterpret_cast<void**>(p) // I hope the
> optimizer doesn't notice that this is illegal?
>
> And in how many source locations does a mark-and-sweep GC read the memory
> it is scanning, anyway?
>
> On Jul 28, 2016 6:48 PM, "Edward Catmur" <ed@catmur.co.uk> wrote:
>>
>>> On Thursday, 28 July 2016 02:35:02 UTC+1, Demi Obenour wrote:
>>>>
>>>> My personal view is that if a memory access points to memory that has
>>>> not been deallocated, and to a valid bit-pattern for the type of the
>>>> access, and there are no data races, the access should be well-defined=
..
>>>>
>>>> Without this, I cannot see how to reasonably implement a garbage
>>>> collector that works with heterogeneous objects that it cannot just tr=
eat
>>>> as opaque bytes (because it needs to follow pointers and possibly invo=
ke
>>>> tracing methods).  In the case, the actual type of the object is often
>>>> unknown, and may not even exist at compile time =E2=80=94 the GC uses =
metadata to
>>>> process the object based on its layout at runtime.
>>>>
>>>
>>> At the risk of sounding like a broken record, why not memcpy?
>>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/h_UoZuTPhZw=
/unsubscribe
>> .
>> To unsubscribe from this group and all its topics, 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/CAJEMUN9LGP=
uLJXMFoE5qsO7Pmjxf5AkOrJUnkZjcvn%2B2FpU-Yg%40mail.gmail.com
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJEMUN9LG=
PuLJXMFoE5qsO7Pmjxf5AkOrJUnkZjcvn%2B2FpU-Yg%40mail.gmail.com?utm_medium=3De=
mail&utm_source=3Dfooter>
>> .
>>
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/h_UoZuTPhZw/=
unsubscribe
> .
> To unsubscribe from this group and all its topics, 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/CAJnLdObnqPR=
u8c%2Bg6WxQvq4t4navAy-%2BfH%2B1hSN4SEzPMMbxYw%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdObnqP=
Ru8c%2Bg6WxQvq4t4navAy-%2BfH%2B1hSN4SEzPMMbxYw%40mail.gmail.com?utm_medium=
=3Demail&utm_source=3Dfooter>
> .
>

--=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/CAJEMUN9j7FEgCWN5EUb7zcK3f11sLR%3DBvo%2B8oyBrBGy=
Q%2BSGbKA%40mail.gmail.com.

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

<p dir=3D"ltr">The bigger issue is a copying GC.=C2=A0 You really don&#39;t=
 want to call move and/or copy constructors.=C2=A0 Much easier if you can r=
estrict yourself the types that can be blitted with memcpy.=C2=A0 This almo=
st certainly runs afoul of object lifetime rules, but is required if you wa=
nt good performance.</p>
<div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Jul 29, 2016 0=
4:28, &quot;&#39;Edward Catmur&#39; via ISO C++ Standard - Future Proposals=
&quot; &lt;<a href=3D"mailto:std-proposals@isocpp.org">std-proposals@isocpp=
..org</a>&gt; wrote:<br type=3D"attribution"><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">=
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Jul 29, 2016 at 8:44 AM, Demi Obenour <span dir=3D"ltr">&lt;<a href=3D"=
mailto:demiobenour@gmail.com" target=3D"_blank">demiobenour@gmail.com</a>&g=
t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir=3D"ltr">Because t=
hat would require way too much use of memcpy.=C2=A0 The code would be compl=
etely unreadable.</p></blockquote><div>So write a wrapper function. What&#3=
9;s more readable, read_memory_as&lt;void*&gt;(p) or *reinterpret_cast&lt;v=
oid**&gt;(p) // I hope the optimizer doesn&#39;t notice that this is illega=
l?</div><div><br></div><div>And in how many source locations does a mark-an=
d-sweep GC read the memory it is scanning, anyway?</div><div><br></div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div class=3D"gmail_extra"><div class=3D"gmail_q=
uote">On Jul 28, 2016 6:48 PM, &quot;Edward Catmur&quot; &lt;<a href=3D"mai=
lto:ed@catmur.co.uk" target=3D"_blank">ed@catmur.co.uk</a>&gt; wrote:<br ty=
pe=3D"attribution"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
..8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Thurs=
day, 28 July 2016 02:35:02 UTC+1, Demi Obenour  wrote:<blockquote class=3D"=
gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid=
;padding-left:1ex"><p dir=3D"ltr">My personal view is that if a memory acce=
ss points to memory that has not been deallocated, and to a valid bit-patte=
rn for the type of the access, and there are no data races, the access shou=
ld be well-defined.</p>
<p dir=3D"ltr">Without this, I cannot see how to reasonably implement a gar=
bage collector that works with heterogeneous objects that it cannot just tr=
eat as opaque bytes (because it needs to follow pointers and possibly invok=
e tracing methods).=C2=A0 In the case, the actual type of the object is oft=
en unknown, and may not even exist at compile time =E2=80=94 the GC uses me=
tadata to process the object based on its layout at runtime.</p></blockquot=
e><div><br></div><div>At the risk of sounding like a broken record, why not=
 memcpy?=C2=A0</div></div></blockquote></div></div><span><font color=3D"#88=
8888">

<p></p>

-- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/h_UoZuTPhZw/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/h_UoZuTPhZw=
/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAJEMUN9LGPuLJXMFoE5qsO7Pmjxf5AkOrJUn=
kZjcvn%2B2FpU-Yg%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-pro=
posals/CAJEMUN9LGPuLJXMFoE5qsO7Pmjxf5AkOrJUnkZjcvn%2B2FpU-Yg%40mail.gmail.c=
om</a>.<br>
</font></span></blockquote></div><br></div></div>

<p></p>

-- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/h_UoZuTPhZw/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/h_UoZuTPhZw=
/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAJnLdObnqPRu8c%2Bg6WxQvq4t4navAy-%2B=
fH%2B1hSN4SEzPMMbxYw%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Df=
ooter" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std=
-proposals/CAJnLdObnqPRu8c%2Bg6WxQvq4t4navAy-%2BfH%2B1hSN4SEzPMMbxYw%40mail=
..gmail.com</a>.<br>
</blockquote></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAJEMUN9j7FEgCWN5EUb7zcK3f11sLR%3DBvo=
%2B8oyBrBGyQ%2BSGbKA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJEMUN9j7F=
EgCWN5EUb7zcK3f11sLR%3DBvo%2B8oyBrBGyQ%2BSGbKA%40mail.gmail.com</a>.<br />

--94eb2c121f92567c550538c8d863--

.

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

Isn't that why we have the TriviallyCopyable concept?

On Fri, Jul 29, 2016 at 12:35 PM, Demi Obenour <demiobenour@gmail.com>
wrote:

> The bigger issue is a copying GC.  You really don't want to call move
> and/or copy constructors.  Much easier if you can restrict yourself the
> types that can be blitted with memcpy.  This almost certainly runs afoul =
of
> object lifetime rules, but is required if you want good performance.
>
> On Jul 29, 2016 04:28, "'Edward Catmur' via ISO C++ Standard - Future
> Proposals" <std-proposals@isocpp.org> wrote:
>
>> On Fri, Jul 29, 2016 at 8:44 AM, Demi Obenour <demiobenour@gmail.com>
>> wrote:
>>
>>> Because that would require way too much use of memcpy.  The code would
>>> be completely unreadable.
>>>
>> So write a wrapper function. What's more readable,
>> read_memory_as<void*>(p) or *reinterpret_cast<void**>(p) // I hope the
>> optimizer doesn't notice that this is illegal?
>>
>> And in how many source locations does a mark-and-sweep GC read the memor=
y
>> it is scanning, anyway?
>>
>> On Jul 28, 2016 6:48 PM, "Edward Catmur" <ed@catmur.co.uk> wrote:
>>>
>>>> On Thursday, 28 July 2016 02:35:02 UTC+1, Demi Obenour wrote:
>>>>>
>>>>> My personal view is that if a memory access points to memory that has
>>>>> not been deallocated, and to a valid bit-pattern for the type of the
>>>>> access, and there are no data races, the access should be well-define=
d.
>>>>>
>>>>> Without this, I cannot see how to reasonably implement a garbage
>>>>> collector that works with heterogeneous objects that it cannot just t=
reat
>>>>> as opaque bytes (because it needs to follow pointers and possibly inv=
oke
>>>>> tracing methods).  In the case, the actual type of the object is ofte=
n
>>>>> unknown, and may not even exist at compile time =E2=80=94 the GC uses=
 metadata to
>>>>> process the object based on its layout at runtime.
>>>>>
>>>>
>>>> At the risk of sounding like a broken record, why not memcpy?
>>>>
>>> --
>>> You received this message because you are subscribed to a topic in the
>>> Google Groups "ISO C++ Standard - Future Proposals" group.
>>> To unsubscribe from this topic, visit
>>> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/h_UoZuTPhZ=
w/unsubscribe
>>> .
>>> To unsubscribe from this group and all its topics, 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/CAJEMUN9LG=
PuLJXMFoE5qsO7Pmjxf5AkOrJUnkZjcvn%2B2FpU-Yg%40mail.gmail.com
>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJEMUN9L=
GPuLJXMFoE5qsO7Pmjxf5AkOrJUnkZjcvn%2B2FpU-Yg%40mail.gmail.com?utm_medium=3D=
email&utm_source=3Dfooter>
>>> .
>>>
>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/h_UoZuTPhZw=
/unsubscribe
>> .
>> To unsubscribe from this group and all its topics, 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/CAJnLdObnqP=
Ru8c%2Bg6WxQvq4t4navAy-%2BfH%2B1hSN4SEzPMMbxYw%40mail.gmail.com
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdObnq=
PRu8c%2Bg6WxQvq4t4navAy-%2BfH%2B1hSN4SEzPMMbxYw%40mail.gmail.com?utm_medium=
=3Demail&utm_source=3Dfooter>
>> .
>>
> --
> 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/CAJEMUN9j7FE=
gCWN5EUb7zcK3f11sLR%3DBvo%2B8oyBrBGyQ%2BSGbKA%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJEMUN9j7F=
EgCWN5EUb7zcK3f11sLR%3DBvo%2B8oyBrBGyQ%2BSGbKA%40mail.gmail.com?utm_medium=
=3Demail&utm_source=3Dfooter>
> .
>

--=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/CAMD6iD8kSbzUSwtSyH78kv601tdPHH7pQbuzZ6AZ2WOH3Td=
3hQ%40mail.gmail.com.

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

<div dir=3D"ltr">Isn&#39;t that why we have the=C2=A0TriviallyCopyable conc=
ept?</div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Fri,=
 Jul 29, 2016 at 12:35 PM, Demi Obenour <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:demiobenour@gmail.com" target=3D"_blank">demiobenour@gmail.com</a>&gt;=
</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir=3D"ltr">The bigger =
issue is a copying GC.=C2=A0 You really don&#39;t want to call move and/or =
copy constructors.=C2=A0 Much easier if you can restrict yourself the types=
 that can be blitted with memcpy.=C2=A0 This almost certainly runs afoul of=
 object lifetime rules, but is required if you want good performance.</p>
<div class=3D"gmail_extra"><br><div class=3D"gmail_quote"><span class=3D"">=
On Jul 29, 2016 04:28, &quot;&#39;Edward Catmur&#39; via ISO C++ Standard -=
 Future Proposals&quot; &lt;<a href=3D"mailto:std-proposals@isocpp.org" tar=
get=3D"_blank">std-proposals@isocpp.org</a>&gt; wrote:<br type=3D"attributi=
on"></span><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><span class=3D""><div dir=3D"ltr"=
><div class=3D"gmail_extra"><div class=3D"gmail_quote">On Fri, Jul 29, 2016=
 at 8:44 AM, Demi Obenour <span dir=3D"ltr">&lt;<a href=3D"mailto:demiobeno=
ur@gmail.com" target=3D"_blank">demiobenour@gmail.com</a>&gt;</span> wrote:=
<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><p dir=3D"ltr">Because that would requir=
e way too much use of memcpy.=C2=A0 The code would be completely unreadable=
..</p></blockquote><div>So write a wrapper function. What&#39;s more readabl=
e, read_memory_as&lt;void*&gt;(p) or *reinterpret_cast&lt;void**&gt;(p) // =
I hope the optimizer doesn&#39;t notice that this is illegal?</div><div><br=
></div><div>And in how many source locations does a mark-and-sweep GC read =
the memory it is scanning, anyway?</div><div><br></div><blockquote class=3D=
"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding=
-left:1ex"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On Jul 28,=
 2016 6:48 PM, &quot;Edward Catmur&quot; &lt;<a href=3D"mailto:ed@catmur.co=
..uk" target=3D"_blank">ed@catmur.co.uk</a>&gt; wrote:<br type=3D"attributio=
n"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Thursday, 28 July 201=
6 02:35:02 UTC+1, Demi Obenour  wrote:<blockquote class=3D"gmail_quote" sty=
le=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1e=
x"><p dir=3D"ltr">My personal view is that if a memory access points to mem=
ory that has not been deallocated, and to a valid bit-pattern for the type =
of the access, and there are no data races, the access should be well-defin=
ed.</p>
<p dir=3D"ltr">Without this, I cannot see how to reasonably implement a gar=
bage collector that works with heterogeneous objects that it cannot just tr=
eat as opaque bytes (because it needs to follow pointers and possibly invok=
e tracing methods).=C2=A0 In the case, the actual type of the object is oft=
en unknown, and may not even exist at compile time =E2=80=94 the GC uses me=
tadata to process the object based on its layout at runtime.</p></blockquot=
e><div><br></div><div>At the risk of sounding like a broken record, why not=
 memcpy?=C2=A0</div></div></blockquote></div></div><span><font color=3D"#88=
8888">

<p></p>

-- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/h_UoZuTPhZw/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/h_UoZuTPhZw=
/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAJEMUN9LGPuLJXMFoE5qsO7Pmjxf5AkOrJUn=
kZjcvn%2B2FpU-Yg%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-pro=
posals/CAJEMUN9LGPuLJXMFoE5qsO7Pmjxf5AkOrJUnkZjcvn%2B2FpU-Yg%40mail.gmail.c=
om</a>.<br>
</font></span></blockquote></div><br></div></div>

<p></p>

-- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/h_UoZuTPhZw/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/h_UoZuTPhZw=
/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAJnLdObnqPRu8c%2Bg6WxQvq4t4navAy-%2B=
fH%2B1hSN4SEzPMMbxYw%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Df=
ooter" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std=
-proposals/CAJnLdObnqPRu8c%2Bg6WxQvq4t4navAy-%2BfH%2B1hSN4SEzPMMbxYw%40mail=
..gmail.com</a>.<br>
</blockquote></div></div><span class=3D"">

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAJEMUN9j7FEgCWN5EUb7zcK3f11sLR%3DBvo=
%2B8oyBrBGyQ%2BSGbKA%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Df=
ooter" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std=
-proposals/CAJEMUN9j7FEgCWN5EUb7zcK3f11sLR%3DBvo%2B8oyBrBGyQ%2BSGbKA%40mail=
..gmail.com</a>.<br>
</blockquote></div><br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAMD6iD8kSbzUSwtSyH78kv601tdPHH7pQbuz=
Z6AZ2WOH3Td3hQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAMD6iD8kSbzUSwtS=
yH78kv601tdPHH7pQbuzZ6AZ2WOH3Td3hQ%40mail.gmail.com</a>.<br />

--001a11c017d4495ad30538c8dfc6--

.

On sexta-feira, 29 de julho de 2016 12:37:53 PDT Ren Industries wrote:
> Isn't that why we have the TriviallyCopyable concept?

No, it's the Relocatable concept and the destructive move, which we've
discussed over and over again but as far as I can tell, there's no actual
proposal of.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--
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/8123209.S67B1QvQPq%40tjmaciei-mobl1.

.

------=_Part_234_240429706.1469815103211
Content-Type: multipart/alternative;
 boundary="----=_Part_235_1155463232.1469815103212"

------=_Part_235_1155463232.1469815103212
Content-Type: text/plain; charset=UTF-8

On Friday, July 29, 2016 at 1:43:50 PM UTC-4, Thiago Macieira wrote:
>
> On sexta-feira, 29 de julho de 2016 12:37:53 PDT Ren Industries wrote:
> > Isn't that why we have the TriviallyCopyable concept?
>
> No, it's the Relocatable concept and the destructive move, which we've
> discussed over and over again but as far as I can tell, there's no actual
> proposal of.
>

You mean besides P0023. And N4158 and N4034?

--
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/b339ac2a-c18b-448e-8071-6c6700832f10%40isocpp.org.

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

<div dir=3D"ltr">On Friday, July 29, 2016 at 1:43:50 PM UTC-4, Thiago Macie=
ira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On sexta-feira, 29 d=
e julho de 2016 12:37:53 PDT Ren Industries wrote:
<br>&gt; Isn&#39;t that why we have the TriviallyCopyable concept?
<br>
<br>No, it&#39;s the Relocatable concept and the destructive move, which we=
&#39;ve=20
<br>discussed over and over again but as far as I can tell, there&#39;s no =
actual=20
<br>proposal of.
<br></blockquote><div><br>You mean besides P0023. And N4158 and N4034?</div=
><br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/b339ac2a-c18b-448e-8071-6c6700832f10%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b339ac2a-c18b-448e-8071-6c6700832f10=
%40isocpp.org</a>.<br />

------=_Part_235_1155463232.1469815103212--

------=_Part_234_240429706.1469815103211--

.

On sexta-feira, 29 de julho de 2016 10:58:23 PDT Nicol Bolas wrote:
> On Friday, July 29, 2016 at 1:43:50 PM UTC-4, Thiago Macieira wrote:
> > On sexta-feira, 29 de julho de 2016 12:37:53 PDT Ren Industries wrote:
> > > Isn't that why we have the TriviallyCopyable concept?
> >
> > No, it's the Relocatable concept and the destructive move, which we've
> > discussed over and over again but as far as I can tell, there's no actual
> > proposal of.
>
> You mean besides P0023. And N4158 and N4034?

I stand corrected. Reading now, thanks for the info.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--
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/5029731.Ryigq7WfGY%40tjmaciei-mobl1.

.

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

I think the bigger question is "Why should one need to go through all those
hoops to do something as simple as reading/writing memory?".

I think that there should be an easier way.  Nobody, to my knowledge,
creates a helper function like was described.  Much easier to use a (quite
common) compiler switch than to change your code.  This proposal provides a
standard way to do what many/most C++ compilers already provide as an
opt-in extension.

On Jul 29, 2016 2:02 PM, "Thiago Macieira" <thiago@macieira.org> wrote:

> On sexta-feira, 29 de julho de 2016 10:58:23 PDT Nicol Bolas wrote:
> > On Friday, July 29, 2016 at 1:43:50 PM UTC-4, Thiago Macieira wrote:
> > > On sexta-feira, 29 de julho de 2016 12:37:53 PDT Ren Industries wrote:
> > > > Isn't that why we have the TriviallyCopyable concept?
> > >
> > > No, it's the Relocatable concept and the destructive move, which we've
> > > discussed over and over again but as far as I can tell, there's no
> actual
> > > proposal of.
> >
> > You mean besides P0023. And N4158 and N4034?
>
> I stand corrected. Reading now, thanks for the info.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>    Software Architect - Intel Open Source Technology Center
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/h_UoZuTPhZw/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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/5029731.Ryigq7WfGY%40tjmaciei-mobl1
> .
>

--
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/CAJEMUN9i7kKoi7cCogCir%2B9fuc2NR0kvQ9zW7%2BDonac3sJ6qfw%40mail.gmail.com.

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

<p dir=3D"ltr">I think the bigger question is &quot;Why should one need to =
go through all those hoops to do something as simple as reading/writing mem=
ory?&quot;.</p>
<p dir=3D"ltr">I think that there should be an easier way.=C2=A0 Nobody, to=
 my knowledge, creates a helper function like was described.=C2=A0 Much eas=
ier to use a (quite common) compiler switch than to change your code.=C2=A0=
 This proposal provides a standard way to do what many/most C++ compilers a=
lready provide as an opt-in extension.</p>
<div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Jul 29, 2016 2=
:02 PM, &quot;Thiago Macieira&quot; &lt;<a href=3D"mailto:thiago@macieira.o=
rg" target=3D"_blank">thiago@macieira.org</a>&gt; wrote:<br type=3D"attribu=
tion"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex">On sexta-feira, 29 de julho de 2016 10=
:58:23 PDT Nicol Bolas wrote:<br>
&gt; On Friday, July 29, 2016 at 1:43:50 PM UTC-4, Thiago Macieira wrote:<b=
r>
&gt; &gt; On sexta-feira, 29 de julho de 2016 12:37:53 PDT Ren Industries w=
rote:<br>
&gt; &gt; &gt; Isn&#39;t that why we have the TriviallyCopyable concept?<br=
>
&gt; &gt;<br>
&gt; &gt; No, it&#39;s the Relocatable concept and the destructive move, wh=
ich we&#39;ve<br>
&gt; &gt; discussed over and over again but as far as I can tell, there&#39=
;s no actual<br>
&gt; &gt; proposal of.<br>
&gt;<br>
&gt; You mean besides P0023. And N4158 and N4034?<br>
<br>
I stand corrected. Reading now, thanks for the info.<br>
<br>
--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"noref=
errer" target=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://=
kde.org" rel=3D"noreferrer" target=3D"_blank">kde.org</a><br>
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<br>
<br>
--<br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/h_UoZuTPhZw/unsubscribe" rel=3D"noreferr=
er" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/topic/std-pr=
oposals/h_UoZuTPhZw/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-proposals+unsubscrib=
e@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/5029731.Ryigq7WfGY%40tjmaciei-mobl1" =
rel=3D"noreferrer" target=3D"_blank">https://groups.google.com/a/isocpp.org=
/d/msgid/std-proposals/5029731.Ryigq7WfGY%40tjmaciei-mobl1</a>.<br>
</blockquote></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAJEMUN9i7kKoi7cCogCir%2B9fuc2NR0kvQ9=
zW7%2BDonac3sJ6qfw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJEMUN9i7kKo=
i7cCogCir%2B9fuc2NR0kvQ9zW7%2BDonac3sJ6qfw%40mail.gmail.com</a>.<br />

--001a113bcc7e114b4a0538cfe24d--

.

On sexta-feira, 29 de julho de 2016 20:59:45 PDT Demi Obenour wrote:
> I think the bigger question is "Why should one need to go through all those
> hoops to do something as simple as reading/writing memory?".

DTRT (Do The Right Thing).

> I think that there should be an easier way.  Nobody, to my knowledge,
> creates a helper function like was described.

We do, if we want to write portable code today. For example, the code I
recently wrote for endianness conversion and reading from unaligned memory
(file and socket buffers) is all based around memcpy.

It may look superfluous and ugly to you, but a line like this:

 qint64 x = qFromBigEndian<qint64>(buffer);

does the endianness swap and unaligned read in a single assembly instruction
(on Haswell processors). In the end, the code is more readable because I know
that the source was big endian.

> Much easier to use a (quite
> common) compiler switch than to change your code.  This proposal provides a
> standard way to do what many/most C++ compilers already provide as an
> opt-in extension.

Using a compiler switch today is not an option for header code.

The pragmas are also not an option for macro code. You and I probably think
that they're poor practice and shouldn't be used, but others may disagree.

Finally, there's the issue that pragmas in template code increase the
complexity for the compiler, since it needs to remember the pragma state for
when it instantiates the template.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--
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/4107654.06zVy5tXzj%40tjmaciei-mobl1.

.

--94eb2c14c53ac96b290538e8c8f6
Content-Type: text/plain; charset=UTF-8

Yes, it may be required, but who actually does it?  I suspect that this
proposal will mostly make code strictly confirming that currently relies on
non-standard switches.

On Jul 29, 2016 10:31 PM, "Thiago Macieira" <thiago@macieira.org> wrote:

> On sexta-feira, 29 de julho de 2016 20:59:45 PDT Demi Obenour wrote:
> > I think the bigger question is "Why should one need to go through all
> those
> > hoops to do something as simple as reading/writing memory?".
>
> DTRT (Do The Right Thing).
>
> > I think that there should be an easier way.  Nobody, to my knowledge,
> > creates a helper function like was described.
>
> We do, if we want to write portable code today. For example, the code I
> recently wrote for endianness conversion and reading from unaligned memory
> (file and socket buffers) is all based around memcpy.
>
> It may look superfluous and ugly to you, but a line like this:
>
>         qint64 x = qFromBigEndian<qint64>(buffer);
>
> does the endianness swap and unaligned read in a single assembly
> instruction
> (on Haswell processors). In the end, the code is more readable because I
> know
> that the source was big endian.
>
> > Much easier to use a (quite
> > common) compiler switch than to change your code.  This proposal
> provides a
> > standard way to do what many/most C++ compilers already provide as an
> > opt-in extension.
>
> Using a compiler switch today is not an option for header code.
>
> The pragmas are also not an option for macro code. You and I probably think
> that they're poor practice and shouldn't be used, but others may disagree.
>
> Finally, there's the issue that pragmas in template code increase the
> complexity for the compiler, since it needs to remember the pragma state
> for
> when it instantiates the template.
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>    Software Architect - Intel Open Source Technology Center
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/h_UoZuTPhZw/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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/4107654.06zVy5tXzj%40tjmaciei-mobl1
> .
>

--
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/CAJEMUN-z6SngOLv_2fPhBiC9-Bor8_nG%2BDE111UepghbSPH1SA%40mail.gmail.com.

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

<p dir=3D"ltr">Yes, it may be required, but who actually does it?=C2=A0 I s=
uspect that this proposal will mostly make code strictly confirming that cu=
rrently relies on non-standard switches.</p>
<div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Jul 29, 2016 1=
0:31 PM, &quot;Thiago Macieira&quot; &lt;<a href=3D"mailto:thiago@macieira.=
org">thiago@macieira.org</a>&gt; wrote:<br type=3D"attribution"><blockquote=
 class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex">On sexta-feira, 29 de julho de 2016 20:59:45 PDT Demi O=
benour wrote:<br>
&gt; I think the bigger question is &quot;Why should one need to go through=
 all those<br>
&gt; hoops to do something as simple as reading/writing memory?&quot;.<br>
<br>
DTRT (Do The Right Thing).<br>
<br>
&gt; I think that there should be an easier way.=C2=A0 Nobody, to my knowle=
dge,<br>
&gt; creates a helper function like was described.<br>
<br>
We do, if we want to write portable code today. For example, the code I<br>
recently wrote for endianness conversion and reading from unaligned memory<=
br>
(file and socket buffers) is all based around memcpy.<br>
<br>
It may look superfluous and ugly to you, but a line like this:<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 qint64 x =3D qFromBigEndian&lt;qint64&gt;(buffe=
r);<br>
<br>
does the endianness swap and unaligned read in a single assembly instructio=
n<br>
(on Haswell processors). In the end, the code is more readable because I kn=
ow<br>
that the source was big endian.<br>
<br>
&gt; Much easier to use a (quite<br>
&gt; common) compiler switch than to change your code.=C2=A0 This proposal =
provides a<br>
&gt; standard way to do what many/most C++ compilers already provide as an<=
br>
&gt; opt-in extension.<br>
<br>
Using a compiler switch today is not an option for header code.<br>
<br>
The pragmas are also not an option for macro code. You and I probably think=
<br>
that they&#39;re poor practice and shouldn&#39;t be used, but others may di=
sagree.<br>
<br>
Finally, there&#39;s the issue that pragmas in template code increase the<b=
r>
complexity for the compiler, since it needs to remember the pragma state fo=
r<br>
when it instantiates the template.<br>
--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"noref=
errer" target=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://=
kde.org" rel=3D"noreferrer" target=3D"_blank">kde.org</a><br>
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<br>
<br>
--<br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/h_UoZuTPhZw/unsubscribe" rel=3D"noreferr=
er" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/topic/std-pr=
oposals/h_UoZuTPhZw/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-proposals+unsubscrib=
e@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/4107654.06zVy5tXzj%40tjmaciei-mobl1" =
rel=3D"noreferrer" target=3D"_blank">https://groups.google.com/a/isocpp.org=
/d/msgid/std-proposals/4107654.06zVy5tXzj%40tjmaciei-mobl1</a>.<br>
</blockquote></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAJEMUN-z6SngOLv_2fPhBiC9-Bor8_nG%2BD=
E111UepghbSPH1SA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJEMUN-z6SngOL=
v_2fPhBiC9-Bor8_nG%2BDE111UepghbSPH1SA%40mail.gmail.com</a>.<br />

--94eb2c14c53ac96b290538e8c8f6--

.

On domingo, 31 de julho de 2016 02:42:15 PDT Demi Obenour wrote:
> Yes, it may be required, but who actually does it?  I suspect that this
> proposal will mostly make code strictly confirming that currently relies on
> non-standard switches.

Like I said, I do.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--
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/1731097.Sz2DCISvSn%40tjmaciei-mobl1.

.

--94eb2c14c53a6d1c500538e9fa5d
Content-Type: text/plain; charset=UTF-8

Do you know of anyone else?  Any open source code?

On Jul 31, 2016 03:15, "Thiago Macieira" <thiago@macieira.org> wrote:

> On domingo, 31 de julho de 2016 02:42:15 PDT Demi Obenour wrote:
> > Yes, it may be required, but who actually does it?  I suspect that this
> > proposal will mostly make code strictly confirming that currently relies
> on
> > non-standard switches.
>
> Like I said, I do.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>    Software Architect - Intel Open Source Technology Center
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/h_UoZuTPhZw/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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/1731097.Sz2DCISvSn%40tjmaciei-mobl1
> .
>

--
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/CAJEMUN8G%2B0OHHE88_ysz%2BQx7OL-d-f-K%2BWNL%2B5HkBC3F1WButw%40mail.gmail.com.

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

<p dir=3D"ltr">Do you know of anyone else?=C2=A0 Any open source code?</p>
<div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Jul 31, 2016 0=
3:15, &quot;Thiago Macieira&quot; &lt;<a href=3D"mailto:thiago@macieira.org=
">thiago@macieira.org</a>&gt; wrote:<br type=3D"attribution"><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex">On domingo, 31 de julho de 2016 02:42:15 PDT Demi Obenour =
wrote:<br>
&gt; Yes, it may be required, but who actually does it?=C2=A0 I suspect tha=
t this<br>
&gt; proposal will mostly make code strictly confirming that currently reli=
es on<br>
&gt; non-standard switches.<br>
<br>
Like I said, I do.<br>
<br>
--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"noref=
errer" target=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://=
kde.org" rel=3D"noreferrer" target=3D"_blank">kde.org</a><br>
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<br>
<br>
--<br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/h_UoZuTPhZw/unsubscribe" rel=3D"noreferr=
er" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/topic/std-pr=
oposals/h_UoZuTPhZw/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-proposals+unsubscrib=
e@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/1731097.Sz2DCISvSn%40tjmaciei-mobl1" =
rel=3D"noreferrer" target=3D"_blank">https://groups.google.com/a/isocpp.org=
/d/msgid/std-proposals/1731097.Sz2DCISvSn%40tjmaciei-mobl1</a>.<br>
</blockquote></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAJEMUN8G%2B0OHHE88_ysz%2BQx7OL-d-f-K=
%2BWNL%2B5HkBC3F1WButw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJEMUN8G=
%2B0OHHE88_ysz%2BQx7OL-d-f-K%2BWNL%2B5HkBC3F1WButw%40mail.gmail.com</a>.<br=
 />

--94eb2c14c53a6d1c500538e9fa5d--

.

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

On 31 Jul 2016 9:07 a.m., "Demi Obenour" <demiobenour@gmail.com> wrote:
>
> Do you know of anyone else?  Any open source code?

Most of the boost code I've seen is correct. Do you want specific examples?

>
> On Jul 31, 2016 03:15, "Thiago Macieira" <thiago@macieira.org> wrote:
>>
>> On domingo, 31 de julho de 2016 02:42:15 PDT Demi Obenour wrote:
>> > Yes, it may be required, but who actually does it?  I suspect that this
>> > proposal will mostly make code strictly confirming that currently
relies on
>> > non-standard switches.
>>
>> Like I said, I do.
>>
>> --
>> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>>    Software Architect - Intel Open Source Technology Center
>>
>> --
>> You received this message because you are subscribed to a topic in the
Google Groups "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this topic, visit
https://groups.google.com/a/isocpp.org/d/topic/std-proposals/h_UoZuTPhZw/unsubscribe
..
>> To unsubscribe from this group and all its topics, 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/1731097.Sz2DCISvSn%40tjmaciei-mobl1
..
>
> --
> You received this message because you are subscribed to a topic in the
Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
https://groups.google.com/a/isocpp.org/d/topic/std-proposals/h_UoZuTPhZw/unsubscribe
..
> To unsubscribe from this group and all its topics, 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/CAJEMUN8G%2B0OHHE88_ysz%2BQx7OL-d-f-K%2BWNL%2B5HkBC3F1WButw%40mail.gmail.com
..

--
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/CAJnLdOZxA-QKv2Eg6izbOopouzQJBRaG9mur6H_xJ81058teDg%40mail.gmail.com.

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

<p dir=3D"ltr">On 31 Jul 2016 9:07 a.m., &quot;Demi Obenour&quot; &lt;<a hr=
ef=3D"mailto:demiobenour@gmail.com">demiobenour@gmail.com</a>&gt; wrote:<br=
>
&gt;<br>
&gt; Do you know of anyone else?=C2=A0 Any open source code?</p>
<p dir=3D"ltr">Most of the boost code I&#39;ve seen is correct. Do you want=
 specific examples? </p>
<p dir=3D"ltr">&gt;<br>
&gt; On Jul 31, 2016 03:15, &quot;Thiago Macieira&quot; &lt;<a href=3D"mail=
to:thiago@macieira.org">thiago@macieira.org</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; On domingo, 31 de julho de 2016 02:42:15 PDT Demi Obenour wrote:<b=
r>
&gt;&gt; &gt; Yes, it may be required, but who actually does it?=C2=A0 I su=
spect that this<br>
&gt;&gt; &gt; proposal will mostly make code strictly confirming that curre=
ntly relies on<br>
&gt;&gt; &gt; non-standard switches.<br>
&gt;&gt;<br>
&gt;&gt; Like I said, I do.<br>
&gt;&gt;<br>
&gt;&gt; --<br>
&gt;&gt; Thiago Macieira - thiago (AT)<a href=3D"http://macieira.info"> mac=
ieira.info</a> - thiago (AT)<a href=3D"http://kde.org"> kde.org</a><br>
&gt;&gt; =C2=A0 =C2=A0Software Architect - Intel Open Source Technology Cen=
ter<br>
&gt;&gt;<br>
&gt;&gt; --<br>
&gt;&gt; You received this message because you are subscribed to a topic in=
 the Google Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<b=
r>
&gt;&gt; To unsubscribe from this topic, visit<a href=3D"https://groups.goo=
gle.com/a/isocpp.org/d/topic/std-proposals/h_UoZuTPhZw/unsubscribe"> https:=
//groups.google.com/a/isocpp.org/d/topic/std-proposals/h_UoZuTPhZw/unsubscr=
ibe</a>.<br>
&gt;&gt; To unsubscribe from this group and all its topics, send an email t=
o<a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org"> std-proposals+u=
nsubscribe@isocpp.org</a>.<br>
&gt;&gt; To post to this group, send email to<a href=3D"mailto:std-proposal=
s@isocpp.org"> std-proposals@isocpp.org</a>.<br>
&gt;&gt; To view this discussion on the web visit<a href=3D"https://groups.=
google.com/a/isocpp.org/d/msgid/std-proposals/1731097.Sz2DCISvSn%40tjmaciei=
-mobl1"> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/17310=
97.Sz2DCISvSn%40tjmaciei-mobl1</a>.<br>
&gt;<br>
&gt; -- <br>
&gt; You received this message because you are subscribed to a topic in the=
 Google Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
&gt; To unsubscribe from this topic, visit<a href=3D"https://groups.google.=
com/a/isocpp.org/d/topic/std-proposals/h_UoZuTPhZw/unsubscribe"> https://gr=
oups.google.com/a/isocpp.org/d/topic/std-proposals/h_UoZuTPhZw/unsubscribe<=
/a>.<br>
&gt; To unsubscribe from this group and all its topics, send an email to<a =
href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org"> std-proposals+unsub=
scribe@isocpp.org</a>.<br>
&gt; To post to this group, send email to<a href=3D"mailto:std-proposals@is=
ocpp.org"> std-proposals@isocpp.org</a>.<br>
&gt; To view this discussion on the web visit<a href=3D"https://groups.goog=
le.com/a/isocpp.org/d/msgid/std-proposals/CAJEMUN8G%2B0OHHE88_ysz%2BQx7OL-d=
-f-K%2BWNL%2B5HkBC3F1WButw%40mail.gmail.com"> https://groups.google.com/a/i=
socpp.org/d/msgid/std-proposals/CAJEMUN8G%2B0OHHE88_ysz%2BQx7OL-d-f-K%2BWNL=
%2B5HkBC3F1WButw%40mail.gmail.com</a>.<br>
</p>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAJnLdOZxA-QKv2Eg6izbOopouzQJBRaG9mur=
6H_xJ81058teDg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOZxA-QKv2Eg=
6izbOopouzQJBRaG9mur6H_xJ81058teDg%40mail.gmail.com</a>.<br />

--001a114757865117690538ea4b03--

.

On domingo, 31 de julho de 2016 04:07:42 PDT Demi Obenour wrote:
> Do you know of anyone else?  Any open source code?

My code is open source.

http://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--
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/7324484.bgNmfJ8lF4%40tjmaciei-mobl1.

.