--e89a8f3b9c374176bd04d7ff508a
Content-Type: text/plain; charset=ISO-8859-1

Hi Herb,

Thanks for your proposal.
I hope we can count on it in C++14.

I have a question about the behavior of unwinding_exception
Given the following code ...

//Begin code-----------------------------------------
struct R
{
~R()
{
bool r = std::unwinding_exception();
}
};

struct S
{
~S()
{
bool s = std::unwinding_exception();
}
};

struct T
{
void cleanup()
{
bool t_cleanup = std::unwinding_exception();
}

~T()
{
bool t = std::unwinding_exception();
cleanup();
}
};

struct U : S
{
~U()
{
R r;
bool u = std::unwinding_exception();
}

T t_;
};

int main()
{
try
{
U u;
throw 1;
} // U::~U() invoked here
catch(...) {}
}

//End code-----------------------------------------

What would be the values of r, s, t_cleanup, t and u ?
(I refer to variables that are within the destructors and in the cleanup
function)
I think it is clear for r, t_cleanup and u, but I have doubts about t and s.
I believe that t and s should be equal to u.

Thanks and regards,
Fernando Pelliccioni.

--

---
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/?hl=en.



--e89a8f3b9c374176bd04d7ff508a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi Herb,<br></div><div><br></div><div>Thanks for your=
 proposal.=A0</div><div>I hope we can count on it in C++14.</div><div><br><=
/div><div>I have a question about the behavior of unwinding_exception</div>=
<div>
Given the following code ...</div><div><br></div><div>//Begin code---------=
--------------------------------</div><div>struct R</div><div>{</div><div><=
span class=3D"" style=3D"white-space:pre"> </span>~R()=A0</div><div><span c=
lass=3D"" style=3D"white-space:pre"> </span>{</div>
<div><span class=3D"" style=3D"white-space:pre">  </span>bool r =3D std::un=
winding_exception();</div><div><span class=3D"" style=3D"white-space:pre"> =
</span>}</div><div>};</div><div><br></div><div>struct S</div><div>{</div><d=
iv><span class=3D"" style=3D"white-space:pre"> </span>~S()=A0</div>
<div><span class=3D"" style=3D"white-space:pre"> </span>{</div><div><span c=
lass=3D"" style=3D"white-space:pre">  </span>bool s =3D std::unwinding_exce=
ption();</div><div><span class=3D"" style=3D"white-space:pre"> </span>}</di=
v><div>};</div>
<div><br></div><div>struct T</div><div>{</div><div><span class=3D"" style=
=3D"white-space:pre"> </span>void cleanup()</div><div><span class=3D"" styl=
e=3D"white-space:pre"> </span>{</div><div><span class=3D"" style=3D"white-s=
pace:pre">  </span>bool t_cleanup =3D std::unwinding_exception();<span clas=
s=3D"" style=3D"white-space:pre"> </span></div>
<div><span class=3D"" style=3D"white-space:pre"> </span>}</div><div><br></d=
iv><div><span class=3D"" style=3D"white-space:pre"> </span>~T()=A0</div><di=
v><span class=3D"" style=3D"white-space:pre"> </span>{</div><div><span clas=
s=3D"" style=3D"white-space:pre">  </span>bool t =3D std::unwinding_excepti=
on();</div>
<div><span class=3D"" style=3D"white-space:pre">  </span>cleanup();</div><d=
iv><span class=3D"" style=3D"white-space:pre"> </span>}</div><div>};</div><=
div><br></div><div>struct U : S</div><div>{</div><div><span class=3D"" styl=
e=3D"white-space:pre"> </span>~U()=A0</div>
<div><span class=3D"" style=3D"white-space:pre"> </span>{</div><div><span c=
lass=3D"" style=3D"white-space:pre">  </span>R r;</div><div><span class=3D"=
" style=3D"white-space:pre">  </span>bool u =3D std::unwinding_exception();=
</div><div>
<span class=3D"" style=3D"white-space:pre"> </span>}</div><div><br></div><d=
iv><span class=3D"" style=3D"white-space:pre"> </span>T t_;</div><div>};</d=
iv><div><br></div><div>int main()=A0</div><div>{</div><div><span class=3D""=
 style=3D"white-space:pre"> </span>try=A0</div>
<div><span class=3D"" style=3D"white-space:pre"> </span>{</div><div><span c=
lass=3D"" style=3D"white-space:pre">  </span>U u;</div><div><span class=3D"=
" style=3D"white-space:pre">  </span>throw 1;</div><div><span class=3D"" st=
yle=3D"white-space:pre"> </span>} // U::~U() invoked here</div>
<div><span class=3D"" style=3D"white-space:pre"> </span>catch(...) {}</div>=
<div>}</div><div><br></div><div>//End code---------------------------------=
--------</div><div><br></div><div>What would be the values of r, s, t_clean=
up, t and u ?=A0</div>
<div>(I refer to variables that are within the destructors and in the clean=
up function)</div><div>I think it is clear for r, t_cleanup and u,=A0but I =
have doubts about t and s.</div><div>I believe that t and s should be equal=
 to u.<br>
</div><div><br></div><div>Thanks and regards,</div><div>Fernando Pelliccion=
i.</div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--e89a8f3b9c374176bd04d7ff508a--

.

On 16 March 2013 01:51, Fernando Pelliccioni <fpelliccioni@gmail.com> wrote:
> What would be the values of r, s, t_cleanup, t and u ?
> (I refer to variables that are within the destructors and in the cleanup
> function)
> I think it is clear for r, t_cleanup and u, but I have doubts about t and s.
> I believe that t and s should be equal to u.

Questions like these are probably the reason why
https://github.com/panaseleus/stack_unwinding
uses an int count rather than a bool flag, and Jens at one point had a
preliminary paper proposing
just that.

--

---
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/?hl=en.



.

------=_Part_1529_18583801.1363406029609
Content-Type: text/plain; charset=ISO-8859-1



On Friday, March 15, 2013 4:51:09 PM UTC-7, Fernando Pelliccioni wrote:
>
> Hi Herb,
>
> Thanks for your proposal.
> I hope we can count on it in C++14.
>
> I have a question about the behavior of unwinding_exception
> Given the following code ...
>
> //Begin code-----------------------------------------
> struct R
> {
> ~R()
> {
>  bool r = std::unwinding_exception();
> }
> };
>
> struct S
> {
> ~S()
>  {
> bool s = std::unwinding_exception();
> }
> };
>
> struct T
> {
> void cleanup()
> {
> bool t_cleanup = std::unwinding_exception();
>  }
>
> ~T()
> {
> bool t = std::unwinding_exception();
>  cleanup();
> }
> };
>
> struct U : S
> {
> ~U()
>  {
> R r;
> bool u = std::unwinding_exception();
>  }
>
> T t_;
> };
>
> int main()
> {
> try
>  {
> U u;
> throw 1;
> } // U::~U() invoked here
>  catch(...) {}
> }
>
> //End code-----------------------------------------
>
> What would be the values of r, s, t_cleanup, t and u ?
> (I refer to variables that are within the destructors and in the cleanup
> function)
> I think it is clear for r, t_cleanup and u, but I have doubts about t and
> s.
> I believe that t and s should be equal to u.
>
> Thanks and regards,
> Fernando Pelliccioni.
>

The wording of the paper is very clear as to the answer to this.

`std::unwinding_exception` can only be true if it is called "inside a
destructor body". Therefore:

   1. `bool u` will be true. `std::unwinding_exception` is called inside a
   destructor body, and the object `u` is being destroyed as a result of stack
   unwinding.
   2. `bool s` will be true. `std::unwinding_exception` is called inside a
   destructor body, and the base class `S` of `u` is being destroyed as a
   result of stack unwinding.
   3. `bool t` will be true. `std::unwinding_exception` is called inside a
   destructor body and the object `t` is being destroyed as a result of stack
   unwinding.
   4. `bool t_cleanup` *will be false*. `std::unwinding_exception` is not
   called inside of a destructor body.
   5. `bool r` will be *false*. `std::unwinding_exception` is called inside
   a destructor body, but the object `r` is *not* being destroyed as a
   result of stack unwinding. No exception was thrown to cause `r` to be
   destroyed, therefore it was not destroyed by stack unwinding.

The only confusing bit is `t_cleanup`. I'm not 100% positive why this
limitation is there. It seems that it could be specified as, "if the most
recently called destructor on the call stack was called as a result of
stack unwinding". Translating that into standardese, of course.

The problem with the integer based "stack_unwinding<https://github.com/panaseleus/stack_unwinding>"
method is that it requires direct RAII usage of some object. You have to
code it into your class explicitly and store the number as a member. It
requires some preparation work. This method only requires direct querying
of a value; its limitation is that you can *only* call it in the destructor.

What they have in common is that neither one can just have a freestanding
function ask, "am I being called because of stack unwinding?". They have to
be part of an object; stack_unwinding requires object state, and
`std::unwinding_exception` requires being called in a destructor.

So it's a question of which limitation matters more to you: having to store
an integer or having to do the test in the destructor?

Also, there's another difference: you can implement the "stack_unwinding"
stuff using existing compiler tech (though not *standard* tech).
`std::unwinding_exception` has to be implemented by the compiler vendor
themselves; it's practically a sanctioned compiler intrinsic, due to its
behavior.

--

---
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/?hl=en.



------=_Part_1529_18583801.1363406029609
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Friday, March 15, 2013 4:51:09 PM UTC-7, Fernando Pelliccioni wr=
ote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>Hi H=
erb,<br></div><div><br></div><div>Thanks for your proposal.&nbsp;</div><div=
>I hope we can count on it in C++14.</div><div><br></div><div>I have a ques=
tion about the behavior of unwinding_exception</div><div>
Given the following code ...</div><div><br></div><div>//Begin code---------=
-----------------<wbr>---------------</div><div>struct R</div><div>{</div><=
div><span style=3D"white-space:pre"> </span>~R()&nbsp;</div><div><span styl=
e=3D"white-space:pre"> </span>{</div>
<div><span style=3D"white-space:pre">  </span>bool r =3D std::unwinding_exc=
eption();</div><div><span style=3D"white-space:pre"> </span>}</div><div>};<=
/div><div><br></div><div>struct S</div><div>{</div><div><span style=3D"whit=
e-space:pre"> </span>~S()&nbsp;</div>
<div><span style=3D"white-space:pre"> </span>{</div><div><span style=3D"whi=
te-space:pre">  </span>bool s =3D std::unwinding_exception();</div><div><sp=
an style=3D"white-space:pre"> </span>}</div><div>};</div>
<div><br></div><div>struct T</div><div>{</div><div><span style=3D"white-spa=
ce:pre"> </span>void cleanup()</div><div><span style=3D"white-space:pre"> <=
/span>{</div><div><span style=3D"white-space:pre">  </span>bool t_cleanup =
=3D std::unwinding_exception();<span style=3D"white-space:pre"> </span></di=
v>
<div><span style=3D"white-space:pre"> </span>}</div><div><br></div><div><sp=
an style=3D"white-space:pre"> </span>~T()&nbsp;</div><div><span style=3D"wh=
ite-space:pre"> </span>{</div><div><span style=3D"white-space:pre">  </span=
>bool t =3D std::unwinding_exception();</div>
<div><span style=3D"white-space:pre">  </span>cleanup();</div><div><span st=
yle=3D"white-space:pre"> </span>}</div><div>};</div><div><br></div><div>str=
uct U : S</div><div>{</div><div><span style=3D"white-space:pre"> </span>~U(=
)&nbsp;</div>
<div><span style=3D"white-space:pre"> </span>{</div><div><span style=3D"whi=
te-space:pre">  </span>R r;</div><div><span style=3D"white-space:pre">  </s=
pan>bool u =3D std::unwinding_exception();</div><div>
<span style=3D"white-space:pre"> </span>}</div><div><br></div><div><span st=
yle=3D"white-space:pre"> </span>T t_;</div><div>};</div><div><br></div><div=
>int main()&nbsp;</div><div>{</div><div><span style=3D"white-space:pre"> </=
span>try&nbsp;</div>
<div><span style=3D"white-space:pre"> </span>{</div><div><span style=3D"whi=
te-space:pre">  </span>U u;</div><div><span style=3D"white-space:pre">  </s=
pan>throw 1;</div><div><span style=3D"white-space:pre"> </span>} // U::~U()=
 invoked here</div>
<div><span style=3D"white-space:pre"> </span>catch(...) {}</div><div>}</div=
><div><br></div><div>//End code--------------------------<wbr>-------------=
--</div><div><br></div><div>What would be the values of r, s, t_cleanup, t =
and u ?&nbsp;</div>
<div>(I refer to variables that are within the destructors and in the clean=
up function)</div><div>I think it is clear for r, t_cleanup and u,&nbsp;but=
 I have doubts about t and s.</div><div>I believe that t and s should be eq=
