------=_Part_21_12446097.1378746475893
Content-Type: text/plain; charset=ISO-8859-1

Hi all,
I would like to propose an alternative to "Differentiating destructor
invocation contexts" (see
https://groups.google.com/a/isocpp.org/forum/?fromgroups#!searchin/std-proposals/destructor/std-proposals/CYXxUYYT_tE/7kiYV4gEkGEJ
).

Both mine and the quoted proposal are based on the need of people to use
destructors for things that might and should throw exceptions. Two typical
use cases are:

1. Flushing a stream at the end of full expression (as in STD IOStreams)
2. A DB connection object which rolls back transaction in case we are
unwinding the stack and commits the transaction otherwise.

In this proposal, the programmer is forced to analyze which work performed
at the end of object lifetime is resource clean-up (where not-throwing
constraint is typically acceptable) and which is a "business logic
completion" (as in the two examples above).

There would be another special member function (like copy constructor,
destructor, etc.). I do not have a good name for it, so let's call it
_COMPETE() for the moment. If your type needs to do a "business logic
completion" you declare this special member function:

class Type
{
public:
  _COMPLETE() { /*completion*/ };
  ~Type() { /* resource cleanup*/};
};

At the gentle (non-stack unwinding) end of the scope when all visible
functions are executed. First, function _COMPLETE() is called; second, the
destructor. In case of stack unwinding, _COMPLETE() is skipped as any
normal function would be. But the destructor is still bound to be executed.

This allows for _COMPLETE() to be called implicitly and throw exceptions
upon failure.

This proposal is enough to implement a DB transaction mechanism:

class Type
{
  bool completed = false;
public:
  _COMPLETE() { commit(); completed = true };
  ~Type() { if (!completed) {rollback();} };
};

It is enough to enable flushing as in std IOStreams or SOCI:

class SQL
{
  _COMPLETE() { execute(); }
  ~SQL() {cleanupResources(); }
};

It is enough to implement a "scope(failuer)" feature from D.

class ScopeFailure
{
  bool failure= true;
public:
  _COMPLETE() { failure = false };
  ~ScopeFailure() { if (failure) {callback();} };
};

the advantage I see over "unwinding and non-unwinding destructor" is that
the _COMPLETE() forces the class author to state his intent clearly: what
is a resource clean-up and what is an invisible business logic.

This is only a sketch of a proposal, but I wanted to collect people's
opinion first.

Regards,
&rzej

--

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

<div dir=3D"ltr"><div><div><div>Hi all,<br>I would like to propose an alter=
native to <span id=3D"t-t" class=3D"">"Differentiating destructor invocatio=
n contexts</span>" (see <a href=3D"https://groups.google.com/a/isocpp.org/f=
orum/?fromgroups#%21searchin/std-proposals/destructor/std-proposals/CYXxUYY=
T_tE/7kiYV4gEkGEJ" target=3D"_blank">https://groups.google.com/a/<wbr>isocp=
p.org/forum/?fromgroups#!<wbr>searchin/std-proposals/<wbr>destructor/std-pr=
oposals/<wbr>CYXxUYYT_tE/7kiYV4gEkGEJ</a>).<br><br>Both
 mine and the quoted proposal are based on the need of people to use=20
destructors for things that might and should throw exceptions. Two=20
typical use cases are:<br><br></div><div>1. Flushing a stream at the end of=
 full expression (as in STD IOStreams)<br></div><div>2. A DB connection obj=
ect which rolls back transaction in case we are unwinding the stack and com=
mits the transaction otherwise.<br><br></div><div>In this proposal, the pro=
grammer is forced to analyze which=20
work performed at the end of object lifetime is resource clean-up (where
 not-throwing constraint is typically acceptable) and which is a=20
"business logic completion" (as in the two examples above).<br><br></div><d=
iv>There
 would be another special member function (like copy constructor,=20
destructor, etc.). I do not have a good name for it, so let's call it=20
_COMPETE() for the moment. If your type needs to do a "business logic compl=
etion" you declare this special member function:<br></div><div><br><div sty=
le=3D"margin-left: 40px;">
class Type<br>{<br>public:<br>&nbsp; _COMPLETE() { /*completion*/ };<br>&nb=
sp; ~Type() { /* resource cleanup*/};<br>};<br></div></div></div></div><div=
><br></div><div>At
 the gentle (non-stack unwinding) end of the scope when all visible=20
functions are executed. First, function _COMPLETE() is called; second,=20
the destructor. In case of stack unwinding, _COMPLETE() is skipped as any n=
ormal function would be. But the destructor is still bound to be executed.<=
br><br></div><div>This allows for _COMPLETE() to be called implicitly and t=
hrow exceptions upon failure.<br><br></div><div>This proposal is enough to =
implement a DB transaction mechanism:<br><br></div><div><div style=3D"margi=
n-left: 40px;"><div><div>class Type<br>{<br></div><div>&nbsp; bool complete=
d =3D false;<br>

</div>public:<br></div>&nbsp; _COMPLETE() { commit(); completed =3D true };=
<br></div><div style=3D"margin-left: 40px;">&nbsp; ~Type() { if (!completed=
) {rollback();} };<br>};<br></div><br></div><div>It is enough to enable flu=
shing as in std IOStreams or SOCI:<br><br></div><div style=3D"margin-left: =
40px;">class SQL<br>{<br>&nbsp; _COMPLETE() { execute(); }<br></div><div st=
yle=3D"margin-left: 40px;">&nbsp; ~SQL() {cleanupResources(); }<br>

</div><div><div style=3D"margin-left: 40px;">};<br></div><br></div><div>It =
is enough to implement a "scope(failuer)" feature from D.<br></div><br><div=
 style=3D"margin-left: 40px;"><div><div>class ScopeFailure<br>{<br></div><d=
iv>&nbsp; bool failure=3D true;<br>
</div>public:<br></div>&nbsp; _COMPLETE() { failure =3D false };<br></div><=
div style=3D"margin-left: 40px;">&nbsp; ~ScopeFailure() { if (failure) {cal=
lback();} };<br>};<br></div><br>the advantage I see over "unwinding and non=
-unwinding destructor" is that the _COMPLETE() forces the class author to s=
tate his intent clearly: what is a resource clean-up and what is an invisib=
le business logic.<br><br>This is only a sketch of a proposal, but I wanted=
 to collect people's opinion first.<br><br>Regards,<br>&amp;rzej<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 />

------=_Part_21_12446097.1378746475893--

.

------=_Part_169_18325026.1378749001031
Content-Type: text/plain; charset=ISO-8859-1

This approach seems to be semantically equal to the "~S(bool)" alternative
#2 of the linked proposal. But the proposal already rejects that
alternative in favor of returning a nesting count from
uncaught_exception_count(). I didn't review all the discussion to see
whether that conclusion remained, but I suppose the proposal page has been
kept up to date.

What I'd like to see is something to encourage *safe* usage. As Sutter
says, and the linked proposal reviews, any throwing business logic inside a
destructor has to be wrapped in a bulletproof try/catch block. That still
applies to your _COMPLETE routine, but because its name looks different
from a destructor, the risk is even further hidden. There is an explicit
declaration of which part is business logic, but that separation appears to
legitimize exceptions in exactly the wrong way.

If you really don't intend _COMPLETE to execute during any unwinding, i.e.
not to construct a transaction within a destructor, then you can use
uncaught_exception as normal. Although it is what Sutter argues against, it
can work fine as long as you avoid the risk.

--

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

<div dir=3D"ltr">This approach seems to be semantically equal to the "~S(bo=
ol)" alternative #2 of the linked proposal. But the proposal already reject=
s that alternative in favor of returning a nesting count from uncaught_exce=
ption_count(). I didn't review all the discussion to see whether that concl=
usion remained, but I suppose the proposal page has been kept up to date.<b=
r><br>What I'd like to see is something to encourage <i>safe</i> usage. As =
Sutter says, and the linked proposal reviews, any throwing business logic i=
nside a destructor has to be wrapped in a bulletproof try/catch block. That=
 still applies to your _COMPLETE routine, but because its name looks differ=
ent from a destructor, the risk is even further hidden. There is an explici=
t declaration of which part is business logic, but that separation appears =
to legitimize exceptions in exactly the wrong way.<br><br>If you really don=
't intend _COMPLETE to execute during any unwinding, i.e. not to construct =
a transaction within a destructor, then you can use uncaught_exception as n=
ormal. Although it is what Sutter argues against, it can work fine as long =
as you avoid the risk.<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 />

------=_Part_169_18325026.1378749001031--

.

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

On 9 September 2013 20:50, David Krauss <potswa@gmail.com> wrote:

> This approach seems to be semantically equal to the "~S(bool)" alternative
> #2 of the linked proposal. But the proposal already rejects that
> alternative in favor of returning a nesting count from
> uncaught_exception_count(). I didn't review all the discussion to see
> whether that conclusion remained, but I suppose the proposal page has been
> kept up to date.
>
> What I'd like to see is something to encourage *safe* usage. As Sutter
> says, and the linked proposal reviews, any throwing business logic inside a
> destructor has to be wrapped in a bulletproof try/catch block. That still
> applies to your _COMPLETE routine, but because its name looks different
> from a destructor, the risk is even further hidden. There is an explicit
> declaration of which part is business logic, but that separation appears to
> legitimize exceptions in exactly the wrong way.
>
> If you really don't intend _COMPLETE to execute during any unwinding, i.e.
> not to construct a transaction within a destructor, then you can use
> uncaught_exception as normal. Although it is what Sutter argues against, it
> can work fine as long as you avoid the risk.
>
>
>
>
 I'm fairly sure the exception_count is a superior alternative. Yes, it
forces writing all branches in one function,
but it doesn't introduce the notion of having multiple destructors. See
https://github.com/panaseleus/stack_unwinding/blob/master/boost/exception/uncaught_exception_count.hpp

I plan to work with Sutter to amend
http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3614.pdf
towards the direction of supporting a count (not a bool, an integer). That
will happen earliest after
Chicago (well, perhaps starting in Chicago), since we have more pressing
issues to deal with.

--

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

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 9 September 2013 20:50, David Krauss <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:potswa@gmail.com" target=3D"_blank">potswa@gmail.com</a>&gt;</=
span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">This app=
roach seems to be semantically equal to the &quot;~S(bool)&quot; alternativ=
e #2 of the linked proposal. But the proposal already rejects that alternat=
ive in favor of returning a nesting count from uncaught_exception_count(). =
I didn&#39;t review all the discussion to see whether that conclusion remai=
ned, but I suppose the proposal page has been kept up to date.<br>
<br>What I&#39;d like to see is something to encourage <i>safe</i> usage. A=
s Sutter says, and the linked proposal reviews, any throwing business logic=
 inside a destructor has to be wrapped in a bulletproof try/catch block. Th=
at still applies to your _COMPLETE routine, but because its name looks diff=
erent from a destructor, the risk is even further hidden. There is an expli=
cit declaration of which part is business logic, but that separation appear=
s to legitimize exceptions in exactly the wrong way.<br>
<br>If you really don&#39;t intend _COMPLETE to execute during any unwindin=
g, i.e. not to construct a transaction within a destructor, then you can us=
e uncaught_exception as normal. Although it is what Sutter argues against, =
it can work fine as long as you avoid the risk.<br>
</div><div class=3D""><div class=3D"h5">

<p></p>

<br><br></div></div></blockquote><div><br></div><div>=A0I&#39;m fairly sure=
 the exception_count is a superior alternative. Yes, it forces writing all =
branches in one function,<br>but it doesn&#39;t introduce the notion of hav=
ing multiple destructors. See<br>
<a href=3D"https://github.com/panaseleus/stack_unwinding/blob/master/boost/=
exception/uncaught_exception_count.hpp">https://github.com/panaseleus/stack=
_unwinding/blob/master/boost/exception/uncaught_exception_count.hpp</a><br>
<br></div><div>I plan to work with Sutter to amend <a href=3D"http://open-s=
td.org/JTC1/SC22/WG21/docs/papers/2013/n3614.pdf">http://open-std.org/JTC1/=
SC22/WG21/docs/papers/2013/n3614.pdf</a><br></div><div>towards the directio=
n of supporting a count (not a bool, an integer). That will happen earliest=
 after<br>
</div><div>Chicago (well, perhaps starting in Chicago), since we have more =
pressing issues to deal with.<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 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 />

--001a11c227e81bfab604e5f7828f--

.

------=_Part_347_33298859.1378762257259
Content-Type: text/plain; charset=ISO-8859-1

`uncaught_exception_count()` could be problematic when object is created on
heap because it can miss unwind.
I would prefer `std::unwinding_exception()` but with small change that
require passing explicitly `this` pointer to it. This will relax some
limitation form n3614<http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3614.pdf>and will allow forwarding without changing destructor syntax.

On Monday, September 9, 2013 8:25:09 PM UTC+2, Ville Voutilainen wrote:
>
>
>
>
> On 9 September 2013 20:50, David Krauss <pot...@gmail.com <javascript:>>wrote:
>
>> This approach seems to be semantically equal to the "~S(bool)"
>> alternative #2 of the linked proposal. But the proposal already rejects
>> that alternative in favor of returning a nesting count from
>> uncaught_exception_count(). I didn't review all the discussion to see
>> whether that conclusion remained, but I suppose the proposal page has been
>> kept up to date.
>>
>> What I'd like to see is something to encourage *safe* usage. As Sutter
>> says, and the linked proposal reviews, any throwing business logic inside a
>> destructor has to be wrapped in a bulletproof try/catch block. That still
>> applies to your _COMPLETE routine, but because its name looks different
>> from a destructor, the risk is even further hidden. There is an explicit
>> declaration of which part is business logic, but that separation appears to
>> legitimize exceptions in exactly the wrong way.
>>
>> If you really don't intend _COMPLETE to execute during any unwinding,
>> i.e. not to construct a transaction within a destructor, then you can use
>> uncaught_exception as normal. Although it is what Sutter argues against, it
>> can work fine as long as you avoid the risk.
>>
>>
>>
>>
>  I'm fairly sure the exception_count is a superior alternative. Yes, it
> forces writing all branches in one function,
> but it doesn't introduce the notion of having multiple destructors. See
>
> https://github.com/panaseleus/stack_unwinding/blob/master/boost/exception/uncaught_exception_count.hpp
>
> I plan to work with Sutter to amend
> http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3614.pdf
> towards the direction of supporting a count (not a bool, an integer). That
> will happen earliest after
> Chicago (well, perhaps starting in Chicago), since we have more pressing
> issues to deal with.
>
>

