Topic: Why not support 'placement delete' syntax like
Author: acqn163@gmail.com
Date: Fri, 2 May 2014 13:10:15 -0700 (PDT)
Raw View
------=_Part_375_31068417.1399061415292
Content-Type: text/plain; charset=UTF-8
In C++11, custom 'placement delete' operators can't be used in the most
intuitive form as demonstrated below:
auto p1 = new Something; // OK
auto p2 = new(myAlloc) Something; // OK, uses some custom placement new
/* ... */
delete p1; // OK
// delete(myAlloc) p2; // ill-formed, but it should do the
following things:
p2->~Something(); // OK
operator delete(p2, myAlloc); // OK
Worse with 'placement' operator delete[]:
auto p1 = new Something[n]; // OK
auto p2 = new(myAlloc) Something[n]; // pitfall: what is the actual
byte-size requested during the call?
// the 'function call form' could be
used with a careful ctor loop
// to avoid the extra-size allocation
problem,
// but then why not just use the
'non-[] new' in the 1st place?
/* ... */
delete[] p1; // OK, no need to reuse the
count 'n'
// delete[](myAlloc) p2; // ill-formed, but it should do
the right things
for (auto i = n; n; ) p2[--n].~Something(); // why need reuse the count?
and is this done right at all?
operator delete[](p2, myAlloc); // oops, might leak memory
depending on the implementation?
As demonstrated above, the asymmetric syntax is not only inconvenient but
also error-prone.
So what's the problem with enabling the intuitive syntax? It might be the
case with 'virtual static operator delete':
struct B { virtual ~B(); };
struct D : B { static void operator delete(void *p); };
B *p = new D;
delete p; // D::operator delete(void *p) will be called,
but note that
// 'operator delete' is 'polymorphic' only in
this form (see below)
// p->~B(); // OK, polymorphic here, but...
// p->operator delete(p); // error, B::operetor delete(void *) is
undefined, and even if it were defined,
// D::operator delete(void *) would not be called'virtually' this way;
// this is not affected whether the dtor has been
called in prior or not
It's said such dynamic calls will be difficult to implement if extra
parameters need be passed. But is that impossible, even with RTTI?
Inconsistency is not good.Especially, for 'polymorphic' placement delete,
there is currently no syntax support. Why not support it?
--
---
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_31068417.1399061415292
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">In C++11, custom 'placement delete' operators can't be use=
d in the most intuitive form as demonstrated below:<br><br><div class=3D"pr=
ettyprint" style=3D"background-color: rgb(250, 250, 250); border-color: rgb=
(187, 187, 187); border-style: solid; border-width: 1px; word-wrap: break-w=
ord;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=
=3D"font-family: courier new,monospace;"><span style=3D"color: #008;" class=
=3D"styled-by-prettify">auto</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> p1 </span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">new<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: #606;" class=3D"styled-by-prettify">Something</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> =
</span><span style=3D"color: #800;" class=3D"styled-by-prettify">// =
OK</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></sp=
an><span style=3D"color: #008;" class=3D"styled-by-prettify">auto</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> p2 </span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">new</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify">myAlloc</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Some=
thing</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: #800;" class=3D"styled-by-prettify">// OK, uses some custom=
placement new</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br></span><span style=3D"color: #800;" 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">delete</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> p1</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> =
</span><span style=
=3D"color: #800;" class=3D"styled-by-prettify">// OK</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: =
#800;" class=3D"styled-by-prettify">// delete(myAlloc) p2; &n=
bsp; // ill-formed, but it should do the following thin=
gs:</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>p2<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">->~</spa=
n><span style=3D"color: #606;" class=3D"styled-by-prettify">Something</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">();</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> &=
nbsp; </span><span style=3D"color: #800;" class=
=3D"styled-by-prettify">// OK</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-=
by-prettify">operator</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify=
">delete</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify">p2</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> myAlloc</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: #800;" class=3D"styled-by-prettify">// OK</span></span></div></code=
></div><br>Worse with 'placement' operator delete[]:<br><br><div class=3D"p=
rettyprint" style=3D"background-color: rgb(250, 250, 250); border-color: rg=
b(187, 187, 187); border-style: solid; border-width: 1px; word-wrap: break-=
word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span styl=
e=3D"font-family: courier new,monospace;"><span style=3D"color: #008;" clas=
s=3D"styled-by-prettify">auto</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> p1 </span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">new=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><s=
pan style=3D"color: #606;" class=3D"styled-by-prettify">Something</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">[</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">n</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">];</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: #800;" class=3D"styled-by-prettify">// OK</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D=
"color: #008;" class=3D"styled-by-prettify">auto</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> p2 </span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styl=
ed-by-prettify">new</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
myAlloc</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><spa=
n style=3D"color: #606;" class=3D"styled-by-prettify">Something</span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">[</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify">n</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">// pitfall: what is the actual byte-size requested during=
the call?</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br> &=
nbsp; </span><span s=
tyle=3D"color: #800;" class=3D"styled-by-prettify">// the 'function call fo=
rm' could be used</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"></span></span><span style=3D"font-family: courier new,monospace;"><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"><code class=3D"pret=
typrint"><span style=3D"font-family: courier new,monospace;"><span style=3D=
"color: #800;" class=3D"styled-by-prettify"> with a careful ctor loop</span=
><span style=3D"color: #800;" class=3D"styled-by-prettify"><br></span></spa=
n></code> &nb=
sp; </span><s=
pan style=3D"color: #800;" class=3D"styled-by-prettify">// to avoid the ext=
ra-size allocation problem,</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br>  =
; &nb=
sp;</span><span style=3D"color: #800;" class=3D"styled-by-prettify">// but =
then why not just use the 'non-[] new' in the 1st place?</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"co=
lor: #800;" class=3D"styled-by-prettify">/* ... */</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #0=
08;" class=3D"styled-by-prettify">delete</span><span style=3D"color: #660;"=
class=3D"styled-by-prettify">[]</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> p1</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> &nb=
sp; </span><span style=3D"color: #=
800;" class=3D"styled-by-prettify">// OK, no need to reuse the count 'n'</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><s=
pan style=3D"color: #800;" class=3D"styled-by-prettify">// delete[](myAlloc=
) p2; =
// ill-formed</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"></span></span><span style=3D"font-family: courier new,monospace;"><span =
style=3D"color: #000;" class=3D"styled-by-prettify"><code class=3D"prettypr=
int"><span style=3D"font-family: courier new,monospace;"><span style=3D"col=
or: #800;" class=3D"styled-by-prettify">, but it should do the right things=
</span><span class=3D"styled-by-prettify"><br></span></span></code></span><=
span style=3D"color: #008;" class=3D"styled-by-prettify">for</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #008=
;" class=3D"styled-by-prettify">auto</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> i </span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> n</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> n</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> p2</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">[--</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify">n</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">].~</span><span style=3D"color: #606;" class=3D"styled-by-prett=
ify">Something</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">();</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #800;" class=3D"styled-by-prettify">// why need =
reuse the count? and is this done right at all?</span><span style=3D"color:=
#000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #008;=
" class=3D"styled-by-prettify">operator</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"=
styled-by-prettify">delete</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">[](</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify">p2</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> myAlloc=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> &nb=
sp; </span><span style=3D"color: #800;" class=3D"style=
d-by-prettify">// oops, might leak memory depending on the implementation?<=
/span></span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
</span></div></code></div><br>As demonstrated above, the asymmetric syntax =
is not only inconvenient but also error-prone.<br>So what's the problem wit=
h enabling the intuitive syntax? It might be the case with 'virtual static =
operator delete':<br><br><div class=3D"prettyprint" style=3D"background-col=
or: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: sol=
id; border-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint">=
<div class=3D"subprettyprint"><span style=3D"font-family: courier new,monos=
pace;"><span style=3D"color: #008;" class=3D"styled-by-prettify">struct</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> B </span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">virtual</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">~</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify">B</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">()</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
;</span><span style=3D"color: #660;" class=3D"styled-by-prettify"></span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"></span><span style=
=3D"color: #066;" class=3D"styled-by-prettify"></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: #660;" class=3D"st=
yled-by-prettify">};</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">struct</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
D </span><span style=3D"color: #660;" class=3D"styled-by-prettify">:</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> B </span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #0=
08;" class=3D"styled-by-prettify">static</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D=
"styled-by-prettify">void</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">operator</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">delet=
e</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><=
span style=3D"color: #008;" class=3D"styled-by-prettify">void</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">*</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify">p</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">);</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">};</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><=
br><br>B </span><span style=3D"color: #660;" class=3D"styled-by-prettify">*=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify">p </span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">new</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> D</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-by=
-prettify">delete</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> p</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> &n=
bsp; </span><span style=3D"color:=
#800;" class=3D"styled-by-prettify">// D::operator delete(void *p) will be=
called, but note that</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"><br> &nb=
sp; </span><span style=3D"color: #800;" class=
=3D"styled-by-prettify">// 'operator delete' is 'polymorphic'</span><span s=
tyle=3D"color: #800;" class=3D"styled-by-prettify"></span></span><span styl=
e=3D"font-family: courier new,monospace;"><span style=3D"color: #800;" clas=
s=3D"styled-by-prettify"><code class=3D"prettyprint"><span style=3D"font-fa=
mily: courier new,monospace;"><span class=3D"styled-by-prettify"> only</spa=
n><span class=3D"styled-by-prettify"></span></span></code> in this form (se=
e below)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><b=
r><br></span><span style=3D"color: #800;" class=3D"styled-by-prettify">// p=
->~B(); // OK, polymorp=
hic here, but...</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"><br></span><span style=3D"color: #800;" class=3D"styled-by-prettify">=
// p->operator delete(p); // error, B::operetor delete(void *) is undefi=
ned, </span><span style=3D"color: #000;" class=3D"styled-by-prettify"></spa=
n></span><span style=3D"font-family: courier new,monospace;"><span style=3D=
"color: #000;" class=3D"styled-by-prettify"><code class=3D"prettyprint"><sp=
an style=3D"font-family: courier new,monospace;"><span style=3D"color: #800=
;" class=3D"styled-by-prettify">and even if it were defined,<br></span></sp=
an></code></span><span style=3D"color: #800;" class=3D"styled-by-prettify">=
&nb=
sp; =
// D::operator delete(void *) would not be</span></span><span style=3D"fon=
t-family: courier new,monospace;"><span style=3D"color: #800;" class=3D"sty=
led-by-prettify"><code class=3D"prettyprint"><span style=3D"font-family: co=
urier new,monospace;"><span class=3D"styled-by-prettify"> called</span></sp=
an></code> 'virtually' this way;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>  =
; </span><span style=3D"color: #8=
00;" class=3D"styled-by-prettify">// this is not affected whether the dtor =
has been called in prior or not</span></span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"><br></span></div></code></div><br>It's
said such dynamic calls will be difficult to implement if extra=20
parameters need be passed. But is that impossible, even with RTTI?<br>Incon=
sistency
is not good.Especially, for 'polymorphic' placement delete, there is=20
currently no syntax support. Why not support it?<br><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_31068417.1399061415292--
.
Author: Sean Middleditch <sean.middleditch@gmail.com>
Date: Fri, 2 May 2014 19:27:24 -0700 (PDT)
Raw View
------=_Part_1351_7776868.1399084044873
Content-Type: text/plain; charset=UTF-8
This code is already legal with a clearly-defined meaning:
delete(a,b);
This applies the comma operator to a and b and then invokes delete on the
result of that expression.
Similarly, then, the following is problematic:
delete(a, b) c;
Most parsing algorithms want to be able to tell what state they should be
in without back-tracking (and compiler implementors generally like this
fact), but the above would need to convert (a,b) from a comma-operator
expression to a parameter list after encountering 'c'. Yuck. If there are
multiple parameters like (a,b,c,d,e) then some compilers would need to
convert an AST tree of binary expressions into a flattened list of
parameter expressions, which is a non-ideal thing to require the compiler
to do. For compilers that emit code as they parse (yes, they exist), this
conversion would require extra buffering. There's possibly other
ambiguities hiding here, too.
If you want to invoke operator delete more easily a little template logic
can wrap operator delete (or invoke the destructor and some other memory
deallocation routine). This has some access level problems for uncommon
protection level patterns, but it works.
template <typename T, typename ...P>
void my_delete(T* pt, P&&... argv) {
operator delete(pt, std::forward<P>(argv)...);
}
Tricks similar this have been used for many years in some games code where
new/delete are often banned (and long before C++11 made it cool to ban them
:-P ).
--
---
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_1351_7776868.1399084044873
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>This code is already legal with a clearly-defined mea=
ning:</div><div><br></div> delete(a,b);<div><br></div><div>This appli=
es the comma operator to a and b and then invokes delete on the result of t=
hat expression.</div><div><br></div><div>Similarly, then, the following is =
problematic:</div><div><br></div><div> delete(a, b) c;</div><div><br>=
</div><div>Most parsing algorithms want to be able to tell what state they =
should be in without back-tracking (and compiler implementors generally lik=
e this fact), but the above would need to convert (a,b) from a comma-operat=
or expression to a parameter list after encountering 'c'. Yuck. If there ar=
e multiple parameters like (a,b,c,d,e) then some compilers would need to co=
nvert an AST tree of binary expressions into a flattened list of parameter =
expressions, which is a non-ideal thing to require the compiler to do. For =
compilers that emit code as they parse (yes, they exist), this conversion w=
ould require extra buffering. There's possibly other ambiguities hiding her=
e, too.</div><div><br></div><div>If you want to invoke operator delete more=
easily a little template logic can wrap operator delete (or invoke the des=
tructor and some other memory deallocation routine). This has some access l=
evel problems for uncommon protection level patterns, but it works.</div><d=
iv><br></div><div> template <typename T, typename ...P></=
div><div> void my_delete(T* pt, P&&... argv) {</div><di=
v> operator delete(pt, std::forward<P>(argv)...);<=
br></div><div> }</div><div><br></div><div>Tricks similar this h=
ave been used for many years in some games code where new/delete are often =
banned (and long before C++11 made it cool to ban them :-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_1351_7776868.1399084044873--
.
Author: David Krauss <potswa@gmail.com>
Date: Sat, 3 May 2014 15:01:43 +0800
Raw View
--Apple-Mail=_9F4C8FB7-4119-4E31-B88D-ED29223CAF7D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
On 2014-05-03, at 4:10 AM, acqn163@gmail.com wrote:
> It's said such dynamic calls will be difficult to implement if extra para=
meters need be passed. But is that impossible, even with RTTI?
> Inconsistency is not good.Especially, for 'polymorphic' placement delete,=
there is currently no syntax support. Why not support it?
Referring to my StackOverflow answer,
For this to work with placement delete, the [virtual] destructor would have=
to somehow pass the additional arguments to operator delete.
Solution 1: Pass the arguments through the virtual function. This requires =
a separate virtual destructor for every static member and global operator d=
elete overload with different arguments.
Solution 2: Let the virtual destructor return a function pointer to the cal=
ler specifying what operator delete should be called. But if the destructor=
does lookup, this hits the same problem of requiring multiple virtual func=
tion definitions as #1. Some kind of abstract overload set would have to be=
created, which the caller would resolve.
You have a perfectly good point, and it would be a nice addition to the lan=
guage. Retrofitting it into the existing semantics of delete is probably ev=
en possible, in theory. But most of the time we don't use the full function=
ality of delete and it suffices to use a pseudo-destructor call followed by=
something like arena.release(p).
--
If anyone can think of another mechanism, do speak up... but I think it's o=
nly marginally possible.
Anyway, member operator new isn't respected by standard containers. You're =
generally better off with the Container/smart-pointer/Allocator paradigm. T=
hen at least you can structure the program such that each object is paired =
with the allocator responsible for it. With class-specific overloads, you s=
till have ::new, placement new, and array forms as valid ways to obtain an =
object, each requiring its own respective mode of destruction, and always U=
B for destroying the wrong way.
If you really want to pass arguments to the deallocation function, I'd reco=
mmend writing a nonconforming allocator and custom containers to support th=
at. Such a strategy may be limited by the need to destroy local objects wit=
hout arguments for the sake of exception safety. On the other hand, if the =
arguments only depend on the container, that translates to a regular statef=
ul allocator which is already fully supported by the standard library.
--=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=_9F4C8FB7-4119-4E31-B88D-ED29223CAF7D
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;05–03, at 4:10 AM, <a href=3D"mailto:acqn163@gmail.com">acqn163=
@gmail.com</a> wrote:</div><br class=3D"Apple-interchange-newline"><blockqu=
ote type=3D"cite"><div dir=3D"ltr">It's
said such dynamic calls will be difficult to implement if extra=20
parameters need be passed. But is that impossible, even with RTTI?<br>Incon=
sistency
is not good.Especially, for 'polymorphic' placement delete, there is=20
currently no syntax support. Why not support it?<br></div></blockquote><br>=
</div><div>Referring to my <a href=3D"http://stackoverflow.com/a/14119=
344/153285">StackOverflow answer</a>,</div><br><div><p>For this to work wit=
h placement delete, the [virtual] destructor would have to somehow pass the=
additional arguments to <code>operator delete</code>.</p>
<ul>
<li><strong>Solution 1:</strong> Pass the arguments through the virtual=20
function. This requires a separate virtual destructor for every static=20
member and global <code>operator delete</code> overload with different argu=
ments.</li>
<li><strong>Solution 2:</strong> Let the virtual destructor return a functi=
on pointer to the caller specifying what <code>operator delete</code>
should be called. But if the destructor does lookup, this hits the same
problem of requiring multiple virtual function definitions as #1. Some=20
kind of abstract overload set would have to be created, which the caller
would resolve.</li>
</ul><p>You have a perfectly good point, and it would be a nice addition to=
=20
the language. Retrofitting it into the existing semantics of <code>delete</=
code> is probably even possible, in theory. But most of the time we don't u=
se the full functionality of <code>delete</code> and it suffices to use a p=
seudo-destructor call followed by something like <code>arena.release(p)</co=
de>.</p></div><div>—</div><div>If anyone can think of another mechani=
sm, do speak up… but I think it’s only marginally possible.</d=
iv><div><br></div><div>Anyway, member <font face=3D"Courier">operator new</=
font> isn’t respected by standard containers. You’re generally =
better off with the Container/smart-pointer/Allocator paradigm. Then at lea=
st you can structure the program such that each object is paired with the a=
llocator responsible for it. With class-specific overloads, you still have&=
nbsp;<font face=3D"Courier">::new</font>, placement new, and array forms as=
valid ways to obtain an object, each requiring its own respective mode of =
destruction, and always UB for destroying the wrong way.</div><div><br></di=
v><div>If you really want to pass arguments to the deallocation function, I=
’d recommend writing a nonconforming allocator and custom containers =
to support that. Such a strategy may be limited by the need to destroy loca=
l objects without arguments for the sake of exception safety. On the other =
hand, if the arguments only depend on the container, that translates to a r=
egular stateful allocator which is already fully supported by the standard =
library.</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=_9F4C8FB7-4119-4E31-B88D-ED29223CAF7D--
.
Author: acqn163@gmail.com
Date: Mon, 5 May 2014 09:59:10 -0700 (PDT)
Raw View
------=_Part_161_32215141.1399309150902
Content-Type: text/plain; charset=UTF-8
Well, I believe that upgrading the old compilers from C++98/C++03 to C++11
support required much more parsing efforts than this could do. I think the
'polymorphic deallocation' is the main trouble here.
As far as I can tell, some compiler work is needed to make that polymorphic
behavior work without the full definition of the derived class where delete
operator resides visible to the base class and/or where the delete gets
called. Maybe we could require that, if the base class is to be
'polymorphically placement-deleted' via a pointer to it, it shall have some
kind of form of 'virtual static delete operator' declaration with
the matching signature in its class definition, so that the compiler can
store some magical info for this to work? This shouldn't be needed for
types without a virtual destructor. There might be some danger/limitation
as the user might forget to/have no way to add such necessary
declarations...
However, after some experiments and thoughts, I found it might be just fine
to add syntax support for global-namespace placement-delete operators and
nothing for class-scope placement operators. It would be just fine to:
* Add language support for the syntax 'delete(args-list...) ptr' to perform
destruction on object pointed to by 'ptr' and then call the matching
global-namespace 'operator delete(ptr, args-list...)'.
* Similarly, to close up the gap, also add support for
'delete[](args-list...) array_ptr' to destroy an array of objects
constructed by a previous 'new(args-list...) ObjectType[count]' operation,
and then call the appropriate global-namespace 'operator
delete[](array_ptr, args-list...)'.
* To avoid potential syntax/semantic conflicts/confusions, a global
namespace qualifier can be required to use this syntax (so like
'::delete(arg) ptr'), and neither support is added for class-scope
new/delete operators nor any for 'sized deallocation' versions of them is.
I am unsure if an empty 'args-list' should be allowed so the expression
would be treated as the parenthesis-less form. Maybe yes to make generic
code cleaner.
Personally, I am never a fan of class-scope new/delete operators, and
future changes in new standards like 'Type-Reflection in C++' might help do
that better, so I won't bother with them here for now. Any comments?
--
---
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_161_32215141.1399309150902
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Well, I believe that upgrading the old compilers from C++9=
8/C++03 to C++11 support required much more parsing efforts than this could=
do. I think the 'polymorphic deallocation' is the main trouble here.<br><d=
iv><br></div><div>As far as I can tell, some compiler work is needed to mak=
e that polymorphic behavior work without the full definition of the de=
rived class where delete operator resides visible to the base class and/or =
where the delete gets called. Maybe we could require that, if the base clas=
s is to be 'polymorphically placement-deleted' via a pointer to i=
t, it shall have some kind of form of 'virtual static delete operator'=
declaration with the matching signature in its class definition,=
so that the compiler can store some magical info for this to work? This sh=
ouldn't be needed for types without a virtual destructor. There might be so=
me danger/limitation as the user might forget to/have no way to add such ne=
cessary declarations...</div><div><div><br></div><div>However, after some e=
xperiments and thoughts, I found it might be just fine to add syntax suppor=
t for global-namespace placement-delete operators and nothing for class-sco=
pe placement operators. It would be just fine to:</div><div>* Add language =
support for the syntax 'delete(args-list...) ptr' to perform destruction on=
object pointed to by 'ptr' and then call the matching global-namespace&nbs=
p;'operator delete(ptr, args-list...)'.</div><div>* Similarly, to clos=
e up the gap, also add support for 'delete[](args-list...) array_ptr' to de=
stroy an array of objects constructed by a previous 'new(args-list...) Obje=
ctType[count]' operation, and then call the appropriate global-namespa=
ce 'operator delete[](array_ptr, args-list...)'.</div><div>* To avoid =
potential syntax/semantic conflicts/confusions, a global namespace qualifie=
r can be required to use this syntax (so like '::delete(arg) ptr'), and nei=
ther support is added for class-scope new/delete operators nor any for 'siz=
ed deallocation' versions of them is.</div><div>I am unsure if an empty 'ar=
gs-list' should be allowed so the expression would be treated as the parent=
hesis-less form. Maybe yes to make generic code cleaner.</div><div><br></di=
v><div><div>Personally, I am never a fan of class-scope new/delete operator=
s, and future changes in new standards like 'Type-Reflection in C++' might =
help do that better, so I won't bother with them here for now. Any comments=
?</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_161_32215141.1399309150902--
.