ual to u.<br>
</div><div><br></div><div>Thanks and regards,</div><div>Fernando Pelliccion=
i.</div></div></blockquote><div><br>The wording of the paper is very clear =
as to the answer to this.<br><br>`std::unwinding_exception` can only be tru=
e if it is called "inside a destructor body". Therefore:<br><ol><li>`bool u=
` will be true. `std::unwinding_exception` is called=20
inside a destructor body, and the object `u` is being destroyed as a=20
result of stack unwinding.</li><li>`bool s` will be true.=20
`std::unwinding_exception` is called inside a destructor body, and the=20
base class `S` of `u` is being destroyed as a result of stack unwinding.<br=
></li><li>`bool t` will be true. `std::unwinding_exception` is called insid=
e a destructor body and the object `t` is being destroyed as a result of st=
ack unwinding.</li><li>`bool t_cleanup` <b>will be false</b>. `std::unwindi=
ng_exception` is not called inside of a destructor body.</li><li>`bool r` w=
ill be <b>false</b>. `std::unwinding_exception` is called inside a destruct=
or body, but the object `r` is <i>not</i>
 being destroyed as a result of stack unwinding. No exception was thrown
 to cause `r` to be destroyed, therefore it was not destroyed by stack=20
unwinding.</li></ol>The only confusing bit is `t_cleanup`. I'm not 100% pos=
itive why this limitation is there. It seems that it could be specified as,=
 "if the most recently called destructor on the call stack was called as a =
result of stack unwinding". Translating that into standardese, of course.<b=
r><br>The problem with the integer based "<a href=3D"https://github.com/pan=
aseleus/stack_unwinding">stack_unwinding</a>" method is that it requires di=
rect RAII usage of some object. You have to code it into your class explici=
tly and store the number as a member. It requires some preparation work. Th=
is method only requires direct querying of a value; its limitation is that =
you can <i>only</i> call it in the destructor.<br><br>What they have in com=
mon is that neither one can just have a freestanding function ask, "am I be=
ing called because of stack unwinding?". They have to be part of an object;=
 stack_unwinding requires object state, and `std::unwinding_exception` requ=
ires being called in a destructor.<br><br>So it's a question of which limit=
ation matters more to you: having to store an integer or having to do the t=
est in the destructor?<br><br>Also, there's another difference: you can imp=
lement the "stack_unwinding" stuff using existing compiler tech (though not=
 <i>standard</i> tech). `std::unwinding_exception` has to be implemented by=
 the compiler vendor themselves; it's practically a sanctioned compiler int=
rinsic, due to its behavior.<br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1529_18583801.1363406029609--

.

On 16 March 2013 05:53, Nicol Bolas <jmckesson@gmail.com> wrote:
> So it's a question of which limitation matters more to you: having to store
> an integer or having to do the test in the destructor?

Jens already showed how to store just a bool, or a bit of a bitfield by
masking the return value of the unwinding query function, for simple cases.

--

---
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/?hl=en.



.

------=_Part_69_21184070.1363418080658
Content-Type: text/plain; charset=ISO-8859-1

On Friday, March 15, 2013 11:37:09 PM UTC-7, Ville Voutilainen wrote:
>
> On 16 March 2013 05:53, Nicol Bolas <jmck...@gmail.com <javascript:>>
> wrote:
> > So it's a question of which limitation matters more to you: having to
> store
> > an integer or having to do the test in the destructor?
>
> Jens already showed how to store just a bool, or a bit of a bitfield by
> masking the return value of the unwinding query function, for simple
> cases.
>

Whether it's a bool, a bitfield, a value in a union, or whatever, it's
still *something* and not *nothing*. It requires *zero work* from the user
to use. It requires zero changes to the class's data structure. It has zero
in-class overhead.

--

---
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/?hl=en.



------=_Part_69_21184070.1363418080658
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Friday, March 15, 2013 11:37:09 PM UTC-7, Ville Voutilainen wrote:<block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;">On 16 March 2013 05:53, Nicol Bolas =
&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"qNmg=
GA5yMI0J">jmck...@gmail.com</a>&gt; wrote:
<br>&gt; So it's a question of which limitation matters more to you: having=
 to store
<br>&gt; an integer or having to do the test in the destructor?
<br>
<br>Jens already showed how to store just a bool, or a bit of a bitfield by
<br>masking the return value of the unwinding query function, for simple ca=
ses.
<br></blockquote><div><br>Whether it's a bool, a bitfield, a value in a uni=
on, or whatever, it's still <i>something</i> and not <i>nothing</i>. It req=
uires <i>zero work</i> from the user to use. It requires zero changes to th=
e class's data structure. It has zero in-class overhead.<br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_69_21184070.1363418080658--

.

------=_Part_901_15809185.1363475470022
Content-Type: text/plain; charset=ISO-8859-1

Nicol is exactly correct about the semantics in this example, that this is
a compiler intrinsic (that's why it's in clause 15, with
uncaught_exception, which is a language clause), and that it does not
require manual discipline to simulate as would a library solution.

I considered proposing that other member functions of the same object
called from the destructor could also use it (and this could be generalized
as you suggest to anything invoked via a destructor wherein the most
recently begun destructor would say 'true'), but for simplicity limited the
initial proposal to just immediate use in destructors. I'm not against this
generalization, but omitting it simplified the proposal, still permits this
as a possible extension, and the proposal is complete without it as the
destructor could simply pass this information to callees.

Herb


On Friday, March 15, 2013 8:53:49 PM UTC-7, Nicol Bolas wrote:

>
>
> On Friday, March 15, 2013 4:51:09 PM UTC-7, Fernando Pelliccioni wrote:
>>
>> Hi Herb,
>>
>> Thanks for your proposal.
>> I hope we can count on it in C++14.
>>
>> I have a question about the behavior of unwinding_exception
>> Given the following code ...
>>
>> //Begin code-----------------------------------------
>> struct R
>> {
>> ~R()
>> {
>>  bool r = std::unwinding_exception();
>> }
>> };
>>
>> struct S
>> {
>> ~S()
>>  {
>> bool s = std::unwinding_exception();
>> }
>> };
>>
>> struct T
>> {
>> void cleanup()
>> {
>> bool t_cleanup = std::unwinding_exception();
>>  }
>>
>> ~T()
>> {
>> bool t = std::unwinding_exception();
>>  cleanup();
>> }
>> };
>>
>> struct U : S
>> {
>> ~U()
>>  {
>> R r;
>> bool u = std::unwinding_exception();
>>  }
>>
>> T t_;
>> };
>>
>> int main()
>> {
>> try
>>  {
>> U u;
>> throw 1;
>> } // U::~U() invoked here
>>  catch(...) {}
>> }
>>
>> //End code-----------------------------------------
>>
>> What would be the values of r, s, t_cleanup, t and u ?
>> (I refer to variables that are within the destructors and in the cleanup
>> function)
>> I think it is clear for r, t_cleanup and u, but I have doubts about t and
>> s.
>> I believe that t and s should be equal to u.
>>
>> Thanks and regards,
>> Fernando Pelliccioni.
>>
>
> The wording of the paper is very clear as to the answer to this.
>
> `std::unwinding_exception` can only be true if it is called "inside a
> destructor body". Therefore:
>
>    1. `bool u` will be true. `std::unwinding_exception` is called inside
>    a destructor body, and the object `u` is being destroyed as a result of
>    stack unwinding.
>    2. `bool s` will be true. `std::unwinding_exception` is called inside
>    a destructor body, and the base class `S` of `u` is being destroyed as a
>    result of stack unwinding.
>    3. `bool t` will be true. `std::unwinding_exception` is called inside
>    a destructor body and the object `t` is being destroyed as a result of
>    stack unwinding.
>    4. `bool t_cleanup` *will be false*. `std::unwinding_exception` is not
>    called inside of a destructor body.
>    5. `bool r` will be *false*. `std::unwinding_exception` is called
>    inside a destructor body, but the object `r` is *not* being destroyed
>    as a result of stack unwinding. No exception was thrown to cause `r` to be
>    destroyed, therefore it was not destroyed by stack unwinding.
>
> The only confusing bit is `t_cleanup`. I'm not 100% positive why this
> limitation is there. It seems that it could be specified as, "if the most
> recently called destructor on the call stack was called as a result of
> stack unwinding". Translating that into standardese, of course.
>
> The problem with the integer based "stack_unwinding<https://github.com/panaseleus/stack_unwinding>"
> method is that it requires direct RAII usage of some object. You have to
> code it into your class explicitly and store the number as a member. It
> requires some preparation work. This method only requires direct querying
> of a value; its limitation is that you can *only* call it in the
> destructor.
>
> What they have in common is that neither one can just have a freestanding
> function ask, "am I being called because of stack unwinding?". They have to
> be part of an object; stack_unwinding requires object state, and
> `std::unwinding_exception` requires being called in a destructor.
>
> So it's a question of which limitation matters more to you: having to
> store an integer or having to do the test in the destructor?
>
> Also, there's another difference: you can implement the "stack_unwinding"
> stuff using existing compiler tech (though not *standard* tech).
> `std::unwinding_exception` has to be implemented by the compiler vendor
> themselves; it's practically a sanctioned compiler intrinsic, due to its
> behavior.
>

--

---
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/?hl=en.