--

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

<div dir=3D"ltr">`uncaught_exception_count()` could be problematic when obj=
ect is created on heap because it can miss unwind.<br>I would prefer `std::=
unwinding_exception()` but with small change that require passing explicitl=
y `this` pointer to it. This will relax some limitation form<span style=3D"=
color: rgb(0, 0, 0);"> <span style=3D"color: rgb(0, 0, 0);"><a href=3D"http=
://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3614.pdf" target=3D"_blank=
">n3614</a></span></span> and will allow forwarding without changing destru=
ctor syntax. <br><br>On Monday, September 9, 2013 8:25:09 PM UTC+2, Ville V=
outilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><br><div><br><br><div class=3D"gmail_quote">On 9 September 2013 20:50, =
David Krauss <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank=
" gdf-obfuscated-mailto=3D"8bSQab2h7SkJ">pot...@gmail.com</a>&gt;</span> wr=
ote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">This app=
roach seems to be semantically equal to the "~S(bool)" alternative #2 of th=
e linked proposal. But the proposal already rejects that alternative in fav=
or of returning a nesting count from uncaught_exception_count(). I didn't r=
eview all the discussion to see whether that conclusion remained, but I sup=
pose the proposal page has been kept up to date.<br>
<br>What I'd like to see is something to encourage <i>safe</i> usage. As Su=
tter says, and the linked proposal reviews, any throwing business logic ins=
ide a destructor has to be wrapped in a bulletproof try/catch block. That s=
till applies to your _COMPLETE routine, but because its name looks differen=
t from a destructor, the risk is even further hidden. There is an explicit =
declaration of which part is business logic, but that separation appears to=
 legitimize exceptions in exactly the wrong way.<br>
<br>If you really don't intend _COMPLETE to execute during any unwinding, i=
..e. not to construct a transaction within a destructor, then you can use un=
caught_exception as normal. Although it is what Sutter argues against, it c=
an work fine as long as you avoid the risk.<br>
</div><div><div>

<p></p>

<br><br></div></div></blockquote><div><br></div><div>&nbsp;I'm fairly sure =
the exception_count is a superior alternative. Yes, it forces writing all b=
ranches in one function,<br>but it doesn't introduce the notion of having m=
ultiple destructors. See<br>
<a href=3D"https://github.com/panaseleus/stack_unwinding/blob/master/boost/=
exception/uncaught_exception_count.hpp" target=3D"_blank">https://github.co=
m/panaseleus/<wbr>stack_unwinding/blob/master/<wbr>boost/exception/uncaught=
_<wbr>exception_count.hpp</a><br>
<br></div><div>I plan to work with Sutter to amend <a href=3D"http://open-s=
td.org/JTC1/SC22/WG21/docs/papers/2013/n3614.pdf" target=3D"_blank">http://=
open-std.org/JTC1/SC22/<wbr>WG21/docs/papers/2013/n3614.<wbr>pdf</a><br></d=
iv><div>towards the direction of supporting a count (not a bool, an integer=
). That will happen earliest after<br>
</div><div>Chicago (well, perhaps starting in Chicago), since we have more =
pressing issues to deal with.<br></div></div><br></div></div>
</blockquote></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 />

------=_Part_347_33298859.1378762257259--

.

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

On 10 September 2013 00:30, <inkwizytoryankes@gmail.com> wrote:

> `uncaught_exception_count()` could be problematic when object is created
> on heap because it can miss unwind.
> I would prefer `std::unwinding_exception()` but with small change that
> require passing explicitly `this` pointer to it. This will relax some
> limitation form n3614<http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3614.pdf>and will allow forwarding without changing destructor syntax.
>
>
I don't follow what you're saying. Can you show an example of such "missing
an unwind" and how this passing
of this is meant to 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/.

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 10 September 2013 00:30,  <span dir=3D"ltr">&lt;<a href=3D"mailt=
o:inkwizytoryankes@gmail.com" target=3D"_blank">inkwizytoryankes@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"><div dir=3D"ltr">`uncaught_exception_count()=
` could be problematic when object is created on heap because it can miss u=
nwind.<br>
I would prefer `std::unwinding_exception()` but with small change that requ=
ire passing explicitly `this` pointer to it. This will relax some limitatio=
n form<span style> <span style><a href=3D"http://open-std.org/JTC1/SC22/WG2=
1/docs/papers/2013/n3614.pdf" target=3D"_blank">n3614</a></span></span> and=
 will allow forwarding without changing destructor syntax. <br>
<br></div></blockquote><div><br></div><div>I don&#39;t follow what you&#39;=
re saying. Can you show an example of such &quot;missing an unwind&quot; an=
d how this passing<br>of this is meant to help? <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 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 />

--001a11c25b4844e8b304e5fa2b60--

.

------=_Part_656_26853271.1378765681205
Content-Type: text/plain; charset=ISO-8859-1

Small example:
struct Foo
{
    std::unique_ptr<trans>& m;
    ~Foo() { m = std::unique_ptr<trans>(new trans()); }
}

int main()
{
    try
    {
        std::unique_ptr<trans> t;
        try
        {
            Foo temp{t};
            throw 1;
            //~Foo set t with trans that have uncaught_exception_count == 1
        }
        catch(...)
        {
        }
        //uncaught_exception_count == 0
        throw 1;
        //uncaught_exception_count == 1, ~trans dont see any exception
    }
    catch(...)
    {
    }
}

This example is very exotic, but is way to prevent it?

In my version heap object simply cant track it by self. They will get that
information form exception handler. User can forward this information to
any object that are deleted.
In case `std::unique_ptr` it will require special delete function that will
do it.

On Monday, September 9, 2013 11:35:37 PM UTC+2, Ville Voutilainen wrote:
>
>
>
>
> On 10 September 2013 00:30, <inkwizyt...@gmail.com <javascript:>> wrote:
>
>> `uncaught_exception_count()` could be problematic when object is created
>> on heap because it can miss unwind.
>> I would prefer `std::unwinding_exception()` but with small change that
>> require passing explicitly `this` pointer to it. This will relax some
>> limitation form n3614<http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3614.pdf>and will allow forwarding without changing destructor syntax.
>>
>>
> I don't follow what you're saying. Can you show an example of such
> "missing an unwind" and how this passing
> of this is meant to 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_656_26853271.1378765681205
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Small example:<br><div class=3D"prettyprint" style=3D"back=
ground-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-=
style: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"pre=
ttyprint"><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"> </span><span style=3D"color: #606;" class=3D"styled-by=
-prettify">Foo</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><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; </span><code class=3D"prettyprint"><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify">std</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify">unique_ptr</span><span style=3D"color: #080;" class=3D"styled-by-=
prettify">&lt;trans&gt;</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify">&amp; m</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">;<br>&nbsp;&nbsp;&nbsp; ~Foo() { m =3D </span></code><code class=
=3D"prettyprint"><span style=3D"color: #660;" class=3D"styled-by-prettify">=
<code class=3D"prettyprint"><code class=3D"prettyprint"><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify">std</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">unique_ptr</span><span style=3D"color: #080;" class=
=3D"styled-by-prettify">&lt;trans&gt;</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify">(new trans());</span></code></code> }<br></span>=
</code><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"><br><br>int main()<=
br>{<br>&nbsp;&nbsp;&nbsp; try<br>&nbsp;&nbsp;&nbsp; {<br>&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp; std</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify">unique_ptr</span><span style=3D"color: #080;" class=3D"styled-by=
-prettify">&lt;trans&gt;</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> t</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br=
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; try<br>&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp; {<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; </span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"><code class=3D"prettyprint"><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"></span><span style=3D"color: #606;" class=3D"styled-by-pre=
ttify">Foo</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 temp{t};<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp; throw 1;<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; //~Foo set t with trans that have </span></code></span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><code class=3D"prettyprint">=
<span style=3D"color: #000;" class=3D"styled-by-prettify">uncaught_exceptio=
n_count</span></code> =3D=3D 1<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; }<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; catch(...)<br>&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; {<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp; }</span><br><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<code class=3D"prettyprint"><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><code class=3D"prettyprint"><span style=3D"color: #000;" class=
=3D"styled-by-prettify">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; //uncaug=
ht_exception_count =3D=3D 0<br></span></code></span></code>&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp; throw 1;<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp; //</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><=
code class=3D"prettyprint"><span style=3D"color: #000;" class=3D"styled-by-=
prettify"><code class=3D"prettyprint"><span style=3D"color: #000;" class=3D=
"styled-by-prettify"><code class=3D"prettyprint"><span style=3D"color: #000=
;" class=3D"styled-by-prettify">uncaught_exception_count =3D=3D 1</span></c=
ode></span></code></span></code>, ~</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"><code class=3D"prettyprint"><span style=3D"color: =
#080;" class=3D"styled-by-prettify"><span style=3D"color: rgb(0, 0, 0);">tr=
ans dont see any exception</span><br></span></code>&nbsp;&nbsp;&nbsp; }<br>=
&nbsp;&nbsp;&nbsp; catch(...)<br>&nbsp;&nbsp;&nbsp; {<br>&nbsp;&nbsp;&nbsp;=
 }<br>}<br><br></span></div></code></div>This example is very exotic, but i=
s way to prevent it?<br><br>In my version heap object simply cant track it =
by self. They will get that information form exception handler. User can fo=
rward this information to any object that are deleted.<br>In case `<code cl=
ass=3D"prettyprint"><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">unique_ptr</=
span></code>` it will require special delete function that will do it.<br><=
br>On Monday, September 9, 2013 11:35:37 PM UTC+2, Ville Voutilainen wrote:=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><br><div><br>=
<br><div class=3D"gmail_quote">On 10 September 2013 00:30,  <span dir=3D"lt=
r">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"X=
gCOk70fddsJ">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"><div dir=3D"ltr">`uncaught_exception_count()=
` could be problematic when object is created on heap because it can miss u=
nwind.<br>
I would prefer `std::unwinding_exception()` but with small change that requ=
ire passing explicitly `this` pointer to it. This will relax some limitatio=
n form<span> <span><a href=3D"http://open-std.org/JTC1/SC22/WG21/docs/paper=
s/2013/n3614.pdf" target=3D"_blank">n3614</a></span></span> and will allow =
forwarding without changing destructor syntax. <br>
<br></div></blockquote><div><br></div><div>I don't follow what you're sayin=
g. Can you show an example of such "missing an unwind" and how this passing=
<br>of this is meant to help? <br></div></div><br></div>
</div>
</blockquote></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 />

------=_Part_656_26853271.1378765681205--

.

------=_Part_2414_19502969.1378822922705
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable



On Tuesday, September 10, 2013 6:28:01 AM UTC+8, inkwizyt...@gmail.com=20
wrote:
>
> Small example:
>

If I understand this, you're saying that really there is a stack of=20
uncaught exceptions, and uncaught_exception_count only provides the size of=
=20
that stack. What the user really wants is a sense of "relative normality,"=
=20
or whether an uncaught exception was thrown since a certain point in the=20
past. If an exception was caught but another was thrown since that time,=20
then there is insufficient information in the stack size. Even worse, note=
=20
that your second throw 1; could produce *exactly the same exception object*=
as the first one which was already caught and handled in the intervening=20
time. So the entire stack would return to an identical state =97 it does no=
t=20
have sufficient information.

One solution would be to assign a serial number to each exception object,=
=20
and discriminate on that instead. But what of duplicate serial numbers?

Combining this insight with my desire for safe usage, observe that there=20
may be only one uncaught exception per try block. The transaction which=20
detects the unwinding is guarded by a try block which will receive the=20
exception that caused unwinding. It would be an error to have such a=20
transaction without a try block!

So I propose an uncaught_exception_ticket_t whose value allows you to=20
detect an uncaught exception from the surrounding try block. It's obtained=
=20
from uncaught_exception_ticket(), but calling this outside a try context is=
=20
an error and throws a diagnostic exception. The value would typically be=20
stored inside the transaction object, likely by its constructor. Once the=
=20
try block exits, the ticket expires and querying on it would be UB. In=20
normal usage (even your example), this cannot happen by accident. You would=
=20
really have to misplace the ticket.

As for the form of the query, I can think of two alternatives. Don't have=
=20
time to think through the choice right now, but they are:

   1. You pass the ticket to bool uncaught_exception(
   uncaught_exception_ticket_t) which tells you whether stack unwinding is=
=20
   proceeding directly up to the scope of the try block wherein the ticket =
was=20
   issued.
   2. You pass the ticket to bool uncaught_exception_since(
   uncaught_exception_ticket_t) which tells you whether there is a current=
=20
   uncaught exception initiated since the given ticket was issued.
  =20
I prefer #1, which is more restrictive and seems to more purely refine the=
=20
existing concept, but #2 is more general. And for completeness, there could=
=20
even be a meaningful exception_ptr get_uncaught_exception(
uncaught_exception_ticket_t) function! (Perhaps. It's bedtime but this=20
seems conceptually sound for now.)


Also=85 It looks like Sutter's unwinding_exception proposal is semantically=
=20
the same as passing a Boolean argument to the destructor. It's effectively=
=20
an anonymous parameter. Since it can only be called from the destructor=20
body, what's the point of passing it this? It seems to be a core language=
=20
feature misplaced in the library.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

------=_Part_2414_19502969.1378822922705
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Tuesday, September 10, 2013 6:28:01 AM UTC+8, i=
nkwizyt...@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr">Small example:<br></div></blockquote><div><br>If I understand=
 this, you're saying that really there is a stack of uncaught exceptions, a=
nd <span style=3D"font-family: courier new,monospace;">uncaught_exception_c=
ount</span> only provides the size of that stack. What the user really want=
s is a sense of "relative normality," or whether an uncaught exception was =
thrown since a certain point in the past. If an exception was caught but an=
other was thrown since that time, then there is insufficient information in=
 the stack size. Even worse, note that your second <span style=3D"font-fami=
