Topic: Optimizing shutdown time by disabling global destructors
Author: Matthew Fioravante <fmatthew5876@gmail.com>
Date: Wed, 4 Mar 2015 18:55:05 -0800 (PST)
Raw View
------=_Part_6675_679087169.1425524105897
Content-Type: multipart/alternative;
boundary="----=_Part_6676_1689949225.1425524105897"
------=_Part_6676_1689949225.1425524105897
Content-Type: text/plain; charset=UTF-8
Destructor calls for many types in global scope are actually redundant.
After main() has exited, the system will start walking through the at exit
list and start freeing memory, only to have the application exit and have
the OS reap all of the memory pages anyway.
struct A {
vector<T> v;
};
A a; //<-The call to a.~A() performed after main is redundant.
//The application will exit and the OS will free all of the memory
anyway.
I've seen production code which uses a lot of memory and swap space take
several minutes to exit because of global destructors triggering so many
page faults from calling free(). In order to avoid this delay, we
specifically leaked the memory. Other systems, such as embedded systems
which reboot after main() would also benefit from disabling these useless
cleanup routines and optimizing their reboot times.
We can implement this behavior ourselves by using hacks with aligned
storage and/or unions. It might be better if there was a first class
language feature to specifically declare that an object's destructor should
never be called.
Not only would a language feature let us specify intent, it could also
possibly be used by the implementation to mark the symbols appropriately
and inform memory checkers not to report leaks from these objects.
Another advantage of never destroying a global variable is that we
eliminate destruction ordering problems. If the destructor is never called
then the object will always be in a valid state. Finally, we also eliminate
the need to register atexit() handlers at startup.
As to how this feature would be accomplished, that's an open question. Here
are few possibilities.
First, we could use an attribute:
class Singleton {
static Singleton& get() {
static Singleton [["nodestroy"]] s;
return s;
}
};
Another option could be to allow objects with deleted destructors in global
scope.
class Singleton {
~Singleton() = delete;
static Singleton& get() {
static Singleton s;
return s;
}
};
--
---
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_6676_1689949225.1425524105897
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Destructor calls for many types in global scope are actual=
ly redundant. After main() has exited, the system will start walking throug=
h the at exit list and start freeing memory, only to have the application e=
xit and have the OS reap all of the memory pages anyway.<div><br></div><div=
><div class=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187, 187); =
word-wrap: break-word; background-color: rgb(250, 250, 250);"><code class=
=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"font-family: =
Arial, Helvetica, sans-serif; font-size: 13px;"><span style=3D"color: #008;=
" class=3D"styled-by-prettify">struct</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> A </span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br> vector</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify"><</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify">T</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">></span><span style=3D"color: #000;" class=3D"styled-by-prettify"> v<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">};</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> <br></span></span><span style=3D"=
color: #000;" class=3D"styled-by-prettify">A a</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> </span><span style=3D"color: #800;" class=3D"st=
yled-by-prettify">//<-The call to a.~A() performed after main is redunda=
nt.</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></s=
pan><font color=3D"#880000"><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><span style=3D"color: #800;" class=3D=
"styled-by-prettify">//The application will exit and the OS will free all o=
f the memory anyway.</span></font></div></code></div><br><div><br></div><di=
v>I've seen production code which uses a lot of memory and swap space take =
several minutes to exit because of global destructors triggering so many pa=
ge faults from calling free(). In order to avoid this delay, we specificall=
y leaked the memory. Other systems, such as embedded systems which reboot a=
fter main() would also benefit from disabling these useless cleanup routine=
s and optimizing their reboot times.</div><div><br></div><div>We can implem=
ent this behavior ourselves by using hacks with aligned storage and/or unio=
ns. It might be better if there was a first class language feature to speci=
fically declare that an object's destructor should never be called. </=
div><div><br></div><div>Not only would a language feature let us specify in=
tent, it could also possibly be used by the implementation to mark the symb=
ols appropriately and inform memory checkers not to report leaks from these=
objects.</div></div><div><br></div><div>Another advantage of never destroy=
ing a global variable is that we eliminate destruction ordering problems. I=
f the destructor is never called then the object will always be in a valid =
state. Finally, we also eliminate the need to register atexit() handlers at=
startup.</div><div><br></div><div>As to how this feature would be accompli=
shed, that's an open question. Here are few possibilities.</div><div><br></=
div><div>First, we could use an attribute:</div><div><br></div><div><div cl=
ass=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187, 187); word-wra=
p: break-word; background-color: rgb(250, 250, 250);"><code class=3D"pretty=
print"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"=
styled-by-prettify">class</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-pret=
tify">Singleton</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"><br> </=
span><span style=3D"color: #008;" class=3D"styled-by-prettify">static</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span st=
yle=3D"color: #606;" class=3D"styled-by-prettify">Singleton</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">&</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #=
008;" class=3D"styled-by-prettify">get</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">()</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"><br> </span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">static</span><font color=3D"#666600"><span style=3D"color: #000;"=
class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" cla=
ss=3D"styled-by-prettify">Singleton </span></font><span class=3D"style=
d-by-prettify" style=3D"font-family: Arial, Helvetica, sans-serif; font-siz=
e: 13.1428575515747px; color: rgb(102, 102, 0);">[[</span><span class=3D"st=
yled-by-prettify" style=3D"font-family: Arial, Helvetica, sans-serif; font-=
size: 13.1428575515747px; color: rgb(0, 136, 0);">"nodestroy"</span><font c=
olor=3D"#666600" style=3D"font-family: Arial, Helvetica, sans-serif; font-s=
ize: 13.1428575515747px;"><span class=3D"styled-by-prettify">]] </span=
></font><span class=3D"styled-by-prettify" style=3D"font-family: Arial, Hel=
vetica, sans-serif; font-size: 13px; color: rgb(0, 0, 0);">s</span><span cl=
ass=3D"styled-by-prettify" style=3D"color: rgb(102, 102, 0); font-family: A=
rial, Helvetica, sans-serif; font-size: 13px;">;</span></div><div class=3D"=
subprettyprint"><span style=3D"color: #000;" class=3D"styled-by-prettify">&=
nbsp; </span><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">return</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
s</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"><br> </span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">}</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"><br></span><font color=3D"=
#666600"><span style=3D"color: #660;" class=3D"styled-by-prettify">};</span=
></font></div></code></div><br>Another option could be to allow objects wit=
h deleted destructors in global scope.</div><div><br></div><div><div class=
=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187, 187); word-wrap: =
break-word; background-color: rgb(250, 250, 250);"><code class=3D"prettypri=
nt"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">class</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettif=
y">Singleton</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"><br> </spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">~</span><span s=
tyle=3D"color: #606;" class=3D"styled-by-prettify">Singleton</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">()</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">delete</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br> </span><span style=3D"color: #008;" class=3D"styled-by-prett=
ify">static</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Singleto=
n</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span =
style=3D"color: #008;" class=3D"styled-by-prettify">get</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">()</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;"=
class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"><br> </span><span style=3D"color: #008;" =
class=3D"styled-by-prettify">static</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"styl=
ed-by-prettify">Singleton</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> s</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><b=
r> </span><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">return</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> s</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"><br> </sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">};</span></div></code></div>=
<font color=3D"#666600" style=3D"font-family: monospace; font-size: 13.1428=
575515747px; background-color: rgb(250, 250, 250);"><span class=3D"styled-b=
y-prettify"><br></span></font><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_6676_1689949225.1425524105897--
------=_Part_6675_679087169.1425524105897--
.
Author: "dgutson ." <danielgutson@gmail.com>
Date: Thu, 5 Mar 2015 00:01:49 -0300
Raw View
--089e0122a3fa0b337c051081ca62
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4226.pdf
El 04/03/2015 23:55, "Matthew Fioravante" <fmatthew5876@gmail.com> escribi=
=C3=B3:
> Destructor calls for many types in global scope are actually redundant.
> After main() has exited, the system will start walking through the at exi=
t
> list and start freeing memory, only to have the application exit and have
> the OS reap all of the memory pages anyway.
>
> struct A {
> vector<T> v;
> };
> A a; //<-The call to a.~A() performed after main is redundant.
> //The application will exit and the OS will free all of the memory
> anyway.
>
>
> I've seen production code which uses a lot of memory and swap space take
> several minutes to exit because of global destructors triggering so many
> page faults from calling free(). In order to avoid this delay, we
> specifically leaked the memory. Other systems, such as embedded systems
> which reboot after main() would also benefit from disabling these useless
> cleanup routines and optimizing their reboot times.
>
> We can implement this behavior ourselves by using hacks with aligned
> storage and/or unions. It might be better if there was a first class
> language feature to specifically declare that an object's destructor shou=
ld
> never be called.
>
> Not only would a language feature let us specify intent, it could also
> possibly be used by the implementation to mark the symbols appropriately
> and inform memory checkers not to report leaks from these objects.
>
> Another advantage of never destroying a global variable is that we
> eliminate destruction ordering problems. If the destructor is never calle=
d
> then the object will always be in a valid state. Finally, we also elimina=
te
> the need to register atexit() handlers at startup.
>
> As to how this feature would be accomplished, that's an open question.
> Here are few possibilities.
>
> First, we could use an attribute:
>
> class Singleton {
> static Singleton& get() {
> static Singleton [["nodestroy"]] s;
> return s;
> }
> };
>
> Another option could be to allow objects with deleted destructors in
> global scope.
>
> class Singleton {
> ~Singleton() =3D delete;
> static Singleton& get() {
> static Singleton s;
> return s;
> }
> };
>
>
> --
>
> ---
> 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/.
--089e0122a3fa0b337c051081ca62
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr"><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/paper=
s/2014/n4226.pdf">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n=
4226.pdf</a></p>
<div class=3D"gmail_quote">El 04/03/2015 23:55, "Matthew Fioravante&qu=
ot; <<a href=3D"mailto:fmatthew5876@gmail.com">fmatthew5876@gmail.com</a=
>> escribi=C3=B3:<br type=3D"attribution"><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr">Destructor calls for many types in global scope are actua=
lly redundant. After main() has exited, the system will start walking throu=
gh the at exit list and start freeing memory, only to have the application =
exit and have the OS reap all of the memory pages anyway.<div><br></div><di=
v><div style=3D"border:1px solid rgb(187,187,187);word-wrap:break-word;back=
ground-color:rgb(250,250,250)"><code><div><span style=3D"font-family:Arial,=
Helvetica,sans-serif;font-size:13px"><span style=3D"color:#008">struct</spa=
n><span style=3D"color:#000"> A </span><span style=3D"color:#660">{</span><=
span style=3D"color:#000"><br>=C2=A0 vector</span><span style=3D"color:#660=
"><</span><span style=3D"color:#000">T</span><span style=3D"color:#660">=
></span><span style=3D"color:#000"> v</span><span style=3D"color:#660">;=
</span><span style=3D"color:#000"><br></span><span style=3D"color:#660">};<=
/span><span style=3D"color:#000"> <br></span></span><span style=3D"color:#0=
00">A a</span><span style=3D"color:#660">;</span><span style=3D"color:#000"=
> </span><span style=3D"color:#800">//<-The call to a.~A() performed aft=
er main is redundant.</span><span style=3D"color:#000"><br></span><font col=
or=3D"#880000"><span style=3D"color:#000">=C2=A0 =C2=A0 =C2=A0</span><span =
style=3D"color:#800">//The application will exit and the OS will free all o=
f the memory anyway.</span></font></div></code></div><br><div><br></div><di=
v>I've seen production code which uses a lot of memory and swap space t=
ake several minutes to exit because of global destructors triggering so man=
y page faults from calling free(). In order to avoid this delay, we specifi=
cally leaked the memory. Other systems, such as embedded systems which rebo=
ot after main() would also benefit from disabling these useless cleanup rou=
tines and optimizing their reboot times.</div><div><br></div><div>We can im=
plement this behavior ourselves by using hacks with aligned storage and/or =
unions. It might be better if there was a first class language feature to s=
pecifically declare that an object's destructor should never be called.=
=C2=A0</div><div><br></div><div>Not only would a language feature let us sp=
ecify intent, it could also possibly be used by the implementation to mark =
the symbols appropriately and inform memory checkers not to report leaks fr=
om these objects.</div></div><div><br></div><div>Another advantage of never=
destroying a global variable is that we eliminate destruction ordering pro=
blems. If the destructor is never called then the object will always be in =
a valid state. Finally, we also eliminate the need to register atexit() han=
dlers at startup.</div><div><br></div><div>As to how this feature would be =
accomplished, that's an open question. Here are few possibilities.</div=
><div><br></div><div>First, we could use an attribute:</div><div><br></div>=
<div><div style=3D"border:1px solid rgb(187,187,187);word-wrap:break-word;b=
ackground-color:rgb(250,250,250)"><code><div><span style=3D"color:#008">cla=
ss</span><span style=3D"color:#000"> </span><span style=3D"color:#606">Sing=
leton</span><span style=3D"color:#000"> </span><span style=3D"color:#660">{=
</span><span style=3D"color:#000"><br>=C2=A0 </span><span style=3D"color:#0=
08">static</span><span style=3D"color:#000"> </span><span style=3D"color:#6=
06">Singleton</span><span style=3D"color:#660">&</span><span style=3D"c=
olor:#000"> </span><span style=3D"color:#008">get</span><span style=3D"colo=
r:#660">()</span><span style=3D"color:#000"> </span><span style=3D"color:#6=
60">{</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span style=
=3D"color:#008">static</span><font color=3D"#666600"><span style=3D"color:#=
000">=C2=A0</span><span style=3D"color:#606">Singleton=C2=A0</span></font><=
span style=3D"font-family:Arial,Helvetica,sans-serif;font-size:13.142857551=
5747px;color:rgb(102,102,0)">[[</span><span style=3D"font-family:Arial,Helv=
etica,sans-serif;font-size:13.1428575515747px;color:rgb(0,136,0)">"nod=
estroy"</span><font color=3D"#666600" style=3D"font-family:Arial,Helve=
tica,sans-serif;font-size:13.1428575515747px"><span>]]=C2=A0</span></font><=
span style=3D"font-family:Arial,Helvetica,sans-serif;font-size:13px;color:r=
gb(0,0,0)">s</span><span style=3D"color:rgb(102,102,0);font-family:Arial,He=
lvetica,sans-serif;font-size:13px">;</span></div><div><span style=3D"color:=
#000">=C2=A0 =C2=A0 </span><span style=3D"color:#008">return</span><span st=
yle=3D"color:#000"> s</span><span style=3D"color:#660">;</span><span style=
=3D"color:#000"><br>=C2=A0 </span><span style=3D"color:#660">}</span><span =
style=3D"color:#000"><br></span><font color=3D"#666600"><span style=3D"colo=
r:#660">};</span></font></div></code></div><br>Another option could be to a=
llow objects with deleted destructors in global scope.</div><div><br></div>=
<div><div style=3D"border:1px solid rgb(187,187,187);word-wrap:break-word;b=
ackground-color:rgb(250,250,250)"><code><div><span style=3D"color:#008">cla=
ss</span><span style=3D"color:#000"> </span><span style=3D"color:#606">Sing=
leton</span><span style=3D"color:#000"> </span><span style=3D"color:#660">{=
</span><span style=3D"color:#000"><br>=C2=A0 </span><span style=3D"color:#6=
60">~</span><span style=3D"color:#606">Singleton</span><span style=3D"color=
:#660">()</span><span style=3D"color:#000"> </span><span style=3D"color:#66=
0">=3D</span><span style=3D"color:#000"> </span><span style=3D"color:#008">=
delete</span><span style=3D"color:#660">;</span><span style=3D"color:#000">=
<br>=C2=A0 </span><span style=3D"color:#008">static</span><span style=3D"co=
lor:#000"> </span><span style=3D"color:#606">Singleton</span><span style=3D=
"color:#660">&</span><span style=3D"color:#000"> </span><span style=3D"=
color:#008">get</span><span style=3D"color:#660">()</span><span style=3D"co=
lor:#000"> </span><span style=3D"color:#660">{</span><span style=3D"color:#=
000"><br>=C2=A0 =C2=A0 </span><span style=3D"color:#008">static</span><span=
style=3D"color:#000"> </span><span style=3D"color:#606">Singleton</span><s=
pan style=3D"color:#000"> s</span><span style=3D"color:#660">;</span><span =
style=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"color:#008">re=
turn</span><span style=3D"color:#000"> s</span><span style=3D"color:#660">;=
</span><span style=3D"color:#000"><br>=C2=A0 </span><span style=3D"color:#6=
60">}</span><span style=3D"color:#000"><br></span><span style=3D"color:#660=
">};</span></div></code></div><font color=3D"#666600" style=3D"font-family:=
monospace;font-size:13.1428575515747px;background-color:rgb(250,250,250)"><=
span><br></span></font><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" 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>
</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 />
--089e0122a3fa0b337c051081ca62--
.
Author: Matthew Fioravante <fmatthew5876@gmail.com>
Date: Wed, 4 Mar 2015 19:06:28 -0800 (PST)
Raw View
------=_Part_6983_267727376.1425524788235
Content-Type: multipart/alternative;
boundary="----=_Part_6984_715767967.1425524788235"
------=_Part_6984_715767967.1425524788235
Content-Type: text/plain; charset=UTF-8
On Wednesday, March 4, 2015 at 10:01:51 PM UTC-5, dgutson wrote:
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4226.pdf
>
This proposal might solve the problem for a lot of scenarios but it
wouldn't work for me because its all or nothing. Freeing memory is
redundant but other destructor work such as syncing files is not.
For example a logger object akin to std::cout I would want to be absolutely
sure is synced to disk when the program exits.
--
---
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_6984_715767967.1425524788235
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Wednesday, March 4, 2015 at 10:01:51 PM UTC-5, =
dgutson wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><p dir=3D"ltr"><=
a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4226.pdf=
" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www=
..google.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdo=
cs%2Fpapers%2F2014%2Fn4226.pdf\46sa\75D\46sntz\0751\46usg\75AFQjCNFr_K-kZZO=
nzzVZI22teGuM0ZTsZg';return true;" onclick=3D"this.href=3D'http://www.googl=
e.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fp=
apers%2F2014%2Fn4226.pdf\46sa\75D\46sntz\0751\46usg\75AFQjCNFr_K-kZZOnzzVZI=
22teGuM0ZTsZg';return true;">http://www.open-std.org/jtc1/<wbr>sc22/wg21/do=
cs/papers/2014/<wbr>n4226.pdf</a></p></blockquote><div>This proposal might =
solve the problem for a lot of scenarios but it wouldn't work for me becaus=
e its all or nothing. Freeing memory is redundant but other destructor work=
such as syncing files is not.</div><div><br></div><div>For example a logge=
r object akin to std::cout I would want to be absolutely sure is synced to =
disk when the program exits. </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_6984_715767967.1425524788235--
------=_Part_6983_267727376.1425524788235--
.
Author: "dgutson ." <danielgutson@gmail.com>
Date: Thu, 5 Mar 2015 00:11:52 -0300
Raw View
--001a113ebe5cf32992051081ed58
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Do your own proposal, but in any case I suggest you to do some prior work
research and explain in what terms your work is different to what already
exists. For example, I did it for you but IMHO you should still find out
what happened with that proposal by reading the meeting minutes and base
your strategy on that.
El 05/03/2015 00:06, "Matthew Fioravante" <fmatthew5876@gmail.com> escribi=
=C3=B3:
>
>
> On Wednesday, March 4, 2015 at 10:01:51 PM UTC-5, dgutson wrote:
>>
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4226.pdf
>>
> This proposal might solve the problem for a lot of scenarios but it
> wouldn't work for me because its all or nothing. Freeing memory is
> redundant but other destructor work such as syncing files is not.
>
> For example a logger object akin to std::cout I would want to be
> absolutely sure is synced to disk when the program exits.
>
> --
>
> ---
> 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/.
--001a113ebe5cf32992051081ed58
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">Do your own proposal, but in any case I suggest you to do so=
me prior work research and explain in what terms your work is different to =
what already exists. For example, I did it for you but IMHO you should stil=
l find out what happened with that proposal by reading the meeting minutes =
and base your strategy on that.</p>
<div class=3D"gmail_quote">El 05/03/2015 00:06, "Matthew Fioravante&qu=
ot; <<a href=3D"mailto:fmatthew5876@gmail.com">fmatthew5876@gmail.com</a=
>> escribi=C3=B3:<br type=3D"attribution"><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr"><br><br>On Wednesday, March 4, 2015 at 10:01:51 PM UTC-5,=
dgutson wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-l=
eft:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir=3D"ltr"><a hr=
ef=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4226.pdf" re=
l=3D"nofollow" target=3D"_blank">http://www.open-std.org/jtc1/<u></u>sc22/w=
g21/docs/papers/2014/<u></u>n4226.pdf</a></p></blockquote><div>This proposa=
l might solve the problem for a lot of scenarios but it wouldn't work f=
or me because its all or nothing. Freeing memory is redundant but other des=
tructor work such as syncing files is not.</div><div><br></div><div>For exa=
mple a logger object akin to std::cout I would want to be absolutely sure i=
s synced to disk when the program exits.=C2=A0</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" 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>
</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 />
--001a113ebe5cf32992051081ed58--
.
Author: Douglas Boffey <douglas.boffey@gmail.com>
Date: Thu, 5 Mar 2015 13:09:05 +0000
Raw View
--089e016337aac096a805108a4523
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Thu, Mar 5, 2015 at 2:55 AM, Matthew Fioravante <fmatthew5876@gmail.com>
wrote:
> Destructor calls for many types in global scope are actually redundant.
> After main() has exited, the system will start walking through the at exi=
t
> list and start freeing memory, only to have the application exit and have
> the OS reap all of the memory pages anyway.
>
> struct A {
> vector<T> v;
> };
> A a; //<-The call to a.~A() performed after main is redundant.
> //The application will exit and the OS will free all of the memory
> anyway.
>
>
> I've seen production code which uses a lot of memory and swap space take
> several minutes to exit because of global destructors triggering so many
> page faults from calling free(). In order to avoid this delay, we
> specifically leaked the memory. Other systems, such as embedded systems
> which reboot after main() would also benefit from disabling these useless
> cleanup routines and optimizing their reboot times.
>
> We can implement this behavior ourselves by using hacks with aligned
> storage and/or unions. It might be better if there was a first class
> language feature to specifically declare that an object's destructor shou=
ld
> never be called.
>
> Not only would a language feature let us specify intent, it could also
> possibly be used by the implementation to mark the symbols appropriately
> and inform memory checkers not to report leaks from these objects.
>
> Another advantage of never destroying a global variable is that we
> eliminate destruction ordering problems. If the destructor is never calle=
d
> then the object will always be in a valid state. Finally, we also elimina=
te
> the need to register atexit() handlers at startup.
>
> As to how this feature would be accomplished, that's an open question.
> Here are few possibilities.
>
> First, we could use an attribute:
>
> class Singleton {
> static Singleton& get() {
> static Singleton [["nodestroy"]] s;
> return s;
> }
> };
>
>
The problem with an attribute is that the compiler is free to ignore it.
For the final two scenarios mentioned, if a compiler decided to ignore it,
you=E2=80=99d end up with incorrect code, rather than a compiler error.
> Another option could be to allow objects with deleted destructors in
> global scope.
>
> class Singleton {
> ~Singleton() =3D delete;
> static Singleton& get() {
> static Singleton s;
> return s;
> }
> };
>
>
> --
>
> ---
> 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/.
--089e016337aac096a805108a4523
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<br>
<div class=3D"gmail_quote">On Thu, Mar 5, 2015 at 2:55 AM, Matthew Fioravan=
te <span dir=3D"ltr"><<a href=3D"mailto:fmatthew5876@gmail.com" target=
=3D"_blank">fmatthew5876@gmail.com</a>></span> wrote:<br>
<blockquote style=3D"BORDER-LEFT:#ccc 1px solid;MARGIN:0px 0px 0px 0.8ex;PA=
DDING-LEFT:1ex" class=3D"gmail_quote">
<div dir=3D"ltr">Destructor calls for many types in global scope are actual=
ly redundant. After main() has exited, the system will start walking throug=
h the at exit list and start freeing memory, only to have the application e=
xit and have the OS reap all of the memory pages anyway.=20
<div><br></div>
<div>
<div style=3D"BORDER-BOTTOM:rgb(187,187,187) 1px solid;BORDER-LEFT:rgb(187,=
187,187) 1px solid;BACKGROUND-COLOR:rgb(250,250,250);WORD-WRAP:break-word;B=
ORDER-TOP:rgb(187,187,187) 1px solid;BORDER-RIGHT:rgb(187,187,187) 1px soli=
d"><code>
<div><span style=3D"FONT-FAMILY:Arial,Helvetica,sans-serif;FONT-SIZE:13px">=
<span style=3D"COLOR:#008">struct</span><span style=3D"COLOR:#000"> A </spa=
n><span style=3D"COLOR:#660">{</span><span style=3D"COLOR:#000"><br>=C2=A0 =
vector</span><span style=3D"COLOR:#660"><</span><span style=3D"COLOR:#00=
0">T</span><span style=3D"COLOR:#660">></span><span style=3D"COLOR:#000"=
> v</span><span style=3D"COLOR:#660">;</span><span style=3D"COLOR:#000"><br=
></span><span style=3D"COLOR:#660">};</span><span style=3D"COLOR:#000"> <br=
></span></span><span style=3D"COLOR:#000">A a</span><span style=3D"COLOR:#6=
60">;</span><span style=3D"COLOR:#000"> </span><span style=3D"COLOR:#800">/=
/<-The call to a.~A() performed after main is redundant.</span><span sty=
le=3D"COLOR:#000"><br></span><font color=3D"#880000"><span style=3D"COLOR:#=
000">=C2=A0 =C2=A0 =C2=A0</span><span style=3D"COLOR:#800">//The applicatio=
n will exit and the OS will free all of the memory anyway.</span></font></d=
iv></code></div><br>
<div><br></div>
<div>I've seen production code which uses a lot of memory and swap spac=
e take several minutes to exit because of global destructors triggering so =
many page faults from calling free(). In order to avoid this delay, we spec=
ifically leaked the memory. Other systems, such as embedded systems which r=
eboot after main() would also benefit from disabling these useless cleanup =
routines and optimizing their reboot times.</div>
<div><br></div>
<div>We can implement this behavior ourselves by using hacks with aligned s=
torage and/or unions. It might be better if there was a first class languag=
e feature to specifically declare that an object's destructor should ne=
ver be called.=C2=A0</div>
<div><br></div>
<div>Not only would a language feature let us specify intent, it could also=
possibly be used by the implementation to mark the symbols appropriately a=
nd inform memory checkers not to report leaks from these objects.</div></di=
v>
<div><br></div>
<div>Another advantage of never destroying a global variable is that we eli=
minate destruction ordering problems. If the destructor is never called the=
n the object will always be in a valid state. Finally, we also eliminate th=
e need to register atexit() handlers at startup.</div>
<div><br></div>
<div>As to how this feature would be accomplished, that's an open quest=
ion. Here are few possibilities.</div>
<div><br></div>
<div>First, we could use an attribute:</div>
<div><br></div>
<div>
<div style=3D"BORDER-BOTTOM:rgb(187,187,187) 1px solid;BORDER-LEFT:rgb(187,=
187,187) 1px solid;BACKGROUND-COLOR:rgb(250,250,250);WORD-WRAP:break-word;B=
ORDER-TOP:rgb(187,187,187) 1px solid;BORDER-RIGHT:rgb(187,187,187) 1px soli=
d"><code>
<div><span style=3D"COLOR:#008">class</span><span style=3D"COLOR:#000"> </s=
pan><span style=3D"COLOR:#606">Singleton</span><span style=3D"COLOR:#000"> =
</span><span style=3D"COLOR:#660">{</span><span style=3D"COLOR:#000"><br>=
=C2=A0 </span><span style=3D"COLOR:#008">static</span><span style=3D"COLOR:=
#000"> </span><span style=3D"COLOR:#606">Singleton</span><span style=3D"COL=
OR:#660">&</span><span style=3D"COLOR:#000"> </span><span style=3D"COLO=
R:#008">get</span><span style=3D"COLOR:#660">()</span><span style=3D"COLOR:=
#000"> </span><span style=3D"COLOR:#660">{</span><span style=3D"COLOR:#000"=
><br>=C2=A0 =C2=A0 </span><span style=3D"COLOR:#008">static</span><font col=
or=3D"#666600"><span style=3D"COLOR:#000">=C2=A0</span><span style=3D"COLOR=
:#606">Singleton=C2=A0</span></font><span style=3D"FONT-FAMILY:Arial,Helvet=
ica,sans-serif;COLOR:rgb(102,102,0);FONT-SIZE:13px">[[</span><span style=3D=
"FONT-FAMILY:Arial,Helvetica,sans-serif;COLOR:rgb(0,136,0);FONT-SIZE:13px">=
"nodestroy"</span><font style=3D"FONT-FAMILY:Arial,Helvetica,sans=
-serif;FONT-SIZE:13px" color=3D"#666600"><span>]]=C2=A0</span></font><span =
style=3D"FONT-FAMILY:Arial,Helvetica,sans-serif;COLOR:rgb(0,0,0);FONT-SIZE:=
13px">s</span><span style=3D"FONT-FAMILY:Arial,Helvetica,sans-serif;COLOR:r=
gb(102,102,0);FONT-SIZE:13px">;</span></div>
<div><span style=3D"COLOR:#000">=C2=A0 =C2=A0 </span><span style=3D"COLOR:#=
008">return</span><span style=3D"COLOR:#000"> s</span><span style=3D"COLOR:=
#660">;</span><span style=3D"COLOR:#000"><br>=C2=A0 </span><span style=3D"C=
OLOR:#660">}</span><span style=3D"COLOR:#000"><br></span><font color=3D"#66=
6600"><span style=3D"COLOR:#660">};</span></font></div></code></div><br></d=
iv></div></blockquote>
<div>=C2=A0</div>
<div>The problem with an attribute is that the compiler is free to ignore i=
t.=C2=A0 For the final two scenarios mentioned, if a compiler decided to ig=
nore it, you=E2=80=99d end up with incorrect code, rather than a compiler e=
rror.</div>
<div>=C2=A0</div>
<blockquote style=3D"BORDER-LEFT:#ccc 1px solid;MARGIN:0px 0px 0px 0.8ex;PA=
DDING-LEFT:1ex" class=3D"gmail_quote">
<div dir=3D"ltr">
<div>Another option could be to allow objects with deleted destructors in g=
lobal scope.</div>
<div><br></div>
<div>
<div style=3D"BORDER-BOTTOM:rgb(187,187,187) 1px solid;BORDER-LEFT:rgb(187,=
187,187) 1px solid;BACKGROUND-COLOR:rgb(250,250,250);WORD-WRAP:break-word;B=
ORDER-TOP:rgb(187,187,187) 1px solid;BORDER-RIGHT:rgb(187,187,187) 1px soli=
d"><code>
<div><span style=3D"COLOR:#008">class</span><span style=3D"COLOR:#000"> </s=
pan><span style=3D"COLOR:#606">Singleton</span><span style=3D"COLOR:#000"> =
</span><span style=3D"COLOR:#660">{</span><span style=3D"COLOR:#000"><br>=
=C2=A0 </span><span style=3D"COLOR:#660">~</span><span style=3D"COLOR:#606"=
>Singleton</span><span style=3D"COLOR:#660">()</span><span style=3D"COLOR:#=
000"> </span><span style=3D"COLOR:#660">=3D</span><span style=3D"COLOR:#000=
"> </span><span style=3D"COLOR:#008">delete</span><span style=3D"COLOR:#660=
">;</span><span style=3D"COLOR:#000"><br>=C2=A0 </span><span style=3D"COLOR=
:#008">static</span><span style=3D"COLOR:#000"> </span><span style=3D"COLOR=
:#606">Singleton</span><span style=3D"COLOR:#660">&</span><span style=
=3D"COLOR:#000"> </span><span style=3D"COLOR:#008">get</span><span style=3D=
"COLOR:#660">()</span><span style=3D"COLOR:#000"> </span><span style=3D"COL=
OR:#660">{</span><span style=3D"COLOR:#000"><br>=C2=A0 =C2=A0 </span><span =
style=3D"COLOR:#008">static</span><span style=3D"COLOR:#000"> </span><span =
style=3D"COLOR:#606">Singleton</span><span style=3D"COLOR:#000"> s</span><s=
pan style=3D"COLOR:#660">;</span><span style=3D"COLOR:#000"><br>=C2=A0 =C2=
=A0 </span><span style=3D"COLOR:#008">return</span><span style=3D"COLOR:#00=
0"> s</span><span style=3D"COLOR:#660">;</span><span style=3D"COLOR:#000"><=
br>=C2=A0 </span><span style=3D"COLOR:#660">}</span><span style=3D"COLOR:#0=
00"><br></span><span style=3D"COLOR:#660">};</span></div></code></div><span=
class=3D"HOEnZb"><font color=3D"#888888"><font style=3D"BACKGROUND-COLOR:r=
gb(250,250,250);FONT-FAMILY:monospace;FONT-SIZE:13px" color=3D"#666600"><sp=
an><br></span></font><br></font></span></div></div><span class=3D"HOEnZb"><=
font color=3D"#888888">
<p></p>-- <br><br>--- <br>You received this message because you are subscri=
bed to the Google Groups "ISO C++ Standard - Future Proposals" gr=
oup.<br>To unsubscribe from this group and stop receiving emails from it, s=
end an email to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" tar=
get=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"ht=
tp://groups.google.com/a/isocpp.org/group/std-proposals/" target=3D"_blank"=
>http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br></font>=
</span></blockquote></div><br>
<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 />
--089e016337aac096a805108a4523--
.
Author: Pavel Kretov <firegurafiku@gmail.com>
Date: Thu, 05 Mar 2015 17:16:30 +0300
Raw View
> The problem with an attribute is that the compiler is free to ignore it.
> For the final two scenarios mentioned, if a compiler decided to ignore it=
,
> you=E2=80=99d end up with incorrect code, rather than a compiler error.
This is optimization after all, so I think an attribute is okay here. If
compiler ignores it, then it performs ordinary destruction which will
slow program shutdown, but the code will still be perfectly correct. If
user marked with that "nodestroy" attribute a variable which needs
non-trivial uninitialization, then it is the user who misuses the
optimization.
Also, what about marking not only variables definitions, but whole
datatypes, like the following:
[[nodestroy]]
class HeavyClass { ...
/* By applying this attribute to my class I promise it can be
safely put into oblivion on program's exit, including
all of its members. But I don't mind if compiler checks
whether my promise is true. */
};
Then the compiler will be able to automatically optimize destruction
on exit, eliminating whole trees of objects. Unfortunately, for this
to reliably work, the whole inheritance tree must be marked by the
attribute, including any possible child classes. Compiler will have to
blindly believe the user without being able to perform a comprehensive
check.
=E2=80=94=E2=80=94=E2=80=94 Pavel Kretov
--=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: Thu, 5 Mar 2015 11:14:34 -0800 (PST)
Raw View
------=_Part_762_2094913045.1425582874497
Content-Type: multipart/alternative;
boundary="----=_Part_763_1209154750.1425582874497"
------=_Part_763_1209154750.1425582874497
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Thursday, March 5, 2015 at 9:16:37 AM UTC-5, Pavel Kretov wrote:
>
> > The problem with an attribute is that the compiler is free to ignore it=
..=20
> > For the final two scenarios mentioned, if a compiler decided to ignore=
=20
> it,=20
> > you=E2=80=99d end up with incorrect code, rather than a compiler error.=
=20
>
> This is optimization after all, so I think an attribute is okay here. If=
=20
> compiler ignores it, then it performs ordinary destruction which will=20
> slow program shutdown, but the code will still be perfectly correct.=20
It can break program correctness if you are relying on nodestroy for=20
correct global destruction order. If the attribute is optional, the feature=
=20
cannot be used for this purpose.
=20
> If=20
> user marked with that "nodestroy" attribute a variable which needs=20
> non-trivial uninitialization, then it is the user who misuses the=20
> optimization.=20
>
> Also, what about marking not only variables definitions, but whole=20
> datatypes, like the following:=20
>
> [[nodestroy]]=20
> class HeavyClass { ...=20
> /* By applying this attribute to my class I promise it can be=20
> safely put into oblivion on program's exit, including=20
> all of its members. But I don't mind if compiler checks=20
> whether my promise is true. */=20
> };=20
>
> Then the compiler will be able to automatically optimize destruction=20
> on exit, eliminating whole trees of objects.=20
This is the same as my singleton example. The attribute is recursive. Any=
=20
data members or base classes of the singleton instance marked as nodestroy=
=20
will not have their destructors called either.
The only difference you're adding here is you're specifying nodestroy as an=
=20
attribute of a type instead of a variable.
=20
> Unfortunately, for this=20
> to reliably work, the whole inheritance tree must be marked by the=20
> attribute, including any possible child classes. Compiler will have to=20
> blindly believe the user without being able to perform a comprehensive=20
> check.=20
>
The base class and data member constructors are called by ~Singleton(), so=
=20
by not calling ~Singleton() you will not call those either. There's no=20
special magic needed here. Just because Singleton is nodelete, doesn't mean=
=20
its base classes / data members need to be.
--=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_763_1209154750.1425582874497
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Thursday, March 5, 2015 at 9:16:37 AM UTC-5, Pa=
vel Kretov wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">> The prob=
lem with an attribute is that the compiler is free to ignore it.
<br>> For the final two scenarios mentioned, if a compiler decided to ig=
nore it,
<br>> you=E2=80=99d end up with incorrect code, rather than a compiler e=
rror.
<br>
<br>This is optimization after all, so I think an attribute is okay here. I=
f
<br>compiler ignores it, then it performs ordinary destruction which will
<br>slow program shutdown, but the code will still be perfectly correct. </=
blockquote><div><br></div><div>It can break program correctness if you are =
relying on nodestroy for correct global destruction order. If the attribute=
is optional, the feature cannot be used for this purpose.</div><div> =
</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;">If
<br>user marked with that "nodestroy" attribute a variable which needs
<br>non-trivial uninitialization, then it is the user who misuses the
<br>optimization.
<br>
<br>Also, what about marking not only variables definitions, but whole
<br>datatypes, like the following:
<br>
<br> [[nodestroy]]
<br> class HeavyClass { ...
<br> /* By applying this attribute to my class I promise it ca=
n be
<br> safely put into oblivion on program's exit, =
including
<br> all of its members. But I don't mind if comp=
iler checks
<br> whether my promise is true. */
<br> };
<br>
<br>Then the compiler will be able to automatically optimize destruction
<br>on exit, eliminating whole trees of objects. </blockquote><div><br></di=
v><div>This is the same as my singleton example. The attribute is recursive=
.. Any data members or base classes of the singleton instance marked as node=
stroy will not have their destructors called either.</div><div><br></div><d=
iv>The only difference you're adding here is you're specifying nodestroy as=
an attribute of a type instead of a variable.</div><div> </div><block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;">Unfortunately, for this
<br>to reliably work, the whole inheritance tree must be marked by the
<br>attribute, including any possible child classes. Compiler will have to
<br>blindly believe the user without being able to perform a comprehensive
<br>check.
<br></blockquote><div><br></div><div>The base class and data member constru=
ctors are called by ~Singleton(), so by not calling ~Singleton() you will n=
ot call those either. There's no special magic needed here. Just because Si=
ngleton is nodelete, doesn't mean its base classes / data members need to b=
e.</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_763_1209154750.1425582874497--
------=_Part_762_2094913045.1425582874497--
.
Author: Pavel Kretov <firegurafiku@gmail.com>
Date: Fri, 06 Mar 2015 09:07:16 +0300
Raw View
> It can break program correctness if you are relying on nodestroy for
> correct global destruction order. If the attribute is optional, the featu=
re
> cannot be used for this purpose.
User must not rely on an attribute as well as, for example, they cannot=20
rely on an "inline" keyword. User must treat your [[nodestroy]] the same=20
way and write their code to be correct regardless of it.
> The only difference you're adding here is you're specifying nodestroy as =
an
> attribute of a type instead of a variable.
That is a huge difference. Suppose you've marked an variable with the=20
attribute, like that:
Application [[nodestroy]] application;
This object can internally hold a whole hierarchy of pointers to other=20
objects (forms, widgets, images loaded into memory), and some of them=20
may probably REALLY need non-trivial destruction (for example, a file=20
stream implicitly created deeply inside the GUI framework's internal=20
objects). User cannot be sure if it is safe for him to use [[nodestroy]]=20
on that variable. Moreover, destructors can also be virtual and user=20
cannot be sure if any possible subclass is safe to skip destructor.
So, [[nodestroy]] attribute on variable is more dangerous when it=20
erroneously used, then it is ignored by the compiler. Sticking it to=20
class declaration may serve as a hint for the compiler do solve the=20
problem by itself in the most sane way.
Also, you can achieve the desired effect already without having to=20
introduce any changes to the standard. Like that:
class Singleton {
static Singleton& get() {
// NB: Memory leak here is intentional and okay.
// Dear maintainer, don't kill me plz.
static Singleton* s =3D new Singleton();
return *s;
}
};
=E2=80=94=E2=80=94=E2=80=94 Pavel Kretov.
--=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: Tony V E <tvaneerd@gmail.com>
Date: Fri, 6 Mar 2015 01:40:21 -0500
Raw View
--001a11c2597268800a051098f502
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Fri, Mar 6, 2015 at 1:07 AM, Pavel Kretov <firegurafiku@gmail.com> wrote=
:
>
> It can break program correctness if you are relying on nodestroy for
>> correct global destruction order. If the attribute is optional, the
>> feature
>> cannot be used for this purpose.
>>
>
> User must not rely on an attribute as well as, for example, they cannot
> rely on an "inline" keyword. User must treat your [[nodestroy]] the same
> way and write their code to be correct regardless of it.
>
> The only difference you're adding here is you're specifying nodestroy as
>> an
>> attribute of a type instead of a variable.
>>
>
> That is a huge difference. Suppose you've marked an variable with the
> attribute, like that:
>
> Application [[nodestroy]] application;
>
> This object can internally hold a whole hierarchy of pointers to other
> objects (forms, widgets, images loaded into memory), and some of them may
> probably REALLY need non-trivial destruction (for example, a file stream
> implicitly created deeply inside the GUI framework's internal objects).
> User cannot be sure if it is safe for him to use [[nodestroy]] on that
> variable. Moreover, destructors can also be virtual and user cannot be su=
re
> if any possible subclass is safe to skip destructor.
>
> So, [[nodestroy]] attribute on variable is more dangerous when it
> erroneously used, then it is ignored by the compiler. Sticking it to clas=
s
> declaration may serve as a hint for the compiler do solve the problem by
> itself in the most sane way.
>
> Also, you can achieve the desired effect already without having to
> introduce any changes to the standard. Like that:
>
> class Singleton {
> static Singleton& get() {
> // NB: Memory leak here is intentional and okay.
> // Dear maintainer, don't kill me plz.
> static Singleton* s =3D new Singleton();
>
// no complaints from mem-checkers:
static char buffer[sizeof(Singleton)]; // also align it...
static Singleton * s =3D new(buffer) Singleton();
> return *s;
> }
> };
>
>
> =E2=80=94=E2=80=94=E2=80=94 Pavel Kretov.
Tony
--=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/.
--001a11c2597268800a051098f502
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Fri, Mar 6, 2015 at 1:07 AM, Pavel Kretov <span dir=3D"ltr"><<a h=
ref=3D"mailto:firegurafiku@gmail.com" target=3D"_blank">firegurafiku@gmail.=
com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"=
"><br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
It can break program correctness if you are relying on nodestroy for<br>
correct global destruction order. If the attribute is optional, the feature=
<br>
cannot be used for this purpose.<br>
</blockquote>
<br></span>
User must not rely on an attribute as well as, for example, they cannot rel=
y on an "inline" keyword. User must treat your [[nodestroy]] the =
same way and write their code to be correct regardless of it.<span class=3D=
""><br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
The only difference you're adding here is you're specifying nodestr=
oy as an<br>
attribute of a type instead of a variable.<br>
</blockquote>
<br></span>
That is a huge difference. Suppose you've marked an variable with the a=
ttribute, like that:<br>
<br>
=C2=A0 =C2=A0 Application [[nodestroy]] application;<br>
<br>
This object can internally hold a whole hierarchy of pointers to other obje=
cts (forms, widgets, images loaded into memory), and some of them may proba=
bly REALLY need non-trivial destruction (for example, a file stream implici=
tly created deeply inside the GUI framework's internal objects). User c=
annot be sure if it is safe for him to use [[nodestroy]] on that variable. =
Moreover, destructors can also be virtual and user cannot be sure if any po=
ssible subclass is safe to skip destructor.<br>
<br>
So, [[nodestroy]] attribute on variable is more dangerous when it erroneous=
ly used, then it is ignored by the compiler. Sticking it to class declarati=
on may serve as a hint for the compiler do solve the problem by itself in t=
he most sane way.<br>
<br>
Also, you can achieve the desired effect already without having to introduc=
e any changes to the standard. Like that:<span class=3D""><br>
<br>
=C2=A0 =C2=A0 class Singleton {<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 static Singleton& get() {<br></span>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // NB: Memory leak here is intent=
ional and okay.<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 //=C2=A0 =C2=A0 =C2=A0Dear mainta=
iner, don't kill me plz.<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 static Singleton* s =3D new Singl=
eton();<br></blockquote><div><br></div><div>// no complaints from mem-check=
ers:<br></div><div>static char buffer[sizeof(Singleton)]; // also align it.=
...<br></div><div>static Singleton * s =3D new(buffer) Singleton();<br>=C2=
=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex">
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return *s;<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }<br>
=C2=A0 =C2=A0 };<br>
<br>
<br>
=E2=80=94=E2=80=94=E2=80=94 Pavel Kretov.</blockquote><div><br><br></div><d=
iv>Tony<br></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 />
--001a11c2597268800a051098f502--
.