------=_Part_901_15809185.1363475470022
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div>Nicol is exactly correct about the semantics in this example, that thi=
s is a compiler intrinsic (that's why it's in clause 15, with uncaught_exce=
ption, which is a language clause), and that it does not require manual dis=
cipline to simulate as would a library solution.</div><div>&nbsp;</div><div=
>I considered proposing that other member functions of the same object call=
ed from the destructor could also use it (and this could be generalized as =
you suggest to anything invoked via a destructor wherein the most recently =
begun destructor would say 'true'), but for simplicity limited the initial =
proposal to just immediate use in destructors. I'm not against this general=
ization, but omitting it simplified the proposal, still permits this as a p=
ossible&nbsp;extension, and the proposal is complete without it as the dest=
ructor could simply pass this information to callees.</div><div>&nbsp;</div=
><div>Herb</div><div>&nbsp;</div><div><br>On Friday, March 15, 2013 8:53:49=
 PM UTC-7, Nicol Bolas wrote:</div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(20=
4, 204, 204); border-left-width: 1px; border-left-style: solid;"><br><br>On=
 Friday, March 15, 2013 4:51:09 PM UTC-7, Fernando Pelliccioni wrote:<block=
quote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-lef=
t: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; bord=
er-left-style: solid;"><div dir=3D"ltr"><div>Hi Herb,<br></div><div><br></d=
iv><div>Thanks for your proposal.&nbsp;</div><div>I hope we can count on it=
 in C++14.</div><div><br></div><div>I have a question about the behavior of=
 unwinding_exception</div><div>
Given the following code ...</div><div><br></div><div>//Begin code---------=
-----------------<wbr>---------------</div><div>struct R</div><div>{</div><=
div><span style=3D"white-space: pre;"> </span>~R()&nbsp;</div><div><span st=
yle=3D"white-space: pre;"> </span>{</div>
<div><span style=3D"white-space: pre;">  </span>bool r =3D std::unwinding_e=
xception();</div><div><span style=3D"white-space: pre;"> </span>}</div><div=
>};</div><div><br></div><div>struct S</div><div>{</div><div><span style=3D"=
white-space: pre;"> </span>~S()&nbsp;</div>
<div><span style=3D"white-space: pre;"> </span>{</div><div><span style=3D"w=
hite-space: pre;">  </span>bool s =3D std::unwinding_exception();</div><div=
><span style=3D"white-space: pre;"> </span>}</div><div>};</div>
<div><br></div><div>struct T</div><div>{</div><div><span style=3D"white-spa=
ce: pre;"> </span>void cleanup()</div><div><span style=3D"white-space: pre;=
"> </span>{</div><div><span style=3D"white-space: pre;">  </span>bool t_cle=
anup =3D std::unwinding_exception();<span style=3D"white-space: pre;"> </sp=
an></div>
<div><span style=3D"white-space: pre;"> </span>}</div><div><br></div><div><=
span style=3D"white-space: pre;"> </span>~T()&nbsp;</div><div><span style=
=3D"white-space: pre;"> </span>{</div><div><span style=3D"white-space: pre;=
">  </span>bool t =3D std::unwinding_exception();</div>
<div><span style=3D"white-space: pre;">  </span>cleanup();</div><div><span =
style=3D"white-space: pre;"> </span>}</div><div>};</div><div><br></div><div=
>struct U : S</div><div>{</div><div><span style=3D"white-space: pre;"> </sp=
an>~U()&nbsp;</div>
<div><span style=3D"white-space: pre;"> </span>{</div><div><span style=3D"w=
hite-space: pre;">  </span>R r;</div><div><span style=3D"white-space: pre;"=
>  </span>bool u =3D std::unwinding_exception();</div><div>
<span style=3D"white-space: pre;"> </span>}</div><div><br></div><div><span =
style=3D"white-space: pre;"> </span>T t_;</div><div>};</div><div><br></div>=
<div>int main()&nbsp;</div><div>{</div><div><span style=3D"white-space: pre=
;"> </span>try&nbsp;</div>
<div><span style=3D"white-space: pre;"> </span>{</div><div><span style=3D"w=
hite-space: pre;">  </span>U u;</div><div><span style=3D"white-space: pre;"=
>  </span>throw 1;</div><div><span style=3D"white-space: pre;"> </span>} //=
 U::~U() invoked here</div>
<div><span style=3D"white-space: pre;"> </span>catch(...) {}</div><div>}</d=
iv><div><br></div><div>//End code--------------------------<wbr>-----------=
----</div><div><br></div><div>What would be the values of r, s, t_cleanup, =
t and u ?&nbsp;</div>
<div>(I refer to variables that are within the destructors and in the clean=
up function)</div><div>I think it is clear for r, t_cleanup and u,&nbsp;but=
 I have doubts about t and s.</div><div>I believe that t and s should be eq=
ual to u.<br>
</div><div><br></div><div>Thanks and regards,</div><div>Fernando Pelliccion=
i.</div></div></blockquote><div><br>The wording of the paper is very clear =
as to the answer to this.<br><br>`std::unwinding_exception` can only be tru=
e if it is called "inside a destructor body". Therefore:<br><ol><li>`bool u=
` will be true. `std::unwinding_exception` is called=20
inside a destructor body, and the object `u` is being destroyed as a=20
result of stack unwinding.</li><li>`bool s` will be true.=20
`std::unwinding_exception` is called inside a destructor body, and the=20
base class `S` of `u` is being destroyed as a result of stack unwinding.<br=
></li><li>`bool t` will be true. `std::unwinding_exception` is called insid=
e a destructor body and the object `t` is being destroyed as a result of st=
ack unwinding.</li><li>`bool t_cleanup` <b>will be false</b>. `std::unwindi=
ng_exception` is not called inside of a destructor body.</li><li>`bool r` w=
ill be <b>false</b>. `std::unwinding_exception` is called inside a destruct=
or body, but the object `r` is <i>not</i>
 being destroyed as a result of stack unwinding. No exception was thrown
 to cause `r` to be destroyed, therefore it was not destroyed by stack=20
unwinding.</li></ol>The only confusing bit is `t_cleanup`. I'm not 100% pos=
itive why this limitation is there. It seems that it could be specified as,=
 "if the most recently called destructor on the call stack was called as a =
result of stack unwinding". Translating that into standardese, of course.<b=
r><br>The problem with the integer based "<a href=3D"https://github.com/pan=
aseleus/stack_unwinding" target=3D"_blank">stack_unwinding</a>" method is t=
hat it requires direct RAII usage of some object. You have to code it into =
your class explicitly and store the number as a member. It requires some pr=
eparation work. This method only requires direct querying of a value; its l=
imitation is that you can <i>only</i> call it in the destructor.<br><br>Wha=
t they have in common is that neither one can just have a freestanding func=
tion ask, "am I being called because of stack unwinding?". They have to be =
part of an object; stack_unwinding requires object state, and `std::unwindi=
ng_exception` requires being called in a destructor.<br><br>So it's a quest=
ion of which limitation matters more to you: having to store an integer or =
having to do the test in the destructor?<br><br>Also, there's another diffe=
rence: you can implement the "stack_unwinding" stuff using existing compile=
r tech (though not <i>standard</i> tech). `std::unwinding_exception` has to=
 be implemented by the compiler vendor themselves; it's practically a sanct=
ioned compiler intrinsic, due to its behavior.<br></div></blockquote>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_901_15809185.1363475470022--

.

--bcaec554042245f2ee04d828bdf3
Content-Type: text/plain; charset=ISO-8859-1

Hi Nicol, hi Herb,

My question is mostly about which objects ( by definition ) should be
destroyed as part of the "stack unwinding" therefore this definition
affects std::unwinding_exception.

My understanding of unwinding_exception behavior is as it described by the
Nicol, but I had some doubts and need to reinforce it with an example.

In my example...
Are the destructors of T and S invoked as part of the "stack unwinding"?
.... or ...
Are executed as part of the destruction of U? ( which is invoked as part of
"stack unwinding" )

About "inside a destructor body", it is obvious what it means and I
understand it, but I wanted to reinforce it with an example to show a
practical example of using of unwinding_exception within a function.

Anyway, all my doubts are gone, thank you very much for your answers.

Regards,
Fernando.


On Sat, Mar 16, 2013 at 8:11 PM, Herb Sutter <admin@isocpp.org> wrote:

> Nicol is exactly correct about the semantics in this example, that this is
> a compiler intrinsic (that's why it's in clause 15, with
> uncaught_exception, which is a language clause), and that it does not
> require manual discipline to simulate as would a library solution.
>
> I considered proposing that other member functions of the same object
> called from the destructor could also use it (and this could be generalized
> as you suggest to anything invoked via a destructor wherein the most
> recently begun destructor would say 'true'), but for simplicity limited the
> initial proposal to just immediate use in destructors. I'm not against this
> generalization, but omitting it simplified the proposal, still permits this
> as a possible extension, and the proposal is complete without it as the
> destructor could simply pass this information to callees.
>
> Herb
>
>
> On Friday, March 15, 2013 8:53:49 PM UTC-7, Nicol Bolas wrote:
>
>>
>>
>> On Friday, March 15, 2013 4:51:09 PM UTC-7, Fernando Pelliccioni wrote:
>>>
>>> Hi Herb,
>>>
>>> Thanks for your proposal.
>>> I hope we can count on it in C++14.
>>>
>>> I have a question about the behavior of unwinding_exception
>>> Given the following code ...
>>>
>>> //Begin code--------------------------**---------------
>>> struct R
>>> {
>>> ~R()
>>> {
>>>  bool r = std::unwinding_exception();
>>> }
>>> };
>>>
>>> struct S
>>> {
>>> ~S()
>>>  {
>>> bool s = std::unwinding_exception();
>>> }
>>> };
>>>
>>> struct T
>>> {
>>> void cleanup()
>>> {
>>> bool t_cleanup = std::unwinding_exception();
>>>  }
>>>
>>> ~T()
>>> {
>>> bool t = std::unwinding_exception();
>>>  cleanup();
>>> }
>>> };
>>>
>>> struct U : S
>>> {
>>> ~U()
>>>  {
>>> R r;
>>> bool u = std::unwinding_exception();
>>>  }
>>>
>>> T t_;
>>> };
>>>
>>> int main()
>>> {
>>> try
>>>  {
>>> U u;
>>> throw 1;
>>> } // U::~U() invoked here
>>>  catch(...) {}
>>> }
>>>
>>> //End code--------------------------**---------------
>>>
>>> What would be the values of r, s, t_cleanup, t and u ?
>>> (I refer to variables that are within the destructors and in the cleanup
>>> function)
>>> I think it is clear for r, t_cleanup and u, but I have doubts about t
>>> and s.
>>> I believe that t and s should be equal to u.
>>>
>>> Thanks and regards,
>>> Fernando Pelliccioni.
>>>
>>
>> The wording of the paper is very clear as to the answer to this.
>>
>> `std::unwinding_exception` can only be true if it is called "inside a
>> destructor body". Therefore:
>>
>>    1. `bool u` will be true. `std::unwinding_exception` is called inside
>>    a destructor body, and the object `u` is being destroyed as a result of
>>    stack unwinding.
>>    2. `bool s` will be true. `std::unwinding_exception` is called inside
>>    a destructor body, and the base class `S` of `u` is being destroyed as a
>>    result of stack unwinding.
>>    3. `bool t` will be true. `std::unwinding_exception` is called inside
>>    a destructor body and the object `t` is being destroyed as a result of
>>    stack unwinding.
>>    4. `bool t_cleanup` *will be false*. `std::unwinding_exception` is
>>    not called inside of a destructor body.
>>    5. `bool r` will be *false*. `std::unwinding_exception` is called
>>    inside a destructor body, but the object `r` is *not* being destroyed
>>    as a result of stack unwinding. No exception was thrown to cause `r` to be
>>    destroyed, therefore it was not destroyed by stack unwinding.
>>
>> The only confusing bit is `t_cleanup`. I'm not 100% positive why this
>> limitation is there. It seems that it could be specified as, "if the most
>> recently called destructor on the call stack was called as a result of
>> stack unwinding". Translating that into standardese, of course.
>>
>> The problem with the integer based "stack_unwinding<https://github.com/panaseleus/stack_unwinding>"
>> method is that it requires direct RAII usage of some object. You have to
>> code it into your class explicitly and store the number as a member. It
>> requires some preparation work. This method only requires direct querying
>> of a value; its limitation is that you can *only* call it in the
>> destructor.
>>
>> What they have in common is that neither one can just have a freestanding
>> function ask, "am I being called because of stack unwinding?". They have to
>> be part of an object; stack_unwinding requires object state, and
>> `std::unwinding_exception` requires being called in a destructor.
>>
>> So it's a question of which limitation matters more to you: having to
>> store an integer or having to do the test in the destructor?
>>
>> Also, there's another difference: you can implement the "stack_unwinding"
>> stuff using existing compiler tech (though not *standard* tech).
>> `std::unwinding_exception` has to be implemented by the compiler vendor
>> themselves; it's practically a sanctioned compiler intrinsic, due to its
>> behavior.
>>
>  --
>
> ---
> 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/?hl=en.
>
>
>