ly: courier new,monospace;">throw 1;</span> could produce <i>exactly the sa=
me exception object</i> as the first one which was already caught and handl=
ed in the intervening time. So the entire stack would return to an identica=
l state =97 it does not have sufficient information.<br><br>One solution wo=
uld be to assign a serial number to each exception object, and discriminate=
 on that instead. But what of duplicate serial numbers?<br><br>Combining th=
is insight with my desire for safe usage, observe that there may be only on=
e uncaught exception per try block. The transaction which detects the unwin=
ding is guarded by a try block which will receive the exception that caused=
 unwinding. It would be an error to have such a transaction without a try b=
lock!<br><br>So I propose an <span style=3D"font-family: courier new,monosp=
ace;">uncaught_exception_ticket_t</span> whose value allows you to detect a=
n uncaught exception from the surrounding <span style=3D"font-family: couri=
er new,monospace;">try</span> block. It's obtained from <span style=3D"font=
-family: courier new,monospace;">uncaught_exception_ticket()</span>, but ca=
lling this outside a <span style=3D"font-family: courier new,monospace;">tr=
y</span> context is an error and throws a diagnostic exception. The value w=
ould typically be stored inside the transaction object, likely by its const=
ructor. Once the <span style=3D"font-family: courier new,monospace;">try</s=
pan> block exits, the ticket expires and querying on it would be UB. In nor=
mal usage (even your example), this cannot happen by accident. You would re=
ally have to misplace the ticket.<br><br>As for the form of the query, I ca=
n think of two alternatives. Don't have time to think through the choice ri=
ght now, but they are:<br><ol><li>You pass the ticket to <span style=3D"fon=
t-family: courier new,monospace;">bool uncaught_exception(</span><span styl=
e=3D"font-family: courier new,monospace;"><span style=3D"font-family: couri=
er new,monospace;">uncaught_exception_ticket_t</span>)</span> which tells y=
ou whether stack unwinding is proceeding directly up to the scope of the tr=
y block wherein the ticket was issued.</li><li>You pass the ticket to <span=
 style=3D"font-family: courier new,monospace;">bool uncaught_exception_sinc=
e(</span><span style=3D"font-family: courier new,monospace;"><span style=3D=
"font-family: courier new,monospace;">uncaught_exception_ticket_t</span>)</=
span> which tells you whether there is a current uncaught exception initiat=
ed since the given ticket was issued.<br></li></ol>I prefer #1, which is mo=
re restrictive and seems to more purely refine the existing concept, but #2=
 is more general. And for completeness, there could even be a meaningful <s=
pan style=3D"font-family: courier new,monospace;">exception_ptr get_uncaugh=
t_exception(</span><span style=3D"font-family: courier new,monospace;"><spa=
n style=3D"font-family: courier new,monospace;">uncaught_exception_ticket_t=
</span>)</span> function! (Perhaps. It's bedtime but this seems conceptuall=
y sound for now.)<br><br><br>Also=85 It looks like Sutter's <span style=3D"=
font-family: courier new,monospace;">unwinding_exception</span>
 proposal is semantically the same as passing a Boolean argument to the=20
destructor. It's effectively an anonymous parameter. Since it can only=20
be called from the destructor body, what's the point of passing it <span st=
yle=3D"font-family: courier new,monospace;">this</span>? It seems to be a c=
ore language feature misplaced in the library.<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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_2414_19502969.1378822922705--

.

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

On 10 September 2013 17:22, David Krauss <potswa@gmail.com> wrote:

>
>
> On Tuesday, September 10, 2013 6:28:01 AM UTC+8, inkwizyt...@gmail.comwrote:
>>
>> Small example:
>>
>
> If I understand this, you're saying that really there is a stack of
> uncaught exceptions, and uncaught_exception_count only provides the size
> of that stack. What the user really wants is a sense of "relative
> normality," or whether an uncaught exception was thrown since a certain
> point in the past. If an exception was caught but another was thrown since
> that time, then there is insufficient information in the stack size. Even
> worse, note that your second throw 1; could produce *exactly the same
> exception *
>

I'm not convinced that is the case. Getting the count on construction and
comparing the count at destruction to that
count seems to cover all the reasonable cases I can come up with. Using
just a bool doesn't, because when unwinding
is ongoing, objects can be created and destroyed without new exceptions
being raised, but the bool would indicate
that unwinding is ongoing even though it isn't.


> One solution would be to assign a serial number to each exception object,
> and discriminate on that instead. But what of duplicate serial numbers?
>

Well, I would love to see a practical use case for it. The count is
existing practice, it has been implemented on
multiple compilers using intrinsics. If I read Evgeny Panasyuk's code
correctly, it works on clang, gcc and msvc.

--

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

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

<div dir=3D"ltr"><div><div class=3D"gmail_extra"><br><div class=3D"gmail_qu=
ote">On 10 September 2013 17:22, David Krauss <span dir=3D"ltr">&lt;<a href=
=3D"mailto:potswa@gmail.com" target=3D"_blank">potswa@gmail.com</a>&gt;</sp=
an> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><br><br>=
On Tuesday, September 10, 2013 6:28:01 AM UTC+8, <a href=3D"mailto:inkwizyt=
....@gmail.com" target=3D"_blank">inkwizyt...@gmail.com</a> wrote:<blockquot=
e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px s=
olid rgb(204,204,204);padding-left:1ex">
<div dir=3D"ltr">Small example:<br></div></blockquote><div><br>If I underst=
and this, you&#39;re saying that really there is a stack of uncaught except=
ions, and <span style=3D"font-family:courier new,monospace">uncaught_except=
ion_count</span> only provides the size of that stack. What the user really=
 wants is a sense of &quot;relative normality,&quot; or whether an uncaught=
 exception was thrown since a certain point in the past. If an exception wa=
s caught but another was thrown since that time, then there is insufficient=
 information in the stack size. Even worse, note that your second <span sty=
le=3D"font-family:courier new,monospace">throw 1;</span> could produce <i>e=
xactly the same exception </i></div>
</div></blockquote><div><br></div><div>I&#39;m not convinced that is the ca=
se. Getting the count on construction and comparing the count at destructio=
n to that<br>count seems to cover all the reasonable cases I can come up wi=
th. Using just a bool doesn&#39;t, because when unwinding<br>
</div><div>is ongoing, objects can be created and destroyed without new exc=
eptions being raised, but the bool would indicate<br>that unwinding is ongo=
ing even though it isn&#39;t. <br>=A0</div><blockquote class=3D"gmail_quote=
" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);=
padding-left:1ex">
<div dir=3D"ltr"><div>One solution would be to assign a serial number to ea=
ch exception object, and discriminate on that instead. But what of duplicat=
e serial numbers?<br></div></div></blockquote><div><br></div><div>Well, I w=
ould love to see a practical use case for it. The count is existing practic=
e, it has been implemented on<br>
multiple compilers using intrinsics. If I read Evgeny Panasyuk&#39;s code c=
orrectly, it works on clang, gcc and msvc.<br><br></div></div></div></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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--047d7b5d571003d94c04e60a1339--

.

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

On Tue, Sep 10, 2013 at 9:34 AM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

>
> On 10 September 2013 17:22, David Krauss <potswa@gmail.com> wrote:
>
>>
>>
>> On Tuesday, September 10, 2013 6:28:01 AM UTC+8, inkwizyt...@gmail.comwrote:
>>>
>>> Small example:
>>>
>>
>> If I understand this, you're saying that really there is a stack of
>> uncaught exceptions, and uncaught_exception_count only provides the size
>> of that stack. What the user really wants is a sense of "relative
>> normality," or whether an uncaught exception was thrown since a certain
>> point in the past. If an exception was caught but another was thrown since
>> that time, then there is insufficient information in the stack size. Even
>> worse, note that your second throw 1; could produce *exactly the same
>> exception *
>>
>
> I'm not convinced that is the case. Getting the count on construction and
> comparing the count at destruction to that
> count seems to cover all the reasonable cases I can come up with. Using
> just a bool doesn't, because when unwinding
> is ongoing, objects can be created and destroyed without new exceptions
> being raised, but the bool would indicate
> that unwinding is ongoing even though it isn't.
>

Things seem to go wrong if your transactions' lifetimes aren't strictly
tied to stack variables. For instance, if your transaction is destroyed in
a stack variable's destructor, but might be created during unwinding:

struct DoSomethingOnDestruction {
  std::optional<transaction> &thing;
  ~DoSomethingOnDestruction() {
    thing.emplace(my_transaction_args);
  }
};

void f() {
  std::optional<transaction> my_trans;
  try {
    DoSomethingOnDestruction dsod{my_trans};
    throw 42; // dsod destroyed, transaction created with unwind count of 1.
  } catch (...) {
    // ok, still have my transaction.
    if (cleanup fails)
      throw 76; // oops, my_trans and contained transaction destroyed with
unwind count of 1. does not roll back!
    if (could not recover)
      throw; // oops, does not roll back!
  }
}

Some might argue that this code is simply not reasonable (it's certainly
contrived). But I can imagine real-world situations that would reduce to
this (suppose dsod incrementally builds a transaction, and creates it when
it first has something to add to it, and wants to add something to the
transaction from its destructor).

Note that this example is also problematic if we want to use a special
destructor: optional<T>'s special destructor would need to know to call T's
special destructor, or we would still fail to roll back on an uncaught
exception in the above example. (And likewise for every other container
type -- we would need to essentially double the number of destructors we
create, or pass a flag through everywhere, to support transactions in
containers.)


> One solution would be to assign a serial number to each exception object,
>> and discriminate on that instead. But what of duplicate serial numbers?
>>
>
> Well, I would love to see a practical use case for it. The count is
> existing practice, it has been implemented on
> multiple compilers using intrinsics. If I read Evgeny Panasyuk's code
> correctly, it works on clang, gcc and msvc.
>

Note that the rethrow above would still fail to perform a transaction
rollback with this approach.

--

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

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

<div dir=3D"ltr">On Tue, Sep 10, 2013 at 9:34 AM, Ville Voutilainen <span d=
ir=3D"ltr">&lt;<a href=3D"mailto:ville.voutilainen@gmail.com" target=3D"_bl=
ank">ville.voutilainen@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gma=
il_extra">
<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204=
);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div><div clas=
s=3D"gmail_extra">
<br><div class=3D"gmail_quote"><div class=3D"im">On 10 September 2013 17:22=
, David Krauss <span dir=3D"ltr">&lt;<a href=3D"mailto:potswa@gmail.com" ta=
rget=3D"_blank">potswa@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);p=
adding-left:1ex"><div dir=3D"ltr"><br><br>On Tuesday, September 10, 2013 6:=
28:01 AM UTC+8, <a href=3D"mailto:inkwizyt...@gmail.com" target=3D"_blank">=
inkwizyt...@gmail.com</a> wrote:<blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;bord=
er-left-color:rgb(204,204,204);padding-left:1ex">

<div dir=3D"ltr">Small example:<br></div></blockquote><div><br>If I underst=
and this, you&#39;re saying that really there is a stack of uncaught except=
ions, and <span style=3D"font-family:&#39;courier new&#39;,monospace">uncau=
ght_exception_count</span> only provides the size of that stack. What the u=
ser really wants is a sense of &quot;relative normality,&quot; or whether a=
n uncaught exception was thrown since a certain point in the past. If an ex=
ception was caught but another was thrown since that time, then there is in=
sufficient information in the stack size. Even worse, note that your second=
 <span style=3D"font-family:&#39;courier new&#39;,monospace">throw 1;</span=
> could produce <i>exactly the same exception </i></div>

</div></blockquote><div><br></div></div><div>I&#39;m not convinced that is =
the case. Getting the count on construction and comparing the count at dest=
ruction to that<br>count seems to cover all the reasonable cases I can come=
 up with. Using just a bool doesn&#39;t, because when unwinding<br>

</div><div>is ongoing, objects can be created and destroyed without new exc=
eptions being raised, but the bool would indicate<br>that unwinding is ongo=
ing even though it isn&#39;t. </div></div></div></div></div></blockquote>
<div><br></div><div>Things seem to go wrong if your transactions&#39; lifet=
imes aren&#39;t strictly tied to stack variables. For instance, if your tra=
nsaction is destroyed in a stack variable&#39;s destructor, but might be cr=
eated during unwinding:</div>
<div><br></div><div>struct DoSomethingOnDestruction {<br></div><div>=A0 std=
::optional&lt;transaction&gt; &amp;thing;</div><div>=A0 ~DoSomethingOnDestr=
uction() {</div><div>=A0 =A0 thing.emplace(my_transaction_args);</div><div>=
=A0 }</div>
<div>};</div><div><br></div><div>void f() {</div><div>=A0 std::optional&lt;=
transaction&gt; my_trans;</div><div>=A0 try {</div><div>=A0 =A0 DoSomething=
OnDestruction dsod{my_trans};<br></div><div>=A0 =A0 throw 42; // dsod destr=
oyed, transaction created with unwind count of 1.</div>
<div>=A0 } catch (...) {</div><div>=A0 =A0 // ok, still have my transaction=
..</div><div>=A0 =A0 if (cleanup fails)</div><div>=A0 =A0 =A0 throw 76; // o=
ops, my_trans and contained transaction destroyed with unwind count of 1. d=
oes not roll back!<br>
</div><div>=A0 =A0 if (could not recover)</div><div>=A0 =A0 =A0 throw; // o=
ops, does not roll back!</div><div>=A0 }</div><div>}</div><div><br></div><d=
iv>Some might argue that this code is simply not reasonable (it&#39;s certa=
inly contrived). But I can imagine real-world situations that would reduce =
to this (suppose dsod incrementally builds a transaction, and creates it wh=
en it first has something to add to it, and wants to add something to the t=
ransaction from its destructor).</div>
<div><br></div><div>Note that this example is also problematic if we want t=
o use a special destructor: optional&lt;T&gt;&#39;s special destructor woul=
d need to know to call T&#39;s special destructor, or we would still fail t=
o roll back on an uncaught exception in the above example. (And likewise fo=
r every other container type -- we would need to essentially double the num=
ber of destructors we create, or pass a flag through everywhere, to support=
 transactions in containers.)</div>
