On 01/09/2013 01:10 AM, Nicol Bolas wrote:
> classSomeClass
> {
> public:
>   ~SomeClass()
>   {
>     if(unwind)
>     {
>       //Special cleanup for exception.
>     }
>   }
> private:
>   std::stack_unwinding unwind;
> };
>
> This would make it more clear to users reading the code what is
> actually going on. I'm not wedded to any of the names in this
> example; I just want an object that makes it more obvious what the
> code is detecting.

I'm sorry, I don't understand what you're aiming at.
Do you want such a class in the exposition in the paper, or
do you want such a class standardized?

Regarding the former, I've updated my paper to actually spell out
the "Transaction" example for the uncaught_exception_count() case,
which should do in terms of explanation.

Regarding the latter, I'm opposed on a few grounds:
 - a base or class data member can't have a size of one bit
 - This is a fringe feature:
     * I want to inflict as little change to the standard as feasible
       to get the feature.
     * People wanting the feature should be able to wrap their head
       around the uncaught_exception_count() logic, not needing and
       not having to learn another fairly thin helper class.
 - The standard text is not a tutorial.

See http://jmaurer.awardspace.info/wg21/destructor-unwinding.html
for the latest version of the paper.

Jens

--




.

------=_Part_2414_13589197.1357717535412
Content-Type: text/plain; charset=ISO-8859-1



On Tuesday, January 8, 2013 10:54:31 PM UTC-8, Jens Maurer wrote:
>
> On 01/09/2013 01:10 AM, Nicol Bolas wrote:
> > classSomeClass
> > {
> > public:
> >   ~SomeClass()
> >   {
> >     if(unwind)
> >     {
> >       //Special cleanup for exception.
> >     }
> >   }
> > private:
> >   std::stack_unwinding unwind;
> > };
> >
> > This would make it more clear to users reading the code what is
> > actually going on. I'm not wedded to any of the names in this
> > example; I just want an object that makes it more obvious what the
> > code is detecting.
>
> I'm sorry, I don't understand what you're aiming at.
> Do you want such a class in the exposition in the paper, or
> do you want such a class standardized?
>

I'm wanting the class in the actual proposal.

Regarding the former, I've updated my paper to actually spell out
> the "Transaction" example for the uncaught_exception_count() case,
> which should do in terms of explanation.
>
> Regarding the latter, I'm opposed on a few grounds:
>  - a base or class data member can't have a size of one bit
>

I'm not saying that the class would *replace* the direct use of
`std::uncaught_exception_count`. It is an alternative, nothing more. So if
you really need that space, you can directly use it. If you're like most
people, they're not going to need those 7 bits that badly, so they'll take
code readability over 7 bits of storage.

Though that brings up a question: if the count can only ever be 0 or 1...
why is it a *count*? Is that a kind of forward-compatibility thing (the
idea that the committee might later allow more than one exception to be
active), or is there something else to it?


>  - This is a fringe feature:
>      * I want to inflict as little change to the standard as feasible
>        to get the feature.
>

I rather doubt the presence or absence of a helper class would adversely
affect the acceptance of the feature.

     * People wanting the feature should be able to wrap their head
>        around the uncaught_exception_count() logic, not needing and
>        not having to learn another fairly thin helper class.
>

As others have pointed out in other threads, people read code more often
than they write it. A small helper class that makes code more legible and
more easily digestible is hardly something burdensome to learn. You just
read what it's called; that tells you what you need to know. It's certainly
easier to learn than idiomatic use of `std::uncaught_exception_count` for
this purpose. It's easier to learn to write and it's easier to learn to
read.

Also, making assumptions about the skill level of those who would and would
not be using the feature is... not wise. You shouldn't want to make a
feature hard to use on the assumption that only experts will want to use
it. Features should be as simple to use as possible without sacrificing
anything of value. And the class is simpler to use for the task of
detecting this sort of thing.

Yes, you'll still want the low-level mechanism. But the class is an obvious
bit of abstraction that makes it easier for all involved. Just like we have
std::thread, but also std::async as a quick-and-dirty means of throwing out
a task.

--




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

<br><br>On Tuesday, January 8, 2013 10:54:31 PM UTC-8, Jens Maurer wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;">On 01/09/2013 01:10 AM, Nicol Bo=
las wrote:
<br>&gt; classSomeClass
<br>&gt; {
<br>&gt; public:
<br>&gt; &nbsp; ~SomeClass()
<br>&gt; &nbsp; {
<br>&gt; &nbsp; &nbsp; if(unwind)
<br>&gt; &nbsp; &nbsp; {
<br>&gt; &nbsp; &nbsp; &nbsp; //Special cleanup for exception.
<br>&gt; &nbsp; &nbsp; }
<br>&gt; &nbsp; }
<br>&gt; private:
<br>&gt; &nbsp; std::stack_unwinding unwind;
<br>&gt; };
<br>&gt;=20
<br>&gt; This would make it more clear to users reading the code what is
<br>&gt; actually going on. I'm not wedded to any of the names in this
<br>&gt; example; I just want an object that makes it more obvious what the
<br>&gt; code is detecting.
<br>
<br>I'm sorry, I don't understand what you're aiming at.
<br>Do you want such a class in the exposition in the paper, or
<br>do you want such a class standardized?
<br></blockquote><div><br>I'm wanting the class in the actual proposal.<br>=
<br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
Regarding the former, I've updated my paper to actually spell out
<br>the "Transaction" example for the uncaught_exception_count() case,
<br>which should do in terms of explanation.
<br>
<br>Regarding the latter, I'm opposed on a few grounds:
<br>&nbsp;- a base or class data member can't have a size of one bit<br></b=
lockquote><div><br>I'm not saying that the class would <i>replace</i> the d=
irect use of `std::uncaught_exception_count`. It is an alternative, nothing=
 more. So if you really need that space, you can directly use it. If you're=
 like most people, they're not going to need those 7 bits that badly, so th=
ey'll take code readability over 7 bits of storage.<br><br>Though that brin=
gs up a question: if the count can only ever be 0 or 1... why is it a <i>co=
unt</i>? Is that a kind of forward-compatibility thing (the idea that the c=
ommittee might later allow more than one exception to be active), or is the=
re something else to it?<br>&nbsp;</div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-le=
ft: 1ex;">&nbsp;- This is a fringe feature:
<br>&nbsp; &nbsp; &nbsp;* I want to inflict as little change to the standar=
d as feasible
<br>&nbsp; &nbsp; &nbsp; &nbsp;to get the feature.
<br></blockquote><div><br>I rather doubt the presence or absence of a helpe=
r class would adversely affect the acceptance of the feature.<br><br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;">&nbsp; &nbsp; &nbsp;* People w=
anting the feature should be able to wrap their head
<br>&nbsp; &nbsp; &nbsp; &nbsp;around the uncaught_exception_count() logic,=
 not needing and