--

---
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/?hl=en.



--bcaec554042245f2ee04d828bdf3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi Nicol, hi Herb,</div><div><br></div><div>My questi=
on is mostly about which objects ( by definition ) should be destroyed as p=
art of the &quot;stack unwinding&quot; therefore this definition affects st=
d::unwinding_exception.</div>
<div><br></div><div>My understanding of unwinding_exception behavior is as =
it described by the Nicol, but I had some doubts and need to reinforce it w=
ith an example.</div><div><br></div><div>In my example...</div><div>Are the=
 destructors of T and S invoked as part of the &quot;stack unwinding&quot;?=
</div>
<div>... or ...</div><div>Are executed as part of the destruction of U? ( w=
hich is invoked as part of &quot;stack unwinding&quot; )</div><div><br></di=
v><div>About &quot;inside a destructor body&quot;, it is obvious what it me=
ans and I understand it, but I wanted to reinforce it with an example to sh=
ow a practical example of using of unwinding_exception within a function.</=
div>
<div><br></div><div>Anyway, all my doubts are gone, thank you very much for=
 your answers.</div><div><br></div><div>Regards,</div><div>Fernando.</div><=
div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Sat, Mar 16=
, 2013 at 8:11 PM, Herb Sutter <span dir=3D"ltr">&lt;<a href=3D"mailto:admi=
n@isocpp.org" target=3D"_blank">admin@isocpp.org</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div>Nicol is exactly correct about the semantics in this =
example, that this is a compiler intrinsic (that&#39;s why it&#39;s in clau=
se 15, with uncaught_exception, which is a language clause), and that it do=
es not require manual discipline to simulate as would a library solution.</=
div>
<div>=A0</div><div>I considered proposing that other member functions of th=
e same object called from the destructor could also use it (and this could =
be generalized as you suggest to anything invoked via a destructor wherein =
the most recently begun destructor would say &#39;true&#39;), but for simpl=
icity limited the initial proposal to just immediate use in destructors. I&=
#39;m not against this generalization, but omitting it simplified the propo=
sal, still permits this as a possible=A0extension, and the proposal is comp=
lete without it as the destructor could simply pass this information to cal=
lees.</div>
<span class=3D""><font color=3D"#888888"><div>=A0</div><div>Herb</div></fon=
t></span><div class=3D""><div class=3D"h5"><div>=A0</div><div><br>On Friday=
, March 15, 2013 8:53:49 PM UTC-7, Nicol Bolas wrote:</div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border=
-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid"=
>
<br><br>On Friday, March 15, 2013 4:51:09 PM UTC-7, Fernando Pelliccioni wr=
ote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;pad=
ding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;bord=
er-left-style:solid">
<div dir=3D"ltr"><div>Hi Herb,<br></div><div><br></div><div>Thanks for your=
 proposal.=A0</div><div>I hope we can count on it in C++14.</div><div><br><=
/div><div>I have a question about the behavior of unwinding_exception</div>
<div>
Given the following code ...</div><div><br></div><div>//Begin code---------=
-----------------<u></u>---------------</div><div>struct R</div><div>{</div=
><div><span style=3D"white-space:pre-wrap"> </span>~R()=A0</div><div><span =
style=3D"white-space:pre-wrap"> </span>{</div>

<div><span style=3D"white-space:pre-wrap">  </span>bool r =3D std::unwindin=
g_exception();</div><div><span style=3D"white-space:pre-wrap"> </span>}</di=
v><div>};</div><div><br></div><div>struct S</div><div>{</div><div><span sty=
le=3D"white-space:pre-wrap"> </span>~S()=A0</div>

<div><span style=3D"white-space:pre-wrap"> </span>{</div><div><span style=
=3D"white-space:pre-wrap">  </span>bool s =3D std::unwinding_exception();</=
div><div><span style=3D"white-space:pre-wrap"> </span>}</div><div>};</div>
<div><br></div><div>struct T</div><div>{</div><div><span style=3D"white-spa=
ce:pre-wrap"> </span>void cleanup()</div><div><span style=3D"white-space:pr=
e-wrap"> </span>{</div><div><span style=3D"white-space:pre-wrap">  </span>b=
ool t_cleanup =3D std::unwinding_exception();<span style=3D"white-space:pre=
-wrap"> </span></div>

<div><span style=3D"white-space:pre-wrap"> </span>}</div><div><br></div><di=
v><span style=3D"white-space:pre-wrap"> </span>~T()=A0</div><div><span styl=
e=3D"white-space:pre-wrap"> </span>{</div><div><span style=3D"white-space:p=
re-wrap">  </span>bool t =3D std::unwinding_exception();</div>

<div><span style=3D"white-space:pre-wrap">  </span>cleanup();</div><div><sp=
an style=3D"white-space:pre-wrap"> </span>}</div><div>};</div><div><br></di=
v><div>struct U : S</div><div>{</div><div><span style=3D"white-space:pre-wr=
ap"> </span>~U()=A0</div>

<div><span style=3D"white-space:pre-wrap"> </span>{</div><div><span style=
=3D"white-space:pre-wrap">  </span>R r;</div><div><span style=3D"white-spac=
e:pre-wrap">  </span>bool u =3D std::unwinding_exception();</div><div>
<span style=3D"white-space:pre-wrap"> </span>}</div><div><br></div><div><sp=
an style=3D"white-space:pre-wrap"> </span>T t_;</div><div>};</div><div><br>=
</div><div>int main()=A0</div><div>{</div><div><span style=3D"white-space:p=
re-wrap"> </span>try=A0</div>

<div><span style=3D"white-space:pre-wrap"> </span>{</div><div><span style=
=3D"white-space:pre-wrap">  </span>U u;</div><div><span style=3D"white-spac=
e:pre-wrap">  </span>throw 1;</div><div><span style=3D"white-space:pre-wrap=
"> </span>} // U::~U() invoked here</div>

<div><span style=3D"white-space:pre-wrap"> </span>catch(...) {}</div><div>}=
</div><div><br></div><div>//End code--------------------------<u></u>------=
---------</div><div><br></div><div>What would be the values of r, s, t_clea=
nup, t and u ?=A0</div>

<div>(I refer to variables that are within the destructors and in the clean=
up function)</div><div>I think it is clear for r, t_cleanup and u,=A0but I =
have doubts about t and s.</div><div>I believe that t and s should be equal=
 to u.<br>

</div><div><br></div><div>Thanks and regards,</div><div>Fernando Pelliccion=
i.</div></div></blockquote><div><br>The wording of the paper is very clear =
as to the answer to this.<br><br>`std::unwinding_exception` can only be tru=
e if it is called &quot;inside a destructor body&quot;. Therefore:<br>
<ol><li>`bool u` will be true. `std::unwinding_exception` is called=20
inside a destructor body, and the object `u` is being destroyed as a=20
result of stack unwinding.</li><li>`bool s` will be true.=20
`std::unwinding_exception` is called inside a destructor body, and the=20
base class `S` of `u` is being destroyed as a result of stack unwinding.<br=
></li><li>`bool t` will be true. `std::unwinding_exception` is called insid=
e a destructor body and the object `t` is being destroyed as a result of st=
ack unwinding.</li>
<li>`bool t_cleanup` <b>will be false</b>. `std::unwinding_exception` is no=
t called inside of a destructor body.</li><li>`bool r` will be <b>false</b>=
.. `std::unwinding_exception` is called inside a destructor body, but the ob=
ject `r` is <i>not</i>
 being destroyed as a result of stack unwinding. No exception was thrown
 to cause `r` to be destroyed, therefore it was not destroyed by stack=20
unwinding.</li></ol>The only confusing bit is `t_cleanup`. I&#39;m not 100%=
 positive why this limitation is there. It seems that it could be specified=
 as, &quot;if the most recently called destructor on the call stack was cal=
led as a result of stack unwinding&quot;. Translating that into standardese=
, of course.<br>
<br>The problem with the integer based &quot;<a href=3D"https://github.com/=
panaseleus/stack_unwinding" target=3D"_blank">stack_unwinding</a>&quot; met=
hod is that it requires direct RAII usage of some object. You have to code =
it into your class explicitly and store the number as a member. It requires=
 some preparation work. This method only requires direct querying of a valu=
e; its limitation is that you can <i>only</i> call it in the destructor.<br=
>
<br>What they have in common is that neither one can just have a freestandi=
ng function ask, &quot;am I being called because of stack unwinding?&quot;.=
 They have to be part of an object; stack_unwinding requires object state, =
and `std::unwinding_exception` requires being called in a destructor.<br>
<br>So it&#39;s a question of which limitation matters more to you: having =
to store an integer or having to do the test in the destructor?<br><br>Also=
, there&#39;s another difference: you can implement the &quot;stack_unwindi=
ng&quot; stuff using existing compiler tech (though not <i>standard</i> tec=
h). `std::unwinding_exception` has to be implemented by the compiler vendor=
 themselves; it&#39;s practically a sanctioned compiler intrinsic, due to i=
ts behavior.<br>
</div></blockquote>

<p></p>

-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den" target=3D"_blank">http://groups.google.com/a/isocpp=
..org/group/std-proposals/?hl=3Den</a>.<br>
=A0<br>
=A0<br>
</div></div></blockquote></div><br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--bcaec554042245f2ee04d828bdf3--

.

------=_Part_1259_6794778.1364162183643
Content-Type: text/plain; charset=ISO-8859-1

There is one very important problem with this. Consider the destructor of
`std::unique_ptr<T>`. It will call the deleter's operator(), which will
call `delete` on the stored pointer. OK... so if a unique_ptr<T> is being
destroyed due to stack unwinding, how can we pass that information along to
`T`'s destructor?

Because, as this feature is currently defined, we can't. The pointer is *not
* being destroyed due to stack unwinding, as only automatic objects and
members/base classes thereof can be destroyed due to stack unwinding.

This seems to be a pretty fatal flaw for the feature as proposed: the
inability to transfer the property to appropriate destructors.

--

---
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/?hl=en.



------=_Part_1259_6794778.1364162183643
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

There is one very important problem with this. Consider the destructor of `=
std::unique_ptr&lt;T&gt;`. It will call the deleter's operator(), which wil=
l call `delete` on the stored pointer. OK... so if a unique_ptr&lt;T&gt; is=
 being destroyed due to stack unwinding, how can we pass that information a=
long to `T`'s destructor?<br><br>Because, as this feature is currently defi=
ned, we can't. The pointer is <i>not</i> being destroyed due to stack unwin=
ding, as only automatic objects and members/base classes thereof can be des=
troyed due to stack unwinding.<br><br>This seems to be a pretty fatal flaw =
for the feature as proposed: the inability to transfer the property to appr=
opriate destructors.<br>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1259_6794778.1364162183643--

.

On 24 March 2013 23:56, Nicol Bolas <jmckesson@gmail.com> wrote:
> There is one very important problem with this. Consider the destructor of
> `std::unique_ptr<T>`. It will call the deleter's operator(), which will call
> `delete` on the stored pointer. OK... so if a unique_ptr<T> is being
> destroyed due to stack unwinding, how can we pass that information along to
> `T`'s destructor?
> Because, as this feature is currently defined, we can't. The pointer is not
> being destroyed due to stack unwinding, as only automatic objects and
> members/base classes thereof can be destroyed due to stack unwinding.
> This seems to be a pretty fatal flaw for the feature as proposed: the
> inability to transfer the property to appropriate destructors.

That's why we should probably look at existing practice in
https://github.com/panaseleus/stack_unwinding, which allows the destructors
to find out whether they are invoked as a result of unwinding or not.
It's been implemented
across a couple of popular implementations, and doesn't suffer from
such a problem.

--

---
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/?hl=en.



.

------=_Part_3_17563218.1364166894109
Content-Type: text/plain; charset=ISO-8859-1

I'm not sure what the flaw is.

With the current proposal as written, a destructor can ask
unwinding_exception() and forward that result. Or if we feel we want to
automatically propagate it to "any destructor invoked during unwinding"
that's a pure extension.

Right?

Herb


On Sunday, March 24, 2013 2:56:23 PM UTC-7, Nicol Bolas wrote:

> There is one very important problem with this. Consider the destructor of
> `std::unique_ptr<T>`. It will call the deleter's operator(), which will
> call `delete` on the stored pointer. OK... so if a unique_ptr<T> is being
> destroyed due to stack unwinding, how can we pass that information along to
> `T`'s destructor?
>
> Because, as this feature is currently defined, we can't. The pointer is *
> not* being destroyed due to stack unwinding, as only automatic objects
> and members/base classes thereof can be destroyed due to stack unwinding.
>
> This seems to be a pretty fatal flaw for the feature as proposed: the
> inability to transfer the property to appropriate destructors.
>

--

---
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/?hl=en.



------=_Part_3_17563218.1364166894109
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div>I'm not sure what the flaw is.</div><div>&nbsp;</div><div>With the cur=
rent proposal as written, a destructor can ask unwinding_exception() and fo=
rward that result. Or if we feel we want to automatically propagate it to "=
any destructor invoked during unwinding" that's a pure extension.</div><div=
>&nbsp;</div><div>Right?</div><div>&nbsp;</div><div>Herb</div><div>&nbsp;</=
div><div><br>On Sunday, March 24, 2013 2:56:23 PM UTC-7, Nicol Bolas wrote:=
</div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex;=
 padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-widt=
h: 1px; border-left-style: solid;">There is one very important problem with=
 this. Consider the destructor of `std::unique_ptr&lt;T&gt;`. It will call =
the deleter's operator(), which will call `delete` on the stored pointer. O=
K... so if a unique_ptr&lt;T&gt; is being destroyed due to stack unwinding,=
 how can we pass that information along to `T`'s destructor?<br><br>Because=
, as this feature is currently defined, we can't. The pointer is <i>not</i>=
 being destroyed due to stack unwinding, as only automatic objects and memb=
ers/base classes thereof can be destroyed due to stack unwinding.<br><br>Th=
is seems to be a pretty fatal flaw for the feature as proposed: the inabili=
ty to transfer the property to appropriate destructors.<br></blockquote>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_3_17563218.1364166894109--

.

On 25 March 2013 01:14, Herb Sutter <admin@isocpp.org> wrote:
> I'm not sure what the flaw is.
> With the current proposal as written, a destructor can ask
> unwinding_exception() and forward that result. Or if we feel we want to

Forward how? I don't think you can always dictate such a change into the APIs
of the things you use in any given class.

The stack_unwind allows arbitrary code to query whether unwinding is
ongoing or not.
Yours doesn't.

--

---
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/?hl=en.



.

------=_Part_95_5826092.1364170977000
Content-Type: text/plain; charset=ISO-8859-1

On Sunday, March 24, 2013 4:14:54 PM UTC-7, Herb Sutter wrote:
>
> I'm not sure what the flaw is.
>
> With the current proposal as written, a destructor can ask
> unwinding_exception() and forward that result. Or if we feel we want to
> automatically propagate it to "any destructor invoked during unwinding"
> that's a pure extension.
>
> Right?
>

That won't fix it. You can't say *any* destructor, because that would mean
a destructor executed in the same scope as the destructor:

struct T
{
  ~T()
  {
    Type v; //This should *never* be considered unwinding, even if ~T is
called during unwinding
  }
};

Yet, we do want this to be able to propagate:

struct U {
  U() member(new Type) {}
  ~U() {
    delete member; //If ~T is being unwound, so is this deletion.
  }

  Type *member;
};

The difference being that, in the case of T, the `Type` object is
constructed in the same "unwinding scope" as it is being destructed in. No
exception was thrown between `Type`'s constructor and destructor. In the
`U` case, if stack unwinding happens between the construction of `member`
and it's destruction, then we want it's destruction to be considered as
part of unwinding.

As ugly as the unwind count thing is, it does resolve this problem.

--

---
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/?hl=en.



------=_Part_95_5826092.1364170977000
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Sunday, March 24, 2013 4:14:54 PM UTC-7, Herb Sutter wrote:<blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px=
 #ccc solid;padding-left: 1ex;"><div>I'm not sure what the flaw is.</div><d=
iv>&nbsp;</div><div>With the current proposal as written, a destructor can =
ask unwinding_exception() and forward that result. Or if we feel we want to=
 automatically propagate it to "any destructor invoked during unwinding" th=
at's a pure extension.</div><div>&nbsp;</div><div>Right?</div></blockquote>=
<div><br>That won't fix it. You can't say <i>any</i> destructor, because th=
at would mean a destructor executed in the same scope as the destructor:<br=
><br><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 25=
0); border-color: rgb(187, 187, 187); border-style: solid; border-width: 1p=
x; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subpre=
ttyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">struct<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> T<br></spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; </span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">~</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify">T</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">()</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"><br>&nbsp; </span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"><br>&nbsp; &nbsp; </span><span style=3D"color: #606;" cla=
ss=3D"styled-by-prettify">Type</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> v</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #800;" class=3D"styled-by-prettify">//This=
 should *never* be considered unwinding, even if ~T is called during unwind=