<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left=
-style:solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">=
<div class=3D"gmail_quote">
<div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:=
rgb(204,204,204);padding-left:1ex">
<div dir=3D"ltr"><div>One solution would be to assign a serial number to ea=
ch exception object, and discriminate on that instead. But what of duplicat=
e serial numbers?<br></div></div></blockquote><div><br></div></div><div>
Well, I would love to see a practical use case for it. The count is existin=
g practice, it has been implemented on<br>
multiple compilers using intrinsics. If I read Evgeny Panasyuk&#39;s code c=
orrectly, it works on clang, gcc and msvc.</div></div></div></div></blockqu=
ote><div><br></div><div>Note that the rethrow above would still fail to per=
form a transaction rollback with this approach.</div>
</div></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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--20cf3071c8c2f5c55904e60b1ab5--

.

------=_Part_380_32358696.1378837978971
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

passing `this` is special case, in general you can pass any pointer to it.=
=20
This will allow calling this function outside destructor body and even from=
=20
static functions e.g. destructor call static function `unregister_object(T*=
=20
ptr)` that can call `unwinding_exception(ptr)` to test why object is=20
unregistering.

I dont think that adding `uncaught_exception_ticket_t` is correct solution,=
=20
this will require store it somewhere and it will be bigger than 1byte=20
(probably 8bytes).

In my solution that will be no space overhead (all required data will be=20
initialized by exception handler). Additional point of creation of object=
=20
is irrelevant for it, only context of destruction will be relevant.
This will fix another similar problem with threads that can have separate=
=20
expeditions handlers (therefore different `uncaught_exception` count).

On Tuesday, September 10, 2013 4:22:02 PM UTC+2, David Krauss wrote:
>
>
>
> On Tuesday, September 10, 2013 6:28:01 AM UTC+8, inkwizyt...@gmail.comwro=
te:
>>
>> Small example:
>>
>
> If I understand this, you're saying that really there is a stack of=20
> uncaught exceptions, and uncaught_exception_count only provides the size=
=20
> of that stack. What the user really wants is a sense of "relative=20
> normality," or whether an uncaught exception was thrown since a certain=
=20
> point in the past. If an exception was caught but another was thrown sinc=
e=20
> that time, then there is insufficient information in the stack size. Even=
=20
> worse, note that your second throw 1; could produce *exactly the same=20
> exception object* as the first one which was already caught and handled=
=20
> in the intervening time. So the entire stack would return to an identical=
=20
> state =97 it does not have sufficient information.
>
> One solution would be to assign a serial number to each exception object,=
=20
> and discriminate on that instead. But what of duplicate serial numbers?
>
> Combining this insight with my desire for safe usage, observe that there=
=20
> may be only one uncaught exception per try block. The transaction which=
=20
> detects the unwinding is guarded by a try block which will receive the=20
> exception that caused unwinding. It would be an error to have such a=20
> transaction without a try block!
>
> So I propose an uncaught_exception_ticket_t whose value allows you to=20
> detect an uncaught exception from the surrounding try block. It's=20
> obtained from uncaught_exception_ticket(), but calling this outside a try=
context is an error and throws a diagnostic exception. The value would=20
> typically be stored inside the transaction object, likely by its=20
> constructor. Once the try block exits, the ticket expires and querying on=
=20
> it would be UB. In normal usage (even your example), this cannot happen b=
y=20
> accident. You would really have to misplace the ticket.
>
> As for the form of the query, I can think of two alternatives. Don't have=
=20
> time to think through the choice right now, but they are:
>
>    1. You pass the ticket to bool uncaught_exception(
>    uncaught_exception_ticket_t) which tells you whether stack unwinding=
=20
>    is proceeding directly up to the scope of the try block wherein the ti=
cket=20
>    was issued.
>    2. You pass the ticket to bool uncaught_exception_since(
>    uncaught_exception_ticket_t) which tells you whether there is a=20
>    current uncaught exception initiated since the given ticket was issued=
..
>   =20
> I prefer #1, which is more restrictive and seems to more purely refine th=
e=20
> existing concept, but #2 is more general. And for completeness, there cou=
ld=20
> even be a meaningful exception_ptr get_uncaught_exception(
> uncaught_exception_ticket_t) function! (Perhaps. It's bedtime but this=20
> seems conceptually sound for now.)
>
>
> Also=85 It looks like Sutter's unwinding_exception proposal is semantical=
ly=20
> the same as passing a Boolean argument to the destructor. It's effectivel=
y=20
> an anonymous parameter. Since it can only be called from the destructor=
=20
> body, what's the point of passing it this? It seems to be a core language=
=20
> feature misplaced in the library.
>

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

------=_Part_380_32358696.1378837978971
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">passing `this` is special case, in general you can pass an=
y pointer to it. This will allow calling this function outside destructor b=
ody and even from static functions e.g. destructor call static function `un=
register_object(T* ptr)` that can call  <span style=3D"font-family:courier =
new,monospace">`unwinding_exception(ptr)`<span style=3D"font-family: arial,=
sans-serif;"> to test why object <font size=3D"2">is </font></span></span>u=
nregistering<span style=3D"font-family: arial,sans-serif;"><font size=3D"2"=
>.</font><br><br>I dont think that adding `</span><span style=3D"font-famil=
y: arial,sans-serif;"><span style=3D"font-family:courier new,monospace"><sp=
an style=3D"font-family:courier new,monospace">uncaught_<wbr>exception_tick=
et_t</span></span>` is correct solution, this will require store it somewhe=
re and it will be bigger than 1byte (probably 8bytes</span><span style=3D"f=
ont-family: arial,sans-serif;">).<br><br>In my solution that will be no spa=
ce overhead (all required data will be initialized by exception handler)</s=
pan>. Additional point of creation of object is irrelevant for it, only con=
text of destruction will be relevant.<br>This will fix another similar prob=
lem with threads that can have separate expeditions handlers (therefore dif=
ferent <span style=3D"font-family:courier new,monospace">`uncaught_exceptio=
n`</span> count).<br><br>On Tuesday, September 10, 2013 4:22:02 PM UTC+2, D=
avid Krauss wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr"><br><br>On Tuesday, September 10, 2013 6:28:01 AM UTC+8, <a>inkwizyt..=
..@gmail.com</a> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;m=
argin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"l=
tr">Small example:<br></div></blockquote><div><br>If I understand this, you=
're saying that really there is a stack of uncaught exceptions, and <span s=
tyle=3D"font-family:courier new,monospace">uncaught_exception_count</span> =
only provides the size of that stack. What the user really wants is a sense=
 of "relative normality," or whether an uncaught exception was thrown since=
 a certain point in the past. If an exception was caught but another was th=
rown since that time, then there is insufficient information in the stack s=
ize. Even worse, note that your second <span style=3D"font-family:courier n=
ew,monospace">throw 1;</span> could produce <i>exactly the same exception o=
bject</i> as the first one which was already caught and handled in the inte=
rvening time. So the entire stack would return to an identical state =97 it=
 does not have sufficient information.<br><br>One solution would be to assi=
gn a serial number to each exception object, and discriminate on that inste=
ad. But what of duplicate serial numbers?<br><br>Combining this insight wit=
h my desire for safe usage, observe that there may be only one uncaught exc=
eption per try block. The transaction which detects the unwinding is guarde=
d by a try block which will receive the exception that caused unwinding. It=
 would be an error to have such a transaction without a try block!<br><br>S=
o I propose an <span style=3D"font-family:courier new,monospace">uncaught_e=
xception_ticket_t</span> whose value allows you to detect an uncaught excep=
tion from the surrounding <span style=3D"font-family:courier new,monospace"=
>try</span> block. It's obtained from <span style=3D"font-family:courier ne=
w,monospace">uncaught_exception_ticket()</span>, but calling this outside a=
 <span style=3D"font-family:courier new,monospace">try</span> context is an=
 error and throws a diagnostic exception. The value would typically be stor=
ed inside the transaction object, likely by its constructor. Once the <span=
 style=3D"font-family:courier new,monospace">try</span> block exits, the ti=
cket expires and querying on it would be UB. In normal usage (even your exa=
mple), this cannot happen by accident. You would really have to misplace th=
e ticket.<br><br>As for the form of the query, I can think of two alternati=
ves. Don't have time to think through the choice right now, but they are:<b=
r><ol><li>You pass the ticket to <span style=3D"font-family:courier new,mon=
ospace">bool uncaught_exception(</span><span style=3D"font-family:courier n=
ew,monospace"><span style=3D"font-family:courier new,monospace">uncaught_<w=
br>exception_ticket_t</span>)</span> which tells you whether stack unwindin=
g is proceeding directly up to the scope of the try block wherein the ticke=
t was issued.</li><li>You pass the ticket to <span style=3D"font-family:cou=
rier new,monospace">bool uncaught_exception_since(</span><span style=3D"fon=
t-family:courier new,monospace"><span style=3D"font-family:courier new,mono=
space">uncau<wbr>ght_exception_ticket_t</span>)</span> which tells you whet=
her there is a current uncaught exception initiated since the given ticket =
was issued.<br></li></ol>I prefer #1, which is more restrictive and seems t=
o more purely refine the existing concept, but #2 is more general. And for =
completeness, there could even be a meaningful <span style=3D"font-family:c=
ourier new,monospace">exception_ptr get_uncaught_exception(</span><span sty=
le=3D"font-family:courier new,monospace"><span style=3D"font-family:courier=
 new,monospace">uncaugh<wbr>t_exception_ticket_t</span>)</span> function! (=
Perhaps. It's bedtime but this seems conceptually sound for now.)<br><br><b=
r>Also=85 It looks like Sutter's <span style=3D"font-family:courier new,mon=
ospace">unwinding_exception</span>
 proposal is semantically the same as passing a Boolean argument to the=20
destructor. It's effectively an anonymous parameter. Since it can only=20
be called from the destructor body, what's the point of passing it <span st=
yle=3D"font-family:courier new,monospace">this</span>? It seems to be a cor=
e language feature misplaced in the library.<br></div></div></blockquote></=
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 />

------=_Part_380_32358696.1378837978971--

.

------=_Part_12_20776453.1378860701797
Content-Type: text/plain; charset=ISO-8859-1



On Wednesday, September 11, 2013 2:32:58 AM UTC+8, inkwizyt...@gmail.com
wrote:
>
> passing `this` is special case, in general you can pass any pointer to it.
> This will allow calling this function outside destructor body and even from
> static functions e.g. destructor call static function `unregister_object(T*
> ptr)` that can call `unwinding_exception(ptr)` to test why object is
> unregistering.
>

How does the pointer map to the Boolean value? Is the implementation
required to store a list of objects undergoing destruction? But you said
other pointers are also valid queries.


> I dont think that adding `uncaught_exception_ticket_t` is correct
> solution, this will require store it somewhere and it will be bigger than
> 1byte (probably 8bytes).
>

Yes. The uncaught_exception_count is also state, requiring storage. In
principle, I think the user is trying to compare the execution state at two
points in time, and the best approach must sample that state somehow.


> In my solution that will be no space overhead (all required data will be
> initialized by exception handler). Additional point of creation of object
> is irrelevant for it, only context of destruction will be relevant.
> This will fix another similar problem with threads that can have separate
> expeditions handlers (therefore different `uncaught_exception` count).
>

Good point! A transaction should certainly be able to retire on a different
thread. To get a different count, you'd have to 1. initiate the transaction
during unwind and then persist it, or 2. terminate an already-persisted
transaction during unwind. The first case could represent an error logging
operation initiated by unwind. The second case would be a transaction
terminating a dependent transaction.

But, the ability to persist transactions across scope contexts suggests
asynchronous I/O which would defer failure conditions, and result in
non-throwing destructors anyway. As for my proposal, I threw away
persistence by expiring the ticket after its exception-handling scope. All
this would be UB.

--

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

<div dir=3D"ltr"><br><br>On Wednesday, September 11, 2013 2:32:58 AM UTC+8,=
 inkwizyt...@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><=
div dir=3D"ltr">passing `this` is special case, in general you can pass any=
 pointer to it. This will allow calling this function outside destructor bo=
dy and even from static functions e.g. destructor call static function `unr=
egister_object(T* ptr)` that can call  <span style=3D"font-family:courier n=
ew,monospace">`unwinding_exception(ptr)`<span style=3D"font-family:arial,sa=
ns-serif"> to test why object <font size=3D"2">is </font></span></span>unre=
gistering<span style=3D"font-family:arial,sans-serif"><font size=3D"2">.</f=
ont><br></span></div></blockquote><div><br>How does the pointer map to the =
Boolean value? Is the implementation required to store a list of objects un=
dergoing destruction? But you said other pointers are also valid queries.<b=
r>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
><span style=3D"font-family:arial,sans-serif">I dont think that adding `</s=
pan><span style=3D"font-family:arial,sans-serif"><span style=3D"font-family=
:courier new,monospace"><span style=3D"font-family:courier new,monospace">u=
ncaught_exception_ticket_t</span></span>` is correct solution, this will re=
quire store it somewhere and it will be bigger than 1byte (probably 8bytes<=
/span><span style=3D"font-family:arial,sans-serif">).<br></span></div></blo=
ckquote><div><br>Yes. The <span style=3D"font-family: courier new,monospace=
;">uncaught_exception_count</span> is also state, requiring storage. In pri=
nciple, I think the user is trying to compare the execution state at two po=
ints in time, and the best approach must sample that state somehow.<br>&nbs=
p;</div><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"><span=
 style=3D"font-family:arial,sans-serif">In my solution that will be no spac=
e overhead (all required data will be initialized by exception handler)</sp=
an>. Additional point of creation of object is irrelevant for it, only cont=
ext of destruction will be relevant.<br>This will fix another similar probl=
em with threads that can have separate expeditions handlers (therefore diff=
erent <span style=3D"font-family:courier new,monospace">`uncaught_exception=
`</span> count).<br></div></blockquote><div><br>Good point! A transaction s=
hould certainly be able to retire on a different thread. To get a different=
 count, you'd have to 1. initiate the transaction during unwind and then pe=
