Topic: Local variables that overstay their welcome
Author: Matthew Fioravante <fmatthew5876@gmail.com>
Date: Wed, 20 Aug 2014 07:24:46 -0700 (PDT)
Raw View
------=_Part_262_91671357.1408544686960
Content-Type: text/plain; charset=UTF-8
I've been using unique_ptr in several projects and one source of bugs I see
in general with move only types is accidentally using the object after it
has been moved from.
Lets look at some legacy code
struct F {
std::vector<int*> v;
~F() { for(auto i: v) { delete i; } }
void run() {
int* i = new int();
v.push_back(i);
doSomethingWith(i);
}
};
Now suppose we want to convert this to using unique_ptr, a worthy goal.
Heres a very easy mistake to make.
struct F {
std::vector<std::unique_ptr<i>> v;
void run() {
auto i = std::make_unique<int>();
v.push_back(std::move(i));
doSomethingWith(i.get());
}
};
The bug might be obvious in this small code snippet but if run() is a large
function its an easy mistake to make that cannot be caught at compile time.
One way to mitigate this is to introduce an extra scope
{
auto i = std::make_unique<int>();
v.push_back(std::move(i));
}
doSomethingWith(i.get()); //<-compiler error, there is no variable named i!
But adding extra scopes is not always possible when you have many local
variables all being used together and having different lifetimes. Also it
adds extra indentation.
Do you agree that this is a big enough source of bugs that it could use a
new feature to help the compiler detect and report these kinds of errors at
compile time? If so, what would such a feature look like?
Here are some ideas:
1) Add a new keyword to prematurely remove an object from the current
scope.
int i = 0;
foo(i); //Ok
kill i; //<-i is removed from the scope
bar(i); //Compiler error, i does not exist anymore!
int j = 0;
if(something) {
a(j); //<-Ok
kill j; //<-j is removed from the if scope
b(j); //<-compiler error
}
c(j); //<- Ok
kill j; //<-j is removed from the scope
d(j); //compiler error
This could be useful because I've found many time that I wish I could
remove a variable from the current scope when I know I won't need to use it
anymore and I want to prevent myself from writing a typo and reusing the
wrong variable. I sometimes find myself introducing new scopes just to
mitigate this problem.
There are some complications and/or potential use cases when names clash.
int i;
void foo() {
int i = 4;
foo(i); //calls foo on the local i
kill i;
bar(i); //calls bar on the global i
}
With this feature, you could kill the unique_ptr after moving from it,
preventing anyone from accidentally using it.
auto i = std::make_unique<int>(i);
v.push_back(std::move(i));
kill i;
doSomething(i.get()); //<-compiler error, i does not exist!
2) Add some kind of attribute or tag. This is almost the same thing, except
the local variable name not actually removed from the scope. In particular
the example with the global would not work.
auto i = std::make_unique<int>(i);
v.push_back(std::move(i));
std::verboten(i);
doSomething(i.get()); //<-compiler error (or warning), i is verboten
void foo() {
int i = 4;
foo(i); //calls foo on the local i
std::verboten(i);
bar(i); //compiler error (or warning), i is verboten!
}
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_262_91671357.1408544686960
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>I've been using unique_ptr in several projects&n=
bsp;and one source of bugs I see in general with move only types =
is accidentally using the object after it has been moved from.</div><div>&n=
bsp;</div><div>Lets look at some legacy code</div><div> </div><div>str=
uct F {</div><div> std::vector<int*> v;</div><div> ~=
F() { for(auto i: v) { delete i; } }</div><div> void run() {</div><di=
v> int* i =3D new int();</div><div> v.p=
ush_back(i);</div><div> doSomethingWith(i); </div><=
div> }<br>};</div><div> </div><div>Now suppose we want to conver=
t this to using unique_ptr, a worthy goal. Heres a very easy mistake to mak=
e.</div><div> </div><div>struct F {</div><div> std::vector<st=
d::unique_ptr<i>> v;</div><div> void run() {</div><div> =
; auto i =3D std::make_unique<int>();</div><div> &nb=
sp; v.push_back(std::move(i));</div><div> doSomethi=
ngWith(i.get());</div><div> }</div><div>};</div><div> </div><div=
>The bug might be obvious in this small code snippet but if run() is a larg=
e function its an easy mistake to make that cannot be caught at compile tim=
e.</div><div> </div><div>One way to mitigate this is to introduce an e=
xtra scope</div><div> </div><div>{</div><div> auto i =3D std::ma=
ke_unique<int>();</div><div> v.push_back(std::move(i));</div><d=
iv>}</div><div>doSomethingWith(i.get()); //<-compiler error, there is no=
variable named i!</div><div> </div><div>But adding extra scopes is no=
t always possible when you have many local variables all being used togethe=
r and having different lifetimes. Also it adds extra indentation.</div><div=
> </div><div>Do you agree that this is a big enough source of bugs tha=
t it could use a new feature to help the compiler detect and report these k=
inds of errors at compile time? If so, what would such a feature look like?=
</div><div> </div><div>Here are some ideas:</div><div> </div><div=
>1) Add a new keyword to prematurely remove an object from the current scop=
e. </div><div> </div><div>int i =3D 0;</div><div>foo(i); //Ok</div><di=
v>kill i; //<-i is removed from the scope</div><div>bar(i); //Compiler e=
rror, i does not exist anymore!</div><div> </div><div>int j =3D 0;</di=
v><div>if(something) {<br> a(j); //<-Ok</div><div> kill j; /=
/<-j is removed from the if scope</div><div> b(j); //<-compiler=
error</div><div>} </div><div> </div><div>c(j); //<- Ok</div><div>k=
ill j; //<-j is removed from the scope</div><div>d(j); //compiler error<=
/div><div> </div><div>This could be useful because I've found many tim=
e that I wish I could remove a variable from the current scope when I know =
I won't need to use it anymore and I want to prevent myself from writing a =
typo and reusing the wrong variable. I sometimes find myself introducing ne=
w scopes just to mitigate this problem.</div><div> </div><div>There ar=
e some complications and/or potential use cases when names clash.</div><div=
> </div><div>int i;</div><div> </div><div>void foo() {<br> =
int i =3D 4;</div><div> foo(i); //calls foo on the local i</div><div>=
kill i;</div><div> bar(i); //calls bar on the global i</div><d=
iv>}</div><div> </div><div>With this feature, you could kill the uniqu=
e_ptr after moving from it, preventing anyone from accidentally using it.</=
div><div> </div><div><div>auto i =3D std::make_unique<int>(i);</=
div><div>v.push_back(std::move(i));</div><div>kill i;</div><div>doSomething=
(i.get()); //<-compiler error, i does not exist!</div></div><div> <=
/div><div>2) Add some kind of attribute or tag. This is almost the same thi=
ng, except the local variable name not actually removed from the scope=
.. In particular the example with the global would not work.</div><div> =
;</div><div>auto i =3D std::make_unique<int>(i);</div><div>v.push_bac=
k(std::move(i));</div><div>std::verboten(i);</div><div>doSomething(i.get())=
; //<-compiler error (or warning), i is verboten</div><div> </div><=
div><div> </div><div>void foo() {<br> int i =3D 4;</div><div> foo(i); //c=
alls foo on the local i</div><div>std::verboten(i);</div><div> bar(i); //c=
ompiler error (or warning), i is verboten!</div><div>}</div></div><div>&nbs=
p;</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_262_91671357.1408544686960--
.
Author: Jean-Marc Bourguet <jm.bourguet@gmail.com>
Date: Wed, 20 Aug 2014 07:41:25 -0700 (PDT)
Raw View
------=_Part_4420_1625316495.1408545685265
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Le mercredi 20 ao=C3=BBt 2014 16:24:46 UTC+2, Matthew Fioravante a =C3=A9cr=
it :
>
> Do you agree that this is a big enough source of bugs that it could use a=
=20
> new feature to help the compiler detect and report these kinds of errors =
at=20
> compile time?=20
>
Not really. The true issue seems to be a too big function.
=20
> If so, what would such a feature look like?
> =20
> Here are some ideas:
> =20
> 1) Add a new keyword to prematurely remove an object from the current=20
> scope.=20
> =20
> int i =3D 0;
> foo(i); //Ok
> kill i; //<-i is removed from the scope
>
When is the variable destructed? At kill, that can break the usual rule=20
that variables are destructed in the reverse order than they are=20
constructed. At end of scope, that's not intuitive for the feature.
Yours,
--=20
Jean-Marc
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_4420_1625316495.1408545685265
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Le mercredi 20 ao=C3=BBt 2014 16:24:46 UTC+2, Matthew Fior=
avante a =C3=A9crit :<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>Do you agree that this is a big enough source of bugs tha=
t it could use a new feature to help the compiler detect and report these k=
inds of errors at compile time? </div></div></blockquote><div><br></div><di=
v>Not really. The true issue seems to be a too big function.</div><di=
v> </div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
><div>If so, what would such a feature look like?<br></div><div> </div=
><div>Here are some ideas:</div><div> </div><div>1) Add a new keyword =
to prematurely remove an object from the current scope. </div><div> </=
div><div>int i =3D 0;</div><div>foo(i); //Ok</div><div>kill i; //<-i is =
removed from the scope</div></div></blockquote><div><br></div><div>When is =
the variable destructed? At kill, that can break the usual rule that variab=
les are destructed in the reverse order than they are constructed. At=
end of scope, that's not intuitive for the feature.</div><div><br></div><d=
iv>Yours,</div><div><br></div><div>-- </div><div>Jean-Marc</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_4420_1625316495.1408545685265--
.
Author: Pablo Oliva <pabloliva87@gmail.com>
Date: Wed, 20 Aug 2014 11:43:57 -0300
Raw View
--089e0158c84e4be33c050110a2b1
Content-Type: text/plain; charset=UTF-8
How would this play with the same variable being defined in multiple scopes?
Consider:
int i = 0;
void foo()
{
int i = 4;
someFun(i); // so far so good, someFun(4)
std::verboten(i);
someFun(i); // compiler error/warning, or someFun(0)
}
I used the std::verboten variant since I don't think that a new keyword
proposal will be well received, IMHO.
2014-08-20 11:24 GMT-03:00 Matthew Fioravante <fmatthew5876@gmail.com>:
> I've been using unique_ptr in several projects and one source of bugs I
> see in general with move only types is accidentally using the object after
> it has been moved from.
>
> Lets look at some legacy code
>
> struct F {
> std::vector<int*> v;
> ~F() { for(auto i: v) { delete i; } }
> void run() {
> int* i = new int();
> v.push_back(i);
> doSomethingWith(i);
> }
> };
>
> Now suppose we want to convert this to using unique_ptr, a worthy goal.
> Heres a very easy mistake to make.
>
> struct F {
> std::vector<std::unique_ptr<i>> v;
> void run() {
> auto i = std::make_unique<int>();
> v.push_back(std::move(i));
> doSomethingWith(i.get());
> }
> };
>
> The bug might be obvious in this small code snippet but if run() is a
> large function its an easy mistake to make that cannot be caught at compile
> time.
>
> One way to mitigate this is to introduce an extra scope
>
> {
> auto i = std::make_unique<int>();
> v.push_back(std::move(i));
> }
> doSomethingWith(i.get()); //<-compiler error, there is no variable named i!
>
> But adding extra scopes is not always possible when you have many local
> variables all being used together and having different lifetimes. Also it
> adds extra indentation.
>
> Do you agree that this is a big enough source of bugs that it could use a
> new feature to help the compiler detect and report these kinds of errors at
> compile time? If so, what would such a feature look like?
>
> Here are some ideas:
>
> 1) Add a new keyword to prematurely remove an object from the current
> scope.
>
> int i = 0;
> foo(i); //Ok
> kill i; //<-i is removed from the scope
> bar(i); //Compiler error, i does not exist anymore!
>
> int j = 0;
> if(something) {
> a(j); //<-Ok
> kill j; //<-j is removed from the if scope
> b(j); //<-compiler error
> }
>
> c(j); //<- Ok
> kill j; //<-j is removed from the scope
> d(j); //compiler error
>
> This could be useful because I've found many time that I wish I could
> remove a variable from the current scope when I know I won't need to use it
> anymore and I want to prevent myself from writing a typo and reusing the
> wrong variable. I sometimes find myself introducing new scopes just to
> mitigate this problem.
>
> There are some complications and/or potential use cases when names clash.
>
> int i;
>
> void foo() {
> int i = 4;
> foo(i); //calls foo on the local i
> kill i;
> bar(i); //calls bar on the global i
> }
>
> With this feature, you could kill the unique_ptr after moving from it,
> preventing anyone from accidentally using it.
>
> auto i = std::make_unique<int>(i);
> v.push_back(std::move(i));
> kill i;
> doSomething(i.get()); //<-compiler error, i does not exist!
>
> 2) Add some kind of attribute or tag. This is almost the same thing,
> except the local variable name not actually removed from the scope. In
> particular the example with the global would not work.
>
> auto i = std::make_unique<int>(i);
> v.push_back(std::move(i));
> std::verboten(i);
> doSomething(i.get()); //<-compiler error (or warning), i is verboten
>
> void foo() {
> int i = 4;
> foo(i); //calls foo on the local i
> std::verboten(i);
> bar(i); //compiler error (or warning), i is verboten!
> }
>
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--089e0158c84e4be33c050110a2b1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">How would this play with the same variable being defined i=
n multiple scopes?<div><br></div><div>Consider:</div><div><br></div><div>in=
t i =3D 0;</div><div><br></div><div>void foo()</div><div>{</div><div>=C2=A0=
=C2=A0 int i =3D 4;</div>
<div>=C2=A0 =C2=A0 someFun(i); // so far so good, someFun(4)</div><div>=C2=
=A0 =C2=A0 std::verboten(i);</div><div>=C2=A0 =C2=A0 someFun(i); // compile=
r error/warning, or someFun(0)</div><div>}</div><div><br></div><div>I used =
the std::verboten variant since I don't think that a new keyword propos=
al will be well received, IMHO.</div>
</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">2014-08=
-20 11:24 GMT-03:00 Matthew Fioravante <span dir=3D"ltr"><<a href=3D"mai=
lto:fmatthew5876@gmail.com" target=3D"_blank">fmatthew5876@gmail.com</a>>=
;</span>:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>I've been using un=
ique_ptr=C2=A0in several projects=C2=A0and one=C2=A0source of bugs=C2=A0I s=
ee in general with move only types is accidentally using the object after i=
t has been moved from.</div>
<div>=C2=A0</div><div>Lets look at some legacy code</div><div>=C2=A0</div><=
div>struct=C2=A0F {</div><div>=C2=A0 std::vector<int*> v;</div><div>=
=C2=A0 ~F() { for(auto i: v) { delete i; } }</div><div>=C2=A0 void run() {<=
/div><div>=C2=A0=C2=A0=C2=A0 int* i =3D new int();</div>
<div>=C2=A0=C2=A0=C2=A0 v.push_back(i);</div><div>=C2=A0=C2=A0 =C2=A0doSome=
thingWith(i);=C2=A0 </div><div>=C2=A0 }<br>};</div><div>=C2=A0</div><div>No=
w suppose we want to convert this to using unique_ptr, a worthy goal. Heres=
a very easy mistake to make.</div><div>=C2=A0</div>
<div>struct F {</div><div>=C2=A0 std::vector<std::unique_ptr<i>>=
; v;</div><div>=C2=A0 void run() {</div><div>=C2=A0=C2=A0=C2=A0 auto i =3D =
std::make_unique<int>();</div><div>=C2=A0=C2=A0=C2=A0 v.push_back(std=
::move(i));</div><div>=C2=A0=C2=A0=C2=A0 doSomethingWith(i.get());</div>
<div>=C2=A0 }</div><div>};</div><div>=C2=A0</div><div>The bug might be obvi=
ous in this small code snippet but if run() is a large function its an easy=
mistake to make that cannot be caught at compile time.</div><div>=C2=A0</d=
iv><div>One way to mitigate this is to introduce an extra scope</div>
<div>=C2=A0</div><div>{</div><div>=C2=A0 auto i =3D std::make_unique<int=
>();</div><div>=C2=A0 v.push_back(std::move(i));</div><div>}</div><div>d=
oSomethingWith(i.get()); //<-compiler error, there is no variable named =
i!</div><div>
=C2=A0</div><div>But adding extra scopes is not always possible when you ha=
ve many local variables all being used together and having different lifeti=
mes. Also it adds extra indentation.</div><div>=C2=A0</div><div>Do you agre=
e that this is a big enough source of bugs that it could use a new feature =
to help the compiler detect and report these kinds of errors at compile tim=
e? If so, what would such a feature look like?</div>
<div>=C2=A0</div><div>Here are some ideas:</div><div>=C2=A0</div><div>1) Ad=
d a new keyword to prematurely remove an object from the current scope. </d=
iv><div>=C2=A0</div><div>int i =3D 0;</div><div>foo(i); //Ok</div><div>kill=
i; //<-i is removed from the scope</div>
<div>bar(i); //Compiler error, i does not exist anymore!</div><div>=C2=A0</=
div><div>int j =3D 0;</div><div>if(something) {<br>=C2=A0 a(j); //<-Ok</=
div><div>=C2=A0 kill j; //<-j is removed from the if scope</div><div>=C2=
=A0 b(j); //<-compiler error</div>
<div>} </div><div>=C2=A0</div><div>c(j); //<- Ok</div><div>kill j; //<=
;-j is removed from the scope</div><div>d(j); //compiler error</div><div>=
=C2=A0</div><div>This could be useful because I've found many time that=
I wish I could remove a variable from the current scope when I know I won&=
#39;t need to use it anymore and I want to prevent myself from writing a ty=
po and reusing the wrong variable. I sometimes find myself introducing new =
scopes just to mitigate this problem.</div>
<div>=C2=A0</div><div>There are some complications and/or potential use cas=
es when names clash.</div><div>=C2=A0</div><div>int i;</div><div>=C2=A0</di=
v><div>void foo() {<br>=C2=A0 int i =3D 4;</div><div>=C2=A0 foo(i); //calls=
foo on the local i</div>
<div>=C2=A0 kill i;</div><div>=C2=A0 bar(i); //calls bar on the global i</d=
iv><div>}</div><div>=C2=A0</div><div>With this feature, you could kill the =
unique_ptr after moving from it, preventing anyone from accidentally using =
it.</div><div>
=C2=A0</div><div><div>auto i =3D std::make_unique<int>(i);</div><div>=
v.push_back(std::move(i));</div><div>kill i;</div><div>doSomething(i.get())=
; //<-compiler error, i does not exist!</div></div><div>=C2=A0</div><div=
>2) Add some kind of attribute or tag. This is almost the same thing, excep=
t the local variable=C2=A0name not actually removed from the scope. In part=
icular the example with the global would not work.</div>
<div>=C2=A0</div><div>auto i =3D std::make_unique<int>(i);</div><div>=
v.push_back(std::move(i));</div><div>std::verboten(i);</div><div>doSomethin=
g(i.get()); //<-compiler error (or warning), i is verboten</div><div>=C2=
=A0</div>
<div><div> </div><div>void foo() {<br> int i =3D 4;</div><div> foo(i); //=
calls foo on the local i</div><div>std::verboten(i);</div><div> bar(i); //=
compiler error (or warning), i is verboten!</div><div>}</div></div><span cl=
ass=3D"HOEnZb"><font color=3D"#888888"><div>
=C2=A0</div></font></span></div><span class=3D"HOEnZb"><font color=3D"#8888=
88">
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" 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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</font></span></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--089e0158c84e4be33c050110a2b1--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Wed, 20 Aug 2014 17:45:04 +0300
Raw View
On 20 August 2014 17:41, Jean-Marc Bourguet <jm.bourguet@gmail.com> wrote:
> Le mercredi 20 ao=C3=BBt 2014 16:24:46 UTC+2, Matthew Fioravante a =C3=A9=
crit :
>>
>> Do you agree that this is a big enough source of bugs that it could use =
a
>> new feature to help the compiler detect and report these kinds of errors=
at
>> compile time?
>
>
> Not really. The true issue seems to be a too big function.
In addition to that, I find it rather difficult to believe that users
who fall into such
traps would know where, when and why to use "kill". Sprinkling it blindly w=
ill
lead to a fairly large number of false positives. There are library solutio=
ns,
the motivation for a language change seems extremely weak.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: Matthew Fioravante <fmatthew5876@gmail.com>
Date: Wed, 20 Aug 2014 07:53:39 -0700 (PDT)
Raw View
------=_Part_436_1839903639.1408546419455
Content-Type: text/plain; charset=UTF-8
On Wednesday, August 20, 2014 10:41:25 AM UTC-4, Jean-Marc Bourguet wrote:
>
> int i = 0;
>> foo(i); //Ok
>> kill i; //<-i is removed from the scope
>>
>
> When is the variable destructed? At kill, that can break the usual rule
> that variables are destructed in the reverse order than they are
> constructed. At end of scope, that's not intuitive for the feature.
>
I thought about this. I believe the variable should still be destructed at
the end of the scope, even though its name is no longer accessible.
It might be possible to allow the compiler to do early destruction as an
optimization when the reverse order rule is still maintain. I don't think
early destruction as an optimization is a good idea though. For something
like std::lock_guard, early destruction would break the program. For other
resources, it would add uncertainty about exactly when certain resources
are released.
On Wednesday, August 20, 2014 10:44:01 AM UTC-4, Pablo Oliva wrote:
>
> How would this play with the same variable being defined in multiple
> scopes?
>
> Consider:
>
> int i = 0;
>
> void foo()
> {
> int i = 4;
> someFun(i); // so far so good, someFun(4)
> std::verboten(i);
> someFun(i); // compiler error/warning, or someFun(0)
> }
>
> I used the std::verboten variant since I don't think that a new keyword
> proposal will be well received, IMHO.
>
>
Sorry I made a typo in the first post. Lets do a full example which should
illuminate
int i;
struct F {
int i;
void f() {
int i;
a(i); //uses local i
kill i;
b(i); //uses data member i
kill i;
c(i); //uses global i
kill i;
d(i); //compiler error
}
};
int j;
struct G {
int j;
void g() {
int j;
a(j);
std::verboten(j);
b(j); //compiler error, j is verboten
std::verboten(j); //compiler error, j is verboten
c(j); //compiler error, j is verboten
std::verboten(j); //compiler error, j is verboten
d(j); //compiler error, j is verboten
}
};
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_436_1839903639.1408546419455
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<br>On Wednesday, August 20, 2014 10:41:25 AM UTC-4, Jean-Marc Bourguet wro=
te:<blockquote style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; borde=
r-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style=
: solid;" class=3D"gmail_quote"><div dir=3D"ltr"><blockquote style=3D"margi=
n: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 2=
04); border-left-width: 1px; border-left-style: solid;" class=3D"gmail_quot=
e"><div dir=3D"ltr"><div>int i =3D 0;</div><div>foo(i); //Ok</div><div>kill=
i; //<-i is removed from the scope</div></div></blockquote><div><br></d=
iv><div>When is the variable destructed? At kill, that can break the usual =
rule that variables are destructed in the reverse order than they are const=
ructed. At end of scope, that's not intuitive for the feature.</div><=
/div></blockquote><div> </div><div>I thought about this. I believe the=
variable should still be destructed at the end of the scope, even though i=
ts name is no longer accessible.</div><div> </div><div>It might be pos=
sible to allow the compiler to do early destruction as an optimization when=
the reverse order rule is still maintain. I don't think early destruction =
as an optimization is a good idea though. For something like std::lock_guar=
d, early destruction would break the program. For other resources, it would=
add uncertainty about exactly when certain resources are released.</div><d=
iv> </div><div><br>On Wednesday, August 20, 2014 10:44:01 AM UTC-4, Pa=
blo Oliva wrote:<blockquote style=3D"margin: 0px 0px 0px 0.8ex; padding-lef=
t: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; bord=
er-left-style: solid;" class=3D"gmail_quote"><div dir=3D"ltr">How would thi=
s play with the same variable being defined in multiple scopes?<div><br></d=
iv><div>Consider:</div><div><br></div><div>int i =3D 0;</div><div><br></div=
><div>void foo()</div><div>{</div><div> int i =3D 4;</div><div> someF=
un(i); // so far so good, someFun(4)</div><div> std::verboten(i);</div><=
div> someFun(i); // compiler error/warning, or someFun(0)</div><div>}</d=
iv><div><br></div><div>I used the std::verboten variant since I don't think=
that a new keyword proposal will be well received, IMHO.</div></div><div>&=
nbsp;</div></blockquote><div> </div><div>Sorry I made a typo in t=
he first post. Lets do a full example which should illuminate</div><di=
v> </div><div>int i;</div><div> </div><div>struct F {</div><div>&=
nbsp; int i;</div><div> void f() {</div><div> =
int i;</div><div> a(i); //uses local i</div><div>&=
nbsp; kill i;</div><div> b(i=
); //uses data member i</div><div> kill i;</div><di=
v> c(i); //uses global i</div><div>  =
; kill i;</div><div> d(i); //compi=
ler error</div><div> }<br>};</div><div> </div><div> </div><=
div>int j;</div><div>struct G {</div><div> int j;</div><div> vo=
id g() {</div><div> int j;</div><div> &n=
bsp;a(j);</div><div> std::verboten(j); </div><div>&n=
bsp; b(j); //compiler error, j is verboten</div><div> &nbs=
p; std::verboten(j); //compiler error, j is verboten</div><div> =
c(j); //compiler error, j is verboten</div><div> &n=
bsp; std::verboten(j); //compiler error, j is verboten</div><div> &nbs=
p; d(j); //compiler error, j is verboten</div><div> }</div><div=
>};</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_436_1839903639.1408546419455--
.
Author: =?UTF-8?Q?David_Rodr=C3=ADguez_Ibeas?= <dibeas@ieee.org>
Date: Wed, 20 Aug 2014 11:02:54 -0400
Raw View
--047d7b41411011ea7d050110e683
Content-Type: text/plain; charset=UTF-8
There are different things in here...
For local variables I would expect this to be QoI. The compiler
(specifically if it is doing flow analysis) or a static analysis tool
should be able to pick this up and warn you in this case, while allowing
other correct reuses of the variable (as in resetting the value to a
different value). Still for local variables, while I don't see this as a
problem to solve I would not be against the solution.
For non-local variables this is problematic and I would be completely
against it. Say that the member function has a 'kill i' for some member
variable 'i'. Now you have a nice feature that hides from lookup the member
variable *inside the rest of this function*, but as soon as the function
completes the user calls on any other function and the variable is seen and
can be used even if from the point of view of the user that member was
*killed*! And in this case, the compiler cannot help, so you are trading
something that can be detected locally to a different issue that cannot be
diagnosed.
David
On Wed, Aug 20, 2014 at 10:53 AM, Matthew Fioravante <fmatthew5876@gmail.com
> wrote:
>
> On Wednesday, August 20, 2014 10:41:25 AM UTC-4, Jean-Marc Bourguet wrote:
>>
>> int i = 0;
>>> foo(i); //Ok
>>> kill i; //<-i is removed from the scope
>>>
>>
>> When is the variable destructed? At kill, that can break the usual rule
>> that variables are destructed in the reverse order than they are
>> constructed. At end of scope, that's not intuitive for the feature.
>>
>
> I thought about this. I believe the variable should still be destructed at
> the end of the scope, even though its name is no longer accessible.
>
> It might be possible to allow the compiler to do early destruction as an
> optimization when the reverse order rule is still maintain. I don't think
> early destruction as an optimization is a good idea though. For something
> like std::lock_guard, early destruction would break the program. For other
> resources, it would add uncertainty about exactly when certain resources
> are released.
>
>
> On Wednesday, August 20, 2014 10:44:01 AM UTC-4, Pablo Oliva wrote:
>
>> How would this play with the same variable being defined in multiple
>> scopes?
>>
>> Consider:
>>
>> int i = 0;
>>
>> void foo()
>> {
>> int i = 4;
>> someFun(i); // so far so good, someFun(4)
>> std::verboten(i);
>> someFun(i); // compiler error/warning, or someFun(0)
>> }
>>
>> I used the std::verboten variant since I don't think that a new keyword
>> proposal will be well received, IMHO.
>>
>>
>
> Sorry I made a typo in the first post. Lets do a full example which should
> illuminate
>
> int i;
>
> struct F {
> int i;
> void f() {
> int i;
> a(i); //uses local i
> kill i;
> b(i); //uses data member i
> kill i;
> c(i); //uses global i
> kill i;
> d(i); //compiler error
> }
> };
>
>
> int j;
> struct G {
> int j;
> void g() {
> int j;
> a(j);
> std::verboten(j);
> b(j); //compiler error, j is verboten
> std::verboten(j); //compiler error, j is verboten
> c(j); //compiler error, j is verboten
> std::verboten(j); //compiler error, j is verboten
> d(j); //compiler error, j is verboten
> }
> };
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--047d7b41411011ea7d050110e683
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">There are different things in here... <br><br>For local va=
riables I would expect this to be QoI. The compiler (specifically if it is =
doing flow analysis) or a static analysis tool should be able to pick this =
up and warn you in this case, while allowing other correct reuses of the va=
riable (as in resetting the value to a different value). Still for local va=
riables, while I don't see this as a problem to solve I would not be ag=
ainst the solution.<br>
<br>For non-local variables this is problematic and I would be completely a=
gainst it. Say that the member function has a 'kill i' for some mem=
ber variable 'i'. Now you have a nice feature that hides from looku=
p the member variable *inside the rest of this function*, but as soon as th=
e function completes the user calls on any other function and the variable =
is seen and can be used even if from the point of view of the user that mem=
ber was *killed*! =C2=A0And in this case, the compiler cannot help, so you =
are trading something that can be detected locally to a different issue tha=
t cannot be diagnosed.<br>
<br>=C2=A0 =C2=A0 David</div><div class=3D"gmail_extra"><br><br><div class=
=3D"gmail_quote">On Wed, Aug 20, 2014 at 10:53 AM, Matthew Fioravante <span=
dir=3D"ltr"><<a href=3D"mailto:fmatthew5876@gmail.com" target=3D"_blank=
">fmatthew5876@gmail.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D""><br>On Wednesday, August 20,=
2014 10:41:25 AM UTC-4, Jean-Marc Bourguet wrote:<blockquote style=3D"marg=
in:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);bo=
rder-left-width:1px;border-left-style:solid" class=3D"gmail_quote">
<div dir=3D"ltr"><blockquote style=3D"margin:0px 0px 0px 0.8ex;padding-left=
:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-s=
tyle:solid" class=3D"gmail_quote"><div dir=3D"ltr"><div>int i =3D 0;</div><=
div>foo(i); //Ok</div>
<div>kill i; //<-i is removed from the scope</div></div></blockquote><di=
v><br></div><div>When is the variable destructed? At kill, that can break t=
he usual rule that variables are destructed in the reverse order than they =
are constructed. =C2=A0At end of scope, that's not intuitive for the fe=
ature.</div>
</div></blockquote><div>=C2=A0</div></div><div>I thought about this. I beli=
eve the variable should still be destructed at the end of the scope, even t=
hough its name is no longer accessible.</div><div>=C2=A0</div><div>It might=
be possible to allow the compiler to do early destruction as an optimizati=
on when the reverse order rule is still maintain. I don't think early d=
estruction as an optimization is a good idea though. For something like std=
::lock_guard, early destruction would break the program. For other resource=
s, it would add uncertainty about exactly when certain resources are releas=
ed.</div>
<div>=C2=A0</div><div><div class=3D""><br>On Wednesday, August 20, 2014 10:=
44:01 AM UTC-4, Pablo Oliva wrote:</div><blockquote 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" class=3D"gmail_quote">
<div dir=3D"ltr"><div class=3D"">How would this play with the same variable=
being defined in multiple scopes?<div><br></div><div>Consider:</div><div><=
br></div><div>int i =3D 0;</div><div><br></div></div><div class=3D""><div>v=
oid foo()</div>
<div>{</div><div> int i =3D 4;</div></div><div class=3D""><div> someF=
un(i); // so far so good, someFun(4)</div><div> std::verboten(i);</div><=
div> someFun(i); // compiler error/warning, or someFun(0)</div><div>}</d=
iv>
<div><br></div><div>I used the std::verboten variant since I don't thin=
k that a new keyword proposal will be well received, IMHO.</div></div></div=
><div>=C2=A0</div></blockquote><div>=C2=A0</div><div>Sorry I made a typo=C2=
=A0in the first post.=C2=A0Lets do a full example which should illuminate</=
div>
<div>=C2=A0</div><div>int i;</div><div>=C2=A0</div><div>struct F {</div><di=
v>=C2=A0 int i;</div><div>=C2=A0 void f() {</div><div>=C2=A0=C2=A0=C2=A0=C2=
=A0 int i;</div><div>=C2=A0=C2=A0=C2=A0=C2=A0 a(i); //uses local i</div><di=
v>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0kill i;</div><div>=C2=A0=C2=A0=C2=A0=C2=A0 =
b(i); //uses data member i</div>
<div>=C2=A0=C2=A0=C2=A0=C2=A0 kill i;</div><div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0c(i); //uses global i</div><div>=C2=A0=C2=A0=C2=A0=C2=A0 kill i;</div><d=
iv>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0d(i); //compiler error</div><div>=C2=A0 }<=
br>};</div><div>=C2=A0</div><div>=C2=A0</div><div>int j;</div><div>struct G=
{</div><div>=C2=A0 int j;</div>
<div>=C2=A0 void g() {</div><div>=C2=A0=C2=A0=C2=A0 int j;</div><div>=C2=A0=
=C2=A0=C2=A0=C2=A0a(j);</div><div>=C2=A0=C2=A0=C2=A0=C2=A0std::verboten(j);=
</div><div>=C2=A0=C2=A0=C2=A0 b(j); //compiler error, j is verboten</div><=
div>=C2=A0=C2=A0=C2=A0 std::verboten(j); //compiler error, j is verboten</d=
iv><div>=C2=A0=C2=A0=C2=A0 c(j); //compiler error, j is verboten</div>
<div>=C2=A0=C2=A0=C2=A0 std::verboten(j); //compiler error, j is verboten</=
div><div>=C2=A0=C2=A0=C2=A0 d(j); //compiler error, j is verboten</div><div=
>=C2=A0 }</div><div>};</div></div><div class=3D"HOEnZb"><div class=3D"h5">
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" 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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--047d7b41411011ea7d050110e683--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Wed, 20 Aug 2014 10:08:04 -0500
Raw View
--f46d044280c4e97535050110fa6a
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On 20 August 2014 09:53, Matthew Fioravante <fmatthew5876@gmail.com> wrote:
> Sorry I made a typo in the first post. Lets do a full example which shoul=
d
>> illuminate
>>
>
> int i;
>
> struct F {
> int i;
> void f() {
> int i;
> a(i); //uses local i
> kill i;
> b(i); //uses data member i
> kill i;
> c(i); //uses global i
> kill i;
> d(i); //compiler error
> }
> };
>
=E2=80=A2 If you know enough to write "kill", you know enough to avoid the =
problem
in the first place.
=E2=80=A2 This exasperates the problem of shadowing. If people are having =
problems
with moved-from objects, why should I believe they can handle shadowing
correctly?
--=20
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--f46d044280c4e97535050110fa6a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On 20 August 2014 09:53, Matthew Fioravante <span dir=3D"l=
tr"><<a href=3D"mailto:fmatthew5876@gmail.com" target=3D"_blank">fmatthe=
w5876@gmail.com</a>></span> wrote:<br><div class=3D"gmail_extra"><div cl=
ass=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div><blockquote 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" class=3D"gmail_quote">
<div dir=3D"ltr"><div class=3D""><div>Sorry I made a typo=C2=A0in the first=
post.=C2=A0Lets do a full example which should illuminate<br></div></div><=
/div></blockquote><div>=C2=A0</div><div>int i;</div><div>=C2=A0</div><div>s=
truct F {</div><div>
=C2=A0 int i;</div><div>=C2=A0 void f() {</div><div>=C2=A0=C2=A0=C2=A0=C2=
=A0 int i;</div><div>=C2=A0=C2=A0=C2=A0=C2=A0 a(i); //uses local i</div><di=
v>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0kill i;</div><div>=C2=A0=C2=A0=C2=A0=C2=A0 =
b(i); //uses data member i</div><div>=C2=A0=C2=A0=C2=A0=C2=A0 kill i;</div>=
<div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0c(i); //uses global i</div>
<div>
=C2=A0=C2=A0=C2=A0=C2=A0 kill i;</div><div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0d(=
i); //compiler error</div><div>=C2=A0 }<br>};</div></div></blockquote><div>=
<br></div><div>=E2=80=A2 If you know enough to write "kill", you =
know enough to avoid the problem in the first place.</div>
<div><br></div><div>=E2=80=A2 This exasperates the problem of shadowing. =
=C2=A0If people are having problems with moved-from objects, why should I b=
elieve they can handle shadowing correctly?</div></div>-- <br>=C2=A0Nevin &=
quot;:-)" Liber=C2=A0 <mailto:<a href=3D"mailto:nevin@eviloverlord.=
com" target=3D"_blank">nevin@eviloverlord.com</a>>=C2=A0 (847) 691-1404
</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--f46d044280c4e97535050110fa6a--
.
Author: Matthew Fioravante <fmatthew5876@gmail.com>
Date: Wed, 20 Aug 2014 08:12:13 -0700 (PDT)
Raw View
------=_Part_4283_1611796945.1408547534043
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Wednesday, August 20, 2014 11:02:56 AM UTC-4, David Rodr=C3=ADguez Ibeas=
=20
wrote:
>
> There are different things in here...=20
>
> For local variables I would expect this to be QoI. The compiler=20
> (specifically if it is doing flow analysis) or a static analysis tool=20
> should be able to pick this up and warn you in this case, while allowing=
=20
> other correct reuses of the variable (as in resetting the value to a=20
> different value).=20
>
=20
I'm not sure this is actually possible for static analysis tools. There can=
=20
be cases where you want use the value after it is moved from.
=20
auto x =3D std::make_unique<int>();
if(something) {
v.push_back(std::move(x));
}
foo(x.get()); //Ok: if something was true then foo gets passed a nullptr,=
=20
which is what we want
=20
=20
=20
> Still for local variables, while I don't see this as a problem to solve I=
=20
> would not be against the solution.
>
> For non-local variables this is problematic and I would be completely=20
> against it. Say that the member function has a 'kill i' for some member=
=20
> variable 'i'. Now you have a nice feature that hides from lookup the memb=
er=20
> variable *inside the rest of this function*, but as soon as the function=
=20
> completes the user calls on any other function and the variable is seen a=
nd=20
> can be used even if from the point of view of the user that member was=20
> *killed*! And in this case, the compiler cannot help, so you are trading=
=20
> something that can be detected locally to a different issue that cannot b=
e=20
> diagnosed.
>
=20
I'm not sure using kill to hide data members and/or globals is actually=20
useful. Its certainly not the intention here but just a side effect of how=
=20
this proposed kill would work. The main focus is on local variables.
=20
=20
Just to clarify in case anyone is confused, the 2 ideas are:
=20
kill - All this does is remove the symbol from lookup.
std::verboten() - Tags the symbol as verboten, all references of this=20
symbol become compiler errors.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_4283_1611796945.1408547534043
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br>On Wednesday, August 20, 2014 11:02:56 AM UTC-4, David=
Rodr=C3=ADguez Ibeas wrote:<blockquote 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;" class=3D"gmail_quote"><div dir=3D"ltr">T=
here are different things in here... <br><br>For local variables I would ex=
pect this to be QoI. The compiler (specifically if it is doing flow analysi=
s) or a static analysis tool should be able to pick this up and warn you in=
this case, while allowing other correct reuses of the variable (as in rese=
tting the value to a different value). </div></blockquote><div> </div>=
<div>I'm not sure this is actually possible for static analysis tools. Ther=
e can be cases where you want use the value after it is moved from.</div><d=
iv> </div><div>auto x =3D std::make_unique<int>();</div><div>if(=
something) {<br> v.push_back(std::move(x));</div><div>}</div><div>foo=
(x.get()); //Ok: if something was true then foo gets passed a nullptr, whic=
h is what we want</div><div> </div><div> </div><div> </div><=
blockquote style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-le=
ft-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: so=
lid;" class=3D"gmail_quote"><div dir=3D"ltr">Still for local variables, whi=
le I don't see this as a problem to solve I would not be against the soluti=
on.<br>
<br>For non-local variables this is problematic and I would be completely a=
gainst it. Say that the member function has a 'kill i' for some member vari=
able 'i'. Now you have a nice feature that hides from lookup the member var=
iable *inside the rest of this function*, but as soon as the function compl=
etes the user calls on any other function and the variable is seen and can =
be used even if from the point of view of the user that member was *killed*=
! And in this case, the compiler cannot help, so you are trading some=
thing that can be detected locally to a different issue that cannot be diag=
nosed.<br></div></blockquote><div> </div><div>I'm not sure using kill =
to hide data members and/or globals is actually useful. Its certainly not t=
he intention here but just a side effect of how this proposed kill would wo=
rk. The main focus is on local variables.</div><div> </div><div> =
</div><div>Just to clarify in case anyone is confused, the 2 ideas are:</di=
v><div> </div><div>kill - All this does is remove the symbol from look=
up.</div><div>std::verboten() - Tags the symbol as verboten, all references=
of this symbol become compiler errors.</div>
</div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_4283_1611796945.1408547534043--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Wed, 20 Aug 2014 10:19:36 -0500
Raw View
--001a11c3b02e3c29130501112449
Content-Type: text/plain; charset=UTF-8
On 20 August 2014 10:12, Matthew Fioravante <fmatthew5876@gmail.com> wrote:
> I'm not sure this is actually possible for static analysis tools. There
> can be cases where you want use the value after it is moved from.
>
> auto x = std::make_unique<int>();
> if(something) {
> v.push_back(std::move(x));
> }
> foo(x.get()); //Ok: if something was true then foo gets passed a nullptr,
> which is what we want
>
Teaching people to count on the moved-from state is a bad idea. Generally,
you should only call functions that have no preconditions (such as
assignment and reset); otherwise, users will get confused about what
moved-from means.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a11c3b02e3c29130501112449
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On 20 August 2014 10:12, Matthew Fioravante <span dir=3D"l=
tr"><<a href=3D"mailto:fmatthew5876@gmail.com" target=3D"_blank">fmatthe=
w5876@gmail.com</a>></span> wrote:<br><div class=3D"gmail_extra"><div cl=
ass=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"">I'm not=
sure this is actually possible for static analysis tools. There can be cas=
es where you want use the value after it is moved from.<br>
</div><div class=3D""><div>=C2=A0</div><div>auto x =3D std::make_unique<=
int>();</div></div><div>if(something) {<br>=C2=A0 v.push_back(std::move(=
x));</div><div>}</div><div>foo(x.get()); //Ok: if something was true then f=
oo gets passed a nullptr, which is what we want</div>
</div></blockquote><div><br></div><div>Teaching people to count on the move=
d-from state is a bad idea. =C2=A0Generally, you should only call functions=
that have no preconditions (such as assignment and reset); otherwise, user=
s will get confused about what moved-from means.</div>
</div>-- <br>=C2=A0Nevin ":-)" Liber=C2=A0 <mailto:<a href=3D"=
mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>=
>=C2=A0 (847) 691-1404
</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a11c3b02e3c29130501112449--
.
Author: =?UTF-8?Q?David_Rodr=C3=ADguez_Ibeas?= <dibeas@ieee.org>
Date: Wed, 20 Aug 2014 11:47:19 -0400
Raw View
--047d7b10ce51ee4b9a0501118422
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
That is not different from, say using assignment where comparison was
intended inside an if, more often than not they indicate an issue.
Compilers opted to warn in that case and use an equivalent syntax for the
case where it is intended:
if ((x =3D foo()))
I could imagine a static analysis tool that allowed you to tag that as
intentional (or silence the warning). You can already tag arguments to
functions in some compilers are being not-null, and if that is the case a
static analyzer could flag the code depending on whether the callee allows
nulls or not. Or you could, outside of the standard, tag the variable as
"dead" for your toolset. If this proves to be useful, either tools can
independently converge on the mechanism, or else it could be standardized
if it proves useful.
One possible way of tagging the code as intentional would be to explicitly
reset the unique pointer:
auto x =3D make_unique<int>();
if (something) {
v.push_back(std::move(x));
x =3D 0; // explicitly say that the state
is known
}
foo(x.get()); // don't warn
David
On Wed, Aug 20, 2014 at 11:12 AM, Matthew Fioravante <fmatthew5876@gmail.co=
m
> wrote:
>
> On Wednesday, August 20, 2014 11:02:56 AM UTC-4, David Rodr=C3=ADguez Ibe=
as
> wrote:
>>
>> There are different things in here...
>>
>> For local variables I would expect this to be QoI. The compiler
>> (specifically if it is doing flow analysis) or a static analysis tool
>> should be able to pick this up and warn you in this case, while allowing
>> other correct reuses of the variable (as in resetting the value to a
>> different value).
>>
>
> I'm not sure this is actually possible for static analysis tools. There
> can be cases where you want use the value after it is moved from.
>
> auto x =3D std::make_unique<int>();
> if(something) {
> v.push_back(std::move(x));
> }
> foo(x.get()); //Ok: if something was true then foo gets passed a nullptr,
> which is what we want
>
>
>
>
>> Still for local variables, while I don't see this as a problem to solve =
I
>> would not be against the solution.
>>
>> For non-local variables this is problematic and I would be completely
>> against it. Say that the member function has a 'kill i' for some member
>> variable 'i'. Now you have a nice feature that hides from lookup the mem=
ber
>> variable *inside the rest of this function*, but as soon as the function
>> completes the user calls on any other function and the variable is seen =
and
>> can be used even if from the point of view of the user that member was
>> *killed*! And in this case, the compiler cannot help, so you are tradin=
g
>> something that can be detected locally to a different issue that cannot =
be
>> diagnosed.
>>
>
> I'm not sure using kill to hide data members and/or globals is actually
> useful. Its certainly not the intention here but just a side effect of ho=
w
> this proposed kill would work. The main focus is on local variables.
>
>
> Just to clarify in case anyone is confused, the 2 ideas are:
>
> kill - All this does is remove the symbol from lookup.
> std::verboten() - Tags the symbol as verboten, all references of this
> symbol become compiler errors.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--047d7b10ce51ee4b9a0501118422
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">That is not different from, say using assignment where com=
parison was intended inside an if, more often than not they indicate an iss=
ue. Compilers opted to warn in that case and use an equivalent syntax for t=
he case where it is intended:<br>
<br>if ((x =3D foo()))<br><br>I could imagine a static analysis tool that a=
llowed you to tag that as intentional (or silence the warning). You can alr=
eady tag arguments to functions in some compilers are being not-null, and i=
f that is the case a static analyzer could flag the code depending on wheth=
er the callee allows nulls or not. Or you could, outside of the standard, t=
ag the variable as "dead" for your toolset. If this proves to be =
useful, either tools can independently converge on the mechanism, or else i=
t could be standardized if it proves useful.<br>
<br>One possible way of tagging the code as intentional would be to explici=
tly reset the unique pointer:<br><br>auto x =3D make_unique<int>();<b=
r>if (something) {<br>=C2=A0 =C2=A0v.push_back(std::move(x));<br>=C2=A0 =C2=
=A0x =3D 0; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// explicitly say that the =
state is known<br>
}<br>foo(x.get()); =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// don't warn<br><br>=C2=A0 =
=C2=A0 David</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_qu=
ote">On Wed, Aug 20, 2014 at 11:12 AM, Matthew Fioravante <span dir=3D"ltr"=
><<a href=3D"mailto:fmatthew5876@gmail.com" target=3D"_blank">fmatthew58=
76@gmail.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D""><br>On Wedn=
esday, August 20, 2014 11:02:56 AM UTC-4, David Rodr=C3=ADguez Ibeas wrote:=
<blockquote 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" class=
=3D"gmail_quote">
<div dir=3D"ltr">There are different things in here... <br><br>For local va=
riables I would expect this to be QoI. The compiler (specifically if it is =
doing flow analysis) or a static analysis tool should be able to pick this =
up and warn you in this case, while allowing other correct reuses of the va=
riable (as in resetting the value to a different value). </div>
</blockquote><div>=C2=A0</div></div><div>I'm not sure this is actually =
possible for static analysis tools. There can be cases where you want use t=
he value after it is moved from.</div><div class=3D""><div>=C2=A0</div><div=
>auto x =3D std::make_unique<int>();</div>
</div><div>if(something) {<br>=C2=A0 v.push_back(std::move(x));</div><div>}=
</div><div>foo(x.get()); //Ok: if something was true then foo gets passed a=
nullptr, which is what we want</div><div class=3D""><div>=C2=A0</div><div>=
=C2=A0</div><div>
=C2=A0</div><blockquote 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" class=3D"gmail_quote"><div dir=3D"ltr">Still for local variables, wh=
ile I don't see this as a problem to solve I would not be against the s=
olution.<br>
<br>For non-local variables this is problematic and I would be completely a=
gainst it. Say that the member function has a 'kill i' for some mem=
ber variable 'i'. Now you have a nice feature that hides from looku=
p the member variable *inside the rest of this function*, but as soon as th=
e function completes the user calls on any other function and the variable =
is seen and can be used even if from the point of view of the user that mem=
ber was *killed*! =C2=A0And in this case, the compiler cannot help, so you =
are trading something that can be detected locally to a different issue tha=
t cannot be diagnosed.<br>
</div></blockquote><div>=C2=A0</div></div><div>I'm not sure using kill =
to hide data members and/or globals is actually useful. Its certainly not t=
he intention here but just a side effect of how this proposed kill would wo=
rk. The main focus is on local variables.</div>
<div>=C2=A0</div><div>=C2=A0</div><div>Just to clarify in case anyone is co=
nfused, the 2 ideas are:</div><div>=C2=A0</div><div>kill - All this does is=
remove the symbol from lookup.</div><div>std::verboten() - Tags the symbol=
as verboten, all references of this symbol become compiler errors.</div>
</div><div class=3D"HOEnZb"><div class=3D"h5">
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" 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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--047d7b10ce51ee4b9a0501118422--
.
Author: Matthew Fioravante <fmatthew5876@gmail.com>
Date: Wed, 20 Aug 2014 09:50:49 -0700 (PDT)
Raw View
------=_Part_4476_382380114.1408553449531
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Wednesday, August 20, 2014 11:47:21 AM UTC-4, David Rodr=C3=ADguez Ibeas=
=20
wrote:
>
>
> One possible way of tagging the code as intentional would be to explicitl=
y=20
> reset the unique pointer:
>
> auto x =3D make_unique<int>();
> if (something) {
> v.push_back(std::move(x));
> x =3D 0; // explicitly say that the sta=
te=20
> is known
> }
> foo(x.get()); // don't warn
>
=20
I like this approach but I'm not sure it can be made to be generic for all=
=20
movable types.
Consider the case where the object is reused later.
=20
auto x =3D make_unique<int>();
v.push_back(std::move(x));
a(x.get()); //Warning: use after move
x =3D make_unique<int>();=20
b(x.get()); //compiler saw a new assignment to x, so we know this is valid
v.push_back(std::move(x));
c(x.get()); //Warning: use after move
=20
x.reset(new int());=20
d(x.get()); //???
=20
In the above example, the compiler needs to have know that=20
unique_ptr::reset() is special and makes the object reusable again. Hard=20
coding the rules for unique_ptr into a compiler warning may terrible=20
idea idea since it is used so often but that approach cannot be generalized=
..
=20
=20
The diagnostic could be made to only trigger for const operations after=20
move and be reset once a non-const operation occurs. This would not catch=
=20
all of the kinds of use-after-move bugs, though. After moving, its safe to=
=20
do operations which overwrite the state but not operations which modify the=
=20
current state. We don't currently have any way to differentiate between the=
=20
2.
=20
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_4476_382380114.1408553449531
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br>On Wednesday, August 20, 2014 11:47:21 AM UTC-4, David=
Rodr=C3=ADguez Ibeas wrote:<blockquote 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;" class=3D"gmail_quote"><div dir=3D"ltr"><=
br>One possible way of tagging the code as intentional would be to explicit=
ly reset the unique pointer:<br><br>auto x =3D make_unique<int>();<br=
>if (something) {<br> v.push_back(std::move(x));<br> &nbs=
p;x =3D 0; &=
nbsp; // explicitly say that the s=
tate is known<br>
}<br>foo(x.get()); =
// don't warn<br></div></blockquot=
e><div> </div><div>I like this approach but I'm not sure it can b=
e made to be generic for all movable types.</div><div>Consider the cas=
e where the object is reused later.</div><div> </div><div>auto x =3D m=
ake_unique<int>();</div><div>v.push_back(std::move(x));</div><div>a(x=
..get()); //Warning: use after move</div><div>x =3D make_unique<int>()=
; </div><div>b(x.get()); //compiler saw a new assignment to x, so we know t=
his is valid</div><div>v.push_back(std::move(x));</div><div>c(x.get()); //W=
arning: use after move</div><div> </div><div>x.reset(new int()); </div=
><div>d(x.get()); //???</div><div> </div><div>In the above example, th=
e compiler needs to have know that unique_ptr::reset() is special and makes=
the object reusable again. Hard coding the rules for unique_ptr into =
a compiler warning may terrible idea idea since it is used s=
o often but that approach cannot be generalized.</div><div> </div><div=
> </div><div>The diagnostic could be made to only trigger for const op=
erations after move and be reset once a non-const operation occurs. This wo=
uld not catch all of the kinds of use-after-move bugs, though. After moving=
, its safe to do operations which overwrite the state but not operations wh=
ich modify the current state. We don't currently have any way to differenti=
ate between the 2.</div><div> </div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_4476_382380114.1408553449531--
.
Author: Matthew Fioravante <fmatthew5876@gmail.com>
Date: Wed, 20 Aug 2014 10:07:48 -0700 (PDT)
Raw View
------=_Part_3264_1676900223.1408554468471
Content-Type: text/plain; charset=UTF-8
Sorry typos, meant to say:
Hard coding the rules for unique_ptr into a compiler warning may not be a
terrible idea since it is used so often but that approach cannot be
generalized.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_3264_1676900223.1408554468471
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Sorry typos, meant to say:</div><div> </div><div=
>Hard coding the rules for unique_ptr into a compiler warning may not be a =
terrible idea since it is used so often but that approach cannot be general=
ized.</div><div> </div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_3264_1676900223.1408554468471--
.
Author: "'Geoffrey Romer' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Wed, 20 Aug 2014 11:44:06 -0700
Raw View
--001a11c2cc1825d2f5050113fd68
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Wed, Aug 20, 2014 at 9:50 AM, Matthew Fioravante <fmatthew5876@gmail.com=
>
wrote:
>
> On Wednesday, August 20, 2014 11:47:21 AM UTC-4, David Rodr=C3=ADguez Ibe=
as
> wrote:
>>
>>
>> One possible way of tagging the code as intentional would be to
>> explicitly reset the unique pointer:
>>
>> auto x =3D make_unique<int>();
>> if (something) {
>> v.push_back(std::move(x));
>> x =3D 0; // explicitly say that the st=
ate
>> is known
>> }
>> foo(x.get()); // don't warn
>>
>
> I like this approach but I'm not sure it can be made to be generic for al=
l
> movable types.
> Consider the case where the object is reused later.
>
> auto x =3D make_unique<int>();
> v.push_back(std::move(x));
> a(x.get()); //Warning: use after move
> x =3D make_unique<int>();
> b(x.get()); //compiler saw a new assignment to x, so we know this is vali=
d
> v.push_back(std::move(x));
> c(x.get()); //Warning: use after move
>
> x.reset(new int());
> d(x.get()); //???
>
> In the above example, the compiler needs to have know that
> unique_ptr::reset() is special and makes the object reusable again. Hard
> coding the rules for unique_ptr into a compiler warning may terrible
> idea idea since it is used so often but that approach cannot be generaliz=
ed.
>
>
> The diagnostic could be made to only trigger for const operations after
> move and be reset once a non-const operation occurs. This would not catch
> all of the kinds of use-after-move bugs, though. After moving, its safe t=
o
> do operations which overwrite the state but not operations which modify t=
he
> current state. We don't currently have any way to differentiate between t=
he
> 2.
>
How about an annotation on reset(), which indicates that it's the moral
equivalent of an assignment?
Alternatively, there's something to be said for standing by the convention
that you don't do anything to a moved-from value other than reassign or
destroy it, and therefore you _shouldn't_ use reset() in this kind of
situation.
>
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--001a11c2cc1825d2f5050113fd68
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Wed, Aug 20, 2014 at 9:50 AM, Matthew Fioravante <span dir=3D"ltr"><<=
a href=3D"mailto:fmatthew5876@gmail.com" target=3D"_blank">fmatthew5876@gma=
il.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D""><br>On Wedn=
esday, August 20, 2014 11:47:21 AM UTC-4, David Rodr=C3=ADguez Ibeas wrote:=
<blockquote 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" class=
=3D"gmail_quote">
<div dir=3D"ltr"><br>One possible way of tagging the code as intentional wo=
uld be to explicitly reset the unique pointer:<br><br>auto x =3D make_uniqu=
e<int>();<br>if (something) {<br>=C2=A0 =C2=A0v.push_back(std::move(x=
));<br>=C2=A0 =C2=A0x =3D 0; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// explic=
itly say that the state is known<br>
}<br>foo(x.get()); =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// don't warn<br></div></block=
quote><div>=C2=A0</div></div><div>I like this approach but=C2=A0I'm not=
sure it can be made=C2=A0to be generic for all movable types.</div><div>Co=
nsider the case where the object is reused later.</div>
<div class=3D""><div>=C2=A0</div><div>auto x =3D make_unique<int>();<=
/div></div><div>v.push_back(std::move(x));</div><div>a(x.get()); //Warning:=
use after move</div><div class=3D""><div>x =3D make_unique<int>(); <=
/div></div>
<div>b(x.get()); //compiler saw a new assignment to x, so we know this is v=
alid</div><div>v.push_back(std::move(x));</div><div>c(x.get()); //Warning: =
use after move</div><div>=C2=A0</div><div>x.reset(new int()); </div><div>d(=
x.get()); //???</div>
<div>=C2=A0</div><div>In the above example, the compiler needs to have know=
that unique_ptr::reset() is special and makes the object reusable again. H=
ard coding the rules for unique_ptr=C2=A0into a compiler=C2=A0warning may=
=C2=A0terrible idea=C2=A0idea since it is used so often but that approach c=
annot be generalized.</div>
<div>=C2=A0</div><div>=C2=A0</div><div>The diagnostic could be made to only=
trigger for const operations after move and be reset once a non-const oper=
ation occurs. This would not catch all of the kinds of use-after-move bugs,=
though. After moving, its safe to do operations which overwrite the state =
but not operations which modify the current state. We don't currently h=
ave any way to differentiate between the 2.</div>
</div></blockquote><div><br></div><div>How about an annotation on reset(), =
which indicates that it's the moral equivalent of an assignment?</div><=
div><br></div><div>Alternatively, there's something to be said for stan=
ding by the convention that you don't do anything to a moved-from value=
other than reassign or destroy it, and therefore you _shouldn't_ use r=
eset() in this kind of situation.=C2=A0</div>
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>=C2=
=A0</div></div><div class=3D"HOEnZb"><div class=3D"h5">
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" 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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a11c2cc1825d2f5050113fd68--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Wed, 20 Aug 2014 14:12:26 -0500
Raw View
--047d7ba9792edb14fd0501146440
Content-Type: text/plain; charset=UTF-8
On 20 August 2014 13:44, 'Geoffrey Romer' via ISO C++ Standard - Future
Proposals <std-proposals@isocpp.org> wrote:
>
> Alternatively, there's something to be said for standing by the convention
> that you don't do anything to a moved-from value other than reassign or
> destroy it, and therefore you _shouldn't_ use reset() in this kind of
> situation.
>
I just teach developers the real rules instead of some subset that the
so-called experts in some organization "bless", because those developers
typically have to read and understand code written by people not in that
organization.
If you don't believe in calling reset on a moved-from unique_ptr, that's
fine for you. Please don't inflict that on the rest of us, as the standard
is clear in that not only is it allowed, but the results are well defined
and predictable. (Contrast that with the previous example of calling get()
on a moved-from unique_ptr, which is legal but results in unspecified
behavior, so one shouldn't count on it returning nullptr).
To quote [lib.types.movedfrom]
Objects of types defined in the C++ standard library may be moved from.
Move operations may
be explicitly specified or implicitly generated. Unless otherwise
specified, such moved-from objects shall be
placed in a valid but unspecified state.
Programmers can count on that.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--047d7ba9792edb14fd0501146440
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On 20 August 2014 13:44, 'Geoffrey Romer' via ISO =
C++ Standard - Future Proposals <span dir=3D"ltr"><<a href=3D"mailto:std=
-proposals@isocpp.org" target=3D"_blank">std-proposals@isocpp.org</a>></=
span> wrote:<br>
<div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote class=3D"=
gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border=
-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div=
dir=3D"ltr">
<div class=3D"gmail_extra"><br><div class=3D"gmail_quote"><div class=3D"">A=
lternatively, there's something to be said for standing by the conventi=
on that you don't do anything to a moved-from value other than reassign=
or destroy it, and therefore you _shouldn't_ use reset() in this kind =
of situation.=C2=A0<br>
</div></div></div></div></blockquote><div><br></div><div>I just teach devel=
opers the real rules instead of some subset that the so-called experts in s=
ome organization "bless", because those developers typically have=
to read and understand code written by people not in that organization.</d=
iv>
<div><br></div><div>If you don't believe in calling reset on a moved-fr=
om unique_ptr, that's fine for you. =C2=A0Please don't inflict that=
on the rest of us, as the standard is clear in that not only is it allowed=
, but the results are well defined and predictable. =C2=A0(Contrast that wi=
th the previous example of calling get() on a moved-from unique_ptr, which =
is legal but results in unspecified behavior, so one shouldn't count on=
it returning nullptr).</div>
<div><br></div><div>To quote=C2=A0<span style=3D"font-family:Helvetica;font=
-size:10px">=C2=A0</span><span style=3D"font-family:Helvetica;font-size:10p=
x">[lib.types.movedfrom]</span></div>
<p style=3D"margin:0px;font-size:10px;font-family:Helvetica">Objects of typ=
es defined in the C<span style=3D"font-size:7px">++ </span>standard library=
may be moved from. Move operations may</p>
<p style=3D"margin:0px;font-size:10px;font-family:Helvetica">be explicitly =
specified or implicitly generated. Unless otherwise specified, such moved-f=
rom objects shall be</p>
<p style=3D"margin:0px;font-size:10px;font-family:Helvetica">placed in a va=
lid but unspecified state.</p><div><br></div><div>Programmers can count on =
that.</div></div>-- <br>=C2=A0Nevin ":-)" Liber=C2=A0 <mailto:=
<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverl=
ord.com</a>>=C2=A0 (847) 691-1404
</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--047d7ba9792edb14fd0501146440--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Wed, 20 Aug 2014 22:20:37 +0300
Raw View
On 20 August 2014 22:12, Nevin Liber <nevin@eviloverlord.com> wrote:
> If you don't believe in calling reset on a moved-from unique_ptr, that's
> fine for you. Please don't inflict that on the rest of us, as the standard
> is clear in that not only is it allowed, but the results are well defined
And calling reset() is little different from an assignment.
> and predictable. (Contrast that with the previous example of calling get()
> on a moved-from unique_ptr, which is legal but results in unspecified
> behavior, so one shouldn't count on it returning nullptr).
Even that behavior isn't unspecified, [unique.ptr]/4 specifies that
the moved-from
unique_ptr contains nullptr, and move operations like
[unique.ptr.single.ctor]/15
state that they perform the ownership transfer that the aforementioned paragraph
specifies.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Matthew Fioravante <fmatthew5876@gmail.com>
Date: Wed, 20 Aug 2014 12:35:06 -0700 (PDT)
Raw View
------=_Part_375_555293571.1408563306145
Content-Type: text/plain; charset=UTF-8
On Wednesday, August 20, 2014 2:44:08 PM UTC-4, Geoffrey Romer wrote:
>
>
> How about an annotation on reset(), which indicates that it's the moral
> equivalent of an assignment?
>
>
We already have const, constexpr, noexcept, etc... One more thing to add
onto member functions for such a minor issue would be too much imho.
> Alternatively, there's something to be said for standing by the convention
> that you don't do anything to a moved-from value other than reassign or
> destroy it, and therefore you _shouldn't_ use reset() in this kind of
> situation.
>
I think this philosophy is too limiting. Its perfectly valid to use reset()
here.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_375_555293571.1408563306145
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br>On Wednesday, August 20, 2014 2:44:08 PM UTC-4, Geoffr=
ey Romer wrote:<blockquote 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;" class=3D"gmail_quote"><div dir=3D"ltr"><div><div clas=
s=3D"gmail_quote"><div> </div><div>How about an annotation on reset(),=
which indicates that it's the moral equivalent of an assignment?</div><div=
> </div></div></div></div></blockquote><div> </div><div>We alread=
y have const, constexpr, noexcept, etc... One more thing to add onto member=
functions for such a minor issue would be too much imho.</div><div> <=
/div><blockquote 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;" class=3D"gmail_quote"><div dir=3D"ltr"><div><div class=3D"gmail=
_quote"><div></div><div>Alternatively, there's something to be said for sta=
nding by the convention that you don't do anything to a moved-from value ot=
her than reassign or destroy it, and therefore you _shouldn't_ use reset() =
in this kind of situation. </div></div></div></div></blockquote><div>&=
nbsp;</div><div>I think this philosophy is too limiting. Its perfectly=
valid to use reset() here.</div><div><br> </div>
</div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_375_555293571.1408563306145--
.
Author: =?UTF-8?Q?David_Rodr=C3=ADguez_Ibeas?= <dibeas@ieee.org>
Date: Wed, 20 Aug 2014 16:17:32 -0400
Raw View
--089e0115ff684462800501154bc7
Content-Type: text/plain; charset=UTF-8
It was you who opened the discussion :)
If you are to consider the two alternatives: provide some annotation on the
class definition vs. provide some annotation after each potential move...
well I'd say that no matter how many annotations there are in the class
definition, that is a single point, while many uses of the type would have
to annotate with the 'kill' or 'verboten'.
I personally believe that you cannot make programming fool proof and that
programmers need to be careful and understand what is going on. I don't see
this as a problem that needs to be solved. As Nevin mentions, programmers
need to understand the code and be careful with what they are doing. That
being said, I believe that tools should exist to catch the inevitable
errors we all do, and I believe that in this case static analysis is a
better tool than adding more complexity to the language.
In particular, I am yet to find a single C++ programmer that truly
understands name lookup, and adding changes that make this more obscure (a
local variable is in the scope, except when it has been 'kill'-ed) seems to
be in the opposite direction of what I'd like to see in the language. I'd
rather have a failure or non-failure diagnostic than the compiler picking a
different entity that happens to have the same name.
On Wed, Aug 20, 2014 at 3:35 PM, Matthew Fioravante <fmatthew5876@gmail.com>
wrote:
>
> On Wednesday, August 20, 2014 2:44:08 PM UTC-4, Geoffrey Romer wrote:
>>
>>
>> How about an annotation on reset(), which indicates that it's the moral
>> equivalent of an assignment?
>>
>>
>
> We already have const, constexpr, noexcept, etc... One more thing to add
> onto member functions for such a minor issue would be too much imho.
>
>
>> Alternatively, there's something to be said for standing by the
>> convention that you don't do anything to a moved-from value other than
>> reassign or destroy it, and therefore you _shouldn't_ use reset() in this
>> kind of situation.
>>
>
> I think this philosophy is too limiting. Its perfectly valid to use
> reset() here.
>
>
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--089e0115ff684462800501154bc7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">It was you who opened the discussion :)<br><br>If you are =
to consider the two alternatives: provide some annotation on the class defi=
nition vs. provide some annotation after each potential move... well I'=
d say that no matter how many annotations there are in the class definition=
, that is a single point, while many uses of the type would have to annotat=
e with the 'kill' or 'verboten'.<br>
<br>I personally believe that you cannot make programming fool proof and th=
at programmers need to be careful and understand what is going on. I don=
9;t see this as a problem that needs to be solved. As Nevin mentions, progr=
ammers need to understand the code and be careful with what they are doing.=
That being said, I believe that tools should exist to catch the inevitable=
errors we all do, and I believe that in this case static analysis is a bet=
ter tool than adding more complexity to the language.<br>
<br>In particular, I am yet to find a single C++ programmer that truly unde=
rstands name lookup, and adding changes that make this more obscure (a loca=
l variable is in the scope, except when it has been 'kill'-ed) seem=
s to be in the opposite direction of what I'd like to see in the langua=
ge. I'd rather have a failure or non-failure diagnostic than the compil=
er picking a different entity that happens to have the same name.</div>
<div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Wed, Aug 2=
0, 2014 at 3:35 PM, Matthew Fioravante <span dir=3D"ltr"><<a href=3D"mai=
lto:fmatthew5876@gmail.com" target=3D"_blank">fmatthew5876@gmail.com</a>>=
;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D""><br>On Wedn=
esday, August 20, 2014 2:44:08 PM UTC-4, Geoffrey Romer wrote:<blockquote s=
tyle=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" class=3D"gmail_quo=
te">
<div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>=C2=A0</div><div>How =
about an annotation on reset(), which indicates that it's the moral equ=
ivalent of an assignment?</div><div>=C2=A0</div></div></div></div></blockqu=
ote><div>=C2=A0</div>
</div><div>We already have const, constexpr, noexcept, etc... One more thin=
g to add onto member functions for such a minor issue would be too much imh=
o.</div><div class=3D""><div>=C2=A0</div><blockquote style=3D"margin:0px 0p=
x 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left=
-width:1px;border-left-style:solid" class=3D"gmail_quote">
<div dir=3D"ltr"><div><div class=3D"gmail_quote"><div></div><div>Alternativ=
ely, there's something to be said for standing by the convention that y=
ou don't do anything to a moved-from value other than reassign or destr=
oy it, and therefore you _shouldn't_ use reset() in this kind of situat=
ion.=C2=A0</div>
</div></div></div></blockquote><div>=C2=A0</div></div><div>I think this phi=
losophy=C2=A0is too limiting. Its perfectly valid to use reset() here.</div=
><div><br>=C2=A0</div>
</div><div class=3D"HOEnZb"><div class=3D"h5">
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" 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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--089e0115ff684462800501154bc7--
.
Author: Sean Middleditch <sean.middleditch@gmail.com>
Date: Wed, 20 Aug 2014 18:27:53 -0700 (PDT)
Raw View
------=_Part_134_463970811.1408584473448
Content-Type: text/plain; charset=UTF-8
The nail in the coffin for me with either of these proposals would be
conditional moves, e.g.
auto ptr = std::make_unique<int>(42);
bounded_queue<std::unique_ptr<int>> bq;
bq.try_push_back(move(ptr));
// `ptr` may or may not be in a moved-from state here
This is common in things like concurrent queues, I/O streams, and so on.
There are other ways to formulate that interface, but none that are quite
so efficient I believe.
Rust is the language to look at here for inspiration, I think, since
they're the only one in the limelight right now with move semantics and
explicit ownership management, but their solution is over-complicated
(lifetime annotations) and inflexible (it can't do the above either). Their
solution is going to have a snowball's chance in hell of making it into
C++, and for good reason.
It would be nice to have a solution here, though. I just got bitten by this
behavior yesterday in code similar to:
void specialized_data_oriented_container::stuff(std::unique_ptr<foo> ptr)
{
_data1.emplace_back(ptr->bar());
_data2.emplace_back(std::move(ptr)); // old code use shared_ptr and
made an unnecessary copy here, so there wasn't a problem before
_data3.emplace_back(ptr->baz()); // oops, with the newly-added move
above this is now an error
}
Not the hardest bug to detect and fix, but still rather obnoxious.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_134_463970811.1408584473448
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">The nail in the coffin for me with either of these proposa=
ls would be conditional moves, e.g.<div><br></div><div> auto ptr =3D =
std::make_unique<int>(42);<br></div><div><br></div><div> bounde=
d_queue<std::unique_ptr<int>> bq;<br></div><div> bq.try_p=
ush_back(move(ptr));</div><div><br></div><div> // `ptr` may or may no=
t be in a moved-from state here</div><div><br></div><div>This is common in =
things like concurrent queues, I/O streams, and so on.</div><div><br></div>=
<div>There are other ways to formulate that interface, but none that are qu=
ite so efficient I believe.</div><div><br></div><div>Rust is the language t=
o look at here for inspiration, I think, since they're the only one in the =
limelight right now with move semantics and explicit ownership management, =
but their solution is over-complicated (lifetime annotations) and inflexibl=
e (it can't do the above either). Their solution is going to have a snowbal=
l's chance in hell of making it into C++, and for good reason.</div><div><b=
r></div><div>It would be nice to have a solution here, though. I just got b=
itten by this behavior yesterday in code similar to:</div><div><br></div><d=
iv> void specialized_data_oriented_container::stuff(std::unique_ptr&l=
t;foo> ptr) {</div><div> _data1.emplace_back(ptr->bar())=
;<br></div><div> _data2.emplace_back(std::move(ptr)); // old c=
ode use shared_ptr and made an unnecessary copy here, so there wasn't a pro=
blem before</div><div> _data3.emplace_back(ptr->baz()); // =
oops, with the newly-added move above this is now an error</div><div> =
}</div><div><br></div><div>Not the hardest bug to detect and fix, but stil=
l rather obnoxious.</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_134_463970811.1408584473448--
.
Author: "col3435 via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Thu, 21 Aug 2014 03:47:25 -0700 (PDT)
Raw View
------=_Part_141_420704534.1408618045065
Content-Type: text/plain; charset=UTF-8
On Wednesday, 20 August 2014 15:24:46 UTC+1, Matthew Fioravante wrote:
> Here are some ideas:
>
> 1) Add a new keyword to prematurely remove an object from the current
> scope.
>
> ...
>
> With this feature, you could kill the unique_ptr after moving from it,
> preventing anyone from accidentally using it.
>
> auto i = std::make_unique<int>(i);
> v.push_back(std::move(i));
> kill i;
> doSomething(i.get()); //<-compiler error, i does not exist!
>
I don't expect this will ever make it into C++. But for those of us who
wish we had "destructive move semantics", rather than the "conservative"
move semantics we got in C++11, this is part of how it could have worked.
Briefly, with destructive move semantics, a function which took a rvalue
reference parameter would take over responsibility for destroying the
object from the calling code. The calling code would look something like
this:
auto i = std::make_unique<int>(50);
kill i: v.push_back(i);
// now variable i may no longer be used
The "kill" statement tells the compiler to treat i like a temporary object
in
the expression that follows. So if i is not passed to another function
it will be destroyed at the end of that statement. But (as here) once i has
been passed to a function by rvalue reference, the compiler will no longer
make a call to the destructor in the calling code. (Note: it's required that
a local variable is either known to be killed, or not killed, at any point
in
the code. You couldn't kill a variable in only one branch of an if-else
pair,
for example.)
As for why you'd want destructive moves in the first place: it's much
easier to write sensible destructive move operations, and in particular
to write *no-throw* destructive move operations, than to write
conservative ones. If we had destructive move we probably wouldn't have
needed the noexcept hack in vector::push_back, and we wouldn't still
be tearing our hair out over things like N4055.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_141_420704534.1408618045065
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Wednesday, 20 August 2014 15:24:46 UTC+1, Matth=
ew Fioravante wrote:<br><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>Here are some ideas:</div><div> </div><div>1) Add a n=
ew keyword to prematurely remove an object from the current scope. </div><d=
iv> </div>...<br><div> </div><div>With this feature, you could ki=
ll the unique_ptr after moving from it, preventing anyone from accidentally=
using it.</div><div> </div><div><div>auto i =3D std::make_unique<i=
nt>(i);</div><div>v.push_back(std::move(i));</div><div>kill i;</div><div=
>doSomething(i.get()); //<-compiler error, i does not exist!</div></div>=
</div></blockquote><div> </div><div>I don't expect this will ever make=
it into C++. But for those of us who<br>wish we had "destructive move sema=
ntics", rather than the "conservative"<br>move semantics we got in C++11, t=
his is part of how it could have worked.<br>Briefly, with destructive move =
semantics, a function which took a rvalue<br>reference parameter would take=
over responsibility for destroying the<br>object from the calling code. Th=
e calling code would look something like<br>this:<br><br><div>auto i =3D st=
d::make_unique<int>(50);</div><div>kill i: v.push_back(i);<br>// now =
variable i may no longer be used<br><br>The "kill" statement tells the comp=
iler to treat i like a temporary object in<br>the expression that follows. =
So if i is not passed to another function<br>it will be destroyed at the en=
d of that statement. But (as here) once i has<br>been passed to a function =
by rvalue reference, the compiler will no longer<br>make a call to the dest=
ructor in the calling code. (Note: it's required that<br>a local variable i=
s either known to be killed, or not killed, at any point in<br>the code. Yo=
u couldn't kill a variable in only one branch of an if-else pair,<br>for ex=
ample.)<br><br></div>As for why you'd want destructive moves in the first p=
lace: it's much<br>easier to write sensible destructive move operations, an=
d in particular<br>to write *no-throw* destructive move operations, than to=
write<br>conservative ones. If we had destructive move we probably wouldn'=
t have<br>needed the noexcept hack in vector::push_back, and we wouldn't st=
ill<br>be tearing our hair out over things like N4055.<br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_141_420704534.1408618045065--
.
Author: Matthew Fioravante <fmatthew5876@gmail.com>
Date: Thu, 21 Aug 2014 08:32:03 -0700 (PDT)
Raw View
------=_Part_573_1371937477.1408635124010
Content-Type: text/plain; charset=UTF-8
On Wednesday, August 20, 2014 9:27:53 PM UTC-4, Sean Middleditch wrote:
>
> The nail in the coffin for me with either of these proposals would be
> conditional moves, e.g.
>
> auto ptr = std::make_unique<int>(42);
>
> bounded_queue<std::unique_ptr<int>> bq;
> bq.try_push_back(move(ptr));
>
> // `ptr` may or may not be in a moved-from state here
>
> This is common in things like concurrent queues, I/O streams, and so on.
>
This is quite interesting because you don't know if the object was moved
from and thus in the general case it could either have the original state
or the "unspecified moved from state". Therefore without additional
information such a return value or caught exception to tell you which state
the object is in, you have to assume the state is unspecified. Therefore
you still would not want to access the object and kill/verboten might still
be useful here.
> There are other ways to formulate that interface, but none that are quite
> so efficient I believe.
>
> Rust is the language to look at here for inspiration, I think, since
> they're the only one in the limelight right now with move semantics and
> explicit ownership management, but their solution is over-complicated
> (lifetime annotations) and inflexible (it can't do the above either). Their
> solution is going to have a snowball's chance in hell of making it into
> C++, and for good reason.
>
> It would be nice to have a solution here, though. I just got bitten by
> this behavior yesterday in code similar to:
>
> void specialized_data_oriented_container::stuff(std::unique_ptr<foo>
> ptr) {
> _data1.emplace_back(ptr->bar());
> _data2.emplace_back(std::move(ptr)); // old code use shared_ptr and
> made an unnecessary copy here, so there wasn't a problem before
> _data3.emplace_back(ptr->baz()); // oops, with the newly-added move
> above this is now an error
> }
>
> Not the hardest bug to detect and fix, but still rather obnoxious.
>
Glad to know I'm not the only one. There are situations where if these
kinds of bugs escape code review they could be hard to find because they
may not produce a crash which is easy to track down.
A lot of people say thing like "programmers have to be careful",
"programmers have to know what they're doing", etc... While I agree what
that in general, the truth is we are humans and we write bugs. I'm not an
infallible genius and neither is anyone on this forum. I consider any tool
which can prevent stupid me from doing stupid things a big win.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_573_1371937477.1408635124010
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Wednesday, August 20, 2014 9:27:53 PM UTC-4, Se=
an Middleditch wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr">The nail in the coffin for me with either of these proposals would=
be conditional moves, e.g.<div><br></div><div> auto ptr =3D std::mak=
e_unique<int>(42);<br></div><div><br></div><div> bounded_queue&=
lt;std::unique_ptr<<wbr>int>> bq;<br></div><div> bq.try_push=
_back(move(ptr));</div><div><br></div><div> // `ptr` may or may not b=
e in a moved-from state here</div><div><br></div><div>This is common in thi=
ngs like concurrent queues, I/O streams, and so on.</div></div></blockquote=
><div><br>This is quite interesting because you don't know if the object wa=
s moved from and thus in the general case it could either have the original=
state or the "unspecified moved from state". Therefore without addit=
ional information such a return value or caught exception to tell you which=
state the object is in, you have to assume the state is unspecified. There=
fore you still would not want to access the object and kill/verboten might =
still be useful here.<br><br><br></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-lef=
t: 1ex;"><div dir=3D"ltr"><div><br></div><div>There are other ways to formu=
late that interface, but none that are quite so efficient I believe.</div><=
div><br></div><div>Rust is the language to look at here for inspiration, I =
think, since they're the only one in the limelight right now with move sema=
ntics and explicit ownership management, but their solution is over-complic=
ated (lifetime annotations) and inflexible (it can't do the above either). =
Their solution is going to have a snowball's chance in hell of making it in=
to C++, and for good reason.</div><div><br></div><div>It would be nice to h=
ave a solution here, though. I just got bitten by this behavior yesterday i=
n code similar to:</div><div><br></div><div> void specialized_data_or=
iented_<wbr>container::stuff(std::unique_<wbr>ptr<foo> ptr) {</div><d=
iv> _data1.emplace_back(ptr->bar()<wbr>);<br></div><div>&nb=
sp; _data2.emplace_back(std::move(<wbr>ptr)); // old code use shared=
_ptr and made an unnecessary copy here, so there wasn't a problem before</d=
iv><div> _data3.emplace_back(ptr->baz()<wbr>); // oops, wit=
h the newly-added move above this is now an error</div><div> }</div><=
div><br></div><div>Not the hardest bug to detect and fix, but still rather =
obnoxious.</div></div></blockquote><div><br>Glad to know I'm not the only o=
ne. There are situations where if these kinds of bugs escape code review th=
ey could be hard to find because they may not produce a crash which is easy=
to track down.<br><br>A lot of people say thing like "programmers have to =
be careful", "programmers have to know what they're doing", etc... While I =
agree what that in general, the truth is we are humans and we write bugs. I=
'm not an infallible genius and neither is anyone on this forum. I consider=
any tool which can prevent stupid me from doing stupid things a big win. <=
br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_573_1371937477.1408635124010--
.
Author: Sean Middleditch <sean@middleditch.us>
Date: Thu, 21 Aug 2014 09:04:01 -0700
Raw View
On Thu, Aug 21, 2014 at 8:32 AM, Matthew Fioravante
<fmatthew5876@gmail.com> wrote:
>
>
> On Wednesday, August 20, 2014 9:27:53 PM UTC-4, Sean Middleditch wrote:
>>
>> The nail in the coffin for me with either of these proposals would be
>> conditional moves, e.g.
>>
>> auto ptr = std::make_unique<int>(42);
>>
>> bounded_queue<std::unique_ptr<int>> bq;
>> bq.try_push_back(move(ptr));
>>
>> // `ptr` may or may not be in a moved-from state here
>>
>> This is common in things like concurrent queues, I/O streams, and so on.
>
>
> This is quite interesting because you don't know if the object was moved
> from and thus in the general case it could either have the original state or
The example was incomplete, sorry. try_push_back or its ilk generally
return a bool or an enum. A more complete usage looks something like:
while (bq.try_push_back(move(ptr)) != bounded_queue_result::success) {
do_something_else_for_awhile();
}
So the try_push_back is repeatedly called. You could mark the variable
as killed explicitly after the while loop easily enough in this
example, but needing to be explicit kinda defeats the whole purpose of
avoiding the class of bugs caused by move semantics. The compiler or
static analyzer really needs to be the one to figure out the lifetime
violation, not a human.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: masse.nicolas@gmail.com
Date: Fri, 22 Aug 2014 04:14:54 -0700 (PDT)
Raw View
------=_Part_1084_1335061900.1408706094646
Content-Type: text/plain; charset=UTF-8
Interesting.
What I understand from that is that the standard library define the
behaviour of move ctors. The problem is that the language doesn't give us
anything to be able to tell that behaviour to the compiler.
The result is that even if the compiler is able to detect the use of a
moved variable and emits warnings/errors in that case, it could still emits
false positive.
Now about the proposeds solutions. I would reject both of them because I
think that either kill or std::verboten() are at the wrong place, and they
don't solve the problem of false positive when reset() if called from a
moved-from unique_ptr for exemple.
For my part I would prefer a solution where a solution able to tell the
compiler that calling x.reset() is still valid while derefencing it
(calling int y = *x; for example) is not.
On Wednesday, August 20, 2014 9:20:40 PM UTC+2, Ville Voutilainen wrote:
>
> On 20 August 2014 22:12, Nevin Liber <ne...@eviloverlord.com <javascript:>>
> wrote:
> > If you don't believe in calling reset on a moved-from unique_ptr, that's
> > fine for you. Please don't inflict that on the rest of us, as the
> standard
> > is clear in that not only is it allowed, but the results are well
> defined
>
> And calling reset() is little different from an assignment.
>
> > and predictable. (Contrast that with the previous example of calling
> get()
> > on a moved-from unique_ptr, which is legal but results in unspecified
> > behavior, so one shouldn't count on it returning nullptr).
>
> Even that behavior isn't unspecified, [unique.ptr]/4 specifies that
> the moved-from
> unique_ptr contains nullptr, and move operations like
> [unique.ptr.single.ctor]/15
> state that they perform the ownership transfer that the aforementioned
> paragraph
> specifies.
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_1084_1335061900.1408706094646
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Interesting. <br>What I understand from that is that the s=
tandard library define the behaviour of move ctors. The problem is that the=
language doesn't give us anything to be able to tell that behaviour to the=
compiler.<br>The result is that even if the compiler is able to detect the=
use of a moved variable and emits warnings/errors in that case, it could s=
till emits false positive.<br><br>Now about the proposeds solutions. I woul=
d reject both of them because I think that either kill or std::verboten() a=
re at the wrong place, and they don't solve the problem of false positive w=
hen reset() if called from a moved-from unique_ptr for exemple.<br>For my p=
art I would prefer a solution where a solution able to tell the compiler th=
at calling x.reset() is still valid while derefencing it (calling int y =3D=
*x; for example) is not.<br><br>On Wednesday, August 20, 2014 9:20:40 PM U=
TC+2, Ville Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">=
On 20 August 2014 22:12, Nevin Liber <<a href=3D"javascript:" target=3D"=
_blank" gdf-obfuscated-mailto=3D"1e0kZ9gFGRcJ" onmousedown=3D"this.href=3D'=
javascript:';return true;" onclick=3D"this.href=3D'javascript:';return true=
;">ne...@eviloverlord.com</a>> wrote:
<br>> If you don't believe in calling reset on a moved-from unique_ptr, =
that's
<br>> fine for you. Please don't inflict that on the rest of us, a=
s the standard
<br>> is clear in that not only is it allowed, but the results are well =
defined
<br>
<br>And calling reset() is little different from an assignment.
<br>
<br>> and predictable. (Contrast that with the previous example of=
calling get()
<br>> on a moved-from unique_ptr, which is legal but results in unspecif=
ied
<br>> behavior, so one shouldn't count on it returning nullptr).
<br>
<br>Even that behavior isn't unspecified, [unique.ptr]/4 specifies that
<br>the moved-from
<br>unique_ptr contains nullptr, and move operations like
<br>[unique.ptr.single.ctor]/15
<br>state that they perform the ownership transfer that the aforementioned =
paragraph
<br>specifies.
<br></blockquote></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1084_1335061900.1408706094646--
.
Author: Adam Nevraumont <afn@theorem.ca>
Date: Fri, 22 Aug 2014 15:30:40 -0700 (PDT)
Raw View
How about:
int i;
i=3;
i.~int();
Calling the destructor explicitly on a value type variable destroys it and removes it from scope.
Downside: explicit destructors are otherwise dangerous.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Sat, 23 Aug 2014 01:42:26 +0300
Raw View
On 23 August 2014 01:30, Adam Nevraumont <afn@theorem.ca> wrote:
> How about:
>
> int i;
> i=3;
> i.~int();
>
> Calling the destructor explicitly on a value type variable destroys it and removes it from scope.
Well, that prevents placement-newing a new object into the storage
designated by the
name, and I expect that would break existing code.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Fri, 22 Aug 2014 22:18:17 -0700
Raw View
On Friday 22 August 2014 15:30:40 Adam Nevraumont wrote:
> How about:
>
> int i;
> i=3;
> i.~int();
>
> Calling the destructor explicitly on a value type variable destroys it and
> removes it from scope.
>
> Downside: explicit destructors are otherwise dangerous.
Other downside: this is already valid today and doesn't remove from scope.
It's possible to reconstruct the variable using placement new.
And this solution still has the problem of breaking the order of destruction.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: David Krauss <potswa@gmail.com>
Date: Sat, 23 Aug 2014 13:58:39 +0800
Raw View
--Apple-Mail=_1C791E7C-0394-4ADB-B6D3-C155EB38C44B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
On 2014-08-23, at 6:30 AM, Adam Nevraumont <afn@theorem.ca> wrote:
> How about:
>=20
> int i;
> i=3D3;
> i.~int();
>=20
> Calling the destructor explicitly on a value type variable destroys it an=
d removes it from scope.
>=20
> Downside: explicit destructors are otherwise dangerous.
I'm horrified.
The move semantics of most types (especially containers and smart pointers)=
define ownership be transferred as owned resources are preserved untouched=
.. If you need an observer to a unique_ptr which meanwhile gets transferred =
into a container, simply use
auto & observer =3D * owner; // Add const if you can.
Refactoring move into legacy code is nontrivial, and better static analysis=
tools would be nice. Perhaps we would all benefit from a std::unused() fun=
ction which does nothing except communicate intent (i.e., let the implement=
ation try to detect and warn on subsequent use). Maybe also std::reuse() to=
silence any possible proactive use-after-move diagnosis, or std::move_but_=
reuse() to prevent the diagnostic analysis from starting in the first place=
.. However, statically detecting use of a variable through aliases is imposs=
ible.
But there's nothing special about legacy code that requires new constructs =
with their own downsides. Maintenance duty is usually when we're most risk-=
averse.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_1C791E7C-0394-4ADB-B6D3-C155EB38C44B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;08–23, at 6:30 AM, Adam Nevraumont <<a href=3D"mailto:afn@th=
eorem.ca">afn@theorem.ca</a>> wrote:</div><br class=3D"Apple-interchange=
-newline"><blockquote type=3D"cite">How about:<br><br>int i;<br>i=3D3;<br>i=
..~int();<br><br>Calling the destructor explicitly on a value type variable =
destroys it and removes it from scope.<br><br>Downside: explicit destructor=
s are otherwise dangerous.<br></blockquote><div><br></div>I’m horrifi=
ed.</div><div><br></div><div>The move semantics of most types (especially c=
ontainers and smart pointers) define ownership be transferred as owned reso=
urces are preserved untouched. If you need an observer to a <font face=3D"C=
ourier">unique_ptr</font> which meanwhile gets transferred into a cont=
ainer, simply use</div><div><br></div><div><font face=3D"Courier">auto &=
; observer =3D * owner; // Add const if you can.</font></div><div><br></div=
><div>Refactoring <font face=3D"Courier">move</font> into legacy code is no=
ntrivial, and better static analysis tools would be nice. Perhaps we would =
all benefit from a <font face=3D"Courier">std::unused()</font> function whi=
ch does nothing except communicate intent (i.e., let the implementation try=
to detect and warn on subsequent use). Maybe also <font face=3D"Courier">s=
td::reuse()</font> to silence any possible proactive use-after-move di=
agnosis, or <font face=3D"Courier">std::move_but_reuse()</font> to pre=
vent the diagnostic analysis from starting in the first place. However, sta=
tically detecting use of a variable through aliases is impossible.</div><di=
v><br></div><div>But there’s nothing special about legacy code that r=
equires new constructs with their own downsides. Maintenance duty is usuall=
y when we’re most risk-averse.</div><div><br></div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_1C791E7C-0394-4ADB-B6D3-C155EB38C44B--
.
Author: Matthew Fioravante <fmatthew5876@gmail.com>
Date: Sat, 23 Aug 2014 07:05:53 -0700 (PDT)
Raw View
------=_Part_100_821576670.1408802753189
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Saturday, August 23, 2014 1:58:51 AM UTC-4, David Krauss wrote:
>
>
> On 2014=E2=80=9308=E2=80=9323, at 6:30 AM, Adam Nevraumont <a...@theorem.=
ca <javascript:>>=20
> wrote:
>
> How about:
>
> int i;
> i=3D3;
> i.~int();
>
> Calling the destructor explicitly on a value type variable destroys it an=
d=20
> removes it from scope.
>
> Downside: explicit destructors are otherwise dangerous.
>
>
> I=E2=80=99m horrified.
>
>
I don't like this approach either. I think messing with the destruction=20
order of automatic variables is bad news and possible source of bugs. If=20
you want to destroy something early you can create an extra scope with=20
braces.
=20
> The move semantics of most types (especially containers and smart=20
> pointers) define ownership be transferred as owned resources are preserve=
d=20
> untouched. If you need an observer to a unique_ptr which meanwhile gets=
=20
> transferred into a container, simply use
>
> auto & observer =3D * owner; // Add const if you can.
>
> Refactoring move into legacy code is nontrivial,=20
>
Indeed, and this is exactly what made me think of this issue.=20
=20
> and better static analysis tools would be nice. Perhaps we would all=20
> benefit from a std::unused() function which does nothing except=20
> communicate intent (i.e., let the implementation try to detect and warn o=
n=20
> subsequent use). Maybe also std::reuse() to silence any possible=20
> proactive use-after-move diagnosis, or std::move_but_reuse() to prevent=
=20
> the diagnostic analysis from starting in the first place. However,=20
> statically detecting use of a variable through aliases is impossible.
>
> That's pretty much the same as my idea for std::verbotten.=20
=20
> But there=E2=80=99s nothing special about legacy code that requires new c=
onstructs=20
> with their own downsides. Maintenance duty is usually when we=E2=80=99re =
most=20
> risk-averse.
>
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_100_821576670.1408802753189
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Saturday, August 23, 2014 1:58:51 AM UTC-4, Dav=
id Krauss wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"=
word-wrap:break-word"><br><div><div>On 2014=E2=80=9308=E2=80=9323, at 6:30 =
AM, Adam Nevraumont <<a href=3D"javascript:" target=3D"_blank" gdf-obfus=
cated-mailto=3D"lAHJwbUUNuAJ" onmousedown=3D"this.href=3D'javascript:';retu=
rn true;" onclick=3D"this.href=3D'javascript:';return true;">a...@theorem.c=
a</a>> wrote:</div><br><blockquote type=3D"cite">How about:<br><br>int i=
;<br>i=3D3;<br>i.~int();<br><br>Calling the destructor explicitly on a valu=
e type variable destroys it and removes it from scope.<br><br>Downside: exp=
licit destructors are otherwise dangerous.<br></blockquote><div><br></div>I=
=E2=80=99m horrified.</div><div><br></div></div></blockquote><div><br></div=
><div>I don't like this approach either. I think messing with the destructi=
on order of automatic variables is bad news and possible source of bugs. If=
you want to destroy something early you can create an extra scope with bra=
ces.</div><div> </div><blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v style=3D"word-wrap:break-word"><div></div><div>The move semantics of most=
types (especially containers and smart pointers) define ownership be trans=
ferred as owned resources are preserved untouched. If you need an observer =
to a <font face=3D"Courier">unique_ptr</font> which meanwhile gets tra=
nsferred into a container, simply use</div><div><br></div><div><font face=
=3D"Courier">auto & observer =3D * owner; // Add const if you can.</fon=
t></div><div><br></div><div>Refactoring <font face=3D"Courier">move</font> =
into legacy code is nontrivial, </div></div></blockquote><div><br></div><di=
v>Indeed, and this is exactly what made me think of this issue. </div>=
<div> </div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D=
"word-wrap:break-word"><div>and better static analysis tools would be nice.=
Perhaps we would all benefit from a <font face=3D"Courier">std::unused()</=
font> function which does nothing except communicate intent (i.e., let the =
implementation try to detect and warn on subsequent use). Maybe also <font =
face=3D"Courier">std::reuse()</font> to silence any possible proactive=
use-after-move diagnosis, or <font face=3D"Courier">std::move_but_reuse()<=
/font> to prevent the diagnostic analysis from starting in the first p=
lace. However, statically detecting use of a variable through aliases is im=
possible.</div><div><br></div></div></blockquote><div>That's pretty much th=
e same as my idea for std::verbotten. </div><div> </div><blockquo=
te class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left:=
1px #ccc solid;padding-left: 1ex;"><div style=3D"word-wrap:break-word"><di=
v></div><div>But there=E2=80=99s nothing special about legacy code that req=
uires new constructs with their own downsides. Maintenance duty is usually =
when we=E2=80=99re most risk-averse.</div><div><br></div></div></blockquote=
></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_100_821576670.1408802753189--
.
Author: David Krauss <potswa@gmail.com>
Date: Sat, 23 Aug 2014 22:26:14 +0800
Raw View
--Apple-Mail=_DF265140-9AF9-4D9A-8A77-B2225C0829E4
Content-Type: text/plain; charset=ISO-8859-1
On 2014-08-23, at 10:05 PM, Matthew Fioravante <fmatthew5876@gmail.com> wrote:
> That's pretty much the same as my idea for std::verboten.
Yeah. The main difference is required diagnosis vs. recommended warning.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--Apple-Mail=_DF265140-9AF9-4D9A-8A77-B2225C0829E4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;08–23, at 10:05 PM, Matthew Fioravante <<a href=3D"mailto:fm=
atthew5876@gmail.com">fmatthew5876@gmail.com</a>> wrote:</div><br class=
=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div style=3D"font=
-family: Helvetica; font-size: 12px; font-style: normal; font-variant: norm=
al; font-weight: normal; letter-spacing: normal; line-height: normal; orpha=
ns: auto; text-align: start; text-indent: 0px; text-transform: none; white-=
space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: =
0px;"><div dir=3D"ltr">That's pretty much the same as my idea for std::verb=
oten. </div></div></blockquote><div><br></div><div>Yeah. The main diff=
erence is required diagnosis vs. recommended warning.</div></div><br></body=
></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_DF265140-9AF9-4D9A-8A77-B2225C0829E4--
.
Author: Douglas Boffey <douglas.boffey@gmail.com>
Date: Sat, 30 Aug 2014 09:49:10 -0700 (PDT)
Raw View
------=_Part_1478_1536131187.1409417350754
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Just one question (sorry if it=E2=80=99s already been addressed and I misse=
d it):
In
int i;
if (/* some condition */)
kill i;
/* Do something with i */
Would that be legal? Would the program need to keep track of whether i has=
=20
been killed or not (in this example, code movement would solve this issue,=
=20
but that is not a general solution)?
Oops=E2=80=94that=E2=80=99s two questions ;)
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_1478_1536131187.1409417350754
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Just one question (sorry if it=E2=80=99s already been addr=
essed and I missed it):<br><br>In<br><br><div class=3D"prettyprint" style=
=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187);=
border-style: solid; border-width: 1px; word-wrap: break-word;"><code clas=
s=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;=
" class=3D"styled-by-prettify">int</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> i</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify"=
>if</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span st=
yle=3D"color: #800;" class=3D"styled-by-prettify">/* some condition */</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br> kill i</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"=
color: #800;" class=3D"styled-by-prettify">/* Do something with i */</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div></code=
></div><br><br>Would that be legal? Would the program need to keep tr=
ack of whether i has been killed or not (in this example, code movement wou=
ld solve this issue, but that is not a general solution)?<br><br>Oops=E2=80=
=94that=E2=80=99s two questions ;)<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1478_1536131187.1409417350754--
.
Author: Matthew Fioravante <fmatthew5876@gmail.com>
Date: Sat, 30 Aug 2014 13:16:32 -0700 (PDT)
Raw View
------=_Part_1585_216752511.1409429792144
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Saturday, August 30, 2014 12:49:10 PM UTC-4, Douglas Boffey wrote:
>
> Just one question (sorry if it=E2=80=99s already been addressed and I mis=
sed it):
>
> In
>
> int i;
> if (/* some condition */)
> kill i;
> /* Do something with i */
>
>
>
> Would that be legal? Would the program need to keep track of whether i=
=20
> has been killed or not (in this example, code movement would solve this=
=20
> issue, but that is not a general solution)?
>
> Oops=E2=80=94that=E2=80=99s two questions ;)
>
This example would remove i from the scope of the if statement. Since the=
=20
if scope doesn't do anything except kill, they essentially does nothing.
This example should illuminate:
int i;
if(something) {
kill i;
++i; //Error, i removed from scope
}
++i; //Ok=20
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_1585_216752511.1409429792144
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Saturday, August 30, 2014 12:49:10 PM UTC-4, Do=
uglas Boffey wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr">Just one question (sorry if it=E2=80=99s already been addressed and I=
missed it):<br><br>In<br><br><div style=3D"background-color:rgb(250,250,25=
0);border-color:rgb(187,187,187);border-style:solid;border-width:1px;word-w=
rap:break-word"><code><div><span style=3D"color:#008">int</span><span style=
=3D"color:#000"> i</span><span style=3D"color:#660">;</span><span style=3D"=
color:#000"><br></span><span style=3D"color:#008">if</span><span style=3D"c=
olor:#000"> </span><span style=3D"color:#660">(</span><span style=3D"color:=
#800">/* some condition */</span><span style=3D"color:#660">)</span><span s=
tyle=3D"color:#000"><br> kill i</span><span style=3D"color:#660">;</s=
pan><span style=3D"color:#000"><br></span><span style=3D"color:#800">/* Do =
something with i */</span><span style=3D"color:#000"><br></span><span style=
=3D"color:#000"><br></span></div></code></div><br><br>Would that be legal?&=
nbsp; Would the program need to keep track of whether i has been killed or =
not (in this example, code movement would solve this issue, but that is not=
a general solution)?<br><br>Oops=E2=80=94that=E2=80=99s two questions ;)<b=
r></div></blockquote><div><br></div><div>This example would remove i from t=
he scope of the if statement. Since the if scope doesn't do anything except=
kill, they essentially does nothing.</div><div><br></div><div>This example=
should illuminate:</div><div><br></div><div>int i;</div><div><br></div><di=
v>if(something) {</div><div> kill i;</div><div> ++i; //Error, i=
removed from scope</div><div>}</div><div>++i; //Ok </div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1585_216752511.1409429792144--
.
Author: rgumpertz@gmail.com
Date: Sun, 7 Sep 2014 15:06:49 -0700 (PDT)
Raw View
------=_Part_1551_978909928.1410127609419
Content-Type: text/plain; charset=UTF-8
It looks to me like this is a specific case of a more general issue: it
would be nice to:
(1) Change a local variable from non-const to const once it has been
initialized
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_1551_978909928.1410127609419
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"ltr"><div>It looks to me like this is a specif=
ic case of a more general issue: it would be nice to:<br> =
(1) Change a local variable from non-const to const once it has been initi=
alized<br><br> <br></div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1551_978909928.1410127609419--
.
Author: rgumpertz@gmail.com
Date: Sun, 7 Sep 2014 15:31:12 -0700 (PDT)
Raw View
------=_Part_1571_336718757.1410129073177
Content-Type: text/plain; charset=UTF-8
It looks to me like this is one case of a more general desire:
(1) tell the compiler that a local variable should be treated as const
for the remainder of the containing block
(2) tell the compiler that the value of a local variable is no longer
"useful"
Neither of the above is currently possible in a trivial manner (and might
be difficult to define cleanly for conditionals, loops, and nested blocks).
For now, however, I agree that compilers might want to treat moved-from
variables similarly to how they treat uninitialized variables and generate
appropriate warnings if the compiler can determine for sure that they are
reused without being reinitializing.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_1571_336718757.1410129073177
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"ltr"><div>It looks to me like this is one case=
of a more general desire:<br> (1) tell the compiler that=
a local variable should be treated as const for the remainder of the conta=
ining block<br> (2) tell the compiler that the value of a=
local variable is no longer "useful"<br>Neither of the above is currently =
possible in a trivial manner (and might be difficult to define cleanly for =
conditionals, loops, and nested blocks).<br><br>For now, however, I agree t=
hat compilers might want to treat moved-from variables similarly to how the=
y treat uninitialized variables and generate appropriate warnings if the co=
mpiler can determine for sure that they are reused without being reinitiali=
zing.<br></div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1571_336718757.1410129073177--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Mon, 8 Sep 2014 01:46:28 +0300
Raw View
On 8 September 2014 01:31, <rgumpertz@gmail.com> wrote:
> For now, however, I agree that compilers might want to treat moved-from
> variables similarly to how they treat uninitialized variables and generate
> appropriate warnings if the compiler can determine for sure that they are
> reused without being reinitializing.
I don't see how that makes sense. Compilers issue warnings for variables
of fundamental type being used before being initialized (and don't seem to
do so for aggregates). But moving from such types does not return them
into an uninitialized state. Library types like containers and unique_ptr
as examples do not go into an invalid state after being moved from.
So I fail to see when such warnings would be appropriate.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Matthew Fioravante <fmatthew5876@gmail.com>
Date: Mon, 8 Sep 2014 10:54:47 -0700 (PDT)
Raw View
------=_Part_765_1913358570.1410198888010
Content-Type: text/plain; charset=UTF-8
On Sunday, September 7, 2014 6:31:13 PM UTC-4, rgum...@gmail.com wrote:
>
> It looks to me like this is one case of a more general desire:
> (1) tell the compiler that a local variable should be treated as const
> for the remainder of the containing block
>
That could easily be implemented using the current proposal:
Foo x;
//do non-const stuff with x
const auto& xc = x;
kill x;
//do const operations on xc
I think changing the type of x itself to be const in the middle of the
block would be a very bad idea. It makes the code very hard to read if the
type can change anywhere. Also it could have disastrous consequences for
templates.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_765_1913358570.1410198888010
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Sunday, September 7, 2014 6:31:13 PM UTC-4, rgu=
m...@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div dir=3D"ltr"><div>It looks to me like this is one case of a mo=
re general desire:<br> (1) tell the compiler that a local=
variable should be treated as const for the remainder of the containing bl=
ock<br></div></div></div></blockquote><div><br>That could easily be impleme=
nted using the current proposal:<br><br>Foo x;<br>//do non-const stuff with=
x<br>const auto& xc =3D x;<br>kill x;<br>//do const operations on xc<b=
r><br>I think changing the type of x itself to be const in the middle of th=
e block would be a very bad idea. It makes the code very hard to read if th=
e type can change anywhere. Also it could have disastrous consequences for =
templates.<br><br> </div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_765_1913358570.1410198888010--
.
Author: Matthew Fioravante <fmatthew5876@gmail.com>
Date: Mon, 8 Sep 2014 13:54:13 -0700 (PDT)
Raw View
------=_Part_150_99755375.1410209654067
Content-Type: text/plain; charset=UTF-8
That doesn't change the type of x. It opens a new scope with a new variable
named x which just happens to be a const reference to the old one.
On Monday, September 8, 2014 4:51:31 PM UTC-4, Chet wrote:
>
>
>
> I beleive changing the type of x is currently possible using lambdas
> (Generalized lambda captures):
>
> Foo x;
> //do non-const stuff with x
> const auto& xc = x;
> [&x=cx,&]()->void{
> //do const operations on x
> }();
>
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_150_99755375.1410209654067
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">That doesn't change the type of x. It opens a new scope wi=
th a new variable named x which just happens to be a const reference to the=
old one.<br><br>On Monday, September 8, 2014 4:51:31 PM UTC-4, Chet wrote:=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><br><div><br>=
</div><div>I beleive changing the type of x is currently possible using lam=
bdas (Generalized lambda captures):</div><div><br></div><div>Foo x;<br>//do=
non-const stuff with x<br>const auto& xc =3D x;<br>[&x=3Dcx,&]=
()->void{<br>//do const operations on x<br></div><div>}();</div><div><br=
></div></div></blockquote></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_150_99755375.1410209654067--
.
Author: Chet <chet.skolos@gmail.com>
Date: Mon, 8 Sep 2014 13:51:30 -0700 (PDT)
Raw View
------=_Part_130_362378358.1410209490980
Content-Type: text/plain; charset=UTF-8
On Monday, 8 September 2014 10:54:48 UTC-7, Matthew Fioravante wrote:
>
>
>
> On Sunday, September 7, 2014 6:31:13 PM UTC-4, rgum...@gmail.com wrote:
>>
>> It looks to me like this is one case of a more general desire:
>> (1) tell the compiler that a local variable should be treated as
>> const for the remainder of the containing block
>>
>
> That could easily be implemented using the current proposal:
>
> Foo x;
> //do non-const stuff with x
> const auto& xc = x;
> kill x;
> //do const operations on xc
>
> I think changing the type of x itself to be const in the middle of the
> block would be a very bad idea. It makes the code very hard to read if the
> type can change anywhere. Also it could have disastrous consequences for
> templates.
>
>
>
I beleive changing the type of x is currently possible using lambdas
(Generalized lambda captures):
Foo x;
//do non-const stuff with x
const auto& xc = x;
[&x=cx,&]()->void{
//do const operations on x
}();
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_130_362378358.1410209490980
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Monday, 8 September 2014 10:54:48 UTC-7, Matthe=
w Fioravante wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><br><br>On Sunday, September 7, 2014 6:31:13 PM UTC-4, <a>rgum...@=
gmail.com</a> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;mar=
gin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr=
"><div dir=3D"ltr"><div>It looks to me like this is one case of a more gene=
ral desire:<br> (1) tell the compiler that a local variab=
le should be treated as const for the remainder of the containing block<br>=
</div></div></div></blockquote><div><br>That could easily be implemented us=
ing the current proposal:<br><br>Foo x;<br>//do non-const stuff with x<br>c=
onst auto& xc =3D x;<br>kill x;<br>//do const operations on xc<br><br>I=
think changing the type of x itself to be const in the middle of the block=
would be a very bad idea. It makes the code very hard to read if the type =
can change anywhere. Also it could have disastrous consequences for templat=
es.<br><br> </div></div></blockquote><div><br></div><div>I beleive cha=
nging the type of x is currently possible using lambdas (Generalized lambda=
captures):</div><div><br></div><div>Foo x;<br>//do non-const stuff with x<=
br>const auto& xc =3D x;<br>[&x=3Dcx,&]()->void{<br>//do con=
st operations on x<br></div><div>}();</div><div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_130_362378358.1410209490980--
.
Author: Adam Nevraumont <afn@theorem.ca>
Date: Tue, 9 Sep 2014 21:25:31 -0700 (PDT)
Raw View
Killing a variable woukd be roughky equivalent to retyping it as void.
Retyping a T as const T, or a Derived* as Base*, would be variations.
T x;
virtual x = T const&;// treat access to x as if it was const
virtual x = void; // treat access to x as illegal
Derived* y;
virtual y = Base*;
virtual y = const Base*;
In general, virtual V = type; is legal if:
1) V is a variable in the enclosing function local scope
2a) type is void **or**
2b) V is implicitly convertable to type
In 2a) case, the variable V is killed. In 2b case, it is hidden by a new V, which is implicitly constructed from the old V.
virtual V = const;
virtual V = const*;
could be used as shortcuts for const&, and decltype(*V) const*.
(Virtual may not be ideal keyword, but)
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Brent Friedman <fourthgeek@gmail.com>
Date: Wed, 10 Sep 2014 01:03:18 -0500
Raw View
--e89a8ff1cf92ff0d1f0502afce35
Content-Type: text/plain; charset=UTF-8
Have you considered this alternative?
optional<T> x = ...;
x->thing();
x = nullopt; // kill x
x->thing(); //undefined behavior
To provide your error/warning, the compiler/static analyzer simply needs to
understand the well-defined semantics of optional.
The original examples you gave were dealing with std::move. Those could be
supported with some nice 'move the value out of the optional' syntax.
optional<T> x = ...;
y = x.pop(); //disengages x and returns T&&; requires x to be engaged.
x->thing(); //undefined behavior
On Tue, Sep 9, 2014 at 11:25 PM, Adam Nevraumont <afn@theorem.ca> wrote:
> Killing a variable woukd be roughky equivalent to retyping it as void.
>
> Retyping a T as const T, or a Derived* as Base*, would be variations.
>
> T x;
> virtual x = T const&;// treat access to x as if it was const
> virtual x = void; // treat access to x as illegal
> Derived* y;
> virtual y = Base*;
> virtual y = const Base*;
>
> In general, virtual V = type; is legal if:
> 1) V is a variable in the enclosing function local scope
> 2a) type is void **or**
> 2b) V is implicitly convertable to type
>
> In 2a) case, the variable V is killed. In 2b case, it is hidden by a new
> V, which is implicitly constructed from the old V.
>
> virtual V = const;
> virtual V = const*;
>
> could be used as shortcuts for const&, and decltype(*V) const*.
>
> (Virtual may not be ideal keyword, but)
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--e89a8ff1cf92ff0d1f0502afce35
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Have you considered this alternative?<div><br></div><div>o=
ptional<T> x =3D ...;</div><div>x->thing();</div><div>x =3D nullop=
t; // kill x</div><div>x->thing(); //undefined behavior</div><div><br></=
div><div>To provide your error/warning, the compiler/static analyzer simply=
needs to understand the well-defined semantics of optional.</div><div><br>=
</div><div><br></div><div>The original examples you gave were dealing with =
std::move. Those could be supported with some nice 'move the value out =
of the optional' syntax.</div><div><br></div><div>optional<T> x =
=3D ...;</div><div>y =3D x.pop(); //disengages x and returns T&&; r=
equires x to be engaged.</div><div>x->thing(); //undefined behavior</div=
></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Tue, Se=
p 9, 2014 at 11:25 PM, Adam Nevraumont <span dir=3D"ltr"><<a href=3D"mai=
lto:afn@theorem.ca" target=3D"_blank">afn@theorem.ca</a>></span> wrote:<=
br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex">Killing a variable woukd be roughky equiv=
alent to retyping it as void.<br>
<br>
Retyping a T as const T, or a Derived* as Base*, would be variations.<br>
<br>
T x;<br>
virtual x =3D T const&;// treat access to x as if it was const<br>
virtual x =3D void; // treat access to x as illegal<br>
Derived* y;<br>
virtual y =3D Base*;<br>
virtual y =3D const Base*;<br>
<br>
In general, virtual V =3D type; is legal if:<br>
1) V is a variable in the enclosing function local scope<br>
2a) type is void **or**<br>
2b) V is implicitly convertable to type<br>
<br>
In 2a) case, the variable V is killed.=C2=A0 In 2b case, it is hidden by a =
new V, which is implicitly constructed from the old V.<br>
<br>
virtual V =3D const;<br>
virtual V =3D const*;<br>
<br>
could be used as shortcuts for const&, and decltype(*V) const*.<br>
<br>
(Virtual may not be ideal keyword, but)<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
--<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">std-propo=
sals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--e89a8ff1cf92ff0d1f0502afce35--
.
Author: Chet <chet.skolos@gmail.com>
Date: Wed, 10 Sep 2014 18:09:47 -0700 (PDT)
Raw View
------=_Part_2124_1075253516.1410397787417
Content-Type: text/plain; charset=UTF-8
Adding a "disengage and move from" method to optional is good idea.
However, the original code can be reworked to not use std::move.
//Code with move:
struct F {
std::vector<std::unique_ptr<int>> v;
void run() {
auto i = std::make_unique<int>();
v.push_back(std::move(i));
doSomethingWith(i.get()); //logic error. i is a "moved from" state.
}
};
//Code without move:
struct F {
std::vector<std::unique_ptr<int>> v;
void run() {
v.push_back(std::make_unique<int>());
doSomethingWith(i.get()); // error here because no i
}
};
//Code without move allowing for more code between make and push back
struct F {
std::vector<std::unique_ptr<int>> v;
void run() {
v.push_back([&]()->std::unique_ptr<int>{
auto i = std::make_unique<int>();
//Do more things with i here.
return i;
}());
doSomethingWith(i.get()); // error here because no i
}
};
//With one more refactoring a potential fix...
struct F {
std::vector<std::unique_ptr<int>> v;
void run() {
v.push_back([&]()->std::unique_ptr<int>{
auto i = std::make_unique<int>();
// possible problem: vector v does not have the pointer when
doSomethingWith is called.
doSomethingWith(i.get());
return i;
}());
}
};
In C++14 it is possible to hide and kill variables by introducing and
closing scopes. If there is a real need to keep multiple variables in the
same scope, creative use of std::optional can also simulate killing a
variable, or you can invent a similar template class that has additional
specific features around killing and moving. (Also, if the indenting really
gets you down, just don't indent; this is c++ not Python. ;-)
On Tuesday, 9 September 2014 23:03:20 UTC-7, Brent Friedman wrote:
>
> Have you considered this alternative?
>
> optional<T> x = ...;
> x->thing();
> x = nullopt; // kill x
> x->thing(); //undefined behavior
>
> To provide your error/warning, the compiler/static analyzer simply needs
> to understand the well-defined semantics of optional.
>
>
> The original examples you gave were dealing with std::move. Those could be
> supported with some nice 'move the value out of the optional' syntax.
>
> optional<T> x = ...;
> y = x.pop(); //disengages x and returns T&&; requires x to be engaged.
> x->thing(); //undefined behavior
>
> On Tue, Sep 9, 2014 at 11:25 PM, Adam Nevraumont <a...@theorem.ca
> <javascript:>> wrote:
>
>> Killing a variable woukd be roughky equivalent to retyping it as void.
>>
>> Retyping a T as const T, or a Derived* as Base*, would be variations.
>>
>> T x;
>> virtual x = T const&;// treat access to x as if it was const
>> virtual x = void; // treat access to x as illegal
>> Derived* y;
>> virtual y = Base*;
>> virtual y = const Base*;
>>
>> In general, virtual V = type; is legal if:
>> 1) V is a variable in the enclosing function local scope
>> 2a) type is void **or**
>> 2b) V is implicitly convertable to type
>>
>> In 2a) case, the variable V is killed. In 2b case, it is hidden by a new
>> V, which is implicitly constructed from the old V.
>>
>> virtual V = const;
>> virtual V = const*;
>>
>> could be used as shortcuts for const&, and decltype(*V) const*.
>>
>> (Virtual may not be ideal keyword, but)
>>
>> --
>>
>> ---
>> 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-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> Visit this group at
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_2124_1075253516.1410397787417
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div>Adding a "disengage and move from" method to opt=
ional is good idea.</div></div><div><br></div>However, the original code ca=
n be reworked to not use std::move.<div><br></div><div>//Code with move:</d=
iv><div><div>struct F {</div><div> std::vector<std::unique_ptr<=
int><wbr>> v;</div><div> void run() {</div><div> &nb=
sp; auto i =3D std::make_unique<int>();</div><div> =
v.push_back(std::move(i));</div><div> doSomethingWith(i.g=
et()); //logic error. i is a "moved from" state.</div><div> }</div><d=
iv>};</div><div><br></div><div>//Code without move:</div><div><div>struct F=
{</div><div> std::vector<std::unique_ptr<int><wbr>> v;</=
div><div> void run() {</div><div> v.push_back(std::=
make_unique<int>());</div><div> doSomethingWith(i.g=
et()); // error here because no i</div><div> }</div><div>};</div></di=
v><div><br></div><div>//Code without move allowing for more code between ma=
ke and push back</div><div><div>struct F {</div><div> std::vect=
or<std::unique_ptr<int>> v;</div><div> void run() {=
</div><div> v.push_back([&]()->std::unique_ptr&l=
t;int>{</div><div> auto i =3D std::make=
_unique<int>();</div><div> //Do more=
things with i here.</div><div> return i;<=
/div><div> }());</div><div> &=
nbsp; doSomethingWith(i.get()); // error here because no i</div><div> =
}</div><div> };</div></div><div><br></div><div>/=
/With one more refactoring a potential fix...</div><div><div>struct F {</di=
v><div> std::vector<std::unique_ptr<int>> v;</div><=
div> void run() {</div><div> v.push_back([&=
amp;]()->std::unique_ptr<int>{</div><div> &nbs=
p; auto i =3D std::make_unique<int>();</div><div> =
// possible problem: vector v does not have the pointer=
when doSomethingWith is called.<br></div><div> =
doSomethingWith(i.get()); </div><div> =
return i;</div><div> }());</div><di=
v> }<br></div><div> };</div></div><div><br>=
</div><div><p class=3D"MsoNormal"><span style=3D"font-size: 10pt; font-fami=
ly: Arial, sans-serif; background-image: initial; background-attachment: in=
itial; background-size: initial; background-origin: initial; background-cli=
p: initial; background-position: initial; background-repeat: initial;">In C=
++14 it is possible to hide and kill
variables by introducing and closing scopes. If there is a real need to
keep multiple variables in the same scope, creative use of std::optional ca=
n
also simulate killing a variable, or you can invent a similar template clas=
s
that has additional specific features around killing and moving. (Also, if =
the
indenting really gets you down, just don't indent; this is c++ not Python. =
;-)</span></p></div><div><br></div>On Tuesday, 9 September 2014 23:03:20 UT=
C-7, Brent Friedman wrote:<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr">Have you considered this alternative?<div><br></div><div>opti=
onal<T> x =3D ...;</div><div>x->thing();</div><div>x =3D nullopt; =
// kill x</div><div>x->thing(); //undefined behavior</div><div><br></div=
><div>To provide your error/warning, the compiler/static analyzer simply ne=
eds to understand the well-defined semantics of optional.</div><div><br></d=
iv><div><br></div><div>The original examples you gave were dealing with std=
::move. Those could be supported with some nice 'move the value out of the =
optional' syntax.</div><div><br></div><div>optional<T> x =3D ...;</di=
v><div>y =3D x.pop(); //disengages x and returns T&&; requires x to=
be engaged.</div><div>x->thing(); //undefined behavior</div></div><div>=
<br><div class=3D"gmail_quote">On Tue, Sep 9, 2014 at 11:25 PM, Adam Nevrau=
mont <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-ob=
fuscated-mailto=3D"oHp9gC5Z6JAJ" onmousedown=3D"this.href=3D'javascript:';r=
eturn true;" onclick=3D"this.href=3D'javascript:';return true;">a...@theore=
m.ca</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Killing a vari=
able woukd be roughky equivalent to retyping it as void.<br>
<br>
Retyping a T as const T, or a Derived* as Base*, would be variations.<br>
<br>
T x;<br>
virtual x =3D T const&;// treat access to x as if it was const<br>
virtual x =3D void; // treat access to x as illegal<br>
Derived* y;<br>
virtual y =3D Base*;<br>
virtual y =3D const Base*;<br>
<br>
In general, virtual V =3D type; is legal if:<br>
1) V is a variable in the enclosing function local scope<br>
2a) type is void **or**<br>
2b) V is implicitly convertable to type<br>
<br>
In 2a) case, the variable V is killed. In 2b case, it is hidden by a =
new V, which is implicitly constructed from the old V.<br>
<br>
virtual V =3D const;<br>
virtual V =3D const*;<br>
<br>
could be used as shortcuts for const&, and decltype(*V) const*.<br>
<br>
(Virtual may not be ideal keyword, but)<br>
<div><div><br>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
oHp9gC5Z6JAJ" onmousedown=3D"this.href=3D'javascript:';return true;" onclic=
k=3D"this.href=3D'javascript:';return true;">std-proposal...@<wbr>isocpp.or=
g</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"oHp9gC5Z6JAJ" onmousedown=3D"this.href=3D'java=
script:';return true;" onclick=3D"this.href=3D'javascript:';return true;">s=
td-pr...@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank" onmousedown=3D"this.href=3D'http://groups=
..google.com/a/isocpp.org/group/std-proposals/';return true;" onclick=3D"thi=
s.href=3D'http://groups.google.com/a/isocpp.org/group/std-proposals/';retur=
n true;">http://groups.google.com/a/<wbr>isocpp.org/group/std-<wbr>proposal=
s/</a>.<br>
</div></div></blockquote></div><br></div>
</blockquote></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_2124_1075253516.1410397787417--
.
Author: David Krauss <potswa@gmail.com>
Date: Thu, 11 Sep 2014 09:35:57 +0800
Raw View
--Apple-Mail=_9B72862E-3CA4-4C8C-9C67-3434E3CB700E
Content-Type: text/plain; charset=ISO-8859-1
On 2014-09-11, at 9:09 AM, Chet <chet.skolos@gmail.com> wrote:
> Adding a "disengage and move from" method to optional is good idea.
It would probably be best if the idiom for moving from an optional would disengage it, so that would be the default.
Food for thought.
It would be doable with an rvalue-qualified conversion function, but it would have to return by (pr)value. Returning an xvalue wouldn't give it a chance to destroy the contained object after entering the disengaged state.
Alternately, std::move() could be overloaded for optional, and return a proxy object which converts to an xvalue and enters the disengaged state upon (temporary proxy) destruction. But that's dirty enough to have undesirable side-effects.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--Apple-Mail=_9B72862E-3CA4-4C8C-9C67-3434E3CB700E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;09–11, at 9:09 AM, Chet <<a href=3D"mailto:chet.skolos@gmail=
..com">chet.skolos@gmail.com</a>> wrote:</div><br class=3D"Apple-intercha=
nge-newline"><blockquote type=3D"cite"><div style=3D"font-family: Helvetica=
; font-size: 12px; font-style: normal; font-variant: normal; font-weight: n=
ormal; letter-spacing: normal; line-height: normal; orphans: auto; text-ali=
gn: start; text-indent: 0px; text-transform: none; white-space: normal; wid=
ows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div dir=3D"=
ltr"><div>Adding a "disengage and move from" method to optional is good ide=
a.</div></div></div></blockquote><br></div><div>It would probably be best i=
f the idiom for moving from an optional would disengage it, so that would b=
e the default.</div><div><br></div><div>Food for thought. </div><div><=
br></div><div><div>It would be doable with an rvalue-qualified conversion f=
unction, but it would have to return by (pr)value. Returning an xvalue woul=
dn’t give it a chance to destroy the contained object after entering =
the disengaged state.</div><div><br></div><div>Alternately, std::move() cou=
ld be overloaded for optional, and return a proxy object which converts to =
an xvalue and enters the disengaged state upon (temporary proxy) destructio=
n. But that’s dirty enough to have undesirable side-effects.</div><di=
v><br></div></div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_9B72862E-3CA4-4C8C-9C67-3434E3CB700E--
.