ing</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nb=
sp; </span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">};</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div></code></di=
v><br>Yet, we do want this to be able to propagate:<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"color: #008;" class=3D"styled-by-prettify">struct</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> U </span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"><br>&nbsp; U</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">()</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> member</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">(</span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">new</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Type</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"><br>&nbsp; </span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">~</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify">U</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">()</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nb=
sp; &nbsp; </span><span style=3D"color: #008;" class=3D"styled-by-prettify"=
>delete</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> me=
mber</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span s=
tyle=3D"color: #800;" class=3D"styled-by-prettify">//If ~T is being unwound=
, so is this deletion.</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"><br>&nbsp; </span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br><br>&nbsp; </span><span style=3D"color: #606;" class=3D"styled-by-p=
rettify">Type</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">*</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify">member</span><s=
pan 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"co=
lor: #660;" class=3D"styled-by-prettify">};</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br></span></div></code></div><br>The diff=
erence being that, in the case of T, the `Type` object is constructed in th=
e same "unwinding scope" as it is being destructed in. No exception was thr=
own between `Type`'s constructor and destructor. In the `U` case, if stack =
unwinding happens between the construction of `member` and it's destruction=
, then we want it's destruction to be considered as part of unwinding.<br><=
br>As ugly as the unwind count thing is, it does resolve this problem.<br><=
/div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_95_5826092.1364170977000--

.

------=_Part_1570_2757519.1364687164407
Content-Type: text/plain; charset=ISO-8859-1

Hello All!

Oops, looks like I am bit late on party :)
Unfortunately, I wasn't aware of Jens proposal. At least I was lucky to
come across this discussion.

"Jens already showed how to store just a bool, or a bit of a bitfield by
masking the return value of the unwinding query function, for simple cases.
"

Storing only one bit of info is enough, see
https://github.com/panaseleus/stack_unwinding/blob/master/boost/exception/uncaught_exception_count.hpp
, there is class uncaught_exception_count_latch built on top of
uncaught_exception_count which stores exactly one bit.

"The problem with the integer based "stack_unwinding" method is that it
requires direct RAII usage of some object."

But yes, it is still context which should be associated with class.
During implementation of stack_unwinding library I was not aimed on
language extension. I just was inspired by Adrei Alexandrescu presentation
(
http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2012/Three-Unlikely-Successful-Features-of-D
), and I tried to implement scope(failure)/scope(success) *now*, for use
with *current* compilers.
So, that explicit context is only artifact of implementation.

Of course with power of compiler implementor it is possible to avoid
requiring explicit context. For instance syntax like - Unwinding Aware
Destructor
https://github.com/panaseleus/stack_unwinding#unwinding-aware-destructor ,
https://github.com/panaseleus/stack_unwinding/blob/master/examples/unwinding_aware_destructor.cpp
..

"Also, there's another difference: you can implement the "stack_unwinding"
stuff using existing compiler tech (though not standard tech).
`std::unwinding_exception` has to be implemented by the compiler vendor
themselves; it's practically a sanctioned compiler intrinsic, due to its
behavior."

By the way, I remember that I tried to implement "unwinding_exception"-like
stuff, i.e. without explicit context.
I tried to inspect registers and call stack in order to find some evidence
of unwinding process - I didn't get stable result, and I just fallback to
uncought_exception_count which I already had and which was stable enough.
I.e. it may be possible to implement "unwinding_exception", but amount of
platform-specifc code/work would be much bigger than just inspecting
integer in memory like uncought_exception_count does.

"As ugly as the unwind count thing is, it does resolve this problem."

Yes, it does reasonably work for nested objects (via aggregation or
inheritance).
It even allow us to handle more complex examples like this:

struct Vector // (approximation of container)
{
    Some *a,*b;
    Vector()
        : a(new Some()), b(new Some())
    {}
    ~Vector()
    {
        delete b; // if it throws then we should propogate right uncaught
exception count to a's destructor.
        /*
           But if we would do:
               try
               {
                   delete b;
               }
               catch(...)
               {
                   delete a; // then at this point we *caught* exception,
and reduced back uncaught exception count
                   throw;
               }
        */
        // Right solution is to use:
        scope(exit)
        {
            delete a; // scope(exit) does not change state of uncaught
exception count
        };
        // That solution was proposed by "Ku-ku" at
http://www.rsdn.ru/forum/flame.comp/4932465.1
        // and it can be extended to containers of many objects
    }
};
________________________
However, technique based on uncaught_exception_count can be fooled in
following case: when object is created during stack unwinding (i.e. in some
destructor), and that object outlived unwinding process, for instance it
was stored in global variable ( I have special test case:
https://github.com/panaseleus/stack_unwinding/blob/master/examples/uncaught_exception_count_floating_object.cpp
).
That fact about "floating" objects should be taken into account, because it
could also lead to different "anti-patterns"

However, that issue does not affect implementation of
scope(success/failure) features on top of uncaught_exception_count, because
- their objects live only in code blocks (compound-statements), and can't
leave them. Even more, If auxiliary variables are created by small macro -
then user can't even "spell" names of these objects.

Maybe in general case, we should consider giving ability to caller of
"delete", or caller of explicit destructor, ability to pass flag to
destructable object indicating whether or not it is "called" during stack
unwinding. That is consistent with Unwinding Aware Destructor - destructor
accepts flag as a parameter, and when we are calling destructor explicitly,
we should have ability to pass argument to it.

It seems logical: when "compiler" manages lifetime of object - it knows
when it calls destructor during unwinding or not.
But when we are managing lifetime of object manually, by calling delete -
there is no any unwinding in this scope by definition (because we reached
delete operator).
And it would be nice to have ability to miminc compiler's behaviour. I.e.:
class AutoManaged
{
    Some a,b;
public: //...
};
and
class ManualyManaged
{
    Some *a, *b;
public: //...
};
Should have ability to expose exactly same obsevable behaviour in respect
to exceptions.

P.S. Herb, I sent to you (and Andrei) e-mail regarding stack_unwinding in
February, did you get it?

P.P.S. Sorry for long message, as compensation here is fully isolated
implementation of scope(failure)/scope(success) - http://ideone.com/tyb14x
, it works on MSVC, GCC, Clang, Intel :)

--

---
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/?hl=en.



------=_Part_1570_2757519.1364687164407
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hello All!<br><br>Oops, looks like I am bit late on party :)<br>Unfortunate=
ly, I wasn't aware of Jens proposal. At least I was lucky to come across th=
is discussion.<br><br>"Jens already showed how to store just a bool, or a b=
it of a bitfield by masking the return value of the unwinding query functio=
n, for simple cases. "<br><br>Storing only one bit of info is enough, see h=
ttps://github.com/panaseleus/stack_unwinding/blob/master/boost/exception/un=
caught_exception_count.hpp , there is class uncaught_exception_count_latch =
built on top of uncaught_exception_count which stores exactly one bit.<br><=
br>"The problem with the integer based "stack_unwinding" method is that it =
requires direct RAII usage of some object."<br><br>But yes, it is still con=
text which should be associated with class.<br>During implementation of sta=
ck_unwinding library I was not aimed on language extension. I just was insp=
ired by Adrei Alexandrescu presentation ( http://channel9.msdn.com/Events/L=
ang-NEXT/Lang-NEXT-2012/Three-Unlikely-Successful-Features-of-D ), and I tr=
ied to implement scope(failure)/scope(success) *now*, for use with *current=
* compilers.<br>So, that explicit context is only artifact of implementatio=
n.<br><br>Of course with power of compiler implementor it is possible to av=
oid requiring explicit context. For instance syntax like - Unwinding Aware =
Destructor https://github.com/panaseleus/stack_unwinding#unwinding-aware-de=
structor , https://github.com/panaseleus/stack_unwinding/blob/master/exampl=
es/unwinding_aware_destructor.cpp .<br><br>"Also, there's another differenc=
e: you can implement the "stack_unwinding" stuff using existing compiler te=
ch (though not standard tech). `std::unwinding_exception` has to be impleme=
nted by the compiler vendor themselves; it's practically a sanctioned compi=
ler intrinsic, due to its behavior."<br><br>By the way, I remember that I t=
ried to implement "unwinding_exception"-like stuff, i.e. without explicit c=
ontext.<br>I tried to inspect registers and call stack in order to find som=
e evidence of unwinding process - I didn't get stable result, and I just fa=
llback to uncought_exception_count which I already had and which was stable=
 enough.<br>I.e. it may be possible to implement "unwinding_exception", but=
 amount of platform-specifc code/work would be much bigger than just inspec=
ting integer in memory like uncought_exception_count does.<br><br>"As ugly =
as the unwind count thing is, it does resolve this problem."<br><br>Yes, it=
 does reasonably work for nested objects (via aggregation or inheritance).<=
br>It even allow us to handle more complex examples like this:<br><br><div =
class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border=
-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wr=
ap: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint">=
<span style=3D"color: #008;" class=3D"styled-by-prettify">struct</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #606;" class=3D"styled-by-prettify">Vector</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #8=
00;" class=3D"styled-by-prettify">// (approximation of container)</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"col=
or: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; </span><span styl=
e=3D"color: #606;" class=3D"styled-by-prettify">Some</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">*</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">a</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">,*</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify">b</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; =
&nbsp; </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Vec=
tor</span><span style=3D"color: #660;" class=3D"styled-by-prettify">()</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbs=
p; &nbsp; &nbsp; </span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">:</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> a=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">new</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"col=
or: #606;" class=3D"styled-by-prettify">Some</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">()),</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> b</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">(</span><span style=3D"color: #008;" class=3D"styled-by=
-prettify">new</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Some<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">())</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; =
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">{}</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; =
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">~</span><s=
pan style=3D"color: #606;" class=3D"styled-by-prettify">Vector</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">()</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; </span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; &nbsp; &nbsp; =
</span><span style=3D"color: #008;" class=3D"styled-by-prettify">delete</sp=
an><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: #=
800;" class=3D"styled-by-prettify">// if it throws then we should propogate=
 right uncaught exception count to a's destructor.</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; &nbsp; &nbsp; </s=
pan><span style=3D"color: #800;" class=3D"styled-by-prettify">/*<br>&nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;But if we would do:<br>&nbsp; &nbsp; &nbs=
p; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;try<br>&nbsp; &nbsp; &nbsp; &nbsp; &nb=
sp; &nbsp; &nbsp; &nbsp;{<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbs=
p; &nbsp; &nbsp; &nbsp;delete b;<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbs=
p; &nbsp; &nbsp;}<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
;catch(...)<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;{<br>=
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;delete=
 a; // then at this point we *caught* exception, and reduced back uncaught =
exception count<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp;throw;<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nb=
sp;}<br>&nbsp; &nbsp; &nbsp; &nbsp; */</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"><br>&nbsp; &nbsp; &nbsp; &nbsp; </span><span st=
yle=3D"color: #800;" class=3D"styled-by-prettify">// Right solution is to u=
se:</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nb=
sp; &nbsp; &nbsp; &nbsp; scope</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">(</span><span style=3D"color: #008;" class=3D"styled-by=
-prettify">exit</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
&nbsp; &nbsp; &nbsp; &nbsp; </span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">delete</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> a</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #800;" class=3D"sty=
led-by-prettify">// scope(exit) does not change state of uncaught exception=
 count</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
&nbsp; &nbsp; &nbsp; &nbsp; </span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">};</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"><br>&nbsp; &nbsp; &nbsp; &nbsp; </span><span style=3D"color: #800=
;" class=3D"styled-by-prettify">// That solution was proposed by "Ku-ku" at=
 http://www.rsdn.ru/forum/flame.comp/4932465.1</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; &nbsp; &nbsp; </span>=
<span style=3D"color: #800;" class=3D"styled-by-prettify">// and it can be =
extended to containers of many objects</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"><br>&nbsp; &nbsp; </span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">};</span></div></code></div>________________________<b=
r>However, technique based on uncaught_exception_count can be fooled in fol=
lowing case: when object is created during stack unwinding (i.e. in some de=
structor), and that object outlived unwinding process, for instance it was =
stored in global variable ( I have special test case: https://github.com/pa=
naseleus/stack_unwinding/blob/master/examples/uncaught_exception_count_floa=
ting_object.cpp ).<br>That fact about "floating" objects should be taken in=
to account, because it could also lead to different "anti-patterns"<br><br>=
However, that issue does not affect implementation of scope(success/failure=
) features on top of uncaught_exception_count, because - their objects live=
 only in code blocks (compound-statements), and can't leave them. Even more=
, If auxiliary variables are created by small macro - then user can't even =
"spell" names of these objects. <br><br>Maybe in general case, we should co=
nsider giving ability to caller of "delete", or caller of explicit destruct=
or, ability to pass flag to destructable object indicating whether or not i=
t is "called" during stack unwinding. That is consistent with Unwinding Awa=
re Destructor - destructor accepts flag as a parameter, and when we are cal=
ling destructor explicitly, we should have ability to pass argument to it.<=
br><br>It seems logical: when "compiler" manages lifetime of object - it kn=
ows when it calls destructor during unwinding or not.<br>But when we are ma=
naging lifetime of object manually, by calling delete - there is no any unw=
inding in this scope by definition (because we reached delete operator).<br=
>And it would be nice to have ability to miminc compiler's behaviour. I.e.:=
<br><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250=
); border-color: rgb(187, 187, 187); border-style: solid; border-width: 1px=
; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subpret=
typrint"><span style=3D"color: #008;" class=3D"styled-by-prettify">class</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
 style=3D"color: #606;" class=3D"styled-by-prettify">AutoManaged</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; </span><span style=
=3D"color: #606;" class=3D"styled-by-prettify">Some</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> a</span><span style=3D"color: #66=
0;" 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"style=
d-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">=
public</span><span style=3D"color: #660;" class=3D"styled-by-prettify">:</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
 style=3D"color: #800;" class=3D"styled-by-prettify">//...</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">};</span></div></code></div>and<b=
r><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250);=
 border-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; =
word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subpretty=
print"><span style=3D"color: #008;" class=3D"styled-by-prettify">class</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span s=
tyle=3D"color: #606;" class=3D"styled-by-prettify">ManualyManaged</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"col=
or: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; </span><span styl=
e=3D"color: #606;" class=3D"styled-by-prettify">Some</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">*</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">a</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">*</=
span><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"><br></span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">public</span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">:</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> </span><span style=3D"color: #800;" class=3D"s=
tyled-by-prettify">//...</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">};</span></div></code></div>Should have ability to expose exactly s=
ame obsevable behaviour in respect to exceptions.<br><br>P.S. Herb, I sent =
to you (and Andrei) e-mail regarding stack_unwinding in February, did you g=
et it?<br><br>P.P.S. Sorry for long message, as compensation here is fully =
isolated implementation of scope(failure)/scope(success) - http://ideone.co=
m/tyb14x , it works on MSVC, GCC, Clang, Intel :)<br>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1570_2757519.1364687164407--

.

------=_Part_4655_3509981.1365435674355
Content-Type: text/plain; charset=ISO-8859-1


On Monday, March 25, 2013 12:14:54 AM UTC+1, Herb Sutter wrote:
>
> I'm not sure what the flaw is.
>
> With the current proposal as written, a destructor can ask
> unwinding_exception() and forward that result. Or if we feel we want to
> automatically propagate it to "any destructor invoked during unwinding"
> that's a pure extension.
>
> Right?
>

