Topic: Specify implementation of reference member within union
Author: Antonio Perez <antonio@perezexcelsior.com>
Date: Mon, 1 Aug 2016 13:38:57 -0700 (PDT)
Raw View
------=_Part_5587_1488639494.1470083937444
Content-Type: multipart/alternative;
boundary="----=_Part_5588_852870582.1470083937445"
------=_Part_5588_852870582.1470083937445
Content-Type: text/plain; charset=UTF-8
Specify that
1. Unions may store references
2. A reference stored inside a union must be implemented as a pointer
3. If a union contains a pointer T* and a reference T&, then setting the
location of the pointer, and then reading from the reference, is DEFINED
BEHAVIOR which will read the value stored at the pointer
template<typename T> union PtrOrRef
{
T* ptr;
T& ref;
};
#include <iostream>
int main(){
int x = 0;
PtrOrRef<int> p{x};//Sets p.ref=x
int y = 5;
p.ptr = &y;
std::cout << p.ref << std::endl; //Defined as being equivalent to std::cout
<< (*p.ptr) << std::endl;
}
Example implementation: g++ compiler
--
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/624601ee-1336-4a9b-8830-81d7b77268e9%40isocpp.org.
------=_Part_5588_852870582.1470083937445
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Specify that<br><ol><li>Unions may store references</li><l=
i>A reference stored inside a union must be implemented as a pointer</li><l=
i>If a union contains a pointer T* and a reference T&, then setting the=
location of the pointer, and then reading from the reference, is DEFINED B=
EHAVIOR which will read the value stored at the pointer<br></li></ol><div c=
lass=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border-=
color: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wra=
p: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><=
span style=3D"color: #008;" class=3D"styled-by-prettify">template</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify"><</span><span sty=
le=3D"color: #008;" class=3D"styled-by-prettify">typename</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> T</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">></span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">union</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-=
prettify">PtrOrRef</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> <br></span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></=
span><div style=3D"margin-left: 40px;"><span style=3D"color: #000;" class=
=3D"styled-by-prettify">T</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">*</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> ptr</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>T</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">&</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">ref</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"><br></span></div><span style=3D"color: #660;=
" class=3D"styled-by-prettify">};</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span><span style=3D"color: #800;" class=3D"st=
yled-by-prettify">#include</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: #080;" class=3D"styled-by-pre=
ttify"><iostream></span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-pre=
ttify">int</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
main</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(){</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><=
div style=3D"margin-left: 40px;"><span style=3D"color: #008;" class=3D"styl=
ed-by-prettify">int</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> x </span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span style=3D"color: #066;" class=3D"styled-by-prettify">0</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"><br></span></div><div style=3D"m=
argin-left: 40px;"><span style=3D"color: #606;" class=3D"styled-by-prettify=
">PtrOrRef</span><span style=3D"color: #080;" class=3D"styled-by-prettify">=
<int></span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> p</span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify">x</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">};</span><span style=3D"c=
olor: #800;" class=3D"styled-by-prettify">//Sets p.ref=3Dx</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"c=
olor: #008;" class=3D"styled-by-prettify">int</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> y </span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> </span><span style=3D"color: #066;" class=3D"styled-b=
y-prettify">5</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>p<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">.</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify">ptr </span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">&</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify">y</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"><br>std</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">c=
out </span><span style=3D"color: #660;" class=3D"styled-by-prettify"><&l=
t;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> p</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">.</span><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">ref</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify"><<</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> std</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify">endl</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #800;" class=3D"styled-by-prettify">//Defi=
ned as being equivalent to std::cout << (*p.ptr) << std::endl;<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span>=
</div><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div></c=
ode></div><br>Example implementation: g++ compiler<br><br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/624601ee-1336-4a9b-8830-81d7b77268e9%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/624601ee-1336-4a9b-8830-81d7b77268e9=
%40isocpp.org</a>.<br />
------=_Part_5588_852870582.1470083937445--
------=_Part_5587_1488639494.1470083937444--
.
Author: "D. B." <db0451@gmail.com>
Date: Mon, 1 Aug 2016 21:41:28 +0100
Raw View
--001a114b703ae854600539089fea
Content-Type: text/plain; charset=UTF-8
Why the duplicate? Perhaps related, I love how you've not bothered to
address any of the objections in your other thread, as to why this
* cannot fit in the Standard due to countless other rules
* is horrible undefined behaviour due to type-punning through a union
* is needed at all, given that std::reference_wrapper exists, without being
disgraceful UB like this example you keep spamming.
Are you just going to post a new thread every time you start getting
scrutiny, and hope no one notices all the abysmal flaws this time around? I
doubt that'll work.
--
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/CACGiwhFZeXNAM%3DJuQFE8j8qFe2LNXLkAHi5Pu_A9J1nYqZh_uA%40mail.gmail.com.
--001a114b703ae854600539089fea
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div><div><div>Why the duplicate? Perhaps related, I =
love how you've not bothered to address any of the objections in your o=
ther thread, as to why this<br></div>* cannot fit in the Standard due to co=
untless other rules<br></div>* is horrible undefined behaviour due to type-=
punning through a union<br></div>* is needed at all, given that std::refere=
nce_wrapper exists, without being disgraceful UB like this example you keep=
spamming.<br><br></div>Are you just going to post a new thread every time =
you start getting scrutiny, and hope no one notices all the abysmal flaws t=
his time around? I doubt that'll work.<br><br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CACGiwhFZeXNAM%3DJuQFE8j8qFe2LNXLkAHi=
5Pu_A9J1nYqZh_uA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhFZeXNAM%=
3DJuQFE8j8qFe2LNXLkAHi5Pu_A9J1nYqZh_uA%40mail.gmail.com</a>.<br />
--001a114b703ae854600539089fea--
.
Author: Antonio Perez <antonio@perezexcelsior.com>
Date: Mon, 1 Aug 2016 13:48:00 -0700 (PDT)
Raw View
------=_Part_5270_597390957.1470084480802
Content-Type: multipart/alternative;
boundary="----=_Part_5271_1550466754.1470084480802"
------=_Part_5271_1550466754.1470084480802
Content-Type: text/plain; charset=UTF-8
A few notes:
- Will NOT change the behavior of any currently written code
- Works independent of system being big or little-endian
- Preserves a reference as a way to alias values
- Is NOT type punning since the proposed change specifies that
references used as members of unions are implemented as pointers of the
type they references; hence, the reference is simply an alias for the value
at the location pointed to by the pointer stored in the union.
On Monday, August 1, 2016 at 2:38:57 PM UTC-6, Antonio Perez wrote:
>
> Specify that
>
> 1. Unions may store references
> 2. A reference stored inside a union must be implemented as a pointer
> 3. If a union contains a pointer T* and a reference T&, then setting
> the location of the pointer, and then reading from the reference, is
> DEFINED BEHAVIOR which will read the value stored at the pointer
>
> template<typename T> union PtrOrRef
> {
> T* ptr;
> T& ref;
> };
> #include <iostream>
> int main(){
> int x = 0;
> PtrOrRef<int> p{x};//Sets p.ref=x
> int y = 5;
> p.ptr = &y;
> std::cout << p.ref << std::endl; //Defined as being equivalent to
> std::cout << (*p.ptr) << std::endl;
> }
>
> Example implementation: g++ compiler
>
>
--
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/ff93ce09-93b2-49a2-afd0-656684b93ebe%40isocpp.org.
------=_Part_5271_1550466754.1470084480802
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">A few notes:<br><ul><li>Will NOT change the behavior of an=
y currently written code</li><li>Works independent of system being big or l=
ittle-endian</li><li>Preserves a reference as a way to alias values</li><li=
>Is NOT type punning since the proposed change specifies that references us=
ed as members of unions are implemented as pointers of the type they refere=
nces; hence, the reference is simply an alias for the value at the location=
pointed to by the pointer stored in the union. <br></li></ul><br>On Monday=
, August 1, 2016 at 2:38:57 PM UTC-6, Antonio Perez wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"ltr">Specify that<br><ol><li>Unions=
may store references</li><li>A reference stored inside a union must be imp=
lemented as a pointer</li><li>If a union contains a pointer T* and a refere=
nce T&, then setting the location of the pointer, and then reading from=
the reference, is DEFINED BEHAVIOR which will read the value stored at the=
pointer<br></li></ol><div style=3D"background-color:rgb(250,250,250);borde=
r-color:rgb(187,187,187);border-style:solid;border-width:1px;word-wrap:brea=
k-word"><code><div><span style=3D"color:#008">template</span><span style=3D=
"color:#660"><</span><span style=3D"color:#008">typename</span><span sty=
le=3D"color:#000"> T</span><span style=3D"color:#660">></span><span styl=
e=3D"color:#000"> </span><span style=3D"color:#008">union</span><span style=
=3D"color:#000"> </span><span style=3D"color:#606">PtrOrRef</span><span sty=
le=3D"color:#000"> <br></span><span style=3D"color:#660">{</span><span styl=
e=3D"color:#000"><br></span><div style=3D"margin-left:40px"><span style=3D"=
color:#000">T</span><span style=3D"color:#660">*</span><span style=3D"color=
:#000"> ptr</span><span style=3D"color:#660">;</span><span style=3D"color:#=
000"><br>T</span><span style=3D"color:#660">&</span><span style=3D"colo=
r:#000"> </span><span style=3D"color:#008">ref</span><span style=3D"color:#=
660">;</span><span style=3D"color:#000"><br></span></div><span style=3D"col=
or:#660">};</span><span style=3D"color:#000"><br></span><span style=3D"colo=
r:#800">#include</span><span style=3D"color:#000"> </span><span style=3D"co=
lor:#080"><iostream></span><span style=3D"color:#000"><br></span><spa=
n style=3D"color:#008">int</span><span style=3D"color:#000"> main</span><sp=
an style=3D"color:#660">(){</span><span style=3D"color:#000"><br></span><di=
v style=3D"margin-left:40px"><span style=3D"color:#008">int</span><span sty=
le=3D"color:#000"> x </span><span style=3D"color:#660">=3D</span><span styl=
e=3D"color:#000"> </span><span style=3D"color:#066">0</span><span style=3D"=
color:#660">;</span><span style=3D"color:#000"><br></span></div><div style=
=3D"margin-left:40px"><span style=3D"color:#606">PtrOrRef</span><span style=
=3D"color:#080"><int></span><span style=3D"color:#000"> p</span><span=
style=3D"color:#660">{</span><span style=3D"color:#000">x</span><span styl=
e=3D"color:#660">};</span><span style=3D"color:#800">//Sets p.ref=3Dx</span=
><span style=3D"color:#000"><br></span><span style=3D"color:#008">int</span=
><span style=3D"color:#000"> y </span><span style=3D"color:#660">=3D</span>=
<span style=3D"color:#000"> </span><span style=3D"color:#066">5</span><span=
style=3D"color:#660">;</span><span style=3D"color:#000"><br>p</span><span =
style=3D"color:#660">.</span><span style=3D"color:#000">ptr </span><span st=
yle=3D"color:#660">=3D</span><span style=3D"color:#000"> </span><span style=
=3D"color:#660">&</span><span style=3D"color:#000">y</span><span style=
=3D"color:#660">;</span><span style=3D"color:#000"><br>std</span><span styl=
e=3D"color:#660">::</span><span style=3D"color:#000">cout </span><span styl=
e=3D"color:#660"><<</span><span style=3D"color:#000"> p</span><span s=
tyle=3D"color:#660">.</span><span style=3D"color:#008">ref</span><span styl=
e=3D"color:#000"> </span><span style=3D"color:#660"><<</span><span st=
yle=3D"color:#000"> std</span><span style=3D"color:#660">::</span><span sty=
le=3D"color:#000">endl</span><span style=3D"color:#660">;</span><span style=
=3D"color:#000"> </span><span style=3D"color:#800">//Defined as being equiv=
alent to std::cout << (*p.ptr) << std::endl;</span><span style=
=3D"color:#000"><br></span></div><span style=3D"color:#660">}</span><span s=
tyle=3D"color:#000"><br></span></div></code></div><br>Example implementatio=
n: g++ compiler<br><br></div></blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/ff93ce09-93b2-49a2-afd0-656684b93ebe%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ff93ce09-93b2-49a2-afd0-656684b93ebe=
%40isocpp.org</a>.<br />
------=_Part_5271_1550466754.1470084480802--
------=_Part_5270_597390957.1470084480802--
.
Author: Antonio Perez <antonio@perezexcelsior.com>
Date: Mon, 1 Aug 2016 13:55:08 -0700 (PDT)
Raw View
------=_Part_5541_473108789.1470084908475
Content-Type: multipart/alternative;
boundary="----=_Part_5542_306431914.1470084908475"
------=_Part_5542_306431914.1470084908475
Content-Type: text/plain; charset=UTF-8
I started a new thread because I felt the other obfuscated the proposed
change to the standard. More specific laws override more general laws, so
this addition would override those older rules in this specific instance.
It's NOT undefined behavior if the implementation of a reference within a
union is specified by the standard. I understand that the implementation of
a reference is not GENERALLY specified to allow for compiler optimization,
so instead I am proposing a specific instance in which it IS specified in
order to ensure defined behavior. Given that a reference is not currently
permitted within a union, it would not affect the compilation of any
current code that strictly adheres to the standard. Further, any code that
doesn't adhere to the standard, and DOES use unions in this manner, already
expects the behavior I hope to standardize (and thus, that code won't be
affected either).
On Monday, August 1, 2016 at 2:41:30 PM UTC-6, D. B. wrote:
>
> Why the duplicate? Perhaps related, I love how you've not bothered to
> address any of the objections in your other thread, as to why this
> * cannot fit in the Standard due to countless other rules
> * is horrible undefined behaviour due to type-punning through a union
> * is needed at all, given that std::reference_wrapper exists, without
> being disgraceful UB like this example you keep spamming.
>
> Are you just going to post a new thread every time you start getting
> scrutiny, and hope no one notices all the abysmal flaws this time around? I
> doubt that'll work.
>
>
--
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/623d9e03-ba01-49b5-8552-a7a32ee5ad4e%40isocpp.org.
------=_Part_5542_306431914.1470084908475
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I started a new thread because I felt the other obfuscated=
the proposed change to the standard. More specific laws override more gene=
ral laws, so this addition would override those older rules in this specifi=
c instance. It's NOT undefined behavior if the implementation of a refe=
rence within a union is specified by the standard. I understand that the im=
plementation of a reference is not GENERALLY specified to allow for compile=
r optimization, so instead I am proposing a specific instance in which it I=
S specified in order to ensure defined behavior. Given that a reference is =
not currently permitted within a union, it would not affect the compilation=
of any current code that strictly adheres to the standard. Further, any co=
de that doesn't adhere to the standard, and DOES use unions in this man=
ner, already expects the behavior I hope to standardize (and thus, that cod=
e won't be affected either). <br><br>On Monday, August 1, 2016 at 2:41:=
30 PM UTC-6, D. B. wrote:<blockquote class=3D"gmail_quote" style=3D"margin:=
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div =
dir=3D"ltr"><div><div><div><div>Why the duplicate? Perhaps related, I love =
how you've not bothered to address any of the objections in your other =
thread, as to why this<br></div>* cannot fit in the Standard due to countle=
ss other rules<br></div>* is horrible undefined behaviour due to type-punni=
ng through a union<br></div>* is needed at all, given that std::reference_w=
rapper exists, without being disgraceful UB like this example you keep spam=
ming.<br><br></div>Are you just going to post a new thread every time you s=
tart getting scrutiny, and hope no one notices all the abysmal flaws this t=
ime around? I doubt that'll work.<br><br></div>
</blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/623d9e03-ba01-49b5-8552-a7a32ee5ad4e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/623d9e03-ba01-49b5-8552-a7a32ee5ad4e=
%40isocpp.org</a>.<br />
------=_Part_5542_306431914.1470084908475--
------=_Part_5541_473108789.1470084908475--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Mon, 01 Aug 2016 16:43:36 -0700
Raw View
On segunda-feira, 1 de agosto de 2016 13:38:57 PDT Antonio Perez wrote:
> 1. Unions may store references
> 2. A reference stored inside a union must be implemented as a pointer
> 3. If a union contains a pointer T* and a reference T&, then setting the
> location of the pointer, and then reading from the reference, is DEFINED
> BEHAVIOR which will read the value stored at the pointer
This still violates the requirement that you can only read from the active
member of a union. If you last stored to a pointer in that union, then you
can't use the reference because it's not active.
--
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/3236233.USbj3oM4X3%40tjmaciei-mobl1.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 1 Aug 2016 17:04:07 -0700 (PDT)
Raw View
------=_Part_535_146231539.1470096247947
Content-Type: multipart/alternative;
boundary="----=_Part_536_1055515507.1470096247947"
------=_Part_536_1055515507.1470096247947
Content-Type: text/plain; charset=UTF-8
On Monday, August 1, 2016 at 7:43:39 PM UTC-4, Thiago Macieira wrote:
>
> On segunda-feira, 1 de agosto de 2016 13:38:57 PDT Antonio Perez wrote:
> > 1. Unions may store references
> > 2. A reference stored inside a union must be implemented as a pointer
> > 3. If a union contains a pointer T* and a reference T&, then setting
> the
> > location of the pointer, and then reading from the reference, is DEFINED
> > BEHAVIOR which will read the value stored at the pointer
>
> This still violates the requirement that you can only read from the active
> member of a union. If you last stored to a pointer in that union, then you
> can't use the reference because it's not active.
>
There are cases where you can access a union through an inactive member.
Right now (by which I mean C++14) they're restricted to standard layout
structs (), and only the common-initiail-squence between them. So I assume
he'd want to expand that to pointers and references.
--
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/49521753-678d-4a91-801d-c54264903454%40isocpp.org.
------=_Part_536_1055515507.1470096247947
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Monday, August 1, 2016 at 7:43:39 PM UTC-4, Thi=
ago Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On segunda-=
feira, 1 de agosto de 2016 13:38:57 PDT Antonio Perez wrote:
<br>> =C2=A0 =C2=A01. Unions may store references
<br>> =C2=A0 =C2=A02. A reference stored inside a union must be implemen=
ted as a pointer
<br>> =C2=A0 =C2=A03. If a union contains a pointer T* and a reference T=
&, then setting the=20
<br>> location of the pointer, and then reading from the reference, is D=
EFINED
<br>> BEHAVIOR which will read the value stored at the pointer
<br>
<br>This still violates the requirement that you can only read from the act=
ive=20
<br>member of a union. If you last stored to a pointer in that union, then =
you=20
<br>can't use the reference because it's not active.<br></blockquot=
e><div><br>There are cases where you can access a union through an inactive=
member. Right now (by which I mean C++14) they're restricted to standa=
rd layout structs (), and only the common-initiail-squence between them. So=
I assume he'd want to expand that to pointers and references.<br></div=
></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/49521753-678d-4a91-801d-c54264903454%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/49521753-678d-4a91-801d-c54264903454=
%40isocpp.org</a>.<br />
------=_Part_536_1055515507.1470096247947--
------=_Part_535_146231539.1470096247947--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Mon, 01 Aug 2016 17:24:56 -0700
Raw View
On segunda-feira, 1 de agosto de 2016 17:04:07 PDT Nicol Bolas wrote:
> On Monday, August 1, 2016 at 7:43:39 PM UTC-4, Thiago Macieira wrote:
> > On segunda-feira, 1 de agosto de 2016 13:38:57 PDT Antonio Perez wrote:
> > > 1. Unions may store references
> > > 2. A reference stored inside a union must be implemented as a pointer
> > > 3. If a union contains a pointer T* and a reference T&, then setting
> >
> > the
> >
> > > location of the pointer, and then reading from the reference, is DEFINED
> > > BEHAVIOR which will read the value stored at the pointer
> >
> > This still violates the requirement that you can only read from the active
> > member of a union. If you last stored to a pointer in that union, then you
> > can't use the reference because it's not active.
>
> There are cases where you can access a union through an inactive member.
> Right now (by which I mean C++14) they're restricted to standard layout
> structs (), and only the common-initiail-squence between them. So I assume
> he'd want to expand that to pointers and references.
Right. If you define that T & in a union is represented as a T*, then it is
layout-compatible with a T*.
--
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/3564286.NUmIOFFnHB%40tjmaciei-mobl1.
.
Author: Miro Knejp <miro.knejp@gmail.com>
Date: Tue, 2 Aug 2016 02:56:27 +0200
Raw View
Am 02.08.2016 um 01:43 schrieb Thiago Macieira:
> On segunda-feira, 1 de agosto de 2016 13:38:57 PDT Antonio Perez wrote:
>> 1. Unions may store references
>> 2. A reference stored inside a union must be implemented as a pointer
>> 3. If a union contains a pointer T* and a reference T&, then setting the
>> location of the pointer, and then reading from the reference, is DEFINED
>> BEHAVIOR which will read the value stored at the pointer
> This still violates the requirement that you can only read from the active
> member of a union. If you last stored to a pointer in that union, then you
> can't use the reference because it's not active.
>
Which he just proposed to make an exception for, IN CAPS.
I sometimes really wonder what's going on in this forum. Someone
suggests a change to the language rules and more often than not one of
the first responses is "that's not possible because it violates the
rules". They are so stubbornly grabbing on to the current wording it
seems like they are incapable of even imagining the rules could be
different.
"I want to change rule X in the standard so I can do Y" - "But you can't
because rule X doesn't allow it" - "But that's why I want to change
it..." - "Well no you can't do Y because it violates rule X." - *smashes
head against desk*
What's the point of such an exchange?
Am I the only one noticing this...
--
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/8af55b56-dc7d-6959-80c8-7d63a0897661%40gmail.com.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Mon, 01 Aug 2016 18:34:45 -0700
Raw View
On ter=C3=A7a-feira, 2 de agosto de 2016 02:56:27 PDT Miro Knejp wrote:
> Am 02.08.2016 um 01:43 schrieb Thiago Macieira:
> > On segunda-feira, 1 de agosto de 2016 13:38:57 PDT Antonio Perez wrote:
> >> 1. Unions may store references
> >> 2. A reference stored inside a union must be implemented as a poin=
ter
> >> 3. If a union contains a pointer T* and a reference T&, then setti=
ng
> >> the
> >>=20
> >> location of the pointer, and then reading from the reference, is DEFIN=
ED
> >> BEHAVIOR which will read the value stored at the pointer
> >=20
> > This still violates the requirement that you can only read from the act=
ive
> > member of a union. If you last stored to a pointer in that union, then =
you
> > can't use the reference because it's not active.
>=20
> Which he just proposed to make an exception for, IN CAPS.
I misread. I only realised that after Nicol replied to me. Then I agreed.
> I sometimes really wonder what's going on in this forum. Someone
> suggests a change to the language rules and more often than not one of
> the first responses is "that's not possible because it violates the
> rules". They are so stubbornly grabbing on to the current wording it
> seems like they are incapable of even imagining the rules could be
> different.
>=20
> "I want to change rule X in the standard so I can do Y" - "But you can't
> because rule X doesn't allow it" - "But that's why I want to change
> it..." - "Well no you can't do Y because it violates rule X." - *smashes
> head against desk*
>=20
> What's the point of such an exchange?
That's not what I saw. I thought that I was answering "you also need to cha=
nge=20
rule Z", without realising that he had suggested that (though not explicitl=
y=20
saying so).
--=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/1984199.9lnV1SdI4E%40tjmaciei-mobl1.
.
Author: Miro Knejp <miro.knejp@gmail.com>
Date: Tue, 2 Aug 2016 04:28:54 +0200
Raw View
Am 02.08.2016 um 03:34 schrieb Thiago Macieira:
> On ter=C3=A7a-feira, 2 de agosto de 2016 02:56:27 PDT Miro Knejp wrote:
>> Am 02.08.2016 um 01:43 schrieb Thiago Macieira:
>>> On segunda-feira, 1 de agosto de 2016 13:38:57 PDT Antonio Perez wrote:
>>>> 1. Unions may store references
>>>> 2. A reference stored inside a union must be implemented as a poi=
nter
>>>> 3. If a union contains a pointer T* and a reference T&, then sett=
ing
>>>> the
>>>>
>>>> location of the pointer, and then reading from the reference, is DEFIN=
ED
>>>> BEHAVIOR which will read the value stored at the pointer
>>> This still violates the requirement that you can only read from the act=
ive
>>> member of a union. If you last stored to a pointer in that union, then =
you
>>> can't use the reference because it's not active.
>> Which he just proposed to make an exception for, IN CAPS.
> I misread. I only realised that after Nicol replied to me. Then I agreed.
>
>> I sometimes really wonder what's going on in this forum. Someone
>> suggests a change to the language rules and more often than not one of
>> the first responses is "that's not possible because it violates the
>> rules". They are so stubbornly grabbing on to the current wording it
>> seems like they are incapable of even imagining the rules could be
>> different.
>>
>> "I want to change rule X in the standard so I can do Y" - "But you can't
>> because rule X doesn't allow it" - "But that's why I want to change
>> it..." - "Well no you can't do Y because it violates rule X." - *smashes
>> head against desk*
>>
>> What's the point of such an exchange?
> That's not what I saw. I thought that I was answering "you also need to c=
hange
> rule Z", without realising that he had suggested that (though not explici=
tly
> saying so).
>
OK, I get that. Though my rambling wasn't directed at you personally,=20
but more in general.
It is a trend that I have noticed several times now and it puzzles me=20
every time it happens.
--=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/ea14d72e-b6a6-736e-c47f-8d41aa3bb28f%40gmail.com=
..
.
Author: gmisocpp@gmail.com
Date: Mon, 1 Aug 2016 19:33:55 -0700 (PDT)
Raw View
------=_Part_154_315621629.1470105235748
Content-Type: multipart/alternative;
boundary="----=_Part_155_1295565809.1470105235749"
------=_Part_155_1295565809.1470105235749
Content-Type: text/plain; charset=UTF-8
>
>
> Which he just proposed to make an exception for, IN CAPS.
>
> I sometimes really wonder what's going on in this forum. Someone
> suggests a change to the language rules and more often than not one of
> the first responses is "that's not possible because it violates the
> rules". They are so stubbornly grabbing on to the current wording it
> seems like they are incapable of even imagining the rules could be
> different.
> "I want to change rule X in the standard so I can do Y" - "But you can't
> because rule X doesn't allow it" - "But that's why I want to change
> it..." - "Well no you can't do Y because it violates rule X." t- *smashes
> head against desk*
>
This, exactly. Thank you.
I tried to make this point in another thread in a comment about voodoo
magic but I made the point too abstractly I feel, but this was exactly one
thing I had I mind when I made my comment. So thanks for putting it plainly.
>
> What's the point of such an exchange?
> Am I the only one noticing this...
>
You are not alone.
--
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/7b8ebe6e-350a-4b48-8e6d-37c38154edad%40isocpp.org.
------=_Part_155_1295565809.1470105235749
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; paddi=
ng-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px=
; border-left-style: solid;"><br>Which he just proposed to make an exceptio=
n for, IN CAPS.
<br>
<br>I sometimes really wonder what's going on in this forum. Someone=20
<br>suggests a change to the language rules and more often than not one of=
=20
<br>the first responses is "that's not possible because it violate=
s the=20
<br>rules". They are so stubbornly grabbing on to the current wording =
it=20
<br>seems like they are incapable of even imagining the rules could be=20
<br>different.
</blockquote><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px=
0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-le=
ft-width: 1px; border-left-style: solid;">
<br>"I want to change rule X in the standard so I can do Y" - &qu=
ot;But you can't=20
<br>because rule X doesn't allow it" - "But that's why I =
want to change=20
<br>it..." - "Well no you can't do Y because it violates rule=
X." t- *smashes=20
<br>head against desk*
<br></blockquote><div><br></div><div><div>This,=C2=A0exactly. Thank you.</d=
iv><div>I tried to make this point in another thread=C2=A0in a comment abou=
t=C2=A0voodoo magic=C2=A0but I made=C2=A0the point=C2=A0too abstractly I fe=
el, but this was exactly one thing I had I=C2=A0mind when I made my comment=
.. So thanks for putting it plainly.</div>=C2=A0</div><blockquote class=3D"g=
mail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-l=
eft-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: s=
olid;">
<br>What's the point of such an exchange?
<br>Am I the only one noticing this...
<br></blockquote><div><br></div><div>You are not alone.</div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/7b8ebe6e-350a-4b48-8e6d-37c38154edad%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7b8ebe6e-350a-4b48-8e6d-37c38154edad=
%40isocpp.org</a>.<br />
------=_Part_155_1295565809.1470105235749--
------=_Part_154_315621629.1470105235748--
.
Author: Ren Industries <renindustries@gmail.com>
Date: Mon, 1 Aug 2016 23:10:57 -0400
Raw View
--94eb2c060208d205de05390e103f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Often those rules exist for very good reasons, and people point out those
reasons.
Simplifying their statements to a strawman and then knocking it down isn't
often the way to enact change.
On Mon, Aug 1, 2016 at 10:28 PM, Miro Knejp <miro.knejp@gmail.com> wrote:
> Am 02.08.2016 um 03:34 schrieb Thiago Macieira:
>
>> On ter=C3=A7a-feira, 2 de agosto de 2016 02:56:27 PDT Miro Knejp wrote:
>>
>>> Am 02.08.2016 um 01:43 schrieb Thiago Macieira:
>>>
>>>> On segunda-feira, 1 de agosto de 2016 13:38:57 PDT Antonio Perez wrote=
:
>>>>
>>>>> 1. Unions may store references
>>>>> 2. A reference stored inside a union must be implemented as a
>>>>> pointer
>>>>> 3. If a union contains a pointer T* and a reference T&, then
>>>>> setting
>>>>> the
>>>>>
>>>>> location of the pointer, and then reading from the reference, is
>>>>> DEFINED
>>>>> BEHAVIOR which will read the value stored at the pointer
>>>>>
>>>> This still violates the requirement that you can only read from the
>>>> active
>>>> member of a union. If you last stored to a pointer in that union, then
>>>> you
>>>> can't use the reference because it's not active.
>>>>
>>> Which he just proposed to make an exception for, IN CAPS.
>>>
>> I misread. I only realised that after Nicol replied to me. Then I agreed=
..
>>
>> I sometimes really wonder what's going on in this forum. Someone
>>> suggests a change to the language rules and more often than not one of
>>> the first responses is "that's not possible because it violates the
>>> rules". They are so stubbornly grabbing on to the current wording it
>>> seems like they are incapable of even imagining the rules could be
>>> different.
>>>
>>> "I want to change rule X in the standard so I can do Y" - "But you can'=
t
>>> because rule X doesn't allow it" - "But that's why I want to change
>>> it..." - "Well no you can't do Y because it violates rule X." - *smashe=
s
>>> head against desk*
>>>
>>> What's the point of such an exchange?
>>>
>> That's not what I saw. I thought that I was answering "you also need to
>> change
>> rule Z", without realising that he had suggested that (though not
>> explicitly
>> saying so).
>>
>> OK, I get that. Though my rambling wasn't directed at you personally, bu=
t
> more in general.
> It is a trend that I have noticed several times now and it puzzles me
> every time it happens.
>
> --
> 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/ea14d72e-b6a=
6-736e-c47f-8d41aa3bb28f%40gmail.com
> .
>
--=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/CAMD6iD8sxwXZbvBTNNy8KWLA_hJ9uGRfGtY-aEAF4xJwg%2=
BGphQ%40mail.gmail.com.
--94eb2c060208d205de05390e103f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Often those rules exist for very good reasons, and people =
point out those reasons.=C2=A0<div>Simplifying their statements to a strawm=
an and then knocking it down isn't often the way to enact change.</div>=
</div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Mon, Aug=
1, 2016 at 10:28 PM, Miro Knejp <span dir=3D"ltr"><<a href=3D"mailto:mi=
ro.knejp@gmail.com" target=3D"_blank">miro.knejp@gmail.com</a>></span> w=
rote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div class=3D"HOEnZb"><div class=3D=
"h5">Am 02.08.2016 um 03:34 schrieb Thiago Macieira:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
On ter=C3=A7a-feira, 2 de agosto de 2016 02:56:27 PDT Miro Knejp wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Am 02.08.2016 um 01:43 schrieb Thiago Macieira:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
On segunda-feira, 1 de agosto de 2016 13:38:57 PDT Antonio Perez wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
=C2=A0 =C2=A0 =C2=A01. Unions may store references<br>
=C2=A0 =C2=A0 =C2=A02. A reference stored inside a union must be implemente=
d as a pointer<br>
=C2=A0 =C2=A0 =C2=A03. If a union contains a pointer T* and a reference T&a=
mp;, then setting<br>
=C2=A0 =C2=A0 =C2=A0the<br>
<br>
location of the pointer, and then reading from the reference, is DEFINED<br=
>
BEHAVIOR which will read the value stored at the pointer<br>
</blockquote>
This still violates the requirement that you can only read from the active<=
br>
member of a union. If you last stored to a pointer in that union, then you<=
br>
can't use the reference because it's not active.<br>
</blockquote>
Which he just proposed to make an exception for, IN CAPS.<br>
</blockquote>
I misread. I only realised that after Nicol replied to me. Then I agreed.<b=
r>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
I sometimes really wonder what's going on in this forum. Someone<br>
suggests a change to the language rules and more often than not one of<br>
the first responses is "that's not possible because it violates th=
e<br>
rules". They are so stubbornly grabbing on to the current wording it<b=
r>
seems like they are incapable of even imagining the rules could be<br>
different.<br>
<br>
"I want to change rule X in the standard so I can do Y" - "B=
ut you can't<br>
because rule X doesn't allow it" - "But that's why I want=
to change<br>
it..." - "Well no you can't do Y because it violates rule X.&=
quot; - *smashes<br>
head against desk*<br>
<br>
What's the point of such an exchange?<br>
</blockquote>
That's not what I saw. I thought that I was answering "you also ne=
ed to change<br>
rule Z", without realising that he had suggested that (though not expl=
icitly<br>
saying so).<br>
<br>
</blockquote></div></div>
OK, I get that. Though my rambling wasn't directed at you personally, b=
ut more in general.<br>
It is a trend that I have noticed several times now and it puzzles me every=
time it happens.<span class=3D""><br>
<br>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@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/ea14d72e-b6a6-736e-c47f-8d41aa3bb28f%=
40gmail.com" rel=3D"noreferrer" target=3D"_blank">https://groups.google.com=
/a/isocpp.org/d/msgid/std-proposals/ea14d72e-b6a6-736e-c47f-8d41aa3bb28f%40=
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" 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/CAMD6iD8sxwXZbvBTNNy8KWLA_hJ9uGRfGtY-=
aEAF4xJwg%2BGphQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAMD6iD8sxwXZbv=
BTNNy8KWLA_hJ9uGRfGtY-aEAF4xJwg%2BGphQ%40mail.gmail.com</a>.<br />
--94eb2c060208d205de05390e103f--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 1 Aug 2016 21:00:00 -0700 (PDT)
Raw View
------=_Part_3184_1736364440.1470110400872
Content-Type: multipart/alternative;
boundary="----=_Part_3185_1899360994.1470110400873"
------=_Part_3185_1899360994.1470110400873
Content-Type: text/plain; charset=UTF-8
On Monday, August 1, 2016 at 8:55:19 PM UTC-4, Miro Knejp wrote:
> "I want to change rule X in the standard so I can do Y" - "But you can't
> because rule X doesn't allow it" - "But that's why I want to change
> it..." - "Well no you can't do Y because it violates rule X." - *smashes
> head against desk*
>
> What's the point of such an exchange?
> Am I the only one noticing this...
>
This is not how the conversation generally happens. It generally tends to
be more like: "I want Y to be possible, so let's change X to allow it to be
possible." - "But what about rule Z; that contradicts the new rule X?" -
"Well, let's change that too, I guess." - "So what do you change rule Z
to?" - "I don't care; I just want Y. Let someone else figure it out." -
"And how does that fit with rules Q-W?"
The point of such an exchange is that the proposal is *incomplete*. That
the matter hasn't been thought very far through, and thus the person making
the proposal needs to go back and fix these things.
This particular proposal isn't an example of that, since it actually
explains what rules it wants and they're generally consistent with existing
rules. Granted, we've yet to see an explanation for why anyone would
actually *want* this feature or what problems it solves. Or why you can't
just use `reference_wrapper`. And it encourages using unions as type
punning boxes.
But rule-wise, it's fine.
--
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/b0ed1f2b-18e5-4d45-bcc1-e950cc4b252c%40isocpp.org.
------=_Part_3185_1899360994.1470110400873
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, August 1, 2016 at 8:55:19 PM UTC-4, Miro Knejp =
wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">"I want to chan=
ge rule X in the standard so I can do Y" - "But you can't=20
<br>because rule X doesn't allow it" - "But that's why I =
want to change=20
<br>it..." - "Well no you can't do Y because it violates rule=
X." - *smashes=20
<br>head against desk*
<br>
<br>What's the point of such an exchange?
<br>Am I the only one noticing this...
<br></blockquote><div><br>This is not how the conversation generally happen=
s. It generally tends to be more like: "I want Y to be possible, so le=
t's change X to allow it to be possible." - "But what about r=
ule Z; that contradicts the new rule X?" - "Well, let's chang=
e that too, I guess." - "So what do you change rule Z to?" -=
"I don't care; I just want Y. Let someone else figure it out.&quo=
t; - "And how does that fit with rules Q-W?"<br><br>The point of =
such an exchange is that the=20
proposal is <i>incomplete</i>. That the matter hasn't been thought very=
far through, and thus the person making the proposal needs to go back and=
=20
fix these things.<br><br>This
particular proposal isn't an example of that, since it actually=20
explains what rules it wants and they're generally consistent with exis=
ting rules. Granted, we've yet to see an=20
explanation for why anyone would actually <i>want</i> this feature or what=
=20
problems it solves. Or why you can't just use `reference_wrapper`. And=
=20
it encourages using unions as type punning boxes.<br><br>But rule-wise, it&=
#39;s fine.<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/b0ed1f2b-18e5-4d45-bcc1-e950cc4b252c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b0ed1f2b-18e5-4d45-bcc1-e950cc4b252c=
%40isocpp.org</a>.<br />
------=_Part_3185_1899360994.1470110400873--
------=_Part_3184_1736364440.1470110400872--
.
Author: Miro Knejp <miro.knejp@gmail.com>
Date: Tue, 2 Aug 2016 06:07:38 +0200
Raw View
This is a multi-part message in MIME format.
--------------40F02B89A60AC6CBB8DB4561
Content-Type: text/plain; charset=UTF-8; format=flowed
Am 02.08.2016 um 06:00 schrieb Nicol Bolas:
> On Monday, August 1, 2016 at 8:55:19 PM UTC-4, Miro Knejp wrote:
>
> "I want to change rule X in the standard so I can do Y" - "But you
> can't
> because rule X doesn't allow it" - "But that's why I want to change
> it..." - "Well no you can't do Y because it violates rule X." -
> *smashes
> head against desk*
>
> What's the point of such an exchange?
> Am I the only one noticing this...
>
>
> This is not how the conversation generally happens. It generally tends
> to be more like: "I want Y to be possible, so let's change X to allow
> it to be possible." - "But what about rule Z; that contradicts the new
> rule X?" - "Well, let's change that too, I guess." - "So what do you
> change rule Z to?" - "I don't care; I just want Y. Let someone else
> figure it out." - "And how does that fit with rules Q-W?"
That is a completely different scenario and there I have no objections.
The scenario that buffles me is when people seemingly cannot understand
the concept of "the feature needs the current rules to change so please
stop evaluating it under the current rules but instead the modified ones
I am proposing".
--
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/7b611e33-410a-3edf-ba1e-6ca6dd722af0%40gmail.com.
--------------40F02B89A60AC6CBB8DB4561
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
Am 02.08.2016 um 06:00 schrieb Nicol Bolas:<br>
<blockquote
cite=3D"mid:b0ed1f2b-18e5-4d45-bcc1-e950cc4b252c@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">On Monday, August 1, 2016 at 8:55:19 PM UTC-4, Miro
Knejp wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">"I want
to change rule X in the standard so I can do Y" - "But you
can't <br>
because rule X doesn't allow it" - "But that's why I want to
change <br>
it..." - "Well no you can't do Y because it violates rule X."
- *smashes <br>
head against desk*
<br>
<br>
What's the point of such an exchange?
<br>
Am I the only one noticing this...
<br>
</blockquote>
<div><br>
This is not how the conversation generally happens. It
generally tends to be more like: "I want Y to be possible, so
let's change X to allow it to be possible." - "But what about
rule Z; that contradicts the new rule X?" - "Well, let's
change that too, I guess." - "So what do you change rule Z
to?" - "I don't care; I just want Y. Let someone else figure
it out." - "And how does that fit with rules Q-W?"<br>
</div>
</div>
</blockquote>
That is a completely different scenario and there I have no
objections. The scenario that buffles me is when people seemingly
cannot understand the concept of "the feature needs the current
rules to change so please stop evaluating it under the current rules
but instead the modified ones I am proposing".<br>
</body>
</html>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/7b611e33-410a-3edf-ba1e-6ca6dd722af0%=
40gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/7b611e33-410a-3edf-ba1e-6ca6dd722af0%=
40gmail.com</a>.<br />
--------------40F02B89A60AC6CBB8DB4561--
.
Author: gmisocpp@gmail.com
Date: Mon, 1 Aug 2016 21:33:05 -0700 (PDT)
Raw View
------=_Part_5770_45894684.1470112385129
Content-Type: multipart/alternative;
boundary="----=_Part_5771_2050328990.1470112385129"
------=_Part_5771_2050328990.1470112385129
Content-Type: text/plain; charset=UTF-8
On Tuesday, August 2, 2016 at 4:00:01 PM UTC+12, Nicol Bolas wrote:
>
> On Monday, August 1, 2016 at 8:55:19 PM UTC-4, Miro Knejp wrote:
>
>> "I want to change rule X in the standard so I can do Y" - "But you can't
>> because rule X doesn't allow it" - "But that's why I want to change
>> it..." - "Well no you can't do Y because it violates rule X." - *smashes
>> head against desk*
>>
>> What's the point of such an exchange?
>> Am I the only one noticing this...
>>
>
> This is not how the conversation generally happens. It generally tends to
> be more like: "I want Y to be possible, so let's change X to allow it to be
> possible." - "But what about rule Z; that contradicts the new rule X?" -
> "Well, let's change that too, I guess." - "So what do you change rule Z
> to?" - "I don't care; I just want Y. Let someone else figure it out." -
> "And how does that fit with rules Q-W?"
>
I think Miro is correct in often goes how he says. Regardless, it's how I
often perceive it going. So clearly Miro is not alone in his view.
> The point of such an exchange is that the proposal is *incomplete*. That
> the matter hasn't been thought very far through, and thus the person making
> the proposal needs to go back and fix these things.
>
Yeah "proposals" are often incomplete, even barely proposals, but I think
the problem is that you are offended by incompleteness because you feel
you are expected to complete it when the proposer could just do more or
stop being lazy. Well if that's your view, you're right! That is often what
people (me at least) probably hope, but it's a hope not a requirement and
getting all intolerant about the reality that some contributions are less
amazing than others just serves to deny certain groups a voice at all. I
don't think that is realistic, necessary, or serves anyone. Nor does it
make for a friendly environment and it may well block reasonable ideas on
occasion or people growing into better contributors. I often here Bjarne
say we don't want C++ getting too expert friendly. I don't see why that
idea shouldn't also apply to this forum.
>
> This particular proposal isn't an example of that, since it actually
> explains what rules it wants and they're generally consistent with existing
> rules. Granted, we've yet to see an explanation for why anyone would
> actually *want* this feature or what problems it solves. Or why you can't
> just use `reference_wrapper`. And it encourages using unions as type
> punning boxes.
>
> But rule-wise, it's fine.
>
--
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/9d35890e-57ee-49ff-9394-7be5006ea417%40isocpp.org.
------=_Part_5771_2050328990.1470112385129
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Tuesday, August 2, 2016 at 4:00:01 PM UTC+12, N=
icol Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px=
0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); borde=
r-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr">On Monday, A=
ugust 1, 2016 at 8:55:19 PM UTC-4, Miro Knejp wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; bor=
der-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-sty=
le: solid;">"I want to change rule X in the standard so I can do Y&quo=
t; - "But you can't=20
<br>because rule X doesn't allow it" - "But that's why I =
want to change=20
<br>it..." - "Well no you can't do Y because it violates rule=
X." - *smashes=20
<br>head against desk*
<br>
<br>What's the point of such an exchange?
<br>Am I the only one noticing this...
<br></blockquote><div><br>This is not how the conversation generally happen=
s. It generally tends to be more like: "I want Y to be possible, so le=
t's change X to allow it to be possible." - "But what about r=
ule Z; that contradicts the new rule X?" - "Well, let's chang=
e that too, I guess." - "So what do you change rule Z to?" -=
"I don't care; I just want Y. Let someone else figure it out.&quo=
t; - "And how does that fit with rules Q-W?"<br></div></div></blo=
ckquote><div><br></div><div>I think=C2=A0Miro=C2=A0is correct in often goes=
how he says. Regardless, it's how I often perceive it going.=C2=A0So c=
learly Miro is not alone in=C2=A0his view.</div><div><br></div><blockquote =
class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex=
; border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-lef=
t-style: solid;"><div dir=3D"ltr"><div><br>The point of such an exchange is=
that the=20
proposal is <i>incomplete</i>. That the matter hasn't been thought very=
far through, and thus the person making the proposal needs to go back and=
=20
fix these things.<br></div></div></blockquote><div><br></div><div>Yeah &quo=
t;proposals" are often incomplete, even barely proposals,=C2=A0but=C2=
=A0I think the problem is that you are offended by incompleteness because y=
ou feel you=C2=A0are expected to complete it when the proposer could just=
=C2=A0do more or stop being lazy.=C2=A0Well if that's your view, you=
9;re right! That is often=C2=A0what people (me=C2=A0at least) probably hope=
, but it's a hope not a requirement and getting all intolerant about=C2=
=A0the reality that some contributions are less amazing than others=C2=A0ju=
st serves to deny certain groups a voice at all. I don't think that is =
realistic, necessary,=C2=A0or serves anyone.=C2=A0Nor does it make for a fr=
iendly environment and it may well block reasonable ideas on occasion or pe=
ople growing into=C2=A0better contributors. I often here Bjarne say we don&=
#39;t want C++ getting too expert friendly. I don't see why that idea s=
houldn't also apply to this forum.</div><div>=C2=A0</div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; =
border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-=
style: solid;"><div dir=3D"ltr"><div><br>This
particular proposal isn't an example of that, since it actually=20
explains what rules it wants and they're generally consistent with exis=
ting rules. Granted, we've yet to see an=20
explanation for why anyone would actually <i>want</i> this feature or what=
=20
problems it solves. Or why you can't just use `reference_wrapper`. And=
=20
it encourages using unions as type punning boxes.<br><br>But rule-wise, it&=
#39;s fine.<br></div></div></blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/9d35890e-57ee-49ff-9394-7be5006ea417%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9d35890e-57ee-49ff-9394-7be5006ea417=
%40isocpp.org</a>.<br />
------=_Part_5771_2050328990.1470112385129--
------=_Part_5770_45894684.1470112385129--
.
Author: Miro Knejp <miro.knejp@gmail.com>
Date: Tue, 2 Aug 2016 06:39:56 +0200
Raw View
Am 02.08.2016 um 05:10 schrieb Ren Industries:
> Often those rules exist for very good reasons, and people point out
> those reasons.
> Simplifying their statements to a strawman and then knocking it down
> isn't often the way to enact change.
Yes often (not always) rules have good reasons but that's not what I'm
talking about. The situation I am describing is when someone
deliberately suggests changing a certain rule X to allow for some new
feature and the response they get is that the feature can't be done
because it violates rule X. In such a scenario the proposer has realized
that a rule needs to be changed (and how), yet still get the stubborn
counter argument that the feature violates the status-quo rule (instead
of describing why it's a bad idea to change said rule). Well, duh... And
the point is? It happens again and again and I don't understand why.
It's like saying "I want to fly planes so I want to get a piloting
license" and then get rejected by the instructor saying "no, you cannot
fly planes because you don't have a piloting license" (instead of
explaining why you can't get a license).
Since I was arguing neither for nor against the proposal in this thread
I see no strawman. I'd simply like this nonsense behavior to stop as it
only creates hostility against new people and is a deterrend to new ideas.
Just take this thread as example: it is full of "your idea is horrible
because rule such and such says so and it's also UB" ignoring the OP's
explanations and desires to make alterations to rules so his idea works.
Regardless of whether the idea is good or bad, that's just not nice.
Here's a hint: the OP acknowledges that it's currently UB, so constantly
repeating that it's currently UB and pointing out his code examples
(which he wants to make work) are UB doesn't help. Instead one might
help with getting a list of changes (without using words like "horrible"
or insulting the OP) that need to be done, or if one isn't capable of
giving constructive feedback just remain quiet and wait for the official
proposal. I salute Antonio's capability of staying polite this whole
time, I probably wouldn't have.
There's also this outright obsession with questioning the motivation
behind every single idea, oh so often implying a "you must be doing it
wrong" undertone. As long as it's just an idea it doesn't need hundreds
of pages of rationale, merely pointing out that it may not be sufficient
is enough. Let the motivation be an issue when it comes to writing the
actual proposal. Until then it's a thought experiment nobody besides the
OP is required to spend any amount of time on.
But unfortunately (for the OP) his topic touches on undefined behavior
and if anyone on this forum even dares to challenge what is currently
undefined or implementation-defined behavior you can virtually hear the
mob arming itself with pitchforks.
Anyway this rant has gone off-topic and I don't have any feedback for
the OP.
--
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/a6d12b01-3f29-4ea8-e6c6-5f3dd3a7e520%40gmail.com.
.
Author: "D. B." <db0451@gmail.com>
Date: Tue, 2 Aug 2016 07:35:15 +0100
Raw View
--94eb2c0d7c60796022053910eb3a
Content-Type: text/plain; charset=UTF-8
On Tue, Aug 2, 2016 at 1:56 AM, Miro Knejp <miro.knejp@gmail.com> wrote:
>
> I sometimes really wonder what's going on in this forum. Someone suggests
> a change to the language rules and more often than not one of the first
> responses is "that's not possible because it violates the rules". They are
> so stubbornly grabbing on to the current wording it seems like they are
> incapable of even imagining the rules could be different.
>
> "I want to change rule X in the standard so I can do Y" - "But you can't
> because rule X doesn't allow it" - "But that's why I want to change it..."
> - "Well no you can't do Y because it violates rule X." - *smashes head
> against desk*
>
> What's the point of such an exchange?
> Am I the only one noticing this...
"What's the point" - Good question. OP hasn't yet provided an answer.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhH_B%2BHJRBKW8B%2BgQXw6pLw_Lp%3D0mHOn997dD2vkQwzwig%40mail.gmail.com.
--94eb2c0d7c60796022053910eb3a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Aug 2, 2016 at 1:56 AM, Miro Knejp <span dir=3D"ltr"><<a href=3D"mai=
lto:miro.knejp@gmail.com" target=3D"_blank">miro.knejp@gmail.com</a>></s=
pan> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><br>
I sometimes really wonder what's going on in this forum. Someone sugges=
ts a change to the language rules and more often than not one of the first =
responses is "that's not possible because it violates the rules&qu=
ot;. They are so stubbornly grabbing on to the current wording it seems lik=
e they are incapable of even imagining the rules could be different.<br>
<br>
"I want to change rule X in the standard so I can do Y" - "B=
ut you can't because rule X doesn't allow it" - "But that=
's why I want to change it..." - "Well no you can't do Y =
because it violates rule X." - *smashes head against desk*<br>
<br>
What's the point of such an exchange?<br>
Am I the only one noticing this...</blockquote><div><br></div><div>"Wh=
at's the point" - Good question. OP hasn't yet provided an ans=
wer. <br></div></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CACGiwhH_B%2BHJRBKW8B%2BgQXw6pLw_Lp%3=
D0mHOn997dD2vkQwzwig%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhH_B%=
2BHJRBKW8B%2BgQXw6pLw_Lp%3D0mHOn997dD2vkQwzwig%40mail.gmail.com</a>.<br />
--94eb2c0d7c60796022053910eb3a--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 2 Aug 2016 19:18:46 -0700 (PDT)
Raw View
------=_Part_49_1924223714.1470190727095
Content-Type: multipart/alternative;
boundary="----=_Part_50_31375618.1470190727095"
------=_Part_50_31375618.1470190727095
Content-Type: text/plain; charset=UTF-8
On Tuesday, August 2, 2016 at 12:38:48 AM UTC-4, Miro Knejp wrote:
> There's also this outright obsession with questioning the motivation
> behind every single idea, oh so often implying a "you must be doing it
> wrong" undertone. As long as it's just an idea it doesn't need hundreds
> of pages of rationale, merely pointing out that it may not be sufficient
> is enough. Let the motivation be an issue when it comes to writing the
> actual proposal. Until then it's a thought experiment nobody besides the
> OP is required to spend any amount of time on.
>
Consider what the "How To Submit a Proposal
<https://isocpp.org/std/submit-a-proposal>" page says: (emphasis added)
Post an initial brief description of your feature on the std-proposals forum
> <http://groups.google.com/a/isocpp.org/forum/?fromgroups#%21forum/std-proposals>, including
> *especially *the problem it solves and alternatives considered.
>
So whatever you may feel towards people talking about rule changes and UB
and so forth, it seems quite clear that the people who set up this forum
think that motivation is a pretty important part of any idea/proposal.
Maybe we just disagree with what this forum is for.
Pursuant to the above, I was under the impression that this place was for
*well-considered* proposals and ideas. I thought the idea was that you'd
actually spend time *on your own*, building the idea into a coherent form,
then bringing it here for commentary/improvement/spec analysis/etc.
I personally feel very strongly in using the time of complete strangers in
a *productive* way. Inundating such people with ideas that clearly haven't
had due consideration, lack any real motivation, or are just a priori trash
does not constitute not using their time productively.
There are plenty of places to go bat around ideas that in an unformed
state. Reddit has a C++ community. But by the time those ideas get *here*,
they should have at least some thought put to them.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/26fe73ff-3df6-4bac-a8da-8838a1743c22%40isocpp.org.
------=_Part_50_31375618.1470190727095
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, August 2, 2016 at 12:38:48 AM UTC-4, Miro Knej=
p wrote:<br><div></div><blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">There&#=
39;s also this outright obsession with questioning the motivation=20
<br>behind every single idea, oh so often implying a "you must be doin=
g it=20
<br>wrong" undertone. As long as it's just an idea it doesn't =
need hundreds=20
<br>of pages of rationale, merely pointing out that it may not be sufficien=
t=20
<br>is enough. Let the motivation be an issue when it comes to writing the=
=20
<br>actual proposal. Until then it's a thought experiment nobody beside=
s the=20
<br>OP is required to spend any amount of time on.<br></blockquote><div><br=
>Consider what the "<a href=3D"https://isocpp.org/std/submit-a-proposa=
l">How To Submit a Proposal</a>" page says: (emphasis added)<br><br><b=
lockquote style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(20=
4, 204, 204); padding-left: 1ex;" class=3D"gmail_quote">Post an initial bri=
ef description of your feature on the <a href=3D"http://groups.google.com/a=
/isocpp.org/forum/?fromgroups#%21forum/std-proposals">std-proposals forum</=
a>,=C2=A0including <b>especially </b>the problem it solves and alternatives=
considered.<br></blockquote><br>So whatever you may feel towards people ta=
lking about rule changes and UB and so forth, it seems quite clear that the=
people who set up this forum think that motivation is a pretty important p=
art of any idea/proposal.<br><br>Maybe we just disagree with what this foru=
m is for.<br><br>Pursuant to the above, I was under the impression that thi=
s place was for <i>well-considered</i>
proposals and ideas. I thought the idea was that you'd actually spend =
time <i>on your own</i>, building the idea into a coherent form, then bring=
ing it here for=20
commentary/improvement/spec analysis/etc.<br><br>I personally feel very str=
ongly in using=20
the time of complete strangers in a <i>productive</i> way. Inundating such =
people with ideas that clearly haven't had due consideration, lack any =
real motivation, or are just a priori trash does not constitute not using t=
heir time productively.<br><br>There are plenty of places to go bat around =
ideas that in an unformed state. Reddit has a C++ community. But by the tim=
e those ideas get <i>here</i>, they should have at least some thought put t=
o them.<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/26fe73ff-3df6-4bac-a8da-8838a1743c22%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/26fe73ff-3df6-4bac-a8da-8838a1743c22=
%40isocpp.org</a>.<br />
------=_Part_50_31375618.1470190727095--
------=_Part_49_1924223714.1470190727095--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 2 Aug 2016 19:58:01 -0700 (PDT)
Raw View
------=_Part_1056_1057455323.1470193081893
Content-Type: multipart/alternative;
boundary="----=_Part_1057_1764821565.1470193081893"
------=_Part_1057_1764821565.1470193081893
Content-Type: text/plain; charset=UTF-8
Something just occurred to me about this proposal. This is essentially
making rebindable references a language feature. *That* is the point of it.
And while I dislike the very idea of the concept... using a `union` is a
surprisingly effective way to handle it.
One of the big issues with any form of rebindable reference is the
distinction between binding the reference and assignments to the value
being referenced. Since C++ doesn't let you rebind references, we know that
`r = val;` is always assigning to the value stored in or referenced by `r`.
Even if we have support for `operator.` and apply it to
`reference_wrapper`, we would still have to make that kind of distinction.
Right now, `reference_wrapper` doesn't even have an `operator=` overload
for `T`, so you can't assign to the value being referenced. If we added
such an overload, to make it more reference like, then the distinction
between rebinding the reference and assigning to it would be this:
r = val; //Assignment
r = std::ref(val); //Rebinding
While that is certainly functional, it's also rather weird. By contrast,
using this `union` idea makes it a bit more clear:
r.ref = val;
r.ptr = &val;
Please do not take this as an endorsement of this idea. I still find it
rather pointless (I've never understood the obsession some people have with
references or `operator.`) and one can get equivalent behavior without a
language change (`reference_wrapper<T>`, or just a `T*`). And it makes it
way too easy to create a NULL reference.
--
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/0086f2aa-965a-42d2-9a2d-d54f4d7502da%40isocpp.org.
------=_Part_1057_1764821565.1470193081893
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Something just occurred to me about this proposal. This is=
essentially making rebindable references a language feature. <i>That</i> i=
s the point of it.<br><br>And while I dislike the very idea of the concept.=
... using a `union` is a surprisingly effective way to handle it.<br><br>One=
of the big issues with any form of rebindable reference is the distinction=
between binding the reference and assignments to the value being reference=
d. Since C++ doesn't let you rebind references, we know that `r =3D val=
;` is always assigning to the value stored in or referenced by `r`.<br><br>=
Even if we have support for `operator.` and apply it to `reference_wrapper`=
, we would still have to make that kind of distinction. Right now, `referen=
ce_wrapper` doesn't even have an `operator=3D` overload for `T`, so you=
can't assign to the value being referenced. If we added such an overlo=
ad, to make it more reference like, then the distinction between rebinding =
the reference and assigning to it would be this:<br><br><div class=3D"prett=
yprint" style=3D"background-color: rgb(250, 250, 250); border-color: rgb(18=
7, 187, 187); border-style: solid; border-width: 1px; word-wrap: break-word=
;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D=
"color: #000;" class=3D"styled-by-prettify">r </span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> val</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #800;" class=3D"styled-by-pret=
tify">//Assignment</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"><br>r </span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> st=
d</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span>=
<span style=3D"color: #008;" class=3D"styled-by-prettify">ref</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify">val</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">);</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> </span><span style=3D"color: #800;" class=3D"st=
yled-by-prettify">//Rebinding</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br></span></div></code></div><br>While that is certainl=
y functional, it's also rather weird. By contrast, using this `union` i=
dea makes it a bit more clear:<br><br><div class=3D"prettyprint" style=3D"b=
ackground-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); bord=
er-style: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"=
prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify">r</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">.</span><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify">ref</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> val</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>r</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">.</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify">ptr </span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">&</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify">val</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;=
</span></div></code></div><br>Please do not take this as an endorsement of =
this idea. I still find it rather pointless (I've never understood the =
obsession some people have with references or `operator.`) and one can get =
equivalent behavior without a language change (`reference_wrapper<T>`=
, or just a `T*`). And it makes it way too easy to create a NULL reference.=
<br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/0086f2aa-965a-42d2-9a2d-d54f4d7502da%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/0086f2aa-965a-42d2-9a2d-d54f4d7502da=
%40isocpp.org</a>.<br />
------=_Part_1057_1764821565.1470193081893--
------=_Part_1056_1057455323.1470193081893--
.
Author: gmisocpp@gmail.com
Date: Tue, 2 Aug 2016 20:08:47 -0700 (PDT)
Raw View
------=_Part_3078_1331329152.1470193727280
Content-Type: multipart/alternative;
boundary="----=_Part_3079_1775094168.1470193727281"
------=_Part_3079_1775094168.1470193727281
Content-Type: text/plain; charset=UTF-8
>
>
>>
> So whatever you may feel towards people talking about rule changes and UB
> and so forth, it seems quite clear that the people who set up this forum
> think that motivation is a pretty important part of any idea/proposal.
>
I'm sure the people who setup this forum would love every proposal to be
well thought out. And it's great there is advice here on how best to create
a proposal that has the best chance to succeed.
But that doesn't mean people must follow it, unless of course you want to
get in the business of banning accounts?
So unless you're going to ban people, why not just be happy people are
interested in the language to at least engage here at all? I think people
are entitled to have a casual level of engagement if that's what they
are comfortable with as long as they are not obnoxious. I don't see what
sense or right there is to make those people feel unwelcome just because
they aren't doing all they could for their proposal.
>
> Maybe we just disagree with what this forum is for.
>
I think so.
>
> Pursuant to the above, I was under the impression that this place was for
> *well-considered* proposals and ideas.
>
It is. But that's why people will also want to engage here. Be happy about
that.
> I thought the idea was that you'd actually spend time *on your own*,
> building the idea into a coherent form, then bringing it here for
> commentary/improvement/spec analysis/etc.
>
I don't see how you can enforce that. So you should Live and let live.
> I personally feel very strongly in using the time of complete strangers in
> a *productive* way. Inundating such people with ideas that clearly
> haven't had due consideration, lack any real motivation, or are just a
> priori trash does not constitute not using their time productively.
>
Sorry but you're too smart for your own good. People want to pick your
brains. Can't you just take that as a sign of respect instead. Because
there is no obligation for you to assist any more than you want to other
than try to be a decent person about whatever level of engagement you do
decide to provide.
>
> There are plenty of places to go bat around ideas that in an unformed
> state. Reddit has a C++ community. But by the time those ideas get *here*,
> they should have at least some thought put to them.
>
Yeah I know you want this place to be a Jedi Council (which it is) just for
Jedi (which I hope it isn't), but sorry Light Sabres are just too much
fun that it's unrealistic of you not to accept that non Jedi will also want
to play with Light Sabres too - even if they don't know how to use them
and even if it upsets Jedi masters. It's called community. It's unhealthy
not to have that. I think your grand desires miss the value of it and
that's a shame.
--
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/678d7ade-760c-4253-a52d-2bd5e828a0d7%40isocpp.org.
------=_Part_3079_1775094168.1470193727281
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px=
0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); borde=
r-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><div><blockq=
uote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left=
: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; borde=
r-left-style: solid;"><br></blockquote><br>So whatever you may feel towards=
people talking about rule changes and UB and so forth, it seems quite clea=
r that the people who set up this forum think that motivation is a pretty i=
mportant part of any idea/proposal.<br></div></div></blockquote><div><br></=
div><div>I'm sure the people who setup this forum would love every prop=
osal to be well thought out. And it's great there is=C2=A0advice here o=
n how best to create a proposal that has the best chance to succeed.</div><=
div><br></div><div>But that doesn't mean people must follow it, unless =
of course you want to get in the business of=C2=A0 banning accounts? </div>=
<div><br></div><div>So unless=C2=A0you're=C2=A0going to ban people, why=
not just be happy people=C2=A0are interested in the language to at least e=
ngage here at all? I think people are entitled to have a casual=C2=A0level=
=C2=A0of engagement=C2=A0if that's=C2=A0what they are=C2=A0comfortable =
with as long as they are not obnoxious. I don't see what sense or right=
=C2=A0there is to make those people feel unwelcome just because they aren&#=
39;t doing all they could for their proposal.</div><div>=C2=A0</div><blockq=
uote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left=
: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; borde=
r-left-style: solid;"><div dir=3D"ltr"><div><br>Maybe we just disagree with=
what this forum is for.<br></div></div></blockquote><div><br></div><div>I =
think so.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"=
margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 2=
04, 204); border-left-width: 1px; border-left-style: solid;"><div dir=3D"lt=
r"><div><br>Pursuant to the above, I was under the impression that this pla=
ce was for <i>well-considered</i>
proposals and ideas. </div></div></blockquote><div><br></div><div>It is. B=
ut that's why people will also want to engage here. Be happy about that=
..</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: =
0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204)=
; border-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><div>=
I thought the idea was that you'd actually spend time <i>on your own</i=
>, building the idea into a coherent form, then bringing it here for=20
commentary/improvement/spec analysis/etc.<br></div></div></blockquote><div>=
<br></div><div>=C2=A0I don't see how you can enforce that. So you shoul=
d Live and let live.</div><div><br></div><blockquote class=3D"gmail_quote" =
style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: r=
gb(204, 204, 204); border-left-width: 1px; border-left-style: solid;"><div =
dir=3D"ltr"><div><br>I personally feel very strongly in using=20
the time of complete strangers in a <i>productive</i> way. Inundating such =
people with ideas that clearly haven't had due consideration, lack any =
real motivation, or are just a priori trash does not constitute not using t=
heir time productively.<br></div></div></blockquote><div><br></div><div>Sor=
ry but you're too smart for your own good. People want to pick your bra=
ins. Can't you just take that as a sign of respect instead.=C2=A0Becaus=
e there is no obligation for you to assist any more than you want to other =
than try to be a decent person about whatever level of engagement you do de=
cide to provide.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" st=
yle=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb=
(204, 204, 204); border-left-width: 1px; border-left-style: solid;"><div di=
r=3D"ltr"><div><br>There are plenty of places to go bat around ideas that i=
n an unformed state. Reddit has a C++ community. But by the time those idea=
s get <i>here</i>, they should have at least some thought put to them.<br><=
/div></div></blockquote><div><br></div><div>Yeah I know you want this place=
to be a Jedi Council (which it is)=C2=A0just for Jedi (which I hope it isn=
't), but sorry Light Sabres are just too much fun=C2=A0that it's un=
realistic of you not to accept that non Jedi will also want to play with=C2=
=A0Light Sabres too -=C2=A0even if they don't know how to use them and=
=C2=A0even if it upsets Jedi masters. It's called community. It's u=
nhealthy not to have that. I think your grand desires miss the value of it =
and that's a shame.</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/678d7ade-760c-4253-a52d-2bd5e828a0d7%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/678d7ade-760c-4253-a52d-2bd5e828a0d7=
%40isocpp.org</a>.<br />
------=_Part_3079_1775094168.1470193727281--
------=_Part_3078_1331329152.1470193727280--
.
Author: Ren Industries <renindustries@gmail.com>
Date: Wed, 3 Aug 2016 00:06:28 -0400
Raw View
--94eb2c06bc2031a285053922f57d
Content-Type: text/plain; charset=UTF-8
Wait, so you are saying simply because something isn't strictly enforced,
we should abandon all pretense of rules and guidelines?
That seems like a recipe for trouble; asking people to follow the
guidelines set out explicitly for the purpose of maintaining this forum is
not a high barrier to ask people to jump over.
That is, after all, *why we have that page at all.*
On Tue, Aug 2, 2016 at 11:08 PM, <gmisocpp@gmail.com> wrote:
>
>>>
>> So whatever you may feel towards people talking about rule changes and UB
>> and so forth, it seems quite clear that the people who set up this forum
>> think that motivation is a pretty important part of any idea/proposal.
>>
>
> I'm sure the people who setup this forum would love every proposal to be
> well thought out. And it's great there is advice here on how best to create
> a proposal that has the best chance to succeed.
>
> But that doesn't mean people must follow it, unless of course you want to
> get in the business of banning accounts?
>
> So unless you're going to ban people, why not just be happy people are
> interested in the language to at least engage here at all? I think people
> are entitled to have a casual level of engagement if that's what they
> are comfortable with as long as they are not obnoxious. I don't see what
> sense or right there is to make those people feel unwelcome just because
> they aren't doing all they could for their proposal.
>
>
>>
>> Maybe we just disagree with what this forum is for.
>>
>
> I think so.
>
>
>>
>> Pursuant to the above, I was under the impression that this place was for
>> *well-considered* proposals and ideas.
>>
>
> It is. But that's why people will also want to engage here. Be happy about
> that.
>
>
>> I thought the idea was that you'd actually spend time *on your own*,
>> building the idea into a coherent form, then bringing it here for
>> commentary/improvement/spec analysis/etc.
>>
>
> I don't see how you can enforce that. So you should Live and let live.
>
>
>> I personally feel very strongly in using the time of complete strangers
>> in a *productive* way. Inundating such people with ideas that clearly
>> haven't had due consideration, lack any real motivation, or are just a
>> priori trash does not constitute not using their time productively.
>>
>
> Sorry but you're too smart for your own good. People want to pick your
> brains. Can't you just take that as a sign of respect instead. Because
> there is no obligation for you to assist any more than you want to other
> than try to be a decent person about whatever level of engagement you do
> decide to provide.
>
>
>>
>> There are plenty of places to go bat around ideas that in an unformed
>> state. Reddit has a C++ community. But by the time those ideas get *here*,
>> they should have at least some thought put to them.
>>
>
> Yeah I know you want this place to be a Jedi Council (which it is) just
> for Jedi (which I hope it isn't), but sorry Light Sabres are just too much
> fun that it's unrealistic of you not to accept that non Jedi will also want
> to play with Light Sabres too - even if they don't know how to use them
> and even if it upsets Jedi masters. It's called community. It's unhealthy
> not to have that. I think your grand desires miss the value of it and
> that's a shame.
>
> --
> 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/678d7ade-760c-4253-a52d-2bd5e828a0d7%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/678d7ade-760c-4253-a52d-2bd5e828a0d7%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>
--
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/CAMD6iD8LN6c%2BovzyUAmUHWHykcLLigMh9tOSeTy9zXc0N%3DvDyg%40mail.gmail.com.
--94eb2c06bc2031a285053922f57d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Wait, so you are saying simply because something isn't=
strictly enforced, we should abandon all pretense of rules and guidelines?=
<div>That seems like a recipe for trouble; asking people to follow the guid=
elines set out explicitly for the purpose of maintaining this forum is not =
a high barrier to ask people to jump over.=C2=A0</div><div><br></div><div>T=
hat is, after all, <i>why we have that page at all.</i></div></div><div cla=
ss=3D"gmail_extra"><br><div class=3D"gmail_quote">On Tue, Aug 2, 2016 at 11=
:08 PM, <span dir=3D"ltr"><<a href=3D"mailto:gmisocpp@gmail.com" target=
=3D"_blank">gmisocpp@gmail.com</a>></span> wrote:<br><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"><span class=3D""><blockquote class=3D"gmail_=
quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color=
:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><div dir=
=3D"ltr"><div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-widt=
h:1px;border-left-style:solid"><br></blockquote><br>So whatever you may fee=
l towards people talking about rule changes and UB and so forth, it seems q=
uite clear that the people who set up this forum think that motivation is a=
pretty important part of any idea/proposal.<br></div></div></blockquote><d=
iv><br></div></span><div>I'm sure the people who setup this forum would=
love every proposal to be well thought out. And it's great there is=C2=
=A0advice here on how best to create a proposal that has the best chance to=
succeed.</div><div><br></div><div>But that doesn't mean people must fo=
llow it, unless of course you want to get in the business of=C2=A0 banning =
accounts? </div><div><br></div><div>So unless=C2=A0you're=C2=A0going to=
ban people, why not just be happy people=C2=A0are interested in the langua=
ge to at least engage here at all? I think people are entitled to have a ca=
sual=C2=A0level=C2=A0of engagement=C2=A0if that's=C2=A0what they are=C2=
=A0comfortable with as long as they are not obnoxious. I don't see what=
sense or right=C2=A0there is to make those people feel unwelcome just beca=
use they aren't doing all they could for their proposal.</div><span cla=
ss=3D""><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);borde=
r-left-width:1px;border-left-style:solid"><div dir=3D"ltr"><div><br>Maybe w=
e just disagree with what this forum is for.<br></div></div></blockquote><d=
iv><br></div></span><div>I think so.</div><span class=3D""><div>=C2=A0</div=
><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;paddin=
g-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-=
left-style:solid"><div dir=3D"ltr"><div><br>Pursuant to the above, I was un=
der the impression that this place was for <i>well-considered</i>
proposals and ideas. </div></div></blockquote><div><br></div></span><div>I=
t is. But that's why people will also want to engage here. Be happy abo=
ut that.</div><span class=3D""><div>=C2=A0</div><blockquote class=3D"gmail_=
quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color=
:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><div dir=
=3D"ltr"><div>I thought the idea was that you'd actually spend time <i>=
on your own</i>, building the idea into a coherent form, then bringing it h=
ere for=20
commentary/improvement/spec analysis/etc.<br></div></div></blockquote><div>=
<br></div></span><div>=C2=A0I don't see how you can enforce that. So yo=
u should Live and let live.</div><span class=3D""><div><br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;=
border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:=
solid"><div dir=3D"ltr"><div><br>I personally feel very strongly in using=
=20
the time of complete strangers in a <i>productive</i> way. Inundating such =
people with ideas that clearly haven't had due consideration, lack any =
real motivation, or are just a priori trash does not constitute not using t=
heir time productively.<br></div></div></blockquote><div><br></div></span><=
div>Sorry but you're too smart for your own good. People want to pick y=
our brains. Can't you just take that as a sign of respect instead.=C2=
=A0Because there is no obligation for you to assist any more than you want =
to other than try to be a decent person about whatever level of engagement =
you do decide to provide.</div><span class=3D""><div>=C2=A0</div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;=
border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:=
solid"><div dir=3D"ltr"><div><br>There are plenty of places to go bat aroun=
d ideas that in an unformed state. Reddit has a C++ community. But by the t=
ime those ideas get <i>here</i>, they should have at least some thought put=
to them.<br></div></div></blockquote><div><br></div></span><div>Yeah I kno=
w you want this place to be a Jedi Council (which it is)=C2=A0just for Jedi=
(which I hope it isn't), but sorry Light Sabres are just too much fun=
=C2=A0that it's unrealistic of you not to accept that non Jedi will als=
o want to play with=C2=A0Light Sabres too -=C2=A0even if they don't kno=
w how to use them and=C2=A0even if it upsets Jedi masters. It's called =
community. It's unhealthy not to have that. I think your grand desires =
miss the value of it and that's a shame.</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" 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/678d7ade-760c-4253-a52d-2bd5e828a0d7%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/678d7ade-760c-=
4253-a52d-2bd5e828a0d7%40isocpp.org</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" 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/CAMD6iD8LN6c%2BovzyUAmUHWHykcLLigMh9t=
OSeTy9zXc0N%3DvDyg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAMD6iD8LN6c%=
2BovzyUAmUHWHykcLLigMh9tOSeTy9zXc0N%3DvDyg%40mail.gmail.com</a>.<br />
--94eb2c06bc2031a285053922f57d--
.
Author: gmisocpp@gmail.com
Date: Tue, 2 Aug 2016 21:29:18 -0700 (PDT)
Raw View
------=_Part_147_56587755.1470198558605
Content-Type: multipart/alternative;
boundary="----=_Part_148_2026808748.1470198558605"
------=_Part_148_2026808748.1470198558605
Content-Type: text/plain; charset=UTF-8
On Wednesday, August 3, 2016 at 4:06:30 PM UTC+12, Ren Industries wrote:
>
> Wait, so you are saying simply because something isn't strictly enforced,
> we should abandon all pretense of rules and guidelines?
> That seems like a recipe for trouble; asking people to follow the
> guidelines set out explicitly for the purpose of maintaining this forum is
> not a high barrier to ask people to jump over.
>
> That is, after all, *why we have that page at all.*
>
>
>
I'm saying what I said: I don't see a problem letting people engage at the
level they are comfortable with as long as they aren't being wildly
obnoxious and that means they shouldn't have to put up with harassment for
simply not providing a proposal to the standard Nicol and possibly others
(you from the sound of it) would like. For example: I have no problem with
the recent "proposals" that sparked these debates. Clearly you do.
I'm clear about what I think you/Nicol should do about that - get over it.
Quite what you actually intend to do about it and can do, is up to you and
really is anyone's guess. You can just keep up this kind of
harassment against relaxed (shall we say) "proposals" but why not just rely
on the fact such proposals are less likely to succeed be it's own just
reward? That'd be my preference instead of getting at people for engaging
at all and chasing them off to Reddit.
--
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/7cd9c678-e81b-4326-ace4-065ca3475e02%40isocpp.org.
------=_Part_148_2026808748.1470198558605
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br>On Wednesday, August 3, 2016 at 4:06:30 PM UTC+12, Ren=
Industries wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0p=
x 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); bord=
er-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr">Wait, so yo=
u are saying simply because something isn't strictly enforced, we shoul=
d abandon all pretense of rules and guidelines?<div>That seems like a recip=
e for trouble; asking people to follow the guidelines set out explicitly fo=
r the purpose of maintaining this forum is not a high barrier to ask people=
to jump over.=C2=A0</div><div><br></div><div>That is, after all, <i>why we=
have that page at all.</i></div></div><div><br><br></div></blockquote><div=
><br></div><div>I'm saying what I said: I don't see a problem letti=
ng people engage at the level they are comfortable with as long as they are=
n't being wildly obnoxious and that means they shouldn't have to pu=
t up with harassment for simply not providing a proposal to the standard Ni=
col and possibly others (you from the sound of it) would like. For example:=
I have no problem=C2=A0with the recent "proposals" that sparked =
these debates. Clearly you do.</div><div><br></div><div>I'm clear about=
what I think you/Nicol should do about that - get over it.</div><div>Quite=
what you actually intend to do about it and can do, is up to you and reall=
y is anyone's guess. You=C2=A0can just keep up this kind of harassment=
=C2=A0against=C2=A0relaxed (shall we say) "proposals" but why not=
just rely on the fact such proposals are less likely to succeed be it'=
s own just reward? That'd be my=C2=A0preference instead of getting at p=
eople for engaging at all and chasing them off to Reddit.</div><div><br></d=
iv></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/7cd9c678-e81b-4326-ace4-065ca3475e02%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7cd9c678-e81b-4326-ace4-065ca3475e02=
%40isocpp.org</a>.<br />
------=_Part_148_2026808748.1470198558605--
------=_Part_147_56587755.1470198558605--
.
Author: Antonio Perez <antonio@perezexcelsior.com>
Date: Wed, 3 Aug 2016 07:44:29 -0700 (PDT)
Raw View
------=_Part_16_1900785621.1470235469429
Content-Type: multipart/alternative;
boundary="----=_Part_17_192069897.1470235469435"
------=_Part_17_192069897.1470235469435
Content-Type: text/plain; charset=UTF-8
In response to "what's the point", I'm proposing the feature for the
following reasons:
1. To provide coders with a method to reduce ambiguity in situations
such as *ptr++ and ++*ptr (they could just use the reference) (those two
lines of code do entirely different things)
1. Also:
double DotProduct(double* l1, double* l2, int len)
{
union { double* v1_ptr = l1; double& v1; };
union { double* v2_ptr= l2; double& v2; };
double sum = 0.0;
for(int i=0;i<len;++i){
sum += v1*v2;
v1_ptr++;
v2_ptr++;
}
return sum;
}
//As opposed to:
void DotProduct(double* l1, double* l2, int len)
{
double* scan1 = l1;
double* scan2 = l2;
double sum = 0.0;
for(int i=0;i<len;++i){
sum += *scan1**scan2;//Looks like exponentiation
scan1++;
scan2++;
}
return sum;
}
2. To provide another piece of syntactic sugar, improving code
readability without harming performance
1. This could help in cases where programmers don't want to use
std::reference_wrapper because another part of the code breaks with
optimization, and without optimization std::reference_wrapper slows down
code
3. To increase compatibility with existing code written on linux and
compiled with c++/g++ (I didn't realize that my code was illegal till I
tried doing something similar in visual studio)
4. Because it's illegal to return a reference to a member variable
within a function, but for some reason it's legal to return a
std::reference_wrapper to that variable, resulting in potentially undefined
behavior. If a union containing a reference and a pointer were used in
place of std::reference_wrapper, and it referenced a member variable, and
the programmer tried to return one of those two, it'd throw an exception
(as it's supposed to).
On Tuesday, August 2, 2016 at 12:35:18 AM UTC-6, D. B. wrote:
>
> On Tue, Aug 2, 2016 at 1:56 AM, Miro Knejp <miro....@gmail.com
> <javascript:>> wrote:
>
>>
>> I sometimes really wonder what's going on in this forum. Someone suggests
>> a change to the language rules and more often than not one of the first
>> responses is "that's not possible because it violates the rules". They are
>> so stubbornly grabbing on to the current wording it seems like they are
>> incapable of even imagining the rules could be different.
>>
>> "I want to change rule X in the standard so I can do Y" - "But you can't
>> because rule X doesn't allow it" - "But that's why I want to change it..."
>> - "Well no you can't do Y because it violates rule X." - *smashes head
>> against desk*
>>
>> What's the point of such an exchange?
>> Am I the only one noticing this...
>
>
> "What's the point" - Good question. OP hasn't yet provided an answer.
>
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/679a44ec-1f66-4f97-ab0c-57be90cfd399%40isocpp.org.
------=_Part_17_192069897.1470235469435
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">In response to "what's the point", I'm p=
roposing the feature for the following reasons:<br><ol><li>To provide coder=
s with a method to reduce ambiguity in situations such as *ptr++ and ++*ptr=
(they could just use the reference) (those two lines of code do entirely d=
ifferent things)</li><ol><li>Also:<code></code><div class=3D"prettyprint" s=
tyle=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 1=
87); border-style: solid; border-width: 1px; word-wrap: break-word;"><code =
class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #=
008;" class=3D"styled-by-prettify">double</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=
=3D"styled-by-prettify">DotProduct</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">(</span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">double</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">*</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> l1</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span =
style=3D"color: #008;" class=3D"styled-by-prettify">double</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">*</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> l2</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">int</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> len</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><div style=
=3D"margin-left: 40px;"><span style=3D"color: #008;" class=3D"styled-by-pre=
ttify">union</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">double</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">*</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> v1_ptr </span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> l1</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">double</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">&</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> v1=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">};</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">union</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify"=
>double</span><span style=3D"color: #660;" class=3D"styled-by-prettify">*</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> v2_ptr</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify"> l2</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" =
class=3D"styled-by-prettify">double</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">&</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> v2</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">};</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">double</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> sum </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #066;=
" class=3D"styled-by-prettify">0.0</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">for</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">(</span><span style=3D"color: #008;" class=3D"styled-by-prettify">int</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> i</span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=
=3D"color: #066;" class=3D"styled-by-prettify">0</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify">i</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify"><</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify">len</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">;++</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
i</span><span style=3D"color: #660;" class=3D"styled-by-prettify">){</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><div s=
tyle=3D"margin-left: 40px;"><span style=3D"color: #000;" class=3D"styled-by=
-prettify">sum </span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">+=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
v1</span><span style=3D"color: #660;" class=3D"styled-by-prettify">*</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify">v2</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br>v1_ptr</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">++;</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"><br>v2_ptr</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">++;</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"><br></span></div><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"><br>return sum;<br></span></div><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br><br></span><span style=3D"color: #800;" class=
=3D"styled-by-prettify">//As opposed to:</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"><br></span><br><code class=3D"prettyprint"><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">void</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"co=
lor: #606;" class=3D"styled-by-prettify">DotProduct</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #008=
;" class=3D"styled-by-prettify">double</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">*</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> l1</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">double=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">*</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> l2</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;=
" class=3D"styled-by-prettify">int</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> len</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></=
span><div style=3D"margin-left: 40px;"><span style=3D"color: #000;" class=
=3D"styled-by-prettify"></span><span style=3D"color: #008;" class=3D"styled=
-by-prettify">double</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">*</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> scan1 </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> l1</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify">;<br></span><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">double</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">*</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> scan2 </span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> l2</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify">;<br></span><span style=3D"color: #008;" class=3D=
"styled-by-prettify">double</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> sum </span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> </span><span style=3D"color: #066;" class=3D"styled-by-prettify">0.0<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span sty=
le=3D"color: #008;" class=3D"styled-by-prettify">for</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">int</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> i</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">=3D</span><span style=3D"color: #066;" class=3D"styled-by=
-prettify">0</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">i</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify"><</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify">len</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">;++</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify">i</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">){</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span><div style=3D"margin-left: 40px;"><span =
style=3D"color: #000;" class=3D"styled-by-prettify">sum </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">+=3D</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> *scan1</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">**</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify">scan2</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">//Looks like exponentiation<br>scan1</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">++;</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"><br>scan2</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">++;</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"><br></span></div><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"><br>return sum;<br></span></div><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span></code></div></code></div></li></ol><li>=
To provide another piece of syntactic sugar, improving code readability wit=
hout harming performance</li><ol><li>This could help in cases where program=
mers don't want to use std::reference_wrapper because another part of t=
he code breaks with optimization, and without optimization std::reference_w=
rapper slows down code<br></li></ol><li>To increase compatibility with exis=
ting code written on linux and compiled with c++/g++ (I didn't realize =
that my code was illegal till I tried doing something similar in visual stu=
dio)</li><li>Because it's illegal to return a reference to a member var=
iable within a function, but for some reason it's legal to return a std=
::reference_wrapper to that variable, resulting in potentially undefined be=
havior. If a union containing a reference and a pointer were used in place =
of std::reference_wrapper, and it referenced a member variable, and the pro=
grammer tried to return one of those two, it'd throw an exception (as i=
t's supposed to).<br></li></ol><br>On Tuesday, August 2, 2016 at 12:35:=
18 AM UTC-6, D. B. wrote:<blockquote class=3D"gmail_quote" style=3D"margin:=
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div =
dir=3D"ltr"><div><div class=3D"gmail_quote">On Tue, Aug 2, 2016 at 1:56 AM,=
Miro Knejp <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank"=
gdf-obfuscated-mailto=3D"CjDp5X3hBgAJ" rel=3D"nofollow" onmousedown=3D"thi=
s.href=3D'javascript:';return true;" onclick=3D"this.href=3D'ja=
vascript:';return true;">miro....@gmail.com</a>></span> wrote:<br><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex"><br>
I sometimes really wonder what's going on in this forum. Someone sugges=
ts a change to the language rules and more often than not one of the first =
responses is "that's not possible because it violates the rules&qu=
ot;. They are so stubbornly grabbing on to the current wording it seems lik=
e they are incapable of even imagining the rules could be different.<br>
<br>
"I want to change rule X in the standard so I can do Y" - "B=
ut you can't because rule X doesn't allow it" - "But that=
's why I want to change it..." - "Well no you can't do Y =
because it violates rule X." - *smashes head against desk*<br>
<br>
What's the point of such an exchange?<br>
Am I the only one noticing this...</blockquote><div><br></div><div>"Wh=
at's the point" - Good question. OP hasn't yet provided an ans=
wer. <br></div></div></div></div>
</blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/679a44ec-1f66-4f97-ab0c-57be90cfd399%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/679a44ec-1f66-4f97-ab0c-57be90cfd399=
%40isocpp.org</a>.<br />
------=_Part_17_192069897.1470235469435--
------=_Part_16_1900785621.1470235469429--
.
Author: Antonio Perez <antonio@perezexcelsior.com>
Date: Wed, 3 Aug 2016 07:49:03 -0700 (PDT)
Raw View
------=_Part_79_1034278953.1470235744064
Content-Type: multipart/alternative;
boundary="----=_Part_80_880903832.1470235744064"
------=_Part_80_880903832.1470235744064
Content-Type: text/plain; charset=UTF-8
It shouldn't affect the risk of creating a NULL reference... any code that
would use this would already be accessing the value inside a pointer, and
if that pointer were null then it'd segfault. The programmer would still
need to check for null pointers. But it would reduce the possibility of
some mistakes
On Tuesday, August 2, 2016 at 8:58:02 PM UTC-6, Nicol Bolas wrote:
>
> Something just occurred to me about this proposal. This is essentially
> making rebindable references a language feature. *That* is the point of
> it.
>
> And while I dislike the very idea of the concept... using a `union` is a
> surprisingly effective way to handle it.
>
> One of the big issues with any form of rebindable reference is the
> distinction between binding the reference and assignments to the value
> being referenced. Since C++ doesn't let you rebind references, we know that
> `r = val;` is always assigning to the value stored in or referenced by `r`.
>
> Even if we have support for `operator.` and apply it to
> `reference_wrapper`, we would still have to make that kind of distinction.
> Right now, `reference_wrapper` doesn't even have an `operator=` overload
> for `T`, so you can't assign to the value being referenced. If we added
> such an overload, to make it more reference like, then the distinction
> between rebinding the reference and assigning to it would be this:
>
> r = val; //Assignment
> r = std::ref(val); //Rebinding
>
> While that is certainly functional, it's also rather weird. By contrast,
> using this `union` idea makes it a bit more clear:
>
> r.ref = val;
> r.ptr = &val;
>
> Please do not take this as an endorsement of this idea. I still find it
> rather pointless (I've never understood the obsession some people have with
> references or `operator.`) and one can get equivalent behavior without a
> language change (`reference_wrapper<T>`, or just a `T*`). And it makes it
> way too easy to create a NULL reference.
>
--
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/e05b3e60-8c20-4ce4-afe7-744983aca131%40isocpp.org.
------=_Part_80_880903832.1470235744064
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">It shouldn't affect the risk of creating a NULL refere=
nce... any code that would use this would already be accessing the value in=
side a pointer, and if that pointer were null then it'd segfault. The p=
rogrammer would still need to check for null pointers. But it would reduce =
the possibility of some mistakes<br><br>On Tuesday, August 2, 2016 at 8:58:=
02 PM UTC-6, Nicol Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
><div dir=3D"ltr">Something just occurred to me about this proposal. This i=
s essentially making rebindable references a language feature. <i>That</i> =
is the point of it.<br><br>And while I dislike the very idea of the concept=
.... using a `union` is a surprisingly effective way to handle it.<br><br>On=
e of the big issues with any form of rebindable reference is the distinctio=
n between binding the reference and assignments to the value being referenc=
ed. Since C++ doesn't let you rebind references, we know that `r =3D va=
l;` is always assigning to the value stored in or referenced by `r`.<br><br=
>Even if we have support for `operator.` and apply it to `reference_wrapper=
`, we would still have to make that kind of distinction. Right now, `refere=
nce_wrapper` doesn't even have an `operator=3D` overload for `T`, so yo=
u can't assign to the value being referenced. If we added such an overl=
oad, to make it more reference like, then the distinction between rebinding=
the reference and assigning to it would be this:<br><br><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:=
#000">r </span><span style=3D"color:#660">=3D</span><span style=3D"color:#0=
00"> val</span><span style=3D"color:#660">;</span><span style=3D"color:#000=
"> </span><span style=3D"color:#800">//Assignment</span><span style=3D"colo=
r:#000"><br>r </span><span style=3D"color:#660">=3D</span><span style=3D"co=
lor:#000"> std</span><span style=3D"color:#660">::</span><span style=3D"col=
or:#008">ref</span><span style=3D"color:#660">(</span><span style=3D"color:=
#000">val</span><span style=3D"color:#660">);</span><span style=3D"color:#0=
00"> </span><span style=3D"color:#800">//Rebinding</span><span style=3D"col=
or:#000"><br></span></div></code></div><br>While that is certainly function=
al, it's also rather weird. By contrast, using this `union` idea makes =
it a bit more clear:<br><br><div style=3D"background-color:rgb(250,250,250)=
;border-color:rgb(187,187,187);border-style:solid;border-width:1px;word-wra=
p:break-word"><code><div><span style=3D"color:#000">r</span><span style=3D"=
color:#660">.</span><span style=3D"color:#008">ref</span><span style=3D"col=
or:#000"> </span><span style=3D"color:#660">=3D</span><span style=3D"color:=
#000"> val</span><span style=3D"color:#660">;</span><span style=3D"color:#0=
00"><br>r</span><span style=3D"color:#660">.</span><span style=3D"color:#00=
0">ptr </span><span style=3D"color:#660">=3D</span><span style=3D"color:#00=
0"> </span><span style=3D"color:#660">&</span><span style=3D"color:#000=
">val</span><span style=3D"color:#660">;</span></div></code></div><br>Pleas=
e do not take this as an endorsement of this idea. I still find it rather p=
ointless (I've never understood the obsession some people have with ref=
erences or `operator.`) and one can get equivalent behavior without a langu=
age change (`reference_wrapper<T>`, or just a `T*`). And it makes it =
way too easy to create a NULL reference.<br></div></blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/e05b3e60-8c20-4ce4-afe7-744983aca131%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e05b3e60-8c20-4ce4-afe7-744983aca131=
%40isocpp.org</a>.<br />
------=_Part_80_880903832.1470235744064--
------=_Part_79_1034278953.1470235744064--
.
Author: "D. B." <db0451@gmail.com>
Date: Wed, 3 Aug 2016 15:50:59 +0100
Raw View
--047d7bf0d2ba373de705392bf62c
Content-Type: text/plain; charset=UTF-8
On Wed, Aug 3, 2016 at 3:44 PM, Antonio Perez <antonio@perezexcelsior.com>
wrote:
> In response to "what's the point", I'm proposing the feature for the
> following reasons:
>
> 1. To provide coders with a method to reduce ambiguity in situations
> such as *ptr++ and ++*ptr (they could just use the reference) (those two
> lines of code do entirely different things)
>
> Sorry, but I have no sympathy for coders who won't just learn operator
precedence rules or at least use parentheses so they don't have to. This is
not worth all the repercussions of having to define a bit representation of
references, something that doesn't currently exist - and to update all the
countless related rules that the proposal renders invalid/ambiguous.
> This could help in cases where programmers don't want to use
> std::reference_wrapper because another part of the code breaks with
> optimization, and without optimization std::reference_wrapper slows down
> code
>
If "another part of the code breaks with optimization", then the code is
ill-formed, and again, I have no sympathy whatsoever.
> To provide another piece of syntactic sugar, improving code readability
> without harming performance
>
Actually, if you ask me, having to define 2 names is* less* sugary than
simply dereferencing the flippin' pointer that you already have right
there. Why is that such an onerous proposition for you?
To increase compatibility with existing code written on linux and compiled
> with c++/g++ (I didn't realize that my code was illegal till I tried doing
> something similar in visual studio)
>
See above. The presence of any amount of ill-formed code doesn't justify
retroactively legitimising it. UB is UB.
> Because it's illegal to return a reference to a member variable within a
> function, but for some reason it's legal to return a std::reference_wrapper
> to that variable, resulting in potentially undefined behavior. If a union
> containing a reference and a pointer were used in place of
> std::reference_wrapper, and it referenced a member variable, and the
> programmer tried to return one of those two, it'd throw an exception (as
> it's supposed to).
>
What? A union cannot throw an exception.
Do you mean a compile-time error? You can get around any of those if you
really trick the compiler. I don't see how it's relevant.
--
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/CACGiwhHyZUQFHpF%3Deswett1hiJb4UYB0W%2B-H8M2HKDnELu_c6A%40mail.gmail.com.
--047d7bf0d2ba373de705392bf62c
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 W=
ed, Aug 3, 2016 at 3:44 PM, Antonio Perez <span dir=3D"ltr"><<a href=3D"=
mailto:antonio@perezexcelsior.com" target=3D"_blank">antonio@perezexcelsior=
..com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:=
1ex"><div dir=3D"ltr">In response to "what's the point", I=
9;m proposing the feature for the following reasons:<br><ol><li>To provide =
coders with a method to reduce ambiguity in situations such as *ptr++ and +=
+*ptr (they could just use the reference) (those two lines of code do entir=
ely different things)<br><span style=3D"color:rgb(0,0,0)"></span></li></ol>=
</div></blockquote><div>Sorry, but I have no sympathy for coders who won=
9;t just learn operator precedence rules or at least use parentheses so the=
y don't have to. This is not worth all the repercussions of having to d=
efine a bit representation of references, something that doesn't curren=
tly exist - and to update all the countless related rules that the proposal=
renders invalid/ambiguous.<br></div><div>=C2=A0</div><blockquote class=3D"=
gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(20=
4,204,204);padding-left:1ex"><div>This could help in cases where programmer=
s don't want to use std::reference_wrapper because another part of the =
code breaks with optimization, and without optimization std::reference_wrap=
per slows down code<br></div></blockquote><div>=C2=A0<div>If "another =
part of the code breaks with optimization", then the code is ill-forme=
d, and again, I have no sympathy whatsoever.<br></div><div>=C2=A0</div></di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left:1px solid rgb(204,204,204);padding-left:1ex"><div>To provide another=
piece of syntactic sugar, improving code readability without harming perfo=
rmance</div></blockquote><div>=C2=A0<br></div><div>Actually, if you ask me,=
having to define 2 names is<i> less</i> sugary than simply dereferencing t=
he flippin' pointer that you already have right there. Why is that such=
an onerous proposition for you?<br><br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,20=
4);padding-left:1ex"><div>To increase compatibility with existing code writ=
ten on linux and compiled with c++/g++ (I didn't realize that my code w=
as illegal till I tried doing something similar in visual studio)</div></bl=
ockquote><div>=C2=A0</div><div>See above. The presence of any amount of ill=
-formed code doesn't justify retroactively legitimising it. UB is UB.<b=
r></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">=
<div>Because it's illegal to return a reference to a member variable wi=
thin a function, but for some reason it's legal to return a std::refere=
nce_wrapper to that variable, resulting in potentially undefined behavior. =
If a union containing a reference and a pointer were used in place of std::=
reference_wrapper, and it referenced a member variable, and the programmer =
tried to return one of those two, it'd throw an exception (as it's =
supposed to).<br></div></blockquote><div><br></div><div>What? A union canno=
t throw an exception.<br><br>Do you mean a compile-time error? You can get =
around any of those if you really trick the compiler. I don't see how i=
t's relevant. <br></div></div><br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CACGiwhHyZUQFHpF%3Deswett1hiJb4UYB0W%=
2B-H8M2HKDnELu_c6A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhHyZUQF=
HpF%3Deswett1hiJb4UYB0W%2B-H8M2HKDnELu_c6A%40mail.gmail.com</a>.<br />
--047d7bf0d2ba373de705392bf62c--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 3 Aug 2016 11:31:08 -0700 (PDT)
Raw View
------=_Part_3653_248774267.1470249068448
Content-Type: multipart/alternative;
boundary="----=_Part_3654_951624313.1470249068449"
------=_Part_3654_951624313.1470249068449
Content-Type: text/plain; charset=UTF-8
On Wednesday, August 3, 2016 at 10:44:29 AM UTC-4, Antonio Perez wrote:
>
> In response to "what's the point", I'm proposing the feature for the
> following reasons:
>
> 1. To provide coders with a method to reduce ambiguity in situations
> such as *ptr++ and ++*ptr (they could just use the reference) (those two
> lines of code do entirely different things)
>
> I feel that a much better solution is to avoid those situations
altogether. For example, your code can be rewritten as follows:
double DotProduct(gsl::span<double> l1, gsl::span<double> l2)
{
double sum = 0;
for(auto i = 0; i < l1.size(); ++i)
sum += l1[i] + l2[i];
return sum;
}
There are also zip iterator gymnastics that can be employed if you like
that sort of thing.
I know this is just an example, but my point is that it's better to *avoid*
these kinds of ambiguous situations to begin with than to go around adding
language features. We have many tools these days to deal with arrays and
views of arrays that don't require direct use of pointer arithmetic. And
thus, things like ++ don't have to be ambiguous.
Not only that, the above code is much *safer*. The user doesn't have to
pass an explicit size, which they could accidentally get wrong. The
receiving code can assert that the two arrays are differently sized. And so
forth.
>
> 1. To increase compatibility with existing code written on linux and
> compiled with c++/g++ (I didn't realize that my code was illegal till I
> tried doing something similar in visual studio)
>
> The fact that one platform supports a compiler extension and another
platform does not is insufficient justification to standardize that
extension.
To avoid falling into this pitfall in the future, always use the strict
conformance settings on your compiler-of-choice.
>
> 1. Because it's illegal to return a reference to a member variable
> within a function, but for some reason it's legal to return a
> std::reference_wrapper to that variable, resulting in potentially undefined
> behavior. If a union containing a reference and a pointer were used in
> place of std::reference_wrapper, and it referenced a member variable, and
> the programmer tried to return one of those two, it'd throw an exception
> (as it's supposed to).
>
> I'm not sure what you mean by "reference to a member variable within a
function" here. Objects have member variables, not functions. And you can
return a reference to a stack variable; it's just undefined behavior to do
so. It's not a compile error.
Perhaps you're talking about how compilers will warn you if you return a
reference to a stack variable, but won't warn you for returning a
`reference_wrapper` to a stack variable. If that's the case, I don't see
how a union's going to help. If a compiler can figure out that you're using
a `union` to type-pun a pointer into a reference, and if it can figure out
that the pointer you stored into it is a pointer to a stack variable, and
if it can figure out that you're returning the reference to that stack
variable... it can just as easily be taught to understand what
`reference_wrapper` is doing.
And if it can't, I'm sure a static analysis tool can.
--
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/8c30e42a-b196-4963-ba67-b0b25ec0c7d5%40isocpp.org.
------=_Part_3654_951624313.1470249068449
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, August 3, 2016 at 10:44:29 AM UTC-4, Antonio=
Perez 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">=
In response to "what's the point", I'm proposing the feat=
ure for the following reasons:<br><ol><li>To provide coders with a method t=
o reduce ambiguity in situations such as *ptr++ and ++*ptr (they could just=
use the reference) (those two lines of code do entirely different things)<=
/li></ol></div></blockquote><div>I feel that a much better solution is to a=
void those situations altogether. For example, your code can be rewritten a=
s follows:<br><br><div class=3D"prettyprint" style=3D"background-color: rgb=
(250, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; bor=
der-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div cl=
ass=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">double</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">DotProd=
uct</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"><code class=3D"p=
rettyprint"><span style=3D"color: #000;" class=3D"styled-by-prettify">gsl</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"></span></code>span</=
span><span style=3D"color: #080;" class=3D"styled-by-prettify"><double&g=
t;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> l1</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> gsl</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify">span</span><span style=3D"color: #08=
0;" class=3D"styled-by-prettify"><double></span><span style=3D"color:=
#000;" class=3D"styled-by-prettify"> l2</span><span style=3D"color: #660;"=
class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"><br>=C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-pre=
ttify">double</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> sum </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #066;" class=3D"styled-by-prettify">0</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </span><span style=3D"c=
olor: #008;" class=3D"styled-by-prettify">for</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">auto</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> i </span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #066;" class=3D"styled-by-prettify">0</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> i </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify"><</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> l1</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">.</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify">size</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">();</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">++</span><span style=3D"color: #000;" class=3D"styled-by-prettify">i</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 sum <=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">+=3D</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> l1</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">[</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify">i</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">]</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">+</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> l2</span><span style=3D"color: #660;" class=3D"styled-by-prettify">[=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify">i</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">];</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </span><span sty=
le=3D"color: #008;" class=3D"styled-by-prettify">return</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> sum</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">}</span></div></code></div><br>There are also zip=
iterator gymnastics that can be employed if you like that sort of thing.<b=
r><br>I know this is just an example, but my point is that it's better =
to <i>avoid</i> these kinds of ambiguous situations to begin with than to g=
o around adding language features. We have many tools these days to deal wi=
th arrays and views of arrays that don't require direct use of pointer =
arithmetic. And thus, things like ++ don't have to be ambiguous.<br><br=
>Not only that, the above code is much <i>safer</i>. The user doesn't h=
ave to pass an explicit size, which they could accidentally get wrong. The =
receiving code can assert that the two arrays are differently sized. And so=
forth.<br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><ol><li>To increase compatibility with existing code written on linux a=
nd compiled with c++/g++ (I didn't realize that my code was illegal til=
l I tried doing something similar in visual studio)</li></ol></div></blockq=
uote><div>The fact that one platform supports a compiler extension and anot=
her platform does not is insufficient justification to standardize that ext=
ension.<br><br>To avoid falling into this pitfall in the future, always use=
the strict conformance settings on your compiler-of-choice.<br></div><bloc=
kquote 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"><ol><li>Because it=
's illegal to return a reference to a member variable within a function=
, but for some reason it's legal to return a std::reference_wrapper to =
that variable, resulting in potentially undefined behavior. If a union cont=
aining a reference and a pointer were used in place of std::reference_wrapp=
er, and it referenced a member variable, and the programmer tried to return=
one of those two, it'd throw an exception (as it's supposed to).<b=
r></li></ol></div></blockquote><div>I'm not sure what you mean by "=
;reference to a member variable within a function" here. Objects have =
member variables, not functions. And you can return a reference to a stack =
variable; it's just undefined behavior to do so. It's not a compile=
error.<br><br>Perhaps you're talking about how compilers will warn you=
if you return a reference to a stack variable, but won't warn you for =
returning a `reference_wrapper` to a stack variable. If that's the case=
, I don't see how a union's going to help. If a compiler can figure=
out that you're using a `union` to type-pun a pointer into a reference=
, and if it can figure out that the pointer you stored into it is a pointer=
to a stack variable, and if it can figure out that you're returning th=
e reference to that stack variable... it can just as easily be taught to un=
derstand what `reference_wrapper` is doing.<br><br>And if it can't, I&#=
39;m sure a static analysis tool can.<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/8c30e42a-b196-4963-ba67-b0b25ec0c7d5%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/8c30e42a-b196-4963-ba67-b0b25ec0c7d5=
%40isocpp.org</a>.<br />
------=_Part_3654_951624313.1470249068449--
------=_Part_3653_248774267.1470249068448--
.
Author: szollosi.lorand@gmail.com
Date: Sun, 9 Oct 2016 10:12:38 -0700 (PDT)
Raw View
------=_Part_349_1492631182.1476033158542
Content-Type: multipart/alternative;
boundary="----=_Part_350_69177571.1476033158543"
------=_Part_350_69177571.1476033158543
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Hi,
Loosely related. Is it UB to placement new into non-polymorphic base class=
=20
this ptr? I.e., new((Base*)this) Base(...); . Technically this works and I=
=20
fail to see why a given implementation would do anything to prevent it, but=
=20
still.. Because, if we allow for this, we have reassignable reference=20
*member* variables with sort of proper syntax.
Thanks,
-lorro
2016. augusztus 1., h=C3=A9tf=C5=91 22:38:57 UTC+2 id=C5=91pontban Antonio =
Perez a=20
k=C3=B6vetkez=C5=91t =C3=ADrta:
>
> Specify that
>
> 1. Unions may store references
> 2. A reference stored inside a union must be implemented as a pointer
> 3. If a union contains a pointer T* and a reference T&, then setting=
=20
> the location of the pointer, and then reading from the reference, is=
=20
> DEFINED BEHAVIOR which will read the value stored at the pointer
> =20
> template<typename T> union PtrOrRef=20
> {
> T* ptr;
> T& ref;
> };
> #include <iostream>
> int main(){
> int x =3D 0;
> PtrOrRef<int> p{x};//Sets p.ref=3Dx
> int y =3D 5;
> p.ptr =3D &y;
> std::cout << p.ref << std::endl; //Defined as being equivalent to=20
> std::cout << (*p.ptr) << std::endl;
> }
>
> Example implementation: g++ compiler
>
>
--=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/7fad3a1d-fd6b-477c-84fd-fed45de6d2ca%40isocpp.or=
g.
------=_Part_350_69177571.1476033158543
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi,<br><br>Loosely related. Is it UB to placement new into=
non-polymorphic base class this ptr? I.e., new((Base*)this) Base(...); . T=
echnically this works and I fail to see why a given implementation would do=
anything to prevent it, but still.. Because, if we allow for this, we have=
reassignable reference <i>member</i> variables with sort of proper syntax.=
<br><br>Thanks,<br>-lorro<br><br>2016. augusztus 1., h=C3=A9tf=C5=91 22:38:=
57 UTC+2 id=C5=91pontban Antonio Perez a k=C3=B6vetkez=C5=91t =C3=ADrta:<bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">Specify that<br>=
<ol><li>Unions may store references</li><li>A reference stored inside a uni=
on must be implemented as a pointer</li><li>If a union contains a pointer T=
* and a reference T&, then setting the location of the pointer, and the=
n reading from the reference, is DEFINED BEHAVIOR which will read the value=
stored at the pointer<br></li></ol><div style=3D"background-color:rgb(250,=
250,250);border-color:rgb(187,187,187);border-style:solid;border-width:1px;=
word-wrap:break-word"><code><div><span style=3D"color:#008">template</span>=
<span style=3D"color:#660"><</span><span style=3D"color:#008">typename</=
span><span style=3D"color:#000"> T</span><span style=3D"color:#660">></s=
pan><span style=3D"color:#000"> </span><span style=3D"color:#008">union</sp=
an><span style=3D"color:#000"> </span><span style=3D"color:#606">PtrOrRef</=
span><span style=3D"color:#000"> <br></span><span style=3D"color:#660">{</s=
pan><span style=3D"color:#000"><br></span><div style=3D"margin-left:40px"><=
span style=3D"color:#000">T</span><span style=3D"color:#660">*</span><span =
style=3D"color:#000"> ptr</span><span style=3D"color:#660">;</span><span st=
yle=3D"color:#000"><br>T</span><span style=3D"color:#660">&</span><span=
style=3D"color:#000"> </span><span style=3D"color:#008">ref</span><span st=
yle=3D"color:#660">;</span><span style=3D"color:#000"><br></span></div><spa=
n style=3D"color:#660">};</span><span style=3D"color:#000"><br></span><span=
style=3D"color:#800">#include</span><span style=3D"color:#000"> </span><sp=
an style=3D"color:#080"><iostream></span><span style=3D"color:#000"><=
br></span><span style=3D"color:#008">int</span><span style=3D"color:#000"> =
main</span><span style=3D"color:#660">(){</span><span style=3D"color:#000">=
<br></span><div style=3D"margin-left:40px"><span style=3D"color:#008">int</=
span><span style=3D"color:#000"> x </span><span style=3D"color:#660">=3D</s=
pan><span style=3D"color:#000"> </span><span style=3D"color:#066">0</span><=
span style=3D"color:#660">;</span><span style=3D"color:#000"><br></span></d=
iv><div style=3D"margin-left:40px"><span style=3D"color:#606">PtrOrRef</spa=
n><span style=3D"color:#080"><int></span><span style=3D"color:#000"> =
p</span><span style=3D"color:#660">{</span><span style=3D"color:#000">x</sp=
an><span style=3D"color:#660">};</span><span style=3D"color:#800">//Sets p.=
ref=3Dx</span><span style=3D"color:#000"><br></span><span style=3D"color:#0=
08">int</span><span style=3D"color:#000"> y </span><span style=3D"color:#66=
0">=3D</span><span style=3D"color:#000"> </span><span style=3D"color:#066">=
5</span><span style=3D"color:#660">;</span><span style=3D"color:#000"><br>p=
</span><span style=3D"color:#660">.</span><span style=3D"color:#000">ptr </=
span><span style=3D"color:#660">=3D</span><span style=3D"color:#000"> </spa=
n><span style=3D"color:#660">&</span><span style=3D"color:#000">y</span=
><span style=3D"color:#660">;</span><span style=3D"color:#000"><br>std</spa=
n><span style=3D"color:#660">::</span><span style=3D"color:#000">cout </spa=
n><span style=3D"color:#660"><<</span><span style=3D"color:#000"> p</=
span><span style=3D"color:#660">.</span><span style=3D"color:#008">ref</spa=
n><span style=3D"color:#000"> </span><span style=3D"color:#660"><<</s=
pan><span style=3D"color:#000"> std</span><span style=3D"color:#660">::</sp=
an><span style=3D"color:#000">endl</span><span style=3D"color:#660">;</span=
><span style=3D"color:#000"> </span><span style=3D"color:#800">//Defined as=
being equivalent to std::cout << (*p.ptr) << std::endl;</span>=
<span style=3D"color:#000"><br></span></div><span style=3D"color:#660">}</s=
pan><span style=3D"color:#000"><br></span></div></code></div><br>Example im=
plementation: g++ compiler<br><br></div></blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/7fad3a1d-fd6b-477c-84fd-fed45de6d2ca%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7fad3a1d-fd6b-477c-84fd-fed45de6d2ca=
%40isocpp.org</a>.<br />
------=_Part_350_69177571.1476033158543--
------=_Part_349_1492631182.1476033158542--
.