rsist it, or 2. terminate an already-persisted transaction during unwind. T=
he first case could represent an error logging operation initiated by unwin=
d. The second case would be a transaction terminating a dependent transacti=
on.<br><br>But, the ability to persist transactions across scope contexts s=
uggests asynchronous I/O which would defer failure conditions, and result i=
n non-throwing destructors anyway. As for my proposal, I threw away persist=
ence by expiring the ticket after its exception-handling scope. All this wo=
uld be UB.<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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_12_20776453.1378860701797--

.

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

On 10 September 2013 20:47, Richard Smith <richard@metafoo.co.uk> wrote:


> Things seem to go wrong if your transactions' lifetimes aren't strictly
> tied to stack variables. For instance, if your transaction is destroyed in
> a stack variable's destructor, but might be created during unwinding:
>
> struct DoSomethingOnDestruction {
>   std::optional<transaction> &thing;
>   ~DoSomethingOnDestruction() {
>     thing.emplace(my_transaction_args);
>   }
> };
>
> void f() {
>   std::optional<transaction> my_trans;
>   try {
>     DoSomethingOnDestruction dsod{my_trans};
>     throw 42; // dsod destroyed, transaction created with unwind count of
> 1.
>   } catch (...) {
>     // ok, still have my transaction.
>     if (cleanup fails)
>       throw 76; // oops, my_trans and contained transaction destroyed with
> unwind count of 1. does not roll back!
>     if (could not recover)
>       throw; // oops, does not roll back!
>   }
> }
>
> Some might argue that this code is simply not reasonable (it's certainly
> contrived). But I can imagine real-world situations that would reduce to
> this (suppose dsod incrementally builds a transaction, and creates it when
> it first has something to add to it, and wants to add something to the
> transaction from its destructor).
>


Does dsod want to add that something to the transaction even if unwinding
is ongoing, or should
dsod be aware of unwinding?

--

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

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 10 September 2013 20:47, Richard Smith <span dir=3D"ltr">&lt;<a =
href=3D"mailto:richard@metafoo.co.uk" target=3D"_blank">richard@metafoo.co.=
uk</a>&gt;</span> wrote:<br>
<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D=
"gmail_extra"><div class=3D"gmail_quote"><div class=3D"im"><div></div></div=
><div>Things seem to go wrong if your transactions&#39; lifetimes aren&#39;=
t strictly tied to stack variables. For instance, if your transaction is de=
stroyed in a stack variable&#39;s destructor, but might be created during u=
nwinding:</div>

<div><br></div><div>struct DoSomethingOnDestruction {<br></div><div>=A0 std=
::optional&lt;transaction&gt; &amp;thing;</div><div>=A0 ~DoSomethingOnDestr=
uction() {</div><div>=A0 =A0 thing.emplace(my_transaction_args);</div><div>=
=A0 }</div>

<div>};</div><div><br></div><div>void f() {</div><div>=A0 std::optional&lt;=
transaction&gt; my_trans;</div><div>=A0 try {</div><div>=A0 =A0 DoSomething=
OnDestruction dsod{my_trans};<br></div><div>=A0 =A0 throw 42; // dsod destr=
oyed, transaction created with unwind count of 1.</div>

<div>=A0 } catch (...) {</div><div>=A0 =A0 // ok, still have my transaction=
..</div><div>=A0 =A0 if (cleanup fails)</div><div>=A0 =A0 =A0 throw 76; // o=
ops, my_trans and contained transaction destroyed with unwind count of 1. d=
oes not roll back!<br>

</div><div>=A0 =A0 if (could not recover)</div><div>=A0 =A0 =A0 throw; // o=
ops, does not roll back!</div><div>=A0 }</div><div>}</div><div><br></div><d=
iv>Some might argue that this code is simply not reasonable (it&#39;s certa=
inly contrived). But I can imagine real-world situations that would reduce =
to this (suppose dsod incrementally builds a transaction, and creates it wh=
en it first has something to add to it, and wants to add something to the t=
ransaction from its destructor).</div>
</div></div></div></blockquote><div><br><br></div><div>Does dsod want to ad=
d that something to the transaction even if unwinding is ongoing, or should=
<br>dsod be aware of unwinding?<br></div></div></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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11c37e30c36a9f04e6153cdc--

.

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

On 11 September 2013 03:51, David Krauss <potswa@gmail.com> wrote:

>
>
>
>> In my solution that will be no space overhead (all required data will be
>> initialized by exception handler). Additional point of creation of
>> object is irrelevant for it, only context of destruction will be relevant.
>> This will fix another similar problem with threads that can have separate
>> expeditions handlers (therefore different `uncaught_exception` count).
>>
>
> Good point! A transaction should certainly be able to retire on a
> different thread. To get a different count, you'd have to 1. initiate the
> transaction during unwind and then persist it, or 2. terminate an
> already-persisted transaction during unwind. The first case could represent
> an error logging operation initiated by unwind. The second case would be a
> transaction terminating a dependent transaction.
>
>
The support library of gcc has both the chain of exceptions and the count.
The code Evgeniy Panasyuk has written uses
the count, but not the chain. The chain can probably cope with the
problematic cases people have presented,
since afaics the count is the same but the chain would be different. If
need be, I suppose a ticket could be
created from the chain via hashing or whatnot. Then again, I'm not sure
whether the chain actually has
in-flight exceptions or just caught ones, as the variable is named
caughtExceptions...

I suppose all of these are per-thread. Propagating to a different thread
will likely mean that the count is
not going to be reliable alone, and whatever can be done with the chain
probably suffers from similar problems,
as will any ticket-based solution. The "context" would likely need to be
refreshed when switching threads,
and I find it hard to imagine how that could happen automatically.

--

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

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 11 September 2013 03:51, David Krauss <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:potswa@gmail.com" target=3D"_blank">potswa@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"><div dir=3D"ltr"><br>=A0<div class=3D"im"><b=
lockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-=
left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><span style=3D"font-family:arial,sans-serif">In my solutio=
n that will be no space overhead (all required data will be initialized by =
exception handler)</span>. Additional point of creation of object is irrele=
vant for it, only context of destruction will be relevant.<br>
This will fix another similar problem with threads that can have separate e=
xpeditions handlers (therefore different <span style=3D"font-family:courier=
 new,monospace">`uncaught_exception`</span> count).<br></div></blockquote>
</div><div><br>Good point! A transaction should certainly be able to retire=
 on a different thread. To get a different count, you&#39;d have to 1. init=
iate the transaction during unwind and then persist it, or 2. terminate an =
already-persisted transaction during unwind. The first case could represent=
 an error logging operation initiated by unwind. The second case would be a=
 transaction terminating a dependent transaction.<br>
<br></div></div></blockquote><div><br></div><div>The support library of gcc=
 has both the chain of exceptions and the count. The code Evgeniy Panasyuk =
has written uses<br>the count, but not the chain. The chain can probably co=
pe with the problematic cases people have presented,<br>
</div><div>since afaics the count is the same but the chain would be differ=
ent. If need be, I suppose a ticket could be<br>created from the chain via =
hashing or whatnot. Then again, I&#39;m not sure whether the chain actually=
 has<br>
</div><div>in-flight exceptions or just caught ones, as the variable is nam=
ed caughtExceptions...<br><br></div><div>I suppose all of these are per-thr=
ead. Propagating to a different thread will likely mean that the count is<b=
r>
</div><div>not going to be reliable alone, and whatever can be done with th=
e chain probably suffers from similar problems,<br></div><div>as will any t=
icket-based solution. The &quot;context&quot; would likely need to be refre=
shed when switching threads,<br>
and I find it hard to imagine how that could happen automatically.<br></div=
><div><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 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 />

--001a11c37e30081ce804e61675b6--

.

------=_Part_2996_13653706.1378884271550
Content-Type: text/plain; charset=ISO-8859-1



On Wednesday, September 11, 2013 1:53:14 PM UTC+8, Ville Voutilainen wrote:
>
>
>
>
> On 10 September 2013 20:47, Richard Smith <ric...@metafoo.co.uk<javascript:>
> > wrote:
>
>
>> Things seem to go wrong if your transactions' lifetimes aren't strictly
>> tied to stack variables. For instance, if your transaction is destroyed in
>> a stack variable's destructor, but might be created during unwinding:
>>
>> struct DoSomethingOnDestruction {
>>   std::optional<transaction> &thing;
>>   ~DoSomethingOnDestruction() {
>>     thing.emplace(my_transaction_args);
>>   }
>> };
>>
>> void f() {
>>   std::optional<transaction> my_trans;
>>   try {
>>     DoSomethingOnDestruction dsod{my_trans};
>>     throw 42; // dsod destroyed, transaction created with unwind count of
>> 1.
>>   } catch (...) {
>>     // ok, still have my transaction.
>>     if (cleanup fails)
>>       throw 76; // oops, my_trans and contained transaction destroyed
>> with unwind count of 1. does not roll back!
>>     if (could not recover)
>>       throw; // oops, does not roll back!
>>   }
>> }
>>
>> Some might argue that this code is simply not reasonable (it's certainly
>> contrived). But I can imagine real-world situations that would reduce to
>> this (suppose dsod incrementally builds a transaction, and creates it when
>> it first has something to add to it, and wants to add something to the
>> transaction from its destructor).
>>
>
>
> Does dsod want to add that something to the transaction even if unwinding
> is ongoing, or should
> dsod be aware of unwinding?
>

DoSomethingOnDestruction = dsod is already gone before the issue appears;
its destructor initiated the transaction as a failsafe. I mentioned this
case above as "an error logging operation initiated by unwind." Whether or
not different cases are taken by dsod::~dsod for unwinding or unexceptional
operation, the presumption is that the transaction should persist, yet the
transaction can also be gracefully cancelled by a failure of its own terms.

For example

   1. Network failure causes an exception.
   2. The exception destroys the transaction.
   3. Transaction destructor logs to a local database using a transaction.
   4. The log transaction is shared (it can record several errors) but
   constructed by the destructor (upon the first error).
   5. Part of the log record goes into the database.
   6. Trying to add a later error (or something) to the log record sends
   the database over quota! This is a new exception.
   7. Attempt to remove the incomplete log record.

The context of the log record's construction and destruction does not
provide the insight necessary for it to tell whether the log operation was
successful or not.

--

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

<div dir=3D"ltr"><br><br>On Wednesday, September 11, 2013 1:53:14 PM UTC+8,=
 Ville Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin:=
 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div =
dir=3D"ltr"><br><div><br><br><div class=3D"gmail_quote">On 10 September 201=
3 20:47, Richard Smith <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=
=3D"_blank" gdf-obfuscated-mailto=3D"TrmuVhmHlzAJ">ric...@metafoo.co.uk</a>=
&gt;</span> wrote:<br>
<div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div =
class=3D"gmail_quote"><div><div></div></div><div>Things seem to go wrong if=
 your transactions' lifetimes aren't strictly tied to stack variables. For =
instance, if your transaction is destroyed in a stack variable's destructor=
, but might be created during unwinding:</div>

<div><br></div><div>struct DoSomethingOnDestruction {<br></div><div>&nbsp; =
std::optional&lt;transaction&gt; &amp;thing;</div><div>&nbsp; ~DoSomethingO=
nDestruction() {</div><div>&nbsp; &nbsp; thing.emplace(my_transaction_<wbr>=
args);</div><div>&nbsp; }</div>

<div>};</div><div><br></div><div>void f() {</div><div>&nbsp; std::optional&=
lt;transaction&gt; my_trans;</div><div>&nbsp; try {</div><div>&nbsp; &nbsp;=
 DoSomethingOnDestruction dsod{my_trans};<br></div><div>&nbsp; &nbsp; throw=
 42; // dsod destroyed, transaction created with unwind count of 1.</div>

<div>&nbsp; } catch (...) {</div><div>&nbsp; &nbsp; // ok, still have my tr=
ansaction.</div><div>&nbsp; &nbsp; if (cleanup fails)</div><div>&nbsp; &nbs=
p; &nbsp; throw 76; // oops, my_trans and contained transaction destroyed w=
ith unwind count of 1. does not roll back!<br>

</div><div>&nbsp; &nbsp; if (could not recover)</div><div>&nbsp; &nbsp; &nb=
sp; throw; // oops, does not roll back!</div><div>&nbsp; }</div><div>}</div=
><div><br></div><div>Some might argue that this code is simply not reasonab=
le (it's certainly contrived). But I can imagine real-world situations that=
 would reduce to this (suppose dsod incrementally builds a transaction, and=
 creates it when it first has something to add to it, and wants to add some=
thing to the transaction from its destructor).</div>
</div></div></div></blockquote><div><br><br></div><div>Does dsod want to ad=
d that something to the transaction even if unwinding is ongoing, or should=
<br>dsod be aware of unwinding?<br></div></div></div></div></blockquote><br=
>DoSomethingOnDestruction =3D dsod is already gone before the issue appears=
; its destructor initiated the transaction as a failsafe. I mentioned this =
case above as "an error logging operation initiated by unwind." Whether or =
not different cases are taken by dsod::~dsod for unwinding or unexceptional=
 operation, the presumption is that the transaction should persist, yet the=
 transaction can also be gracefully cancelled by a failure of its own terms=
..<br><br>For example<br><ol><li>Network failure causes an exception.</li><l=
i>The exception destroys the transaction.</li><li>Transaction destructor lo=
gs to a local database using a transaction.</li><li>The log transaction is =
shared (it can record several errors) but constructed by the destructor (up=
on the first error).<br></li><li>Part of the log record goes into the datab=
ase.</li><li>Trying to add a later error (or something) to the log record s=
ends the database over quota! This is a new exception.<br></li><li>Attempt =
to remove the incomplete log record.</li></ol><p>The context of the log rec=
ord's construction and destruction does not provide the insight necessary f=
or it to tell whether the log operation was successful or not.<br></p></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 />

------=_Part_2996_13653706.1378884271550--

.

------=_Part_3136_28137030.1378887042602
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable



On Wednesday, September 11, 2013 3:20:33 PM UTC+8, Ville Voutilainen wrote:
>
>
> On 11 September 2013 03:51, David Krauss <pot...@gmail.com <javascript:>>=
wrote:
>
>>
>> =20
>>
>>> In my solution that will be no space overhead (all required data will b=
e=20
>>> initialized by exception handler). Additional point of creation of=20
>>> object is irrelevant for it, only context of destruction will be releva=
nt.
>>> This will fix another similar problem with threads that can have=20
>>> separate expeditions handlers (therefore different `uncaught_exception`=
count).
>>>
>>
>> Good point! A transaction should certainly be able to retire on a=20
>> different thread. To get a different count, you'd have to 1. initiate th=
e=20
>> transaction during unwind and then persist it, or 2. terminate an=20
>> already-persisted transaction during unwind. The first case could repres=
ent=20
>> an error logging operation initiated by unwind. The second case would be=
 a=20
>> transaction terminating a dependent transaction.
>>
>>
> The support library of gcc has both the chain of exceptions and the count=
..=20
> The code Evgeniy Panasyuk has written uses
> the count, but not the chain. The chain can probably cope with the=20
> problematic cases people have presented,
>

Such a mechanism is likely to work in practice but isn't fully=20
deterministic as "doing the same thing twice" can result in coincidental=20
chains.
=20

> since afaics the count is the same but the chain would be different. If=
=20
> need be, I suppose a ticket could be
> created from the chain via hashing or whatnot.
>

To be deterministic, tickets need to be managed by a central registry.=20
That's a main point of my proposal, but questions remain about how it would=
=20
work. I'll try to hammer out something workable and performant. Some ideal=
=20
features won't make it :v( . Anyway it's just theory at this point.
=20

> I suppose all of these are per-thread. Propagating to a different thread=
=20
> will likely mean that the count is
> not going to be reliable alone, and whatever can be done with the chain=
=20
> probably suffers from similar problems,
> as will any ticket-based solution. The "context" would likely need to be=
=20
> refreshed when switching threads,
> and I find it hard to imagine how that could happen automatically.
>

I'll try and figure it out=85 it must be possible to extrapolate a real-wor=
ld=20
scenario, if one exists. Such things are only contrived until someone=20
builds a sophisticated enough system. But I suspect any non-scope-based=20
transaction system (a prerequisite for switching threads) simply cannot=20
rely on scoping to signal success or failure.

For what it's worth, my semantic #2 might be able to handle multithreading=
=20
with a small modification (in bold; actually it sort of goes without=20
saying):

2. You pass the ticket to bool uncaught_exception_since(
uncaught_exception_ticket_t) which tells you whether there is a current=20
uncaught exception initiated *on the current thread* since the given ticket=
=20
was issued.

On the face of it, this appears to invite a race condition, but an object=
=20
owning a ticket must be locked to work anyway (else you could destroy the=
=20
same transaction twice). The effect is that any transaction started on=20
another thread which is being retired by unwind on the current thread is=20
facing cancellation, unless it was started after the cancellation process=
=20
began. This merely implies synchronization between transaction initiation=
=20
and transaction cancellation. Hmm, I'm leaning toward thinking this is=20
unreasonably strict.

Anyhow, lest I give the impression that this is a serious theoretical flaw,=
=20
the other solutions do have bigger problems. For example, Sutter's=20
intrinsic always signals false if the transaction is in any kind of=20
container.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

------=_Part_3136_28137030.1378887042602
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Wednesday, September 11, 2013 3:20:33 PM UTC+8,=
 Ville Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin:=
 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div =
dir=3D"ltr"><br><div><div class=3D"gmail_quote">On 11 September 2013 03:51,=
 David Krauss <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blan=
k" gdf-obfuscated-mailto=3D"qaq9i-uYZCsJ">pot...@gmail.com</a>&gt;</span> w=
rote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br>&nbsp;<div><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"><span style=3D"font-family:arial,sans-serif">In my solutio=
n that will be no space overhead (all required data will be initialized by =
exception handler)</span>. Additional point of creation of object is irrele=
vant for it, only context of destruction will be relevant.<br>
This will fix another similar problem with threads that can have separate e=
xpeditions handlers (therefore different <span style=3D"font-family:courier=
 new,monospace">`uncaught_exception`</span> count).<br></div></blockquote>
</div><div><br>Good point! A transaction should certainly be able to retire=
 on a different thread. To get a different count, you'd have to 1. initiate=
 the transaction during unwind and then persist it, or 2. terminate an alre=
ady-persisted transaction during unwind. The first case could represent an =
error logging operation initiated by unwind. The second case would be a tra=
nsaction terminating a dependent transaction.<br>
<br></div></div></blockquote><div><br></div><div>The support library of gcc=
 has both the chain of exceptions and the count. The code Evgeniy Panasyuk =
has written uses<br>the count, but not the chain. The chain can probably co=
pe with the problematic cases people have presented,<br></div></div></div><=
/div></blockquote><div><br>Such a mechanism is likely to work in practice b=
ut isn't fully deterministic as "doing the same thing twice" can result in =
coincidental chains.<br>&nbsp;</div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>
</div><div>since afaics the count is the same but the chain would be differ=
ent. If need be, I suppose a ticket could be<br>created from the chain via =
hashing or whatnot.</div></div></div></div></blockquote><div><br>To be dete=
rministic, tickets need to be managed by a central registry. That's a main =
point of my proposal, but questions remain about how it would work. I'll tr=
y to hammer out something workable and performant. Some ideal features won'=
t make it :v( . Anyway it's just theory at this point.<br>&nbsp;</div><bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D=
"gmail_quote">I suppose all of these are per-thread. Propagating to a diffe=
rent thread will likely mean that the count is<br>
<div>not going to be reliable alone, and whatever can be done with the chai=
n probably suffers from similar problems,<br></div><div>as will any ticket-=
based solution. The "context" would likely need to be refreshed when switch=
ing threads,<br>
and I find it hard to imagine how that could happen automatically.<br></div=
></div></div></div></blockquote><div><br>I'll try and figure it out=85 it m=
ust be possible to extrapolate a real-world scenario, if one exists. Such t=
hings are only contrived until someone builds a sophisticated enough system=
.. But I suspect any non-scope-based transaction system (a prerequisite for =
switching threads) simply cannot rely on scoping to signal success or failu=
re.<br><br>For what it's worth, my semantic #2 might be able to handle mult=
ithreading with a small modification (in bold; actually it sort of goes wit=
hout saying):<br><br>2. You pass the ticket to <span style=3D"font-family:c=
ourier new,monospace">bool uncaught_exception_since(</span><span style=3D"f=
ont-family:courier new,monospace"><span style=3D"font-family:courier new,mo=
nospace">uncau<wbr>ght_exception_ticket_t</span>)</span> which tells you wh=
ether there is a current uncaught exception initiated <b>on the current thr=
ead</b> since the given ticket was issued.<br><br>On the face of it, this a=
ppears to invite a race condition, but an object owning a ticket must be lo=
cked to work anyway (else you could destroy the same transaction twice). Th=
e effect is that any transaction started on another thread which is being r=
etired by unwind on the current thread is facing cancellation, unless it wa=
s started after the cancellation process began. This merely implies synchro=
nization between transaction initiation and transaction cancellation. Hmm, =
I'm leaning toward thinking this is unreasonably strict.<br><br>Anyhow, les=
t I give the impression that this is a serious theoretical flaw, the other =
solutions do have bigger problems. For example, Sutter's intrinsic always s=
ignals false if the transaction is in any kind of container.<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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_3136_28137030.1378887042602--

.

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

On 11 September 2013 10:24, David Krauss <potswa@gmail.com> wrote:

> The context of the log record's construction and destruction does not
> provide the insight necessary for it to tell whether the log operation was
> successful or not.
>
>
>
>
Just to make sure there are no misconceptions, I have no plans to limit the
invocations of exception_count
(or querying the chain, if we go that way) to constructors and 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/.

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 11 September 2013 10:24, David Krauss <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:potswa@gmail.com" target=3D"_blank">potswa@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"><div dir=3D"ltr">The context of the log reco=
rd&#39;s construction and destruction does not provide the insight necessar=
y for it to tell whether the log operation was successful or not.<br>
</div><div class=3D"HOEnZb"><div class=3D"h5">

<p></p>

<br><br></div></div></blockquote><div><br></div><div>Just to make sure ther=
e are no misconceptions, I have no plans to limit the invocations of except=
ion_count<br></div><div>(or querying the chain, if we go that way) to const=
ructors and destructors. <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 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 />

--047d7beb93b43f526e04e61777fc--

.

------=_Part_1306_14220828.1378888795933
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable



On Wednesday, September 11, 2013 4:32:45 PM UTC+8, Ville Voutilainen wrote:
>
>
> On 11 September 2013 10:24, David Krauss <pot...@gmail.com <javascript:>>=
wrote:
>
>> The context of the log record's construction and destruction does not=20
>> provide the insight necessary for it to tell whether the log operation w=
as=20
>> successful or not.
>>
>
> Just to make sure there are no misconceptions, I have no plans to limit=
=20
> the invocations of exception_count
> (or querying the chain, if we go that way) to constructors and=20
> destructors.=20
>

That's not the way I tend to think=85 :)

If I'm going to be serious about this (or taken seriously), I should=20
probably find out who's who and write proper correspondence. Are you=20
particularly involved with this issue or maintaining an actual exceptions=
=20
implementation?

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

------=_Part_1306_14220828.1378888795933
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Wednesday, September 11, 2013 4:32:45 PM UTC+8,=
 Ville Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin:=
 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div =
dir=3D"ltr"><br><div><div class=3D"gmail_quote">On 11 September 2013 10:24,=
 David Krauss <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blan=
k" gdf-obfuscated-mailto=3D"gzTXJLMoD8kJ">pot...@gmail.com</a>&gt;</span> w=
rote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">The context of the log reco=
rd's construction and destruction does not provide the insight necessary fo=
r it to tell whether the log operation was successful or not.<br>
</div></blockquote><div><br></div><div>Just to make sure there are no misco=
nceptions, I have no plans to limit the invocations of exception_count<br><=
/div><div>(or querying the chain, if we go that way) to constructors and de=
structors. <br></div></div></div></div></blockquote><div><br>That's not the=
 way I tend to think=85 :)<br><br>If I'm going to be serious about this (or=
 taken seriously), I should probably find out who's who and write proper co=
rrespondence. Are you particularly involved with this issue or maintaining =
an actual exceptions implementation?<br><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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_1306_14220828.1378888795933--

.

--001a11c25bda1362f004e6179ef8
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On 11 September 2013 11:39, David Krauss <potswa@gmail.com> wrote:

>
>
> On Wednesday, September 11, 2013 4:32:45 PM UTC+8, Ville Voutilainen wrot=
e:
>
>>
>> On 11 September 2013 10:24, David Krauss <pot...@gmail.com> wrote:
>>
>>> The context of the log record's construction and destruction does not
>>> provide the insight necessary for it to tell whether the log operation =
was
>>> successful or not.
>>>
>>
>> Just to make sure there are no misconceptions, I have no plans to limit
>> the invocations of exception_count
>> (or querying the chain, if we go that way) to constructors and
>> destructors.
>>
>
> That's not the way I tend to think=85 :)
>
> If I'm going to be serious about this (or taken seriously), I should
> probably find out who's who and write proper correspondence. Are you
> particularly involved with this issue or maintaining an actual exceptions
> implementation?
>
>
I don't deal with any of the implementations. I plan to write a
continuation paper to Herb's proposal, since
it is clear to me at least that just a bool won't cut it. I think I should
play with at least libsup++ to see what
it can do. If you're interested in working on this area, I welcome
contributions and co-authors.

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

--001a11c25bda1362f004e6179ef8
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 11 September 2013 11:39, David Krauss <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:potswa@gmail.com" target=3D"_blank">potswa@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"><div dir=3D"ltr"><br><br>On Wednesday, Septe=
mber 11, 2013 4:32:45 PM UTC+8, Ville Voutilainen wrote:<div class=3D"im"><=
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"><br><div><div class=3D"gmail_quote">On 11 September 2013 1=
0:24, David Krauss <span dir=3D"ltr">&lt;<a>pot...@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"><div dir=3D"ltr">The context of the log reco=
rd&#39;s construction and destruction does not provide the insight necessar=
y for it to tell whether the log operation was successful or not.<br>

</div></blockquote><div><br></div><div>Just to make sure there are no misco=
nceptions, I have no plans to limit the invocations of exception_count<br><=
/div><div>(or querying the chain, if we go that way) to constructors and de=
structors. <br>
</div></div></div></div></blockquote></div><div><br>That&#39;s not the way =
I tend to think=85 :)<br><br>If I&#39;m going to be serious about this (or =
taken seriously), I should probably find out who&#39;s who and write proper=
 correspondence. Are you particularly involved with this issue or maintaini=
ng an actual exceptions implementation?<br>
<br></div></div></blockquote><div><br></div><div>I don&#39;t deal with any =
of the implementations. I plan to write a continuation paper to Herb&#39;s =
proposal, since<br></div><div>it is clear to me at least that just a bool w=
on&#39;t cut it. I think I should play with at least libsup++ to see what<b=
r>
</div><div>it can do. If you&#39;re interested in working on this area, I w=
elcome contributions and co-authors. <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 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 />

--001a11c25bda1362f004e6179ef8--

.

------=_Part_2645_3501836.1378893157955
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Le mardi 10 septembre 2013 19:47:58 UTC+2, Richard Smith a =E9crit :
>
>
> Things seem to go wrong if your transactions' lifetimes aren't strictly=
=20
> tied to stack variables.=20
>

There are three stacks:
- the stack of exception unwinding contexts
- the block stack
- the transaction stack,

The stack of unwinding contexts is a subset of the block stack.

A destructor has three evaluations contexts: explicitly called (delete and=
=20
explicit destructor call), automatic unwinding, exception unwinding.  The=
=20
use of exception unwinding depth allows explicit call which are proxy for=
=20
unwinding  one to determine if they are a proxy for an automatic or=20
exception one, under the assumption that their capture of the depth is made=
=20
at a correct time.  So it provides a way to support the "transaction needs=
=20
to be poped at the same level of the block stack as they are pushed" which=
=20
is needed to support proxy objects without too much burden.  It support=20
some more policies naturally as it checks only the depth of the exception=
=20
unwinding contexts and even more if you play with the captured depth.  But=
=20
those were not the design requirement.  I'm not sure the requirements were=
=20
more than allowing an automatic destructor to know if it is unwinding=20
automatically or due to an exception and allowing RAII controlled explicit=
=20
object to determine the same thing is not just an additional benefit. =20
Obviously knowing that this benefit can be achieved at near no cost make=20
all solutions not providing it at a disadvantage.

If you make the transaction stack totally independent of the block stack, I=
=20
fear that in general the state of the block stacks are no more enough to=20
determine if you need to unwind the transaction stack or not when leaving a=
=20
block stack frame.  You can probably think of policies more general than=20
the above under which you are able to do and for which the unwinding depth=
=20
is not enough, but I'd like first a statement of the policies for managing=
=20
the transaction stack we want to support in the standard before designing=
=20
methods to support them.  I'm not sure I'll consider them important enough=
=20
to warrant the time.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

<div dir=3D"ltr">Le mardi 10 septembre 2013 19:47:58 UTC+2, Richard Smith a=
 =E9crit&nbsp;:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr=
"><div><div class=3D"gmail_quote">
<div><br></div><div>Things seem to go wrong if your transactions' lifetimes=
 aren't strictly tied to stack variables. <br></div></div></div></div></blo=
ckquote><div><br>There are three stacks:<br>- the stack of exception unwind=
ing contexts<br>- the block stack<br>- the transaction stack,<br><br>The st=
ack of unwinding contexts is a subset of the block stack.<br><br>A destruct=
or has three evaluations contexts: explicitly called (delete=20
and explicit destructor call), automatic unwinding, exception=20
unwinding.&nbsp; The use of exception unwinding depth allows explicit call =
which are proxy for unwinding&nbsp; one to determine if they are a proxy fo=
r an automatic or exception one, under the assumption that their capture of=
 the depth is made at a correct time.&nbsp; So it provides a way to support=
 the "transaction needs=20
to be poped at the same level of the block stack as they are pushed" which =
is needed to support proxy objects without too much burden.&nbsp; It suppor=
t some more policies naturally as it checks only the depth of the exception=
 unwinding contexts and even more if you play with the captured depth.&nbsp=
; But those were not the design requirement.&nbsp; I'm not sure the require=
ments were more than allowing an automatic destructor to know if it is unwi=
nding automatically or due to an exception and allowing RAII controlled exp=
licit object to determine the same thing is not just an additional benefit.=
&nbsp; Obviously knowing that this benefit can be achieved at near no cost =
make all solutions not providing it at a disadvantage.<br><br>If you make t=
he transaction stack totally independent of the block stack, I fear that in=
 general the state of the block stacks are no more enough to determine if y=
ou need to unwind the transaction stack or not when leaving a block stack f=
rame.&nbsp; You can probably think of policies more general than the above =
under which you are able to do and for which the unwinding depth is not eno=
ugh, but I'd like first a statement of the policies for managing the transa=
ction stack we want to support in the standard before designing methods to =
support them.&nbsp; I'm not sure I'll consider them important enough to war=
rant the time.<br><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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_2645_3501836.1378893157955--

.

------=_Part_152_1382768.1378902935982
Content-Type: text/plain; charset=ISO-8859-1


On Wednesday, September 11, 2013 2:51:41 AM UTC+2, David Krauss wrote:
>
>
>
> On Wednesday, September 11, 2013 2:32:58 AM UTC+8, inkwizyt...@gmail.comwrote:
>>
>> passing `this` is special case, in general you can pass any pointer to
>> it. This will allow calling this function outside destructor body and even
>> from static functions e.g. destructor call static function
>> `unregister_object(T* ptr)` that can call `unwinding_exception(ptr)` to
>> test why object is unregistering.
>>
>
> How does the pointer map to the Boolean value? Is the implementation
> required to store a list of objects undergoing destruction? But you said
> other pointers are also valid queries.
>

Exactly, but because you can "forward" it cant be list. It should be some
kind of tree. Another detail is this should store range `[ this,
this+sizeof(*this) )` not only pointer `this`  because sub objects should
have easy access to `unwinding_exception(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/.

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

<div dir=3D"ltr"><br>On Wednesday, September 11, 2013 2:51:41 AM UTC+2, Dav=
id Krauss wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"lt=
r"><br><br>On Wednesday, September 11, 2013 2:32:58 AM UTC+8, <a>inkwizyt..=
..@gmail.com</a> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;m=
argin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"l=
tr">passing `this` is special case, in general you can pass any pointer to =
it. This will allow calling this function outside destructor body and even =
from static functions e.g. destructor call static function `unregister_obje=
ct(T* ptr)` that can call  <span style=3D"font-family:courier new,monospace=
">`unwinding_exception(ptr)`<span style=3D"font-family:arial,sans-serif"> t=
o test why object <font size=3D"2">is </font></span></span>unregistering<sp=
an style=3D"font-family:arial,sans-serif"><font size=3D"2">.</font><br></sp=
an></div></blockquote><div><br>How does the pointer map to the Boolean valu=
e? Is the implementation required to store a list of objects undergoing des=
truction? But you said other pointers are also valid queries. <br></div></d=
iv></blockquote><div><br>Exactly, but because you can "forward" it cant be =
list. It should be some kind of tree. Another detail is this should store r=
ange `[ this, this+sizeof(*this) )` not only pointer `this`&nbsp; because s=
ub objects should have easy access to <span style=3D"font-family:courier ne=
w,monospace">`unwinding_exception(value*)`<span style=3D"font-family:arial,=
sans-serif"></span></span>.<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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_152_1382768.1378902935982--

.

------=_Part_412_1429740.1380882381482
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

9 sep 2013 =D0=B3., 21:07:55 UTC+4 Andrzej Krzemie=C5=84ski :
>
> There would be another special member function (like copy constructor,=20
> destructor, etc.). I do not have a good name for it, so let's call it=20
> _COMPETE() for the moment. If your type needs to do a "business logic=20
> completion" you declare this special member function:
>
>
I have implemented this concept a year ago based on=20
uncaught_exception_count. I call it "Two Stage Destructor":
1. https://github.com/panaseleus/stack_unwinding#two-stage-destructor
2.=20
https://github.com/panaseleus/stack_unwinding/blob/master/examples/two_stag=
e_destructor.cpp
3.=20
http://boost.2283326.n4.nabble.com/scope-exit-D-style-scope-failure-and-sco=
pe-success-in-C-td4636441.html#a4636921

class RAII_Deferred
{
    bool fail_on_flush;
public:
    RAII_Deferred(bool fail_on_flush_) : fail_on_flush(fail_on_flush_)
    {
        cout << "acquiring resource" << endl;
    }
    TWO_STAGE_DESTRUCTOR_RELEASE(RAII_Deferred)
    {
        cout << "release resource" << endl;
    }
    TWO_STAGE_DESTRUCTOR_DEFERRED(RAII_Deferred)
    {
        cout << "flush pending actions on resource" << endl;
        if(fail_on_flush) throw 1;
    }
};


=D0=92=D0=B2=D0=B5=D0=B4=D0=B8=D1=82=D0=B5 =D0=BA=D0=BE=D0=B4...


--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

------=_Part_412_1429740.1380882381482
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">9 sep 2013&nbsp;=D0=B3., 21:07:55 UTC+4 Andrzej Krzemie=C5=
=84ski :<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>=
<div><div>There
 would be another special member function (like copy constructor,=20
destructor, etc.). I do not have a good name for it, so let's call it=20
_COMPETE() for the moment. If your type needs to do a "business logic compl=
etion" you declare this special member function:<br></div><br></div></div><=
/div></blockquote><div><br>I have implemented this concept a year ago based=
 on uncaught_exception_count. I call it "Two Stage Destructor":<br>1. https=
://github.com/panaseleus/stack_unwinding#two-stage-destructor<br>2. https:/=
/github.com/panaseleus/stack_unwinding/blob/master/examples/two_stage_destr=
uctor.cpp<br>3. http://boost.2283326.n4.nabble.com/scope-exit-D-style-scope=
-failure-and-scope-success-in-C-td4636441.html#a4636921<br><br><div class=
=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border-colo=
r: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wrap: b=
reak-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span=
 style=3D"color: #008;" class=3D"styled-by-prettify">class</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> RAII_Deferred<br></span><s=
pan 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: #008;" class=3D"styled-by-prettify">bool</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> fail_on_flush</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">public</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; RAII_Deferred</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">bool</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> fail_on_flush_</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: #660;" class=3D"s=
tyled-by-prettify">:</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> fail_on_flush</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify">fail_on_flush_</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br>&nbsp; &nbsp; </span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><=
br>&nbsp; &nbsp; &nbsp; &nbsp; cout </span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">&lt;&lt;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #080;" class=3D"style=
d-by-prettify">"acquiring resource"</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">&lt;&lt;</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> endl</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br>&nbsp; &nbsp; </span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><=
br>&nbsp; &nbsp; TWO_STAGE_DESTRUCTOR_RELEASE</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify">RAII_Deferred</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;" c=
lass=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br>&nbsp; &nbsp; &nbsp; &nbsp; cout </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">&lt;&lt;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #080;" class=3D"styled-by-prettify">"release resource"</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">&lt;&lt;</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> endl</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; TWO_STAGE_DESTRUCTOR_DEFERRED</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify">RAII_Deferred</span><sp=
an 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: #660;" class=3D"styled-by-prettify">{</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; &nbsp; &nb=
sp; cout </span><span style=3D"color: #660;" class=3D"styled-by-prettify">&=
lt;&lt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #080;" class=3D"styled-by-prettify">"flush pendi=
ng actions on resource"</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">&lt;&lt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> endl</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">fail_on=
_flush</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: #008;" class=3D"styled-by-prettify">throw</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"colo=
r: #066;" class=3D"styled-by-prettify">1</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></div></code></div><br><br><div class=3D"prettyprint=
" style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187=
, 187); border-style: solid; border-width: 1px; word-wrap: break-word;"><co=
de class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color=
: #660;" class=3D"styled-by-prettify">=D0=92=D0=B2=D0=B5=D0=B4=D0=B8=D1=82=
=D0=B5</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">=D0=BA=D0=BE=
=D0=B4...</span></div></code></div><br><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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_412_1429740.1380882381482--

.

------=_Part_2315_2347154.1381070415990
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

9 sep 2013 =D0=B3., 21:07:55 UTC+4  Andrzej Krzemie=C5=84ski:

> This is only a sketch of a proposal, but I wanted to collect people's=20
> opinion first.
>
>
I am pretty sure that it should not be standardized in that way:

1. It is over-restricted abstraction built on top of unwinding aware=20
destructor. It is not in spirit of C++ to standardize something constrained=
=20
when more broadly applicable approach is easily available.

2. Such two stage destructor would require unwinding aware destructor in=20
standard too, in any case.
Just think about places where destructor is explicitly called via "delete=
=20
obj" or "obj->~T()". At such places there is no any unwinding - it is just=
=20
normal code flow.
But is obviously desirable to give option to user to propogate unwinding=20
flag. Just think about smart pointers.
Or even better - about vector's destructor: list of elements is being=20
destructed and one of them has just throwed, now - we should tell somehow=
=20
to others, that they should call only non-throwable part of destructor,=20
i.e. something like "obj.~T(/*due_to_unwinding*/ true);".
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
And not only in ISO, but also external code, containers, etc should be=20
adjusted too. That would be too invasive.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

------=_Part_2315_2347154.1381070415990
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">9 sep 2013&nbsp;=D0=B3., 21:07:55 UTC+4&nbsp; Andrzej Krze=
mie=C5=84ski:<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr">This is only a sketch of a proposal, but I wanted to collect people's o=
pinion first.<br><br></div></blockquote><div><br>I am pretty sure that it s=
hould not be standardized in that way:<br><br>1. It is over-restricted abst=
raction built on top of unwinding aware destructor. It is not in spirit of =
C++ to standardize something constrained when more broadly applicable appro=
ach is easily available.<br><br>2. Such two stage destructor would require =
unwinding aware destructor in standard too, in any case.<br>Just think abou=
t places where destructor is explicitly called via "delete obj" or "obj-&gt=
;~T()". At such places there is no any unwinding - it is just normal code f=
low.<br>But is obviously desirable to give option to user to propogate unwi=
nding flag. Just think about smart pointers.<br>Or even better - about vect=
or's destructor: list of elements is being destructed and one of them has j=
ust throwed, now - we should tell somehow to others, that they should call =
only non-throwable part of destructor, i.e. something like "obj.~T(/*due_to=
_unwinding*/ true);".<br>And once we would have such thing - we have to adj=
ust a lot of places in
 ISO: built-in arrays, containers, smart pointers, members, bases, etc,=20
etc. And not only in ISO, but also external code, containers, etc should be=
 adjusted too. That would be too invasive.<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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_2315_2347154.1381070415990--

.

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

9 sep 2013 =C7., 22:25:09 UTC+4 Ville Voutilainen:
>
> I plan to work with Sutter to amend=20
> http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3614.pdf
> towards the direction of supporting a count (not a bool, an integer).
>

It must be amended. Even if change bool to count is not planned.
Current definition itself is controversial (=20
https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/PCpJMgzl=
a80=20
) - it is not clear how it works for members of objects.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

<div dir=3D"ltr">9 sep 2013&nbsp;=C7., 22:25:09 UTC+4 Ville Voutilainen:<bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=
=3D"gmail_quote"><div>I plan to work with Sutter to amend <a href=3D"http:/=
/open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3614.pdf" target=3D"_blank">=
http://open-std.org/JTC1/SC22/<wbr>WG21/docs/papers/2013/n3614.<wbr>pdf</a>=
<br></div><div>towards the direction of supporting a count (not a bool, an =
integer).<br></div></div></div></div></blockquote><div><br>It must be amend=
ed. Even if change bool to count is not planned.<br>Current definition itse=
lf is controversial ( https://groups.google.com/a/isocpp.org/forum/#!topic/=
std-proposals/PCpJMgzla80 ) - it is not clear how it works for members of o=
bjects.<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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_2448_2091588.1381070937031--

.

------=_Part_1588_23121870.1381074284082
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


10 sep 2013 =D0=B3., 2:28:01 UTC+4 inkwizyt...@gmail.com:
>
>
> This example is very exotic, but is way to prevent it?
>

That problem is recognized. For instance, technique based on=20
uncaught_exception_count can be fooled in following case: when object is=20
created during stack unwinding (i.e. in some destructor), and that object=
=20
outlived unwinding process, for instance it was stored in global variable (=
=20
I have made special test case a year ago:=20
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=
=20
could also lead to different "anti-patterns"

I think that main aim of N3614 (and related proposals) is to enable=20
implementation of scope_guard like classes (scope(success/failure),=20
transactions, etc) with ability to distinguish between success/failure of=
=20
expression or normal scope leaving. Objects of such classes have automatic=
=20
storage duration or are temporaries (yes, there are some use cases for=20
temporaries - for instance at Boost.Log).
uncaught_exception_count is not aimed to provide universal "is_unwinding"=
=20
to destructors, but to enable implementation of special kind of objects=20
like: scope(success/failure) and transactions, etc - which live only in=20
code blocks.

However, uncaught_exception_count also works reasonably well for nested=20
objects (via aggregation or inheritance).
It even allow us to handle more complex examples like vector, where objects=
=20
are destructed by hands:
struct Vector // (approximation of container)
{
    Some *a, *b;
    // ...
    ~Vector() noexcept(false)
    {
        /*
        delete b; // if it throws then we should propogate right uncaught=
=20
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=20
reduced back uncaught exception count
            throw;
        }
        */
        // Right solution is to use:
        scope(exit)
        {
            delete a; // scope(exit) does not change state of uncaught=20
exception count
        };
        delete b;
        // That solution was proposed by "Ku-ku" at=20
http://www.rsdn.ru/forum/flame.comp/4932465.1
        // and it can be extended to containers of many objects
    }
};

But if aim is to get universal solution which distinguish every possible=20
case then:
1) some way of manual propagation should be provided like "obj.~T(=20
/*is_unwinding =3D*/ true )"
2) and once we would have such thing - we have to adjust a lot of places in=
=20
ISO, and a lot of code like custom containers or smart pointers (because=20
now - they should propagate unwinding info).=20

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

------=_Part_1588_23121870.1381074284082
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br>10 sep 2013&nbsp;=D0=B3., 2:28:01 UTC+4 inkwizyt...@gm=
ail.com:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br><div dir=3D"ltr"><=
code></code>This example is very exotic, but is way to prevent it?<br></div=
></blockquote><br>That problem is recognized. For instance, technique based=
 on uncaught_exception_count can be fooled in=20
following case: when object is created during stack unwinding (i.e. in=20
some destructor), and that object outlived unwinding process, for=20
instance it was stored in global variable ( I have made special test case a=
 year ago: <a href=3D"https://github.com/panaseleus/stack_unwinding/blob/ma=
ster/examples/uncaught_exception_count_floating_object.cpp" target=3D"_blan=
k">https://github.com/panaseleus/<wbr>stack_unwinding/blob/master/<wbr>exam=
ples/uncaught_exception_<wbr>count_floating_object.cpp</a> ).<br>That fact =
about "floating" objects should be taken into account, because it could als=
o lead to different "anti-patterns"<br><br>I think that main aim of N3614 (=
and related proposals) is to enable implementation of scope_guard like clas=
ses (scope(success/failure), transactions, etc) with ability to distinguish=
 between success/failure of expression or normal scope leaving. Objects of =
such classes have automatic storage duration or are temporaries (yes, there=
 are some use cases for temporaries - for instance at Boost.Log).<br>uncaug=
ht_exception_count is not aimed to provide universal "is_unwinding" to dest=
ructors, but to enable implementation of special kind of objects like: scop=
e(success/failure) and transactions, etc - which live only in code blocks.<=
br><br>However, uncaught_exception_count also works reasonably well for nes=
ted objects (via aggregation or inheritance).<br>It even allow us to handle=
 more complex examples like vector, where objects are destructed by hands:<=
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"subprett=
yprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">struct</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
 style=3D"color: #606;" class=3D"styled-by-prettify">Vector</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"col=
or: #800;" class=3D"styled-by-prettify">// (approximation of container)</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><sp=
an 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">Some</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"col=
or: #660;" 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"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">*</span><span style=3D"color: #000;" class=3D"styled-by-prettify">b</=
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: #800;" 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: #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"> noexcept</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">false</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; </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: #800;" class=3D"styled-by-prettify">/*<br>&nbsp; &nbsp; &nbsp; &=
nbsp; delete b; // if it throws then we should propogate right uncaught exc=
eption count to a's destructor.<br>&nbsp; &nbsp; &nbsp; &nbsp; // But if we=
 would do:<br>&nbsp; &nbsp; &nbsp; &nbsp; try<br>&nbsp; &nbsp; &nbsp; &nbsp=
; {<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; delete b;<br>&nbsp; &nbsp;=
 &nbsp; &nbsp; }<br>&nbsp; &nbsp; &nbsp; &nbsp; catch(...)<br>&nbsp; &nbsp;=
 &nbsp; &nbsp; {<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; delete a; // =
then at this point we *caught* exception, and reduced back uncaught excepti=
on count<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; throw;<br>&nbsp; &nbs=
p; &nbsp; &nbsp; }<br>&nbsp; &nbsp; &nbsp; &nbsp; */</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; &nbsp; &nbsp; <=
/span><span style=3D"color: #800;" class=3D"styled-by-prettify">// Right so=
lution is to use:</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"><br>&nbsp; &nbsp; &nbsp; &nbsp; scope</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">(</span><span style=3D"color: #008;" clas=
s=3D"styled-by-prettify">exit</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"><br>&nbsp; &nbsp; &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; &nbsp; &nbsp; </spa=
n><span style=3D"color: #008;" class=3D"styled-by-prettify">delete</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> a</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #800;"=
 class=3D"styled-by-prettify">// scope(exit) does not change state of uncau=
ght exception count</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br>&nbsp; &nbsp; &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</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> b</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"><br>&nbsp; &nbsp; &nbsp; &nbsp; </span><span styl=
e=3D"color: #800;" class=3D"styled-by-prettify">// That solution was propos=
ed 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;" 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></div></code></div><br>But if=
 aim is to get universal solution which distinguish every possible case the=
n:<br>1) some way of manual propagation should be provided like "obj.~T( /*=
is_unwinding =3D*/ true )"<br>2) and once we would have such thing - we hav=
e to adjust a lot of places in
 ISO, and a lot of code like custom containers or smart pointers (because n=
ow - they should propagate unwinding info). </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 />

------=_Part_1588_23121870.1381074284082--

.

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

10 sept 2013 =C7., 18:22:02 UTC+4 David Krauss :

> One solution would be to assign a serial number to each exception object,=
=20
> and discriminate on that instead.
>

I think that any kind of solution based on comparison of two exceptions=20
states is not reliable for 100%, by design.
C++ has heap objects, such objects can "fly" to any place with every=20
possible exception state since it's creation, it can be destructed in=20
context of any other destructor.
And whenever it is OK to throw from destructor of heap object depends more=
=20
on surrounding context, rather than solely on exception state, because=20
destruction may happen within any other destructor, where it may be safe to=
=20
throw, because that destructor has opportunity to catch, or it may be not=
=20
safe, because that destructor itself have thrown exception.
Just for example -=20
https://github.com/panaseleus/stack_unwinding/blob/master/examples/uncaught=
_exception_count_floating_object.cpp

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

<div dir=3D"ltr">10 sept 2013&nbsp;=C7., 18:22:02 UTC+4 David Krauss :<br><=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>One solut=
ion would be to assign a serial number to each exception object, and discri=
minate on that instead.<br></div></div></blockquote><div><br>I think that a=
ny kind of solution based on comparison of two exceptions states is not rel=
iable for 100%, by design.<br>C++ has heap objects, such objects can "fly" =
to any place with every possible exception state since it's creation, it ca=
n be destructed in context of any other destructor.<br>And whenever it is O=
K to throw from destructor of heap object depends more on surrounding conte=
xt, rather than solely on exception state, because destruction may happen w=
ithin any other destructor, where it may be safe to throw, because that des=
tructor has opportunity to catch, or it may be not safe, because that destr=
uctor itself have thrown exception.<br>Just for example - https://github.co=
m/panaseleus/stack_unwinding/blob/master/examples/uncaught_exception_count_=
floating_object.cpp<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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_50_20424651.1381076790927--

.

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

10 sept 2013 =C7., 20:34:09 UTC+4 Ville Voutilainen:
>
> If I read Evgeny Panasyuk's code correctly, it works on clang, gcc and=20
> msvc.
>

Yes, that is correct.
I even remember that occasionally I have tried Intel's compiler, but I=20
haven't documented that.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

<div dir=3D"ltr">10 sept 2013&nbsp;=C7., 20:34:09 UTC+4 Ville Voutilainen:<=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div>If I=
 read Evgeny Panasyuk's code correctly, it works on clang, gcc and msvc.<br=
></div></div></div></blockquote><div><br>Yes, that is correct.<br>I even re=
member that occasionally I have tried Intel's compiler, but I haven't docum=
ented that.<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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_41_12727014.1381077136801--

.

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

10 sept 2013 =C7., 22:32:58 UTC+4 inkwizyt...@gmail.com:
>
> I dont think that adding `uncaught_exception_ticket_t` is correct=20
> solution, this will require store it somewhere and it will be bigger than=
=20
> 1byte (probably 8bytes).
>

Just for note:
For implementation of ScopeGuard-like objects, i.e. scope(failure/success),=
=20
transaction, etc - it is enough to store only 1bit of state - last bit of=
=20
exception count.
Because within one scope uncaught_exception_count can be changed only by +1=
..
Example ( from scope(failure/success) implementation -=20
http://ideone.com/EKsBDB ) :
class uncaught_exception_count_latch
{
    unsigned char enter_state;
public:
    uncaught_exception_count_latch()
        : enter_state(static_cast<unsigned char>( uncaught_exception_count(=
)=20
& 1 ))
    {}
    bool transitioned() const
    {
        return enter_state !=3D ( uncaught_exception_count() & 1 );
    }
};

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

------=_Part_1607_20843627.1381077597315
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">10 sept 2013&nbsp;=D0=B3., 22:32:58 UTC+4 inkwizyt...@gmai=
l.com:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><span s=
tyle=3D"font-family:arial,sans-serif">I dont think that adding `</span><spa=
n style=3D"font-family:arial,sans-serif"><span style=3D"font-family:courier=
 new,monospace"><span style=3D"font-family:courier new,monospace">uncaught_=
exception_ticket_t</span></span>` is correct solution, this will require st=
ore it somewhere and it will be bigger than 1byte (probably 8bytes</span><s=
pan style=3D"font-family:arial,sans-serif">).</span><br></div></blockquote>=
<div><br>Just for note:<br>For implementation of ScopeGuard-like objects, i=
..e. scope(failure/success), transaction, etc - it is enough to store only 1=
bit of state - last bit of exception count.<br>Because within one scope unc=
aught_exception_count can be changed only by +1.<br>Example ( from scope(fa=
ilure/success) implementation - http://ideone.com/EKsBDB ) :<br><div class=
=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border-colo=
r: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wrap: b=
reak-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span=
 style=3D"color: #008;" class=3D"styled-by-prettify">class</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> uncaught_exception_count_l=
atch<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; </span><span style=3D"color: #008;" class=3D"styled-by-prettify">uns=
igned</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span style=3D"color: #008;" class=3D"styled-by-prettify">char</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> enter_state</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"c=
olor: #008;" class=3D"styled-by-prettify">public</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; uncaught_exception_count_lat=
ch</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: #660;" class=3D"styled-by-pret=
tify">:</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> en=
ter_state</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(=
</span><span style=3D"color: #008;" class=3D"styled-by-prettify">static_cas=
t</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</spa=
n><span style=3D"color: #008;" class=3D"styled-by-prettify">unsigned</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span sty=
le=3D"color: #008;" class=3D"styled-by-prettify">char</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">&gt;(</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> uncaught_exception_count</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=
: #660;" class=3D"styled-by-prettify">&amp;</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #066;" class=
=3D"styled-by-prettify">1</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">))</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><b=
r>&nbsp; &nbsp; </span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">{}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><b=
r>&nbsp; &nbsp; </span><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">bool</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 transitioned</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">()</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span style=3D"color: #008;" class=3D"styled-by-prettify">const</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; <=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; &n=
bsp; &nbsp; </span><span style=3D"color: #008;" class=3D"styled-by-prettify=
">return</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> e=
nter_state </span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>!=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> uncaught_exception_cou=
nt</span><span style=3D"color: #660;" class=3D"styled-by-prettify">()</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">&amp;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #066;" class=3D"styled-by-prettify">1</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-b=
y-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-prett=
ify">};</span></div></code></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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_1607_20843627.1381077597315--

.

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

11 sept 2013 =C7., 12:43:37 UTC+4 Ville Voutilainen:

> I don't deal with any of the implementations. I plan to write a=20
> continuation paper to Herb's proposal, since
> it is clear to me at least that just a bool won't cut it. I think I shoul=
d=20
> play with at least libsup++ to see what
> it can do. If you're interested in working on this area, I welcome=20
> contributions and co-authors.=20
>

I keep in mind this problem for about a year (since following article:=20
http://cpp-next.com/archive/2012/08/evil-or-just-misunderstood/ ). I am=20
willing to collaborate on this topic.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

<div dir=3D"ltr">11 sept 2013&nbsp;=C7., 12:43:37 UTC+4 Ville Voutilainen:<=
br><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div =
class=3D"gmail_quote"><div>I don't deal with any of the implementations. I =
plan to write a continuation paper to Herb's proposal, since<br></div><div>=
it is clear to me at least that just a bool won't cut it. I think I should =
play with at least libsup++ to see what<br>
</div><div>it can do. If you're interested in working on this area, I welco=
me contributions and co-authors. <br></div></div></div></div></blockquote><=
div><br>I keep in mind this problem for about a year (since following artic=
le: http://cpp-next.com/archive/2012/08/evil-or-just-misunderstood/ ). I am=
 willing to collaborate on this topic.<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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_245_19187307.1381086040844--

.