I have this class:

class Something {
  WantsToKnowIfItsUnwinding member;
};

The way this proposal currently works, Something doesn't need to be aware
that its member is querying unwinding state. This is a good thing.

Now I want to reduce compile time and decide to PIMPL the member out of the
header file.

class Something {
  struct Impl;
  std::unique_ptr<Impl> pimpl;
public:
  Something();
  ~Something();
};
// in cpp:
struct Something::Impl {
  WantsToKnowIfItsUnwinding member;
};
Something::Something() : pimpl(new Impl()) {}
Something::~Something() = default;

Simple enough transformation? Sorry, you just broke the code in a very
subtle and hard-to-detect way.

Now that I think about this, this is so dangerous and unintuitive that it
should be a total showstopper for this proposal as-is. You need to fix this.

Sebastian

--

---
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/?hl=en.



------=_Part_4655_3509981.1365435674355
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br>On Monday, March 25, 2013 12:14:54 AM UTC+1, Herb Sutter wrote:<blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;"><div>I'm not sure what the flaw is.</d=
iv><div>&nbsp;</div><div>With the current proposal as written, a destructor=
 can ask unwinding_exception() and forward that result. Or if we feel we wa=
nt to automatically propagate it to "any destructor invoked during unwindin=
g" that's a pure extension.</div><div>&nbsp;</div><div>Right?</div></blockq=
uote><div><br></div><div>I have this class:</div><div><br></div><div>class =
Something {</div><div>&nbsp; WantsToKnowIfItsUnwinding member;</div><div>};=
</div><div><br></div><div>The way this proposal currently works, Something =
doesn't need to be aware that its member is querying unwinding state. This =
is a good thing.</div><div><br></div><div>Now I want to reduce compile time=
 and decide to PIMPL the member out of the header file.</div><div><br></div=
><div>class Something {<br></div><div>&nbsp; struct Impl;</div><div>&nbsp; =
std::unique_ptr&lt;Impl&gt; pimpl;</div><div>public:</div><div>&nbsp; Somet=
hing();</div><div>&nbsp; ~Something();</div><div>};</div><div>// in cpp:</d=
iv><div>struct Something::Impl {</div><div>&nbsp; WantsToKnowIfItsUnwinding=
 member;</div><div>};</div><div>Something::Something() : pimpl(new Impl()) =
{}</div><div>Something::~Something() =3D default;</div><div><br></div><div>=
Simple enough transformation? Sorry, you just broke the code in a very subt=
le and hard-to-detect way.</div><div><br></div><div>Now that I think about =
this, this is so dangerous and unintuitive that it should be a total showst=
opper for this proposal as-is. You need to fix this.</div><div><br></div><d=
iv>Sebastian</div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_4655_3509981.1365435674355--

.

------=_Part_1516_26035210.1365471661855
Content-Type: text/plain; charset=KOI8-R
Content-Transfer-Encoding: quoted-printable

8 april 2013 =C7., 19:41:14 UTC+4 corn...@google.com:

> I have this class:
>
> class Something {
>   WantsToKnowIfItsUnwinding member;
> };
> The way this proposal currently works, Something doesn't need to be aware=
=20
> that its member is querying unwinding state. This is a good thing.
>

I doubt if wording of current proposal really states that.
As far as I read it - it means, that in such case, unwinding_exception()=20
will be false in "member"'s destructor under any circumstances.
That is because only "Something" can be "invoked to perform stack=20
unwinding", while "member"'s destructor is always executed as part of=20
"Something" destruction.
Fact that "Something" owns some member - is just some kind of=20
"implementation detail". Unwinding process never calls "member"'s=20
destructor directly, but it is only called as part of "Something"=20
destruction process.

Simple enough transformation? Sorry, you just broke the code in a very=20
> subtle and hard-to-detect way.
> Now that I think about this, this is so dangerous and unintuitive that it=
=20
> should be a total showstopper for this proposal as-is. You need to fix th=
is.
>

As you have noted, once we are trying to propagate unwinding info - we are=
=20
facing problem of "heap" objects, which can logicly be an aggregatee of=20
larger object - and if we have propagation of unwinding info to "normal"=20
objects, it is desirible to have ability to mimic such behaviour for "heap"=
=20
objects.
Such kind of objects ("heap"-like) are *never* destructed due to unwinding=
=20
directly - "delete obj" or "obj->~T()" are always invoked explicitly by=20
some code - and at place where it happens there is no any unwinding - it is=
=20
just normal code flow.
Propogation of "unwinding_exception" via such explicit actions, cannot be=
=20
done automaticly - it is code writer should decide which=20
"unwinding_exception" value should be "passed" to destructor, like=20
"parameter".
So, that leads us to notion of unwinding aware destructor=20
https://github.com/panaseleus/stack_unwinding#unwinding-aware-destructor :

struct Foo
{
    ~Foo(bool due_to_unwinding)
    {
        if(due_to_unwinding)
            // ...
        else
            // ...
    }
};

And once we would have such thing - we have to adjust a lot of places in=20
ISO: built-in arrays, containers, smart pointers, members, bases, etc, etc.=
=20
That would be too invasive.
Moreover, if some class relies heavily on unwinding info - it can't be=20
easily inserted to some hierarchy or composition, because "relies heavily=
=20
on unwinding info" is transitive property. Once you have inserted object of=
=20
such class into deep composition - all of classes in composition tree also=
=20
became "relies heavily on unwinding info". It is important to consider,=20
because all explicit destructions should carefully propagate unwinding info=
..

I think that main aim of this proposal is to enable implementation of=20
scope_guard like classes with ability to distinguish between=20
success/failure of expression or scope leaving. Objects of such classes=20
have automatic storage duration or are temporaries (yes, there are some use=
=20
cases for temporaries), and they typically do not have any members/bases=20
which also need to know anything about unwinding.
Even if some sub-object of such scope_guard class needs unwinding info=20
(which I think is very rare) - it can be passed explicitly from scope_guard=
=20
without problems. As the result, propagation to members/bases is not needed=
=20
to be defined, which simplifies a lot of things.

So, I think it is better to forbid any half-baked automatic propagation to=
=20
members and bases (if it is not forbided already), in order to remove=20
"subtle and hard-to-detect" cases as you said.

P.S. If unwinding info propagation is really important, then we should=20
consider uncaught_exception_count - it covers most of patterns arisen=20
during propagation, and it is very easy to define.

--=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/?hl=3Den.



------=_Part_1516_26035210.1365471661855
Content-Type: text/html; charset=KOI8-R
Content-Transfer-Encoding: quoted-printable

8 april 2013&nbsp;=C7., 19:41:14 UTC+4 corn...@google.com:<br><blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px=
 #ccc solid;padding-left: 1ex;"><div>I have this class:</div><div><br></div=
><div>class Something {</div><div>&nbsp; WantsToKnowIfItsUnwinding member;<=
/div><div>};</div><div>The way this proposal currently works, Something doe=
sn't need to be aware that its member is querying unwinding state. This is =
a good thing.</div></blockquote><div><br>I doubt if wording of current prop=
osal really states that.<br>As far as I read it - it means, that in such ca=
se, unwinding_exception() will be false in "member"'s destructor under any =
circumstances.<br>That is because only "Something" can be "invoked to perfo=
rm stack unwinding", while "member"'s destructor is always executed as part=
 of "Something" destruction.<br>Fact that "Something" owns some member - is=
 just some kind of "implementation detail". Unwinding process never calls "=
member"'s destructor directly, but it is only called as part of "Something"=
 destruction process.<br><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div>Simple enough transformation? Sorry, you just broke the code in =
a very subtle and hard-to-detect way.</div><div>Now that I think about this=
, this is so dangerous and unintuitive that it should be a total showstoppe=
r for this proposal as-is. You need to fix this.</div></blockquote><div><br=
>As you have noted, once we are trying to propagate unwinding info - we are=
 facing problem of "heap" objects, which can logicly be an aggregatee of la=
rger object - and if we have propagation of unwinding info to "normal" obje=
cts, it is desirible to have ability to mimic such behaviour for "heap" obj=
ects.<br></div><div>Such kind of objects ("heap"-like) are <b>never</b> des=
tructed due to unwinding directly - "delete obj" or "obj-&gt;~T()" are alwa=
ys invoked explicitly by some code - and at place where it happens there is=
 no any unwinding - it is just normal code flow.<br>Propogation of "unwindi=
ng_exception" via such explicit actions, cannot be done automaticly - it is=
 code writer should decide which "unwinding_exception" value should be "pas=
sed" to destructor, like "parameter".<br>So, that leads us to notion of unw=
inding aware destructor https://github.com/panaseleus/stack_unwinding#unwin=
ding-aware-destructor :<br><div class=3D"prettyprint" style=3D"background-c=
olor: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: s=
olid; border-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint=
"><div class=3D"subprettyprint"><pre><span class=3D"k"><span style=3D"color=
: #008;" class=3D"styled-by-prettify">struct</span></span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> </span><span class=3D"n"><span st=
yle=3D"color: #606;" class=3D"styled-by-prettify">Foo</span></span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span class=3D=
"p"><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span></spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbs=
p; </span><span class=3D"o"><span style=3D"color: #660;" class=3D"styled-by=
-prettify">~</span></span><span class=3D"n"><span style=3D"color: #606;" cl=
ass=3D"styled-by-prettify">Foo</span></span><span class=3D"p"><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(</span></span><span class=
=3D"kt"><span style=3D"color: #008;" class=3D"styled-by-prettify">bool</spa=
n></span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span>=
<span class=3D"n"><span style=3D"color: #000;" class=3D"styled-by-prettify"=
>due_to_unwinding</span></span><span class=3D"p"><span style=3D"color: #660=
;" class=3D"styled-by-prettify">)</span></span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"><br>&nbsp; &nbsp; </span><span class=3D"p"><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">{</span></span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; &nb=
sp; &nbsp; </span><span class=3D"k"><span style=3D"color: #008;" class=3D"s=
tyled-by-prettify">if</span></span><span class=3D"p"><span style=3D"color: =
#660;" class=3D"styled-by-prettify">(</span></span><span class=3D"n"><span =
style=3D"color: #000;" class=3D"styled-by-prettify">due_to_unwinding</span>=
</span><span class=3D"p"><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">)</span></span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"><br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; </span><span class=3D"c=
1"><span style=3D"color: #800;" class=3D"styled-by-prettify">// ...</span><=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; =
&nbsp; &nbsp; &nbsp; </span><span class=3D"k"><span style=3D"color: #008;" =
class=3D"styled-by-prettify">else</span></span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"><br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;=
 </span><span class=3D"c1"><span style=3D"color: #800;" class=3D"styled-by-=
prettify">// ...</span></span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"><br>&nbsp; &nbsp; </span><span class=3D"p"><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">}</span></span><span style=3D"color:=
 #000;" class=3D"styled-by-prettify"><br></span><span class=3D"p"><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">};</span></span></pre></di=
v></code></div>And once we would have such thing - we have to adjust a lot =
of places in ISO: built-in arrays, containers, smart pointers, members, bas=
es, etc, etc. That would be too invasive.<br>Moreover, if some class relies=
 heavily on unwinding info - it can't be easily inserted to some hierarchy =
or composition, because "relies heavily on unwinding info" is transitive pr=
operty. Once you have inserted object of such class into deep composition -=
 all of classes in composition tree also became "relies heavily on unwindin=
g info". It is important to consider, because all explicit destructions sho=
uld carefully propagate unwinding info.<br><br>I think that main aim of thi=
s proposal is to enable implementation of=20
scope_guard like classes with ability to distinguish between=20
success/failure of expression or scope leaving. Objects of such classes hav=
e automatic storage duration or are temporaries (yes, there are some use ca=
ses for temporaries), and they typically=20
do not have any members/bases which also need to know anything about unwind=
ing.<br>Even if some sub-object of such scope_guard class needs unwinding i=
nfo (which I think is very rare) - it can be passed explicitly from scope_g=
uard without problems. As the result, propagation to members/bases is not n=
eeded to be defined, which=20
simplifies a lot of things.<br><br>So, I think it is better to forbid any h=
alf-baked automatic propagation to members and bases (if it is not forbided=
 already), in order to remove "subtle and hard-to-detect" cases as you said=
..<br><br>P.S. If unwinding info propagation is really important, then we sh=
ould consider uncaught_exception_count - it covers most of patterns arisen =
during propagation, and it is very easy to define.<br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1516_26035210.1365471661855--

.

------=_Part_613_18279057.1374866256898
Content-Type: text/plain; charset=ISO-8859-1


I have an idea of another approach.

Before calling destructor on unwinding object, exception mark memory range
of that object.
After that in destructor we can test if any object is currently destroyed
by unwinding by calling function:

bool std::is_unwinding(void* p);

struct T
{
    ~T()
    {
        if(std::is_unwinding(this)) rollback();
    }
}




As we mark whole object, every subobject can test it (as its `this` pointer
fall in that range).

To propagate "unwinding" we could introduce helper class that will do it
for us

~Foo()
{
    std::unwind_help f(this);
    f.del(ptrA); //inside destructor of `ptrA` we have
`std::is_unwinding(this->ptrA) == std::is_unwinding(this)`
    f.delArray(ptrArray);
}




All this can be simple implemented by enabled linked list to exception data
(stored in active exception data and in `std::unwind_help::del` call).

struct DeleteRange
{
    DeleteRange* prev;
    void* from;
    void* to;
    bool fall_in_range(void* _this)
    {
        return _this >= from && _this < to;
    }
}



New exception and `del` call will add new element to that list (end
removing it when is done).
Function `is_unwinding` will traverse that list and test pointer if it fall
in any of ranges in that list.
Most complex thing in solution is to get correct range form pointer to base
class in `del` function.
But as `delete` have all required information, we can share them with `del`
function.

This approach have probably only one weakness. when deleting long list of
object using recursion calls with propagating "unwinding" we will get
complexity of `is_unwinding` like O(n) and stack will be bigger by `n*3*4`
bytes where `n` is length of that list.

--

---
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_613_18279057.1374866256898
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br>I have an idea of another approach.<br><br>Before calling destructor on=
 unwinding object, exception mark memory range of that object.<br>After tha=
t in destructor we can test if any object is currently destroyed by unwindi=
ng by calling function:<br><div class=3D"prettyprint" style=3D"background-c=
olor: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: s=
olid; border-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint=
"><div class=3D"subprettyprint"><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">bool</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify">is_unwindin=
g</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: #660;" class=3D"styled-by-prettify">*</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> p</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">);</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"><br><br></span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">struct</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> T<br></span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"><br>&nbsp; &nbsp; </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">~</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify">T</span><span style=3D"color: #660;" class=3D"styled-by-prettify">()<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; =
&nbsp; </span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &=
nbsp; &nbsp; &nbsp; </span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">if</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">std</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify">is_unwinding</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">this</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">))</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> rollback</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">();</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"><br>&nbsp; &nbsp; </span><span style=3D"color: #66=
0;" 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"st=
yled-by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br><br></span></div></code></div><br><br><br>As we mark whole obj=
ect, every subobject can test it (as its `this` pointer fall in that range)=
..<br><br>To propagate "unwinding" we could introduce helper class that will=
 do it for us<br><div class=3D"prettyprint" style=3D"background-color: rgb(=
250, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; bord=
er-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div cla=
ss=3D"subprettyprint"><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">~=
</span><span style=3D"color: #606;" class=3D"styled-by-prettify">Foo</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">()</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; std</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify">unwind_help f</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">this</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">);</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br>&nbsp; &nbsp; f</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">.</span><span style=3D"color: #008;" class=3D"s=
tyled-by-prettify">del</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y">ptrA</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">//inside destructor =
of `ptrA` we have `std::is_unwinding(this-&gt;ptrA) =3D=3D std::is_unwindin=
g(this)`</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><b=
r>&nbsp; &nbsp; f</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">.</span><span style=3D"color: #000;" class=3D"styled-by-prettify">de=
lArray</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify">ptrArray</spa=
n><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 style=3D"color=
: #000;" class=3D"styled-by-prettify"><br>&nbsp;<br></span></div></code></d=
iv><br><br><br>All this can be simple implemented by enabled linked list to=
 exception data (stored in active exception data and in `std::unwind_help::=
del` call).<br><div class=3D"prettyprint" style=3D"background-color: rgb(25=
0, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; border=
-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=
=3D"subprettyprint"><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">str=
uct</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #606;" class=3D"styled-by-prettify">DeleteRange</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; </span><sp=
an style=3D"color: #606;" class=3D"styled-by-prettify">DeleteRange</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">*</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> prev</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; </span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">void</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">*</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">from</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"><br>&nbsp; &nbsp; </span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">void</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">*</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> to</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; </s=
pan><span style=3D"color: #008;" class=3D"styled-by-prettify">bool</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> fall_in_range</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span s=
tyle=3D"color: #008;" class=3D"styled-by-prettify">void</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">*</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> _this</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"><br>&nbsp; &nbsp; </span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>&nbsp; &nbsp; &nbsp; &nbsp; </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">return</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> _this </span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">&gt;=3D</span><span style=3D"color:=
 #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" c=
lass=3D"styled-by-prettify">from</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">&amp;&amp;</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> _this </span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">&lt;</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> to</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp;=
 &nbsp; </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><br></span></div></cod=
e></div><br><br>New exception and `del` call will add new element to that l=
ist (end removing it when is done).<br>Function `is_unwinding` will travers=
e that list and test pointer if it fall in any of ranges in that list.<br>M=
ost complex thing in solution is to get correct range form pointer to base =
class in `del` function.<br>But as `delete` have all required information, =
we can share them with `del` function.<br><br>This approach have probably o=
nly one weakness. when deleting long list of object using recursion calls w=
ith propagating "unwinding" we will get<br>complexity of `is_unwinding` lik=
e O(n) and stack will be bigger by `n*3*4` bytes where `n` is length of tha=
t list.<br>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
&nbsp;<br />
&nbsp;<br />

------=_Part_613_18279057.1374866256898--

.

--047d7bb03d36c699d504e27236a2
Content-Type: text/plain; charset=ISO-8859-1

On 26 July 2013 22:17, <inkwizytoryankes@gmail.com> wrote:

>
> I have an idea of another approach.
>
> Before calling destructor on unwinding object, exception mark memory range
> of that object.
>

Mark how, and with what value?

--

---
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/.



--047d7bb03d36c699d504e27236a2
Content-Type: text/html; charset=ISO-8859-1

<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On 26 July 2013 22:17,  <span dir="ltr">&lt;<a href="mailto:inkwizytoryankes@gmail.com" target="_blank">inkwizytoryankes@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>I have an idea of another approach.<br><br>Before calling destructor on unwinding object, exception mark memory range of that object.<br>
</blockquote><div><br></div><div>Mark how, and with what value?<br><br></div></div><br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />
&nbsp;<br />
&nbsp;<br />

--047d7bb03d36c699d504e27236a2--

.

------=_Part_711_28090113.1374883986455
Content-Type: text/plain; charset=ISO-8859-1



On Saturday, July 27, 2013 1:07:59 AM UTC+2, Ville Voutilainen wrote:
>
>
>
>
> On 26 July 2013 22:17, <inkwizyt...@gmail.com <javascript:>> wrote:
>
>>
>> I have an idea of another approach.
>>
>> Before calling destructor on unwinding object, exception mark memory
>> range of that object.
>>
>
>
>
> Mark how, and with what value?
>
> exception data (I mean data that is used to handle exception) should have
stored `DeleteRange` object somewhere.
For object on stack we know exactly type, size and position. we simply use
it to made range [this, this + sizeof(*this)] and write it to `DeleteRange`
(pointers `from`, `to`).
This is that "mark". After that we can test for any object in destructor if
his position fall in that range. When destructor returns then next object
to unwind is marked and his destructor called.

I have small improvements to my previous proposition. To fix problem with
O(n) in `is_unwinding` we can do two approach:
a) dont use list but binary tree. all ranges dont overlap then we can esay
binary search through them to find correct answer. This will requare couple
new pointer to create that tree and lot of O(log(n)) operation to add and
remove different ranges.
b) Dont bother with testing if different objects are currently unwinding,
this will test only for most recent unwind (and `unwind_help::del` call).
This could cause that depending when we test for unwinding we could get
different result even object is still unwinding
(this will happen when we test that object form destructor called by nested
exception or form `unwind_help`).

--

---
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_711_28090113.1374883986455
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Saturday, July 27, 2013 1:07:59 AM UTC+2, Ville Voutilainen wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><br><div><b=
r><br><div>On 26 July 2013 22:17,  <span dir=3D"ltr">&lt;<a href=3D"javascr=
ipt:" target=3D"_blank" gdf-obfuscated-mailto=3D"BQDUkmJ3qq4J">inkwizyt...@=
gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><br>I have an idea of another approach.<br><=
br>Before calling destructor on unwinding object, exception mark memory ran=
ge of that object.<br>
</blockquote><br><br><br>Mark how, and with what value?<br><code><span styl=
e=3D"color:#000"><br></span></code></div></div></div></blockquote><div>exce=
ption data (I mean data that is used to handle exception) should have store=
d `DeleteRange` object somewhere.<br>For object on stack we know exactly ty=
pe, size and position. we simply use it to made range [this, this + sizeof(=
*this)] and write it to `DeleteRange` (pointers `from`, `to`).<br>This is t=
hat "mark". After that we can test for any object in destructor if his posi=
tion fall in that range. When destructor returns then next object to unwind=
 is marked and his destructor called.<br><br>I have small improvements to m=
y previous proposition. To fix problem with O(n) in `is_unwinding` we can d=
o two approach:<br>a) dont use list but binary tree. all ranges dont overla=
p then we can esay binary search through them to find correct answer. This =
will requare couple new pointer to create that tree and lot of O(log(n)) op=
eration to add and remove different ranges.<br>b) Dont bother with testing =
if different objects are currently unwinding, this will test only for most =
recent unwind (and `unwind_help::del` call).<br>This could cause that depen=
ding when we test for unwinding we could get different result even object i=
s still unwinding<br>(this will happen when we test that object form destru=
ctor called by nested exception or form `unwind_help`).<br><br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
&nbsp;<br />
&nbsp;<br />

------=_Part_711_28090113.1374883986455--

.