<br>&nbsp; &nbsp; &nbsp; &nbsp;not having to learn another fairly thin help=
er class.<br></blockquote><div><br>As others have pointed out in other thre=
ads, people read code more often than they write it. A small helper class t=
hat makes code more legible and more easily digestible is hardly something =
burdensome to learn. You just read what it's called; that tells you what yo=
u need to know. It's certainly easier to learn than idiomatic use of `std::=
uncaught_exception_count` for this purpose. It's easier to learn to write a=
nd it's easier to learn to read.<br><br>Also, making assumptions about the =
skill level of those who would and would not be using the feature is... not=
 wise. You shouldn't want to make a feature hard to use on the assumption t=
hat only experts will want to use it. Features should be as simple to use a=
s possible without sacrificing anything of value. And the class is simpler =
to use for the task of detecting this sort of thing.<br><br>Yes, you'll sti=
ll want the low-level mechanism. But the class is an obvious bit of abstrac=
tion that makes it easier for all involved. Just like we have std::thread, =
but also std::async as a quick-and-dirty means of throwing out a task.<br><=
/div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_2414_13589197.1357717535412--

.

This is a multi-part message in MIME format.
--------------030909020806010800040507
Content-Type: text/plain; charset=ISO-8859-1; format=flowed


> Though that brings up a question: if the count can only ever be 0 or
> 1... why is it a /count/? Is that a kind of forward-compatibility
> thing (the idea that the committee might later allow more than one
> exception to be active), or is there something else to it?
The count can be more than 1, otherwise the already existing
std::uncaught_exception would be enough. See the motivating example in
the proposal.
The 1bit version relies to the fact if the count is odd or even.


Mikael

--




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

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <br>
    <blockquote
      cite="mid:62834009-6cb4-434c-8e5c-47f498cdb87f@isocpp.org"
      type="cite">
      <div>Though that brings up a question: if the count can only ever
        be 0 or 1... why is it a <i>count</i>? Is that a kind of
        forward-compatibility thing (the idea that the committee might
        later allow more than one exception to be active), or is there
        something else to it?<br>
        &nbsp;</div>
    </blockquote>
    The count can be more than 1, otherwise the already existing
    std::uncaught_exception would be enough. See the motivating example
    in the proposal.<br>
    The 1bit version relies to the fact if the count is odd or even.<br>
    <br>
    <br>
    Mikael<br>
  </body>
</html>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

--------------030909020806010800040507--

.

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



On Wednesday, January 9, 2013 1:30:20 AM UTC-8, Mikael Kilpel=E4inen wrote:
>
> =20
>  Though that brings up a question: if the count can only ever be 0 or=20
> 1... why is it a *count*? Is that a kind of forward-compatibility thing=
=20
> (the idea that the committee might later allow more than one exception to=
=20
> be active), or is there something else to it?
> =20
>
> The count can be more than 1, otherwise the already existing=20
> std::uncaught_exception would be enough. See the motivating example in th=
e=20
> proposal.
>

I fail to see how. The motivating example could work if it were rewritten=
=20
like this:

struct Transaction
{
  bool currentException;

  Transaction() : currentException(std::uncaught_exception() ? true : false=
)
  ~Transaction()
  {
    if (!currentException && std::uncaught_exception())
      RollBack();
    else
      Commit();
  }
};

This should work:

U::~U()
{
  try
  {
    Transaction t( /*...*/ );
    // do work
  }
  catch( ... )
  {
    // clean up
  }
}

If `U::~U` is being called due to stack unwinding, then=20
`std::uncaught_exception()` will be a real value. Therefore,=20
Transaction::currentException will be `true`. And therefore it will not=20
roll anything back.

However, if `U::~U` was being called just from falling off the stack or an=
=20
explicit destructor call, then `Transaction::currentException` will be=20
`false`. If `do work` throws an exception, when `Transaction::~Transaction`=
=20
is called, then `std::uncaught_exception()` will be a value. And therefore=
=20
the conditions for a rollback are needed. Whereas if `do work` ends=20
normally, `std::uncaught_exception()` will not have anything in it, and=20
everyone will be fine.

I don't see how it's possible to have more than one uncaught exception. So=
=20
I don't see why we need a count when a boolean will do. Indeed, I'm not=20
sure why we can't just use `std::uncaught_exception()` as I demonstrated to=
=20
detect all of this.

If that code is too ugly, then wrap it in a nice class, as I explained.

The 1bit version relies to the fact if the count is odd or even.
>

I don't understand how that works. Let's assume that the number of uncaught=
=20
exceptions can be more than 1. Then it's entirely possible that it was 0 on=
=20
construction of the object, but 2 on destruction. So just checking odd vs.=
=20
even won't be sufficient.

--=20




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

<br><br>On Wednesday, January 9, 2013 1:30:20 AM UTC-8, Mikael Kilpel=E4ine=
n wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
 =20
   =20
 =20
  <div bgcolor=3D"#FFFFFF" text=3D"#000000">
    <br>
    <blockquote type=3D"cite">
      <div>Though that brings up a question: if the count can only ever
        be 0 or 1... why is it a <i>count</i>? Is that a kind of
        forward-compatibility thing (the idea that the committee might
        later allow more than one exception to be active), or is there
        something else to it?<br>
        &nbsp;</div>
    </blockquote>
    The count can be more than 1, otherwise the already existing
    std::uncaught_exception would be enough. See the motivating example
    in the proposal.<br></div></blockquote><div><br>I fail to see how. The =
motivating example could work if it were rewritten like this:<br><br><div c=
lass=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border-=
color: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wra=
p: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><=
span style=3D"color: #008;" class=3D"styled-by-prettify">struct</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D=
"color: #606;" class=3D"styled-by-prettify">Transaction</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br>&nbsp; </span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">bool</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> currentException</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><br>&nbsp; </span><span style=3D"color: #606;"=
 class=3D"styled-by-prettify">Transaction</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"style=
d-by-prettify">:</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><code class=3D"prettyprint"><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify">currentException</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify"></span></code><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">(</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify"><code class=3D"prettyprint"><span style=3D"color: #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"styl=
ed-by-prettify">uncaught_exception</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">()</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify"> ? true : false</span></code>)</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"><br>&nbsp; </span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">~</span><span style=3D"color: #606;" c=
lass=3D"styled-by-prettify">Transaction</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">()</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"><br>&nbsp; </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br>&nbsp; &nbsp; </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">if</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">(!</span><code class=3D"prettyprint"><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify">currentException</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify"></span></code><span style=3D"color: #660;"=
 class=3D"styled-by-prettify"> &amp;&amp; std::uncaught_exception())</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp;=
 &nbsp; </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Ro=
llBack</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">els=
e</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp=
; &nbsp; &nbsp; </span><span style=3D"color: #606;" class=3D"styled-by-pret=
tify">Commit</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">();</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&=
nbsp; </span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">};</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div></code></d=
iv><br>This should work:<br><br><div class=3D"prettyprint" style=3D"backgro=
und-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-sty=
le: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"pretty=
print"><div class=3D"subprettyprint"><span style=3D"color: #000;" class=3D"=
styled-by-prettify">U</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">::~</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy">U</span><span style=3D"color: #660;" class=3D"styled-by-prettify">()</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">{</span><br><span s=
tyle=3D"color: #008;" class=3D"styled-by-prettify">&nbsp; try</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; </span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">{<br>&nbsp;&nbsp;&nbsp;=
 </span><span style=3D"color: #000;" class=3D"styled-by-prettify"></span><s=
pan style=3D"color: #606;" class=3D"styled-by-prettify">Transaction</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> t</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #800;=
" 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">);<br>&nbsp;&nbsp;&nbsp; </span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"></span><span style=3D"color: #800;" class=
=3D"styled-by-prettify">// do work<br>&nbsp; }<br>&nbsp; catch( ... )<br>&n=
bsp; {<br>&nbsp;&nbsp;&nbsp; // clean up<br>&nbsp; }<br> }</span></div></co=
de></div><br>If `U::~U` is being called due to stack unwinding, then `std::=
uncaught_exception()` will be a real value. Therefore, Transaction::current=
Exception will be `true`. And therefore it will not roll anything back.<br>=
<br>However, if `U::~U` was being called just from falling off the stack or=
 an explicit destructor call, then `Transaction::currentException` will be =
`false`. If `do work` throws an exception, when `Transaction::~Transaction`=
 is called, then `std::uncaught_exception()` will be a value. And therefore=
 the conditions for a rollback are needed. Whereas if `do work` ends normal=
ly, `std::uncaught_exception()` will not have anything in it, and everyone =
will be fine.<br><br>I don't see how it's possible to have more than one un=
caught exception. So I don't see why we need a count when a boolean will do=
.. Indeed, I'm not sure why we can't just use `std::uncaught_exception()` as=
 I demonstrated to detect all of this.<br><br>If that code is too ugly, the=
n wrap it in a nice class, as I explained.<br><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div bgcolor=3D"#FFFFFF" text=3D"#000000">
    The 1bit version relies to the fact if the count is odd or even.<br></d=
iv></blockquote><div><br>I don't understand how that works. Let's assume th=
at the number of uncaught exceptions can be more than 1. Then it's entirely=
 possible that it was 0 on construction of the object, but 2 on destruction=
.. So just checking odd vs. even won't be sufficient.<br></div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1711_11332740.1357727418034--

.

> I don't understand how that works. Let's assume that the number of
> uncaught exceptions can be more than 1. Then it's entirely possible
> that it was 0 on construction of the object, but 2 on destruction. So
> just checking odd vs. even won't be sufficient.


If

try {
   Foo f;
   throw 42;
} catch (int) }
}

is executed in a destructor, whatever the number of uncought exceptions
is when constructing f, it will be one more when its destructor is
executed.

You can't construct similar cases where it would be two more because
std::terminate() will be called before.

Yours,

--
Jean-Marc

--




.

> If `U::~U` is being called due to stack unwinding, then
> `std::uncaught_exception()` will be a real value. Therefore,
> Transaction::currentException will be `true`. And therefore it will
> not roll anything back.
>
If the "do work" throws you are still committing, that is the case you
cannot deduce from this information. In this case you would have two
exceptions in progress, the original one that caused the ~U call and the
one thrown inside the ~U. This is all good as long as the ~U doesn't
leak the exception.

>
> I don't understand how that works. Let's assume that the number of
> uncaught exceptions can be more than 1. Then it's entirely possible
> that it was 0 on construction of the object, but 2 on destruction. So
> just checking odd vs. even won't be sufficient.
The idea is.. The count can be arbitrary but since we cannot allow
destructor to leak the exception (which would terminate) the count can
change only by one in this stack frame.


Mikael

--




.

------=_Part_225_84629.1357729563917
Content-Type: text/plain; charset=ISO-8859-1



On Wednesday, January 9, 2013 2:52:01 AM UTC-8, Jean-Marc Bourguet wrote:
>
>
> > I don't understand how that works. Let's assume that the number of
> > uncaught exceptions can be more than 1. Then it's entirely possible
> > that it was 0 on construction of the object, but 2 on destruction. So
> > just checking odd vs. even won't be sufficient.
>
>
> If
>
> try {
>    Foo f;
>    throw 42;
> } catch (int) }
> }
>
> is executed in a destructor, whatever the number of uncought exceptions
> is when constructing f, it will be one more when its destructor is
> executed.
>
> You can't construct similar cases where it would be two more because
> std::terminate() will be called before.
>

If you cannot construct cases where it would be two more than it was
before, then you cannot construct cases where it will be *two* at all. You
throw an exception, the counter gets bumped. Once the stack unwinding
finishes, the counter goes back down.

Unless `std::uncaught_exception_count` is intended to be some kind of
global (or at least thread-local) counter, where every time an exception is
thrown, it is bumped and it never goes down. If so, then the proposal
should be updated, because "The exception implementation maintains a count
of exceptions currently causing stack unwinding," is very misleading in
this regard.

If stack unwinding is happening, it will only ever be due to one exception.
So the count will be either 0 or 1.

--




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

<br><br>On Wednesday, January 9, 2013 2:52:01 AM UTC-8, Jean-Marc Bourguet =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>&gt; I don't understand how that works. Let's assume that the number of
<br>&gt; uncaught exceptions can be more than 1. Then it's entirely possibl=
e
<br>&gt; that it was 0 on construction of the object, but 2 on destruction.=
 So
<br>&gt; just checking odd vs. even won't be sufficient.
<br>
<br>
<br>If
<br>
<br>try {
<br>&nbsp; &nbsp;Foo f;
<br>&nbsp; &nbsp;throw 42;
<br>} catch (int) }
<br>}
<br>
<br>is executed in a destructor, whatever the number of uncought exceptions
<br>is when constructing f, it will be one more when its destructor is
<br>executed.
<br>
<br>You can't construct similar cases where it would be two more because=20
<br>std::terminate() will be called before.<br></blockquote><div><br>If you=
 cannot construct cases where it would be two more than it was before, then=
 you cannot construct cases where it will be <i>two</i> at all. You throw a=
n exception, the counter gets bumped. Once the stack unwinding finishes, th=
e counter goes back down.<br><br>Unless `std::uncaught_exception_count` is =
intended to be some kind of global (or at least thread-local) counter, wher=
e every time an exception is thrown, it is bumped and it never goes down. I=
f so, then the proposal should be updated, because "The exception implement=
ation maintains a count of exceptions currently causing stack unwinding," i=
s very misleading in this regard.<br><br>If stack unwinding is happening, i=
t will only ever be due to one exception. So the count will be either 0 or =
1.<br></div><br>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_225_84629.1357729563917--

.

------=_Part_99_23778528.1357729862236
Content-Type: text/plain; charset=ISO-8859-1

On Wednesday, January 9, 2013 2:30:18 PM UTC+4, Nicol Bolas wrote:
>
>
> I don't see how it's possible to have more than one uncaught exception.
>

There may be nested destructor calls:
http://liveworkspace.org/code/2WPjRQ$0


> I don't understand how that works. Let's assume that the number of
> uncaught exceptions can be more than 1. Then it's entirely possible that it
> was 0 on construction of the object, but 2 on destruction.
>

That's impossible if by "on destruction" you mean "when the object's
destructor is just entered".

--




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

On Wednesday, January 9, 2013 2:30:18 PM UTC+4, Nicol Bolas wrote:<blockquo=
te class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left:=
 1px #ccc solid;padding-left: 1ex;"><br><div>I don't see how it's possible =
to have more than one uncaught exception.</div></blockquote><div><br>There =
may be nested destructor calls:<br>http://liveworkspace.org/code/2WPjRQ$0<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>I don't und=
erstand how that works. Let's assume that the number of uncaught exceptions=
 can be more than 1. Then it's entirely possible that it was 0 on construct=
ion of the object, but 2 on destruction.<br></div></blockquote><div><br>Tha=
t's impossible if by "on destruction" you mean "when the object's destructo=
r is just entered".<br></div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_99_23778528.1357729862236--

.

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



On Wednesday, January 9, 2013 2:52:49 AM UTC-8, Mikael Kilpel=E4inen wrote:
>
>
> > If `U::~U` is being called due to stack unwinding, then=20
> > `std::uncaught_exception()` will be a real value. Therefore,=20
> > Transaction::currentException will be `true`. And therefore it will=20
> > not roll anything back.=20
> >=20
> If the "do work" throws you are still committing, that is the case you=20
> cannot deduce from this information. In this case you would have two=20
> exceptions in progress, the original one that caused the ~U call and the=
=20
> one thrown inside the ~U. This is all good as long as the ~U doesn't=20
> leak the exception.
>

I forgot that you could get multiple unwindings without std::terminate as=
=20
long as the destructor doesn't leak. So you're right, we do need a count.=
=20
And it would seem that, because the exceptions can't leak, that the counter=
=20
will only ever be either the current count or the current count - 1. So the=
=20
1-bit version does work.

--=20




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

<br><br>On Wednesday, January 9, 2013 2:52:49 AM UTC-8, Mikael Kilpel=E4ine=
n wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>&gt; If `U::~U` is being called due to stack unwinding, then=20
<br>&gt; `std::uncaught_exception()` will be a real value. Therefore,=20
<br>&gt; Transaction::currentException will be `true`. And therefore it wil=
l=20
<br>&gt; not roll anything back.
<br>&gt;
<br>If the "do work" throws you are still committing, that is the case you=
=20
<br>cannot deduce from this information. In this case you would have two=20
<br>exceptions in progress, the original one that caused the ~U call and th=
e=20
<br>one thrown inside the ~U. This is all good as long as the ~U doesn't=20
<br>leak the exception.<br></blockquote><div><br>I forgot that you could ge=
t multiple unwindings without std::terminate as long as the destructor does=
n't leak. So you're right, we do need a count. And it would seem that, beca=
use the exceptions can't leak, that the counter will only ever be either th=
e current count or the current count - 1. So the 1-bit version does work.</=
div><br>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1164_6581142.1357730074985--

.

--Apple-Mail=_BDC39EFE-F097-4C54-84C7-C87E1BACC225
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1


Il giorno 09/gen/2013, alle ore 08:45, Nicol Bolas <jmckesson@gmail.com> ha=
 scritto:

>=20
>=20
> On Tuesday, January 8, 2013 10:54:31 PM UTC-8, Jens Maurer wrote:
> On 01/09/2013 01:10 AM, Nicol Bolas wrote:=20
> > classSomeClass=20
> > {=20
> > public:=20
> >   ~SomeClass()=20
> >   {=20
> >     if(unwind)=20
> >     {=20
> >       //Special cleanup for exception.=20
> >     }=20
> >   }=20
> > private:=20
> >   std::stack_unwinding unwind;=20
> > };=20
> >=20
> > This would make it more clear to users reading the code what is=20
> > actually going on. I'm not wedded to any of the names in this=20
> > example; I just want an object that makes it more obvious what the=20
> > code is detecting.=20
>=20
> I'm sorry, I don't understand what you're aiming at.=20
> Do you want such a class in the exposition in the paper, or=20
> do you want such a class standardized?=20
>=20
> I'm wanting the class in the actual proposal.

I believe the class approach has its merits. The interface is clearer and m=
ore readable than a pair of calls to uncaught_exception_count(). Moreover, =
a static code analyzer might easily detect the intended pattern and provide=
 a warning message if class SomeClass is ever allocated on the heap. Given =
that static code analyzers are becoming more popular every day, the value o=
f this should not be underestimated.

Ganesh

--=20




--Apple-Mail=_BDC39EFE-F097-4C54-84C7-C87E1BACC225
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Diso-8859-1"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mo=
de: space; -webkit-line-break: after-white-space; "><br><div><div>Il giorno=
 09/gen/2013, alle ore 08:45, Nicol Bolas &lt;<a href=3D"mailto:jmckesson@g=
mail.com">jmckesson@gmail.com</a>&gt; ha scritto:</div><br class=3D"Apple-i=
nterchange-newline"><blockquote type=3D"cite"><br><br>On Tuesday, January 8=
, 2013 10:54:31 PM UTC-8, Jens Maurer wrote:<blockquote class=3D"gmail_quot=
e" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddin=
g-left: 1ex;">On 01/09/2013 01:10 AM, Nicol Bolas wrote:
<br>&gt; classSomeClass
<br>&gt; {
<br>&gt; public:
<br>&gt; &nbsp; ~SomeClass()
<br>&gt; &nbsp; {
<br>&gt; &nbsp; &nbsp; if(unwind)
<br>&gt; &nbsp; &nbsp; {
<br>&gt; &nbsp; &nbsp; &nbsp; //Special cleanup for exception.
<br>&gt; &nbsp; &nbsp; }
<br>&gt; &nbsp; }
<br>&gt; private:
<br>&gt; &nbsp; std::stack_unwinding unwind;
<br>&gt; };
<br>&gt;=20
<br>&gt; This would make it more clear to users reading the code what is
<br>&gt; actually going on. I'm not wedded to any of the names in this
<br>&gt; example; I just want an object that makes it more obvious what the
<br>&gt; code is detecting.
<br>
<br>I'm sorry, I don't understand what you're aiming at.
<br>Do you want such a class in the exposition in the paper, or
<br>do you want such a class standardized?
<br></blockquote><div><br>I'm wanting the class in the actual proposal.<br>=
</div></blockquote></div><br><div>I believe the class approach has its meri=
ts. The interface is clearer and more readable than a pair of calls to unca=
ught_exception_count(). Moreover, a static code analyzer might easily detec=
t the intended pattern and provide a warning message if class SomeClass is =
ever allocated on the heap. Given that static code&nbsp;analyzers are becom=
ing more popular every day, the value of this should not be underestimated.=
</div><div><br></div><div>Ganesh</div><div><br></div></body></html>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

--Apple-Mail=_BDC39EFE-F097-4C54-84C7-C87E1BACC225--

.

On Tue, Jan 15, 2013 at 10:18 AM, Alberto Ganesh Barbati wrote:
>
>> On 01/09/2013 01:10 AM, Nicol Bolas wrote:
>> > class SomeClass
>> > {
>> > public:
>> >   ~SomeClass()
>> >   {
>> >     if(unwind)
>> >     {
>> >       //Special cleanup for exception.
>> >     }
>> >   }
>> > private:
>> >   std::stack_unwinding unwind;
>> > };
>> >
>> > This would make it more clear to users reading the code what is
>> > actually going on. I'm not wedded to any of the names in this
>> > example; I just want an object that makes it more obvious what the
>> > code is detecting.
>
> I believe the class approach has its merits. The interface is clearer and
> more readable than a pair of calls to uncaught_exception_count(). Moreover,
> a static code analyzer might easily detect the intended pattern and provide
> a warning message if class SomeClass is ever allocated on the heap. Given
> that static code analyzers are becoming more popular every day, the value of
> this should not be underestimated.

I have trouble predicting how a stack-allocated vector<SomeClass>
behaves during unwinding. But I guess it would just work and that
there is no need to warn about heap allocation in this case. So, even
though some object is heap-allocated, its life-time might still be
bounded by the life-time of a stack-allocated object.

--




.

Il giorno 15/gen/2013, alle ore 10:34, Sebastian Gesemann <s.gesemann@gmail.com> ha scritto:

> On Tue, Jan 15, 2013 at 10:18 AM, Alberto Ganesh Barbati wrote:
>>
>>> On 01/09/2013 01:10 AM, Nicol Bolas wrote:
>>>> class SomeClass
>>>> {
>>>> public:
>>>>  ~SomeClass()
>>>>  {
>>>>    if(unwind)
>>>>    {
>>>>      //Special cleanup for exception.
>>>>    }
>>>>  }
>>>> private:
>>>>  std::stack_unwinding unwind;
>>>> };
>>>>
>>>> This would make it more clear to users reading the code what is
>>>> actually going on. I'm not wedded to any of the names in this
>>>> example; I just want an object that makes it more obvious what the
>>>> code is detecting.
>>
>> I believe the class approach has its merits. The interface is clearer and
>> more readable than a pair of calls to uncaught_exception_count(). Moreover,
>> a static code analyzer might easily detect the intended pattern and provide
>> a warning message if class SomeClass is ever allocated on the heap. Given
>> that static code analyzers are becoming more popular every day, the value of
>> this should not be underestimated.
>
> I have trouble predicting how a stack-allocated vector<SomeClass>
> behaves during unwinding. But I guess it would just work and that
> there is no need to warn about heap allocation in this case. So, even
> though some object is heap-allocated, its life-time might still be
> bounded by the life-time of a stack-allocated object.

The accuracy of the warning is a QOI issue. A static analyzer might or might not be smart enough to avoid false positives as the one you describe. In any case, it is a not a good reason against providing a tool that allows an analyzer to make a choice.

Ganesh

--




.

------=_Part_2480_10422187.1364131437102
Content-Type: text/plain; charset=ISO-8859-1

I believe that the simpler approach is simply to pass the exception object
into the destructor, if it is the cause of the destructor being called.
Consider:

struct Transaction {
    ~Transaction() { commit(); }
    ~Transaction(std::runtime_error& e) { rollback(); }
};

This would also permit other use cases designs, like

struct layered_exception {
     std::vector<std::string> messages;
};

struct ExceptionInfo {
    std::string data;
    ~ExceptionInfo() {}
    ~ExceptionInfo(layered_exception& e) { e.messages.push_back(data); }
};

Implicitly ~T(...) simply calls ~T().

--

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



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

I believe that the simpler approach is simply to pass the exception object =
into the destructor, if it is the cause of the destructor being called. Con=
sider:<div><br></div><div>struct Transaction {<br>&nbsp; &nbsp; ~Transactio=
n() { commit(); }</div><div>&nbsp; &nbsp; ~Transaction(std::runtime_error&a=
mp; e) { rollback(); }</div><div>};</div><div><br></div><div>This would als=
o permit other use cases designs, like</div><div><br></div><div>struct laye=
red_exception {<br>&nbsp; &nbsp; &nbsp;std::vector&lt;std::string&gt; messa=
ges;</div><div>};</div><div><br></div><div>struct ExceptionInfo {<br>&nbsp;=
 &nbsp; std::string data;</div><div>&nbsp; &nbsp; ~ExceptionInfo() {}<br>&n=
bsp; &nbsp; ~ExceptionInfo(layered_exception&amp; e) { e.messages.push_back=
(data); }</div><div>};</div><div><br></div><div>Implicitly ~T(...) simply c=
alls ~T().</div>

<p></p>

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

------=_Part_2480_10422187.1364131437102--

.

------=_Part_251_16264120.1364157801280
Content-Type: text/plain; charset=ISO-8859-1



On Sunday, March 24, 2013 6:23:57 AM UTC-7, DeadMG wrote:
>
> I believe that the simpler approach is simply to pass the exception object
> into the destructor, if it is the cause of the destructor being called.
> Consider:
>
> struct Transaction {
>     ~Transaction() { commit(); }
>     ~Transaction(std::runtime_error& e) { rollback(); }
> };
>
> This would also permit other use cases designs, like
>
> struct layered_exception {
>      std::vector<std::string> messages;
> };
>
> struct ExceptionInfo {
>     std::string data;
>     ~ExceptionInfo() {}
>     ~ExceptionInfo(layered_exception& e) { e.messages.push_back(data); }
> };
>
> Implicitly ~T(...) simply calls ~T().
>

So what do you do if you don't care what the exception was, like 90+% of
the use cases? It'd be strange if `~T(...)` was not a variadic function and
instead had some other meaning. It would also be strange if you couldn't
explicitly call one of these destructor. Yet doing so represents a problem;
you shouldn't be able to invoke this code unless actual exception-based
stack unwinding is happening.

--

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



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

<br><br>On Sunday, March 24, 2013 6:23:57 AM UTC-7, DeadMG wrote:<blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;">I believe that the simpler approach is s=
imply to pass the exception object into the destructor, if it is the cause =
of the destructor being called. Consider:<div><br></div><div>struct Transac=
tion {<br>&nbsp; &nbsp; ~Transaction() { commit(); }</div><div>&nbsp; &nbsp=
; ~Transaction(std::runtime_<wbr>error&amp; e) { rollback(); }</div><div>};=
</div><div><br></div><div>This would also permit other use cases designs, l=
ike</div><div><br></div><div>struct layered_exception {<br>&nbsp; &nbsp; &n=
bsp;std::vector&lt;std::string&gt; messages;</div><div>};</div><div><br></d=
iv><div>struct ExceptionInfo {<br>&nbsp; &nbsp; std::string data;</div><div=
>&nbsp; &nbsp; ~ExceptionInfo() {}<br>&nbsp; &nbsp; ~ExceptionInfo(layered_=
<wbr>exception&amp; e) { e.messages.push_back(data); }</div><div>};</div><d=
iv><br></div><div>Implicitly ~T(...) simply calls ~T().</div></blockquote><=
div><br>So what do you do if you don't care what the exception was, like 90=
+% of the use cases? It'd be strange if `~T(...)` was not a variadic functi=
on and instead had some other meaning. It would also be strange if you coul=
dn't explicitly call one of these destructor. Yet doing so represents a pro=
blem; you shouldn't be able to invoke this code unless actual exception-bas=
ed stack unwinding is happening.<br></div>

<p></p>

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

------=_Part_251_16264120.1364157801280--

.

------=_Part_2858_18702208.1364158399900
Content-Type: text/plain; charset=ISO-8859-1

Nicol: It appears to me that it is intrinsically necessary for them to be
both regular functions and indeed, explicitly callable. Consider what would
happen in, say, std::vector's destructor- it would have to pass on the
exception to the contained objects' destructors.

Conceptually, ~T(...) would be fine for cases where you don't care what the
exception was. Although I admit it would be strange for it to have
different semantics to regular variadic functions, I don't think this is a
serious problem, since destructors in general are a special case in
virtually every scenario anyway, so it's hardly surprising to find that a
destructor has a different rule. Since the argument is inaccessible anyway,
it would be simplest to simply specify that if ~T(...) is resolved by
overload resolution, then no argument is passed, which also sidesteps the
issue of UB for complex types.

--

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



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

Nicol: It appears to me that it is intrinsically necessary for them to be b=
oth regular functions and indeed, explicitly callable. Consider what would =
happen in, say, std::vector's destructor- it would have to pass on the exce=
ption to the contained objects' destructors.<div><br></div><div>Conceptuall=
y, ~T(...) would be fine for cases where you don't care what the exception =
was. Although I admit it would be strange for it to have different semantic=
s to regular variadic functions, I don't think this is a serious problem, s=
ince destructors in general are a special case in virtually every scenario =
anyway, so it's hardly surprising to find that a destructor has a different=
 rule. Since the argument is inaccessible anyway, it would be simplest to s=
imply specify that if ~T(...) is resolved by overload resolution, then no a=
rgument is passed, which also sidesteps the issue of UB for complex types.<=
/div>

<p></p>

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

------=_Part_2858_18702208.1364158399900--

.

------=_Part_7_20911938.1364162900476
Content-Type: text/plain; charset=ISO-8859-1

On Sunday, March 24, 2013 1:53:19 PM UTC-7, DeadMG wrote:
>
> Nicol: It appears to me that it is intrinsically necessary for them to be
> both regular functions and indeed, explicitly callable. Consider what would
> happen in, say, std::vector's destructor- it would have to pass on the
> exception to the contained objects' destructors.


Right but... why do we want that? If all I want is to know whether my
destructor is being called due to stack unwinding, do I really want to
declare a whole new function just to know that? If there was a real need to
be able to differentiate this stuff, then that might be fine. But what are
the use cases for wanting to do different things based on exceptions,
rather than just asking, "am I being destroyed because of unwinding?"

More importantly, what happens if a class doesn't implement a destructor
for a particular exception, yet std::vector wants to explicitly call it?
Does it call `~T()`? You can't really call it a "regular function" if
calling it doesn't work regularly, if calling it with parameters can just
ignore those parameters and call a completely different overload without
any implicit conversion or anything.

Even more importantly, consider std::unique_ptr. Do we want
std::default_delete to be passed an exception? Does it need to have this?

template<class U, class E>
void operator() (T*, E&) const;

And how would you implement it? The `T` pointer is assumed to be allocated
via `new T`; therefore, it *must* be deleted with `delete T`. You can't
call its destructor directly, because there's no way to deallocate the
memory correctly. I'm fairly sure C++ doesn't protect this:

T *t = new T;
t->~T();
delete reinterpret_cast<char *>(t);

As much as I *hate* the stack unwinding count, it seems to be the only
solution presented (thus far) that can cover all of the cases of forwarding
the information about unwinding to all of its descendents, regardless of
how they were allocated/deallocated.

Conceptually, ~T(...) would be fine for cases where you don't care what the
> exception was. Although I admit it would be strange for it to have
> different semantics to regular variadic functions, I don't think this is a
> serious problem, since destructors in general are a special case in
> virtually every scenario anyway, so it's hardly surprising to find that a
> destructor has a different rule. Since the argument is inaccessible anyway,
> it would be simplest to simply specify that if ~T(...) is resolved by
> overload resolution, then no argument is passed, which also sidesteps the
> issue of UB for complex types.
>

I'm not sure how that's "simple" this is. You're talking about making this
work in a way that's completely foreign to how anything else in C++ works.
I'm not saying you can't do it, but it isn't "simple" if people have to
learn entirely new rules for how parameters work.

--

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



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

On Sunday, March 24, 2013 1:53:19 PM UTC-7, DeadMG wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;">Nicol: It appears to me that it is intrinsicall=
y necessary for them to be both regular functions and indeed, explicitly ca=
llable. Consider what would happen in, say, std::vector's destructor- it wo=
uld have to pass on the exception to the contained objects' destructors.</b=
lockquote><div><br>Right but... why do we want that? If all I want is to kn=
ow whether my destructor is being called due to stack unwinding, do I reall=
y want to declare a whole new function just to know that? If there was a re=
al need to be able to differentiate this stuff, then that might be fine. Bu=
t what are the use cases for wanting to do different things based on except=
ions, rather than just asking, "am I being destroyed because of unwinding?"=
<br><br>More importantly, what happens if a class doesn't implement a destr=
uctor for a particular exception, yet std::vector wants to explicitly call =
it? Does it call `~T()`? You can't really call it a "regular function" if c=
alling it doesn't work regularly, if calling it with parameters can just ig=
nore those parameters and call a completely different overload without any =
implicit conversion or anything.<br><br>Even more importantly, consider std=
::unique_ptr. Do we want std::default_delete to be passed an exception? Doe=
s it need to have this?<br><br><div class=3D"prettyprint" style=3D"backgrou=
nd-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-styl=
e: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"prettyp=
rint"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"s=
tyled-by-prettify">template</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">&lt;</span><span style=3D"color: #008;" class=3D"styled-by=
-prettify">class</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> U</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">class</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> E</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">&gt;</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #008;"=
 class=3D"styled-by-prettify">void</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">operator</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">()</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify">T</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">*,</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> E</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">&amp;)</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">const</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">;</span></div></code></div><br>And how would you imple=
ment it? The `T` pointer is assumed to be allocated via `new T`; therefore,=
 it <i>must</i> be deleted with `delete T`. You can't call its destructor d=
irectly, because there's no way to deallocate the memory correctly. I'm fai=
rly sure C++ doesn't protect this:<br><br><div class=3D"prettyprint" style=
=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187);=
 border-style: solid; border-width: 1px; word-wrap: break-word;"><code clas=
s=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #000;=
" class=3D"styled-by-prettify">T </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">*</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify">t </span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 </span><span style=3D"color: #008;" class=3D"styled-by-prettify">new</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> T</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><br>t</span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">-&gt;~</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify">T</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">();</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-by=
-prettify">delete</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">re=
interpret_cast</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">&lt;</span><span style=3D"color: #008;" class=3D"styled-by-prettify">ch=
ar</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">*&gt;(</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify">t</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">);</span></div></code></div>=
<br>As much as I <i>hate</i> the stack unwinding count, it seems to be the =
only solution presented (thus far) that can cover all of the cases of forwa=
rding the information about unwinding to all of its descendents, regardless=
 of how they were allocated/deallocated.<br><br></div><blockquote class=3D"=
gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc so=
lid;padding-left: 1ex;"><div>Conceptually, ~T(...) would be fine for cases =
where you don't care what the exception was. Although I admit it would be s=
trange for it to have different semantics to regular variadic functions, I =
don't think this is a serious problem, since destructors in general are a s=
pecial case in virtually every scenario anyway, so it's hardly surprising t=
o find that a destructor has a different rule. Since the argument is inacce=
ssible anyway, it would be simplest to simply specify that if ~T(...) is re=
solved by overload resolution, then no argument is passed, which also sides=
teps the issue of UB for complex types.</div></blockquote><div><br>I'm not =
sure how that's "simple" this is. You're talking about making this work in =
a way that's completely foreign to how anything else in C++ works. I'm not =
saying you can't do it, but it isn't "simple" if people have to learn entir=
ely new rules for how parameters work.<br></div>

<p></p>

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

------=_Part_7_20911938.1364162900476--

.

------=_Part_397_26855969.1364165486606
Content-Type: text/plain; charset=ISO-8859-1


>
> I'm not sure how that's "simple" this is. You're talking about making this
> work in a way that's completely foreign to how anything else in C++ works


Variadic arguments are used solely for the purpose of guiding overload
resolution all the time in some SFINAE techniques. We also use it in
*exactly* this fashion in catch(...), which is exactly what I had in mind
when suggesting it.

But what are the use cases for wanting to do different things based on
> exceptions, rather than just asking, "am I being destroyed because of
> unwinding?"


The use case I showed is being able to add additional information to the
exception object, something which is currently impossible.

More importantly, what happens if a class doesn't implement a destructor
> for a particular exception, yet std::vector wants to explicitly call it?
> Does it call `~T()`?


~T(...) behaves just like a regular function w.r.t. overload resolution, so
~T(...) will be called. The implicit definition simply calls ~T(), so
there's no need for any user code to update as a result of this if they
don't need this functionality.

Even more importantly, consider std::unique_ptr. Do we want
> std::default_delete to be passed an exception? Does it need to have this?
> And how would you implement it? The `T` pointer is assumed to be allocated
> via `new T`; therefore, it *must* be deleted with `delete T`. You can't
> call its destructor directly, because there's no way to deallocate the
> memory correctly.


These points I had not considered. It would, indeed, require
std::default_delete to be passed an exception (if one occurred) and it
would also require essentially new syntax for `delete` to call the
appropriate destructor- perhaps `delete T(except);`.

Conceptually, it offers something more complete than the count-based
proposal, which is that you can inspect or mutate exceptions without
actually having to throw and catch them, and you don't have to deal with
the count. But it definitely also seems to be more of a challenge to
specify and implement.

It might be simpler instead to simply build on the previously-suggested
std::stack_unwind by adding a method which could be used to get the current
exception object- perhaps something like get_exception_as<T>() returning T*.

--

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



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

<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; borde=
r-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style=
: solid; padding-left: 1ex;">I'm not sure how that's "simple" this is. You'=
re talking about making this work in a way that's completely foreign to how=
 anything else in C++ works</blockquote><div><br></div>Variadic arguments a=
re used solely for the purpose of guiding overload resolution all the time =
in some SFINAE techniques. We also use it in *exactly* this fashion in catc=
h(...), which is exactly what I had in mind when suggesting it.<div><br></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; bo=
rder-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-st=
yle: solid; padding-left: 1ex;">But what are the use cases for wanting to d=
o different things based on exceptions, rather than just asking, "am I bein=
g destroyed because of unwinding?"</blockquote><div><br></div><div>The use =
case I showed is being able to add additional information to the exception =
object, something which is currently impossible.&nbsp;</div><div><br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; borde=
r-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style=
: solid; padding-left: 1ex;">More importantly, what happens if a class does=
n't implement a destructor for a particular exception, yet std::vector want=
s to explicitly call it? Does it call `~T()`?</blockquote><div><br></div><d=
iv>~T(...) behaves just like a regular function w.r.t. overload resolution,=
 so ~T(...) will be called. The implicit definition simply calls ~T(), so t=
here's no need for any user code to update as a result of this if they don'=
t need this functionality.</div><div><br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-le=
ft-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"=
>Even more importantly, consider std::unique_ptr. Do we want std::default_d=
elete to be passed an exception? Does it need to have this? And how would y=
ou implement it? The `T` pointer is assumed to be allocated via `new T`; th=
erefore, it&nbsp;<i>must</i>&nbsp;be deleted with `delete T`. You can't cal=
l its destructor directly, because there's no way to deallocate the memory =
correctly.</blockquote><div><br></div><div>These points I had not considere=
d. It would, indeed, require std::default_delete to be passed an exception =
(if one occurred) and it would also require essentially new syntax for `del=
ete` to call the appropriate destructor- perhaps `delete T(except);`.&nbsp;=
</div><div><br></div><div>Conceptually, it offers something more complete t=
han the count-based proposal, which is that you can inspect or mutate excep=
tions without actually having to throw and catch them, and you don't have t=
o deal with the count. But it definitely also seems to be more of a challen=
ge to specify and implement.</div><div><br></div><div>It might be simpler i=
nstead to simply build on the previously-suggested std::stack_unwind by add=
ing a method which could be used to get the current exception object- perha=
ps something like get_exception_as&lt;T&gt;() returning T*.</div>

<p></p>

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

------=_Part_397_26855969.1364165486606--

.

On 25 March 2013 00:51, DeadMG <wolfeinstein@gmail.com> wrote:
> It might be simpler instead to simply build on the previously-suggested
> std::stack_unwind by adding a method which could be used to get the current
> exception object- perhaps something like get_exception_as<T>() returning T*.

Yep - the existing current_exception() has the limitation that it
won't return an exception
until a handler has been activated. With the stack_unwind, we know
that there's an exception,
but there's no way to get any information about that exception.

--

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



.

------=_Part_495_26254731.1364171423771
Content-Type: text/plain; charset=ISO-8859-1



On Sunday, March 24, 2013 3:51:26 PM UTC-7, DeadMG wrote:
>
> I'm not sure how that's "simple" this is. You're talking about making this
>> work in a way that's completely foreign to how anything else in C++ works
>
>
> Variadic arguments are used solely for the purpose of guiding overload
> resolution all the time in some SFINAE techniques. We also use it in
> *exactly* this fashion in catch(...), which is exactly what I had in mind
> when suggesting it.


Right, but `catch` is a keyword, not a function. So `keyword(...)` can have
be given an arbitrary. We already know what `meaning.functionName(...)` is
supposed to mean, so it's confusing to infuse it with a new, arbitrary
meaning.

Especially if you say that you can't use the variadic macros to get at the
argument.


>
> But what are the use cases for wanting to do different things based on
>> exceptions, rather than just asking, "am I being destroyed because of
>> unwinding?"
>
>
> The use case I showed is being able to add additional information to the
> exception object, something which is currently impossible.
>

I would consider that a feature, not a bug. Right now, exception handling
is direct communication between the thrower and the catcher. What you
suggest would allow someone, who may not be easily visible, to interfere in
this communication pathway and theoretically corrupt the exception.

--

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



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

<br><br>On Sunday, March 24, 2013 3:51:26 PM UTC-7, DeadMG wrote:<blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;"><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(20=
4,204,204);border-left-style:solid;padding-left:1ex">I'm not sure how that'=
s "simple" this is. You're talking about making this work in a way that's c=
ompletely foreign to how anything else in C++ works</blockquote><div><br></=
div>Variadic arguments are used solely for the purpose of guiding overload =
resolution all the time in some SFINAE techniques. We also use it in *exact=
ly* this fashion in catch(...), which is exactly what I had in mind when su=
ggesting it.</blockquote><div><br>Right, but `catch` is a keyword, not a fu=
nction. So `keyword(...)` can have be given an arbitrary. We already know w=
hat `meaning.functionName(...)` is supposed to mean, so it's confusing to i=
nfuse it with a new, arbitrary meaning.<br><br>Especially if you say that y=
ou can't use the variadic macros to get at the argument.<br>&nbsp;</div><bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;"><div><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo=
rder-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">=
But what are the use cases for wanting to do different things based on exce=
ptions, rather than just asking, "am I being destroyed because of unwinding=
?"</blockquote><div><br></div><div>The use case I showed is being able to a=
dd additional information to the exception object, something which is curre=
ntly impossible.&nbsp;</div></blockquote><div><br>I would consider that a f=
eature, not a bug. Right now, exception handling is direct communication be=
tween the thrower and the catcher. What you suggest would allow someone, wh=
o may not be easily visible, to interfere in this communication pathway and=
 theoretically corrupt the exception.</div>

<p></p>

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

------=_Part_495_26254731.1364171423771--

.

On Mar 24, 2013, at 6:08 PM, Nicol Bolas <jmckesson@gmail.com> wrote:

> As much as I hate the stack unwinding count, it seems to be the only solu=
tion presented (thus far) that can cover all of the cases of forwarding the=
 information about unwinding to all of its descendents, regardless of how t=
hey were allocated/deallocated.

Exposing the stack unwinding count, and nothing more, is currently where my=
 support lies.  It is obviously do-able on all platforms.  And it appears t=
o enable the desired use cases, perhaps with extra convenience classes perh=
aps not.  But this is an area where the existing practice consists only of =
std::uncaught_exception, and so I prefer to advance cautiously (lest we sho=
ot ourselves in the foot yet again).

At the very least, I would like to see where exposing the count creates har=
dship.  The use of it in the examples I've seen so far looks extremely easy=
:

class Transaction
{
    unsigned on_entry_;
public:
    Transaction()
        : on_entry_(std::uncaught_exception_count()) {}

    ~Transaction();
};

Transaction::~Transaction()
{
    if( on_entry_ !=3D std::uncaught_exception_count() )
        Rollback();
}

Howard

--=20

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



.

------=_Part_397_9287028.1364176210154
Content-Type: text/plain; charset=ISO-8859-1



On Sunday, March 24, 2013 5:48:30 PM UTC-7, Howard Hinnant wrote:
>
> On Mar 24, 2013, at 6:08 PM, Nicol Bolas <jmck...@gmail.com <javascript:>>
> wrote:
>
> > As much as I hate the stack unwinding count, it seems to be the only
> solution presented (thus far) that can cover all of the cases of forwarding
> the information about unwinding to all of its descendents, regardless of
> how they were allocated/deallocated.
>
> Exposing the stack unwinding count, and nothing more, is currently where
> my support lies.


I think, if we're going this route, we should have some reasonable helper
objects in addition to the raw count. A simple "unwinding" type who's
constructor fetches the count, with an `explicit operator bool` to test to
see if it's unwinding, would be a reasonable helper.

I never think we should see this in code: `if(on_entry_ !=
std::uncaught_exception_count())`. Or at least, not outside of some *very*specific needs, like someone who absolutely must pack as much data in as
small a size as possible. The use of this feature should be as obvious and
clear as to what's going on as possible.


>  It is obviously do-able on all platforms.  And it appears to enable the
> desired use cases, perhaps with extra convenience classes perhaps not.  But
> this is an area where the existing practice consists only of
> std::uncaught_exception, and so I prefer to advance cautiously (lest we
> shoot ourselves in the foot yet again).
>
> At the very least, I would like to see where exposing the count creates
> hardship.
>

It's not so much that it creates *hardship* as that it's non-trivial. It's
intrusive. You can't just put something in the destructor to track it; you
have to put it in the object. And therefore, it must go into every object
that cares to tell the difference.

It just *feels* like a hack solution. It doesn't feel like information that
should be a *part* of the object; it instead feels like something that
could be tracked externally. It feels like there must be some better,
easier, non-intrusive way to do this. Granted, no such method has presented
itself thus far. But I think this is something that bears investigation
before giving this solution the blessing of standardization.

--

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



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

<br><br>On Sunday, March 24, 2013 5:48:30 PM UTC-7, Howard Hinnant wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;">On Mar 24, 2013, at 6:08 PM, Nic=
ol Bolas &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailt=
o=3D"jCYAhiTza2sJ">jmck...@gmail.com</a>&gt; wrote: <br> <br>&gt; As much a=
s I hate the stack unwinding count, it seems to be the only solution presen=
ted (thus far) that can cover all of the cases of forwarding the informatio=
n about unwinding to all of its descendents, regardless of how they were al=
located/deallocated. <br> <br>Exposing the stack unwinding count, and nothi=
ng more, is currently where my support lies.</blockquote><div><br>I think, =
if we're going this route, we should have some reasonable helper objects in=
 addition to the raw count. A simple "unwinding" type who's constructor fet=
ches the count, with an `explicit operator bool` to test to see if it's unw=
inding, would be a reasonable helper.<br><br>I never think we should see th=
is in code: `if(on_entry_ !=3D std::uncaught_exception_count())`. Or at lea=
st, not outside of some <i>very</i> specific needs, like someone who absolu=
tely must pack as much data in as small a size as possible. The use of this=
 feature should be as obvious and clear as to what's going on as possible.<=
br>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"> &nbsp;It is ob=
viously do-able on all platforms. &nbsp;And it appears to enable the desire=
d use cases, perhaps with extra convenience classes perhaps not. &nbsp;But =
this is an area where the existing practice consists only of std::uncaught_=
exception, and so I prefer to advance cautiously (lest we shoot ourselves i=
n the foot yet again). <br> <br>At the very least, I would like to see wher=
e exposing the count creates hardship.<br></blockquote><div><br>It's not so=
 much that it creates <i>hardship</i> as that it's non-trivial. It's intrus=
ive. You can't just put something in the destructor to track it; you have t=
o put it in the object. And therefore, it must go into every object that ca=
res to tell the difference.<br><br>It just <i>feels</i> like a hack solutio=
n. It doesn't feel like information that should be a <i>part</i> of the obj=
ect; it instead feels like something that could be tracked externally. It f=
eels like there must be some better, easier, non-intrusive way to do this. =
Granted, no such method has presented itself thus far. But I think this is =
something that bears investigation before giving this solution the blessing=
 of standardization.<br></div>

<p></p>

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

------=_Part_397_9287028.1364176210154--

.