On 14 September 2015 at 12:56, David Krauss <potswa@gmail.com> wrote:
> std::uncaught_exception is now deprecated in favor of
> std::uncaught_exceptions, which appears to be a drop-in replacement.
> Unfortunately, using it as such defeats its purpose. A class
> std::unwinding_state is proposed to encapsulate the correct usage. Since
> there is no other use for the current count of unwinding exceptions, it is
> proposed that the class replace uncaught_exceptions, to restore latitude and
> freedom of extension to implementations.


The paper seems to suggest that LEWG is the right working group for it, which is
wrong; the paper should target EWG.

--

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

.

On 14.09.2015 12:56, David Krauss wrote:
> Abstract:
>
> std::uncaught_exception is now deprecated in favor of
> std::uncaught_exceptions, which appears to be a drop-in replacement.
> Unfortunately, using it as such defeats its purpose. A class
> std::unwinding_state is proposed to encapsulate the correct usage. Since
> there is no other use for the current count of unwinding exceptions, it
> is proposed that the class replace uncaught_exceptions, to restore
> latitude and freedom of extension to implementations.
>
>
> Interface:
>
> class unwinding_state {
> public:
>      unwinding_state() noexcept;
>      unwinding_state( unwinding_state const & ) noexcept;
>      unwinding_state & operator = ( unwinding_state const & ) noexcept;
>      ~ unwinding_state();
>
>      explicit operator bool () const & noexcept;
>
> };

In your proposal (section 2.2), you make an example of analysing the
current stack pointer. First, this is an ABI-specific behavior. I'm not
sure it's specified in ABI when the stack pointer is adjusted but I
presume in order to successfully run destructors the pointer would have
to be adjusted similarly to when the stack is unwound due to a normal
return. Second, the behavior becomes undefined when the unwinding_state
object is allocated on the heap. I know you make a case that it is never
needed, but I disagree. I think restricting unwinding_state to only
automatic storage duration is a bad idea. If you really want that, leave
std::uncaught_exceptions() be for other uses.

[quote]
Using an invalid value (or a value which is valid on another thread)
results in undefined behavior.
[/quote]

What value is considered invalid (in addition to the other threads' values)?

[quote]
Typically the copy constructor and assignment operator may be defined as
defaulted. Reasons for nontriviality include validation to assist
debugging, or retaining a shared-ownership exception_ptr handle to the
exception object, which could be provided to the user as an extension.
(However, it might make more sense to hold a weak version of
exception_ptr instead.)
[/quote]

What if I don't want these extensions and only need a way to detect that
unwinding is in progress? Why do I have to pay for that?


In general, I'm not opposed to your proposal, but only _in_addition_ to
the lower level std::uncaught_exceptions(). It can be advertised as a
higher level service which may provide additional information or
improved performance in select use cases but the lower layer must still
remain.

--

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

.

--Apple-Mail=_4AC57C50-EE64-48B2-9258-0DD471EA0CFA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9309=E2=80=9314, at 6:16 PM, Ville Voutilainen <ville.vouti=
lainen@gmail.com> wrote:
>=20
> The paper seems to suggest that LEWG is the right working group for it, w=
hich is
> wrong; the paper should target EWG.

OK. I assume it would still need to go to LEWG afterward. What would EWG ne=
ed to decide? Maybe it would be better to slice off an LEWG subset.


> On 2015=E2=80=9309=E2=80=9314, at 6:34 PM, Andrey Semashev <andrey.semash=
ev@gmail.com> wrote:
>=20
> In your proposal (section 2.2), you make an example of analysing the curr=
ent stack pointer. First, this is an ABI-specific behavior. I'm not sure it=
's specified in ABI when the stack pointer is adjusted but I presume in ord=
er to successfully run destructors the pointer would have to be adjusted si=
milarly to when the stack is unwound due to a normal return. Second, the be=
havior becomes undefined when the unwinding_state object is allocated on th=
e heap. I know you make a case that it is never needed, but I disagree. I t=
hink restricting unwinding_state to only automatic storage duration is a ba=
d idea. If you really want that, leave std::uncaught_exceptions() be for ot=
her uses.

Please read the paragraph following that one.

> [quote]
> Using an invalid value (or a value which is valid on another thread) resu=
lts in undefined behavior.
> [/quote]
>=20
> What value is considered invalid (in addition to the other threads' value=
s)?

A value which was specifically invalidated in the paragraph/bullet point im=
mediately before that sentence.

> [quote]
> Typically the copy constructor and assignment operator may be defined as =
defaulted. Reasons for nontriviality include validation to assist debugging=
, or retaining a shared-ownership exception_ptr handle to the exception obj=
ect, which could be provided to the user as an extension. (However, it migh=
t make more sense to hold a weak version of exception_ptr instead.)
> [/quote]
>=20
> What if I don't want these extensions and only need a way to detect that =
unwinding is in progress? Why do I have to pay for that?

The efficiency of debugging mode is up to the implementation. Few standard =
classes are specified to be trivially copyable; it=E2=80=99s generally left=
 up to QOI. Classes that would copy unwinding_state are in a minority and p=
robably have other overheads to worry about, but usage experience can deter=
mine this. And that=E2=80=99s the point =E2=80=94 to leave room for expansi=
on based on future experience and ideas.

> In general, I'm not opposed to your proposal, but only _in_addition_ to t=
he lower level std::uncaught_exceptions(). It can be advertised as a higher=
 level service which may provide additional information or improved perform=
ance in select use cases but the lower layer must still remain.


Why?

Note that uncaught_exceptions isn=E2=80=99t necessarily the basis that an u=
nderlying library wants to provide. So it=E2=80=99s a bit misleading to cal=
l it =E2=80=9Clower level.=E2=80=9D

--=20

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

--Apple-Mail=_4AC57C50-EE64-48B2-9258-0DD471EA0CFA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9309=
=E2=80=9314, at 6:16 PM, Ville Voutilainen &lt;<a href=3D"mailto:ville.vout=
ilainen@gmail.com" class=3D"">ville.voutilainen@gmail.com</a>&gt; wrote:</d=
iv><br class=3D"Apple-interchange-newline"><div class=3D""><span style=3D"f=
ont-family: Helvetica; font-size: 12px; font-style: normal; font-variant: n=
ormal; font-weight: normal; letter-spacing: normal; line-height: normal; or=
phans: auto; text-align: start; text-indent: 0px; text-transform: none; whi=
te-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-widt=
h: 0px; float: none; display: inline !important;" class=3D"">The paper seem=
s to suggest that LEWG is the right working group for it, which is</span><b=
r style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; fon=
t-variant: normal; font-weight: normal; letter-spacing: normal; line-height=
: normal; orphans: auto; text-align: start; text-indent: 0px; text-transfor=
m: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text=
-stroke-width: 0px;" class=3D""><span style=3D"font-family: Helvetica; font=
-size: 12px; font-style: normal; font-variant: normal; font-weight: normal;=
 letter-spacing: normal; line-height: normal; orphans: auto; text-align: st=
art; text-indent: 0px; text-transform: none; white-space: normal; widows: a=
uto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; displa=
y: inline !important;" class=3D"">wrong; the paper should target EWG.</span=
><br style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant: normal; font-weight: normal; letter-spacing: normal; line-hei=
ght: normal; orphans: auto; text-align: start; text-indent: 0px; text-trans=
form: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-t=
ext-stroke-width: 0px;" class=3D""></div></blockquote></div><br class=3D"">=
<div class=3D"">OK. I assume it would still need to go to LEWG afterward. W=
hat would EWG need to decide? Maybe it would be better to slice off an LEWG=
 subset.</div><div class=3D""><br class=3D""></div><div class=3D""><br clas=
s=3D""></div><div class=3D""><blockquote type=3D"cite" class=3D""><div clas=
s=3D"">On 2015=E2=80=9309=E2=80=9314, at 6:34 PM, Andrey Semashev &lt;<a hr=
ef=3D"mailto:andrey.semashev@gmail.com" class=3D"">andrey.semashev@gmail.co=
m</a>&gt; wrote:</div><br class=3D"Apple-interchange-newline"><div class=3D=
""><span class=3D"" style=3D"float: none; display: inline !important;">In y=
our proposal (section 2.2), you make an example of analysing the current st=
ack pointer. First, this is an ABI-specific behavior. I'm not sure it's spe=
cified in ABI when the stack pointer is adjusted but I presume in order to =
successfully run destructors the pointer would have to be adjusted similarl=
y to when the stack is unwound due to a normal return. Second, the behavior=
 becomes undefined when the unwinding_state object is allocated on the heap=
.. I know you make a case that it is never needed, but I disagree. I think r=
estricting unwinding_state to only automatic storage duration is a bad idea=
.. If you really want that, leave std::uncaught_exceptions() be for other us=
es.</span><br class=3D""></div></blockquote><div class=3D""><br class=3D"">=
</div><div class=3D"">Please read the paragraph following that one.</div><b=
r class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><span cla=
ss=3D"" style=3D"float: none; display: inline !important;">[quote]</span><b=
r class=3D""><span class=3D"" style=3D"float: none; display: inline !import=
ant;">Using an invalid value (or a value which is valid on another thread) =
results in undefined behavior.</span><br class=3D""><span class=3D"" style=
=3D"float: none; display: inline !important;">[/quote]</span><br class=3D""=
><br class=3D""><span class=3D"" style=3D"float: none; display: inline !imp=
ortant;">What value is considered invalid (in addition to the other threads=
' values)?</span><br class=3D""></div></blockquote><div class=3D""><br clas=
s=3D""></div><div class=3D"">A value which was specifically invalidated in =
the paragraph/bullet point immediately before that sentence.</div><br class=
=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><span class=3D""=
 style=3D"float: none; display: inline !important;">[quote]</span><br class=
=3D""><span class=3D"" style=3D"float: none; display: inline !important;">T=
ypically the copy constructor and assignment operator may be defined as def=
aulted. Reasons for nontriviality include validation to assist debugging, o=
r retaining a shared-ownership exception_ptr handle to the exception object=
, which could be provided to the user as an extension. (However, it might m=
ake more sense to hold a weak version of exception_ptr instead.)</span><br =
class=3D""><span class=3D"" style=3D"float: none; display: inline !importan=
t;">[/quote]</span><br class=3D""><br class=3D""><span class=3D"" style=3D"=
float: none; display: inline !important;">What if I don't want these extens=
ions and only need a way to detect that unwinding is in progress? Why do I =
have to pay for that?</span><br class=3D""></div></blockquote><div class=3D=
""><br class=3D""></div><div class=3D"">The efficiency of debugging mode is=
 up to the implementation. Few standard classes are specified to be trivial=
ly copyable; it=E2=80=99s generally left up to QOI. Classes that would copy=
&nbsp;<font face=3D"Courier" class=3D"">unwinding_state</font> are in a min=
ority and probably have other overheads to worry about, but usage experienc=
e can determine this. And that=E2=80=99s the point =E2=80=94 to leave room =
for expansion based on future experience and ideas.</div><br class=3D""><bl=
ockquote type=3D"cite" class=3D""><div class=3D""><span class=3D"" style=3D=
"float: none; display: inline !important;">In general, I'm not opposed to y=
our proposal, but only _in_addition_ to the lower level std::uncaught_excep=
tions(). It can be advertised as a higher level service which may provide a=
dditional information or improved performance in select use cases but the l=
ower layer must still remain.</span><br class=3D""></div></blockquote></div=
><div class=3D""><div class=3D""><span class=3D"" style=3D"float: none; dis=
play: inline !important;"><br class=3D""></span></div></div><div class=3D""=
><span class=3D"" style=3D"float: none; display: inline !important;">Why?</=
span></div><div class=3D""><span class=3D"" style=3D"float: none; display: =
inline !important;"><br class=3D""></span></div><div class=3D""><span class=
=3D"" style=3D"float: none; display: inline !important;">Note that <font fa=
ce=3D"Courier" class=3D"">uncaught_exceptions</font> isn=E2=80=99t necessar=
ily the basis that an underlying library <i class=3D"">wants</i>&nbsp;to pr=
ovide. So it=E2=80=99s a bit misleading to call it =E2=80=9Clower level.=E2=
=80=9D</span></div><div class=3D""><span class=3D"" style=3D"float: none; d=
isplay: inline !important;"><br class=3D""></span></div></body></html>

<p></p>

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

--Apple-Mail=_4AC57C50-EE64-48B2-9258-0DD471EA0CFA--

.

2015-09-14 12:16 GMT+02:00 Ville Voutilainen <ville.voutilainen@gmail.com>:
> On 14 September 2015 at 12:56, David Krauss <potswa@gmail.com> wrote:
>> std::uncaught_exception is now deprecated in favor of
>> std::uncaught_exceptions, which appears to be a drop-in replacement.
>> Unfortunately, using it as such defeats its purpose. A class
>> std::unwinding_state is proposed to encapsulate the correct usage. Since
>> there is no other use for the current count of unwinding exceptions, it is
>> proposed that the class replace uncaught_exceptions, to restore latitude and
>> freedom of extension to implementations.
>
> The paper seems to suggest that LEWG is the right working group for it, which is
> wrong; the paper should target EWG.

If the semantics of std::unwinding_state is completely defined and
specified in the Library section based on existing Library
functionality (which I would assume to be possible based on the
introduction David has given in his announcement), I don't see any
reason why this would involve EWG instead of LEWG.

- Daniel

--

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

.

--Apple-Mail=_57713251-C95A-4DF0-AF06-ADE256CD4399
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9309=E2=80=9314, at 7:12 PM, Daniel Kr=C3=BCgler <daniel.kr=
uegler@gmail.com> wrote:
>=20
> If the semantics of std::unwinding_state is completely defined and
> specified in the Library section based on existing Library
> functionality (which I would assume to be possible based on the
> introduction David has given in his announcement), I don't see any
> reason why this would involve EWG instead of LEWG.

I suspect that the sticking point is the recommendation to remove std::unca=
ught_exceptions, rather than wrap it and leave it at that.

Of course, if EWG recommends against the deprecation, I=E2=80=99d still hop=
e that LEWG would be interested in taking it as an extension.

--=20

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

--Apple-Mail=_57713251-C95A-4DF0-AF06-ADE256CD4399
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9309=
=E2=80=9314, at 7:12 PM, Daniel Kr=C3=BCgler &lt;<a href=3D"mailto:daniel.k=
ruegler@gmail.com" class=3D"">daniel.kruegler@gmail.com</a>&gt; wrote:</div=
><br class=3D"Apple-interchange-newline"><div class=3D"">If the semantics o=
f std::unwinding_state is completely defined and<br class=3D"">specified in=
 the Library section based on existing Library<br class=3D"">functionality =
(which I would assume to be possible based on the<br class=3D"">introductio=
n David has given in his announcement), I don't see any<br class=3D"">reaso=
n why this would involve EWG instead of LEWG.<br class=3D""></div></blockqu=
ote></div><br class=3D""><div class=3D"">I suspect that the sticking point =
is the recommendation to remove&nbsp;<span style=3D"font-family: Courier;" =
class=3D"">std::uncaught_exceptions</span>, rather than wrap it and leave i=
t at that.</div><div class=3D""><br class=3D""></div><div class=3D"">Of cou=
rse, if EWG recommends against the deprecation, I=E2=80=99d still hope that=
 LEWG would be interested in taking it as an extension.</div><div class=3D"=
"><br class=3D""></div></body></html>

<p></p>

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

--Apple-Mail=_57713251-C95A-4DF0-AF06-ADE256CD4399--

.

2015-09-14 13:24 GMT+02:00 David Krauss <potswa@gmail.com>:
>
> On 2015=E2=80=9309=E2=80=9314, at 7:12 PM, Daniel Kr=C3=BCgler <daniel.kr=
uegler@gmail.com> wrote:
>
> If the semantics of std::unwinding_state is completely defined and
> specified in the Library section based on existing Library
> functionality (which I would assume to be possible based on the
> introduction David has given in his announcement), I don't see any
> reason why this would involve EWG instead of LEWG.
>
>
> I suspect that the sticking point is the recommendation to remove
> std::uncaught_exceptions, rather than wrap it and leave it at that.

I agree that if that recommendation would be part of any normative
wording, this needs to be part of EWG analysis (I originally didn't
read that in this way from the announcement, but taking a second look
I agree that this could be read into it).

- Daniel

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

.

On 14 September 2015 at 14:31, Daniel Kr=C3=BCgler <daniel.kruegler@gmail.c=
om> wrote:
> 2015-09-14 13:24 GMT+02:00 David Krauss <potswa@gmail.com>:
>>
>> On 2015=E2=80=9309=E2=80=9314, at 7:12 PM, Daniel Kr=C3=BCgler <daniel.k=
ruegler@gmail.com> wrote:
>>
>> If the semantics of std::unwinding_state is completely defined and
>> specified in the Library section based on existing Library
>> functionality (which I would assume to be possible based on the
>> introduction David has given in his announcement), I don't see any
>> reason why this would involve EWG instead of LEWG.
>>
>>
>> I suspect that the sticking point is the recommendation to remove
>> std::uncaught_exceptions, rather than wrap it and leave it at that.
>
> I agree that if that recommendation would be part of any normative
> wording, this needs to be part of EWG analysis (I originally didn't
> read that in this way from the announcement, but taking a second look
> I agree that this could be read into it).


1) the facility is on the language/library boundary, which means it's
EWG's bailiwick.
2) the facility deals with how exceptions are dealt with in C++ in general,
which also means it's EWG's bailiwick.
3) uncaught_exceptions went through EWG first, and therefore this proposal
should follow, regardless of whether it does or does not completely replace
uncaught_exceptions; it's touching similar areas.

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

.

On 14.09.2015 14:10, David Krauss wrote:
>
>> On 2015=E2=80=9309=E2=80=9314, at 6:34 PM, Andrey Semashev <andrey.semas=
hev@gmail.com
>> <mailto:andrey.semashev@gmail.com>> wrote:
>>
>> In your proposal (section 2.2), you make an example of analysing the
>> current stack pointer. First, this is an ABI-specific behavior. I'm
>> not sure it's specified in ABI when the stack pointer is adjusted but
>> I presume in order to successfully run destructors the pointer would
>> have to be adjusted similarly to when the stack is unwound due to a
>> normal return. Second, the behavior becomes undefined when the
>> unwinding_state object is allocated on the heap. I know you make a
>> case that it is never needed, but I disagree. I think restricting
>> unwinding_state to only automatic storage duration is a bad idea. If
>> you really want that, leave std::uncaught_exceptions() be for other uses=
..
>
> Please read the paragraph following that one.

I did, and I took it into account in my comment. If you're looking for=20
an example when unwinding_state might be placed on heap then think of=20
pimpl-based transactions.

>> [quote]
>> Using an invalid value (or a value which is valid on another thread)
>> results in undefined behavior.
>> [/quote]
>>
>> What value is considered invalid (in addition to the other threads'
>> values)?
>
> A value which was specifically invalidated in the paragraph/bullet point
> immediately before that sentence.

Oh, I misunderstood it as if the unwinding_state contents change to=20
refer to the current unwinding state. Ok, so no stray unwinding_state=20
objects allowed.

>> [quote]
>> Typically the copy constructor and assignment operator may be defined
>> as defaulted. Reasons for nontriviality include validation to assist
>> debugging, or retaining a shared-ownership exception_ptr handle to the
>> exception object, which could be provided to the user as an extension.
>> (However, it might make more sense to hold a weak version of
>> exception_ptr instead.)
>> [/quote]
>>
>> What if I don't want these extensions and only need a way to detect
>> that unwinding is in progress? Why do I have to pay for that?
>
> The efficiency of debugging mode is up to the implementation. Few
> standard classes are specified to be trivially copyable; it=E2=80=99s gen=
erally
> left up to QOI. Classes that would copy unwinding_state are in a
> minority and probably have other overheads to worry about, but usage
> experience can determine this. And that=E2=80=99s the point =E2=80=94 to =
leave room for
> expansion based on future experience and ideas.

The point is that the int returned by uncaught_exceptions has roughly=20
the same QOI on all compilers, and BTW has trivial=20
constructor/destructor/assignment. For your class you explicitly allow=20
something more elaborate, which is something I might not want.

>> In general, I'm not opposed to your proposal, but only _in_addition_
>> to the lower level std::uncaught_exceptions(). It can be advertised as
>> a higher level service which may provide additional information or
>> improved performance in select use cases but the lower layer must
>> still remain.
>
> Why?

Because of the reason I outlined above - the unwinding_state class can=20
entail additional costs that I don't want to pay. That is if you don't=20
restrict unwinding_state to automatic storage only - in which case it=20
would be plain unusable in some cases.

> Note that uncaught_exceptions isn=E2=80=99t necessarily the basis that an
> underlying library /wants/ to provide. So it=E2=80=99s a bit misleading t=
o call
> it =E2=80=9Clower level.=E2=80=9D

Ok, that's true. But frankly, I don't think there will be many different=20
implementations given that some equivalent of uncaught_exceptions=20
already exists in most runtimes.

--=20

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

.

--Apple-Mail=_0A623C9C-B057-47BD-BF01-C49F9D0373B1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9309=E2=80=9314, at 8:01 PM, Andrey Semashev <andrey.semash=
ev@gmail.com> wrote:
>=20
> I did, and I took it into account in my comment. If you're looking for an=
 example when unwinding_state might be placed on heap then think of pimpl-b=
ased transactions.

The paragraph in question mentions make_unique, and that the implementation=
 can only take the pointer arithmetic approach if it=E2=80=99s sure the obj=
ect is on the stack and that it=E2=80=99s never copied.

> Oh, I misunderstood it as if the unwinding_state contents change to refer=
 to the current unwinding state. Ok, so no stray unwinding_state objects al=
lowed.

Right. I thought about specifically disallowing strays, but stopped short b=
ecause they might be present in moved-from state. You can have a stale obje=
ct but you=E2=80=99re not allowed to =E2=80=9Cuse=E2=80=9D it, where I didn=
=E2=80=99t bother to define what =E2=80=9Cuse=E2=80=9D is. My intent is tha=
t they=E2=80=99re destructible.

> The point is that the int returned by uncaught_exceptions has roughly the=
 same QOI on all compilers, and BTW has trivial constructor/destructor/assi=
gnment. For your class you explicitly allow something more elaborate, which=
 is something I might not want.

I can=E2=80=99t think of a good reason why unwinding_state would not be tri=
vially copyable. But neither can I justify requiring it to be, because it d=
oesn=E2=80=99t seem to be much of a difference.

If others believe that this difference alone is significant enough to justi=
fy the existence of unwinding_exceptions, then perhaps I should require tri=
viality. Debugging libraries can choose to be nonconforming in such matters=
..

> Because of the reason I outlined above - the unwinding_state class can en=
tail additional costs that I don't want to pay. That is if you don't restri=
ct unwinding_state to automatic storage only - in which case it would be pl=
ain unusable in some cases.

The language currently has no mechanism to restrict classes to automatic st=
orage, so that=E2=80=99s not on the table.

> Ok, that's true. But frankly, I don't think there will be many different =
implementations given that some equivalent of uncaught_exceptions already e=
xists in most runtimes.

It=E2=80=99s part of the Common ABI <http://mentorembedded.github.io/cxx-ab=
i/abi-eh.html#cxx-data>, but the exception handling mechanism described the=
re is too heavy for some environments. It=E2=80=99s likely that a lighter-w=
eight mechanism will come about for embedded systems.

--=20

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

--Apple-Mail=_0A623C9C-B057-47BD-BF01-C49F9D0373B1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9309=
=E2=80=9314, at 8:01 PM, Andrey Semashev &lt;<a href=3D"mailto:andrey.semas=
hev@gmail.com" class=3D"">andrey.semashev@gmail.com</a>&gt; wrote:</div><br=
 class=3D"Apple-interchange-newline"><div class=3D""><span style=3D"font-fa=
mily: Helvetica; font-size: 12px; font-style: normal; font-variant: normal;=
 font-weight: normal; letter-spacing: normal; line-height: normal; orphans:=
 auto; text-align: start; text-indent: 0px; text-transform: none; white-spa=
ce: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px=
; float: none; display: inline !important;" class=3D"">I did, and I took it=
 into account in my comment. If you're looking for an example when unwindin=
g_state might be placed on heap then think of pimpl-based transactions.</sp=
an><br style=3D"font-family: Helvetica; font-size: 12px; font-style: normal=
; font-variant: normal; font-weight: normal; letter-spacing: normal; line-h=
eight: normal; orphans: auto; text-align: start; text-indent: 0px; text-tra=
nsform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit=
-text-stroke-width: 0px;" class=3D""></div></blockquote><div><br class=3D""=
></div><div>The paragraph in question mentions <font face=3D"Courier" class=
=3D"">make_unique</font>, and that the implementation can only take the poi=
nter arithmetic approach if it=E2=80=99s sure the object is on the stack an=
d that it=E2=80=99s never copied.</div><br class=3D""><blockquote type=3D"c=
ite" class=3D""><div class=3D""><span style=3D"font-family: Helvetica; font=
-size: 12px; font-style: normal; font-variant: normal; font-weight: normal;=
 letter-spacing: normal; line-height: normal; orphans: auto; text-align: st=
art; text-indent: 0px; text-transform: none; white-space: normal; widows: a=
uto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; displa=
y: inline !important;" class=3D"">Oh, I misunderstood it as if the unwindin=
g_state contents change to refer to the current unwinding state. Ok, so no =
stray unwinding_state objects allowed.</span><br style=3D"font-family: Helv=
etica; font-size: 12px; font-style: normal; font-variant: normal; font-weig=
ht: normal; letter-spacing: normal; line-height: normal; orphans: auto; tex=
t-align: start; text-indent: 0px; text-transform: none; white-space: normal=
; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=
=3D""></div></blockquote><div><br class=3D""></div><div>Right. I thought ab=
out specifically disallowing strays, but stopped short because they might b=
e present in moved-from state. You can have a stale object but you=E2=80=99=
re not allowed to =E2=80=9Cuse=E2=80=9D it, where I didn=E2=80=99t bother t=
o define what =E2=80=9Cuse=E2=80=9D is. My intent is that they=E2=80=99re d=
estructible.</div><br class=3D""><blockquote type=3D"cite" class=3D""><div =
class=3D""><span style=3D"font-family: Helvetica; font-size: 12px; font-sty=
le: normal; font-variant: normal; font-weight: normal; letter-spacing: norm=
al; line-height: normal; orphans: auto; text-align: start; text-indent: 0px=
; text-transform: none; white-space: normal; widows: auto; word-spacing: 0p=
x; -webkit-text-stroke-width: 0px; float: none; display: inline !important;=
" class=3D"">The point is that the int returned by uncaught_exceptions has =
roughly the same QOI on all compilers, and BTW has trivial constructor/dest=
ructor/assignment. For your class you explicitly allow something more elabo=
rate, which is something I might not want.</span><br style=3D"font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-=
weight: normal; letter-spacing: normal; line-height: normal; orphans: auto;=
 text-align: start; text-indent: 0px; text-transform: none; white-space: no=
rmal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" cla=
ss=3D""></div></blockquote><div><br class=3D""></div><div>I can=E2=80=99t t=
hink of a good reason why <font face=3D"Courier" class=3D"">unwinding_state=
</font> would not be trivially copyable. But neither can I justify requirin=
g it to be, because it doesn=E2=80=99t seem to be much of a difference.</di=
v><div><br class=3D""></div><div>If others believe that this difference alo=
ne is significant enough to justify the existence of <font face=3D"Courier"=
 class=3D"">unwinding_exceptions</font>, then perhaps I should require triv=
iality. Debugging libraries can choose to be nonconforming in such matters.=
</div><br class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><=
span style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant: normal; font-weight: normal; letter-spacing: normal; line-hei=
ght: normal; orphans: auto; text-align: start; text-indent: 0px; text-trans=
form: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-t=
ext-stroke-width: 0px; float: none; display: inline !important;" class=3D""=
>Because of the reason I outlined above - the unwinding_state class can ent=
ail additional costs that I don't want to pay. That is if you don't restric=
t unwinding_state to automatic storage only - in which case it would be pla=
in unusable in some cases.</span><br style=3D"font-family: Helvetica; font-=
size: 12px; font-style: normal; font-variant: normal; font-weight: normal; =
letter-spacing: normal; line-height: normal; orphans: auto; text-align: sta=
rt; text-indent: 0px; text-transform: none; white-space: normal; widows: au=
to; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""></div></=
blockquote><div><br class=3D""></div><div>The language currently has no mec=
hanism to restrict classes to automatic storage, so that=E2=80=99s not on t=
he table.</div><br class=3D""><blockquote type=3D"cite" class=3D""><div cla=
ss=3D""><span style=3D"font-family: Helvetica; font-size: 12px; font-style:=
 normal; font-variant: normal; font-weight: normal; letter-spacing: normal;=
 line-height: normal; orphans: auto; text-align: start; text-indent: 0px; t=
ext-transform: none; white-space: normal; widows: auto; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; float: none; display: inline !important;" c=
lass=3D"">Ok, that's true. But frankly, I don't think there will be many di=
fferent implementations given that some equivalent of uncaught_exceptions a=
lready exists in most runtimes.</span><br style=3D"font-family: Helvetica; =
font-size: 12px; font-style: normal; font-variant: normal; font-weight: nor=
mal; letter-spacing: normal; line-height: normal; orphans: auto; text-align=
: start; text-indent: 0px; text-transform: none; white-space: normal; widow=
s: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""></d=
iv></blockquote><div><br class=3D""></div><div>It=E2=80=99s part of the&nbs=
p;<a href=3D"http://mentorembedded.github.io/cxx-abi/abi-eh.html#cxx-data" =
class=3D"">Common ABI</a>, but the exception handling mechanism described t=
here is too heavy for some environments. It=E2=80=99s likely that a lighter=
-weight mechanism will come about for embedded systems.</div><div><br class=
=3D""></div></div></body></html>

<p></p>

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

--Apple-Mail=_0A623C9C-B057-47BD-BF01-C49F9D0373B1--

.

On 14 September 2015 at 15:43, David Krauss <potswa@gmail.com> wrote:
> I can=E2=80=99t think of a good reason why unwinding_state would not be t=
rivially
> copyable. But neither can I justify requiring it to be, because it doesn=
=E2=80=99t
> seem to be much of a difference.

Specifying that or not specifying that has a portability impact for
any type that uses
unwinding_state. That difference is potentially rather significant.

--=20

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

.

--Apple-Mail=_FCEFF056-8A84-4D3A-A9D3-8A3ECE9674F0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9309=E2=80=9314, at 8:53 PM, Ville Voutilainen <ville.vouti=
lainen@gmail.com> wrote:
>=20
> On 14 September 2015 at 15:43, David Krauss <potswa@gmail.com> wrote:
>> I can=E2=80=99t think of a good reason why unwinding_state would not be =
trivially
>> copyable. But neither can I justify requiring it to be, because it doesn=
=E2=80=99t
>> seem to be much of a difference.
>=20
> Specifying that or not specifying that has a portability impact for
> any type that uses
> unwinding_state. That difference is potentially rather significant.


I meant that it doesn=E2=80=99t seem to be much of a performance difference=
.. Are you saying that it should not be unspecified?

To be sure, several things have unspecified (and actually ambiguous) copy c=
onstructibility. Scanning through the standard: iterators besides pointers,=
 lambda and bind objects, =E2=80=A6 not much else, treating constexpr copy =
constructors as trivial.

I=E2=80=99ll just require triviality. It doesn=E2=80=99t seem to rule out a=
nything worthwhile.

--=20

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

--Apple-Mail=_FCEFF056-8A84-4D3A-A9D3-8A3ECE9674F0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9309=
=E2=80=9314, at 8:53 PM, Ville Voutilainen &lt;<a href=3D"mailto:ville.vout=
ilainen@gmail.com" class=3D"">ville.voutilainen@gmail.com</a>&gt; wrote:</d=
iv><br class=3D"Apple-interchange-newline"><div class=3D"">On 14 September =
2015 at 15:43, David Krauss &lt;<a href=3D"mailto:potswa@gmail.com" class=
=3D"">potswa@gmail.com</a>&gt; wrote:<br class=3D""><blockquote type=3D"cit=
e" class=3D"">I can=E2=80=99t think of a good reason why unwinding_state wo=
uld not be trivially<br class=3D"">copyable. But neither can I justify requ=
iring it to be, because it doesn=E2=80=99t<br class=3D"">seem to be much of=
 a difference.<br class=3D""></blockquote><br class=3D"">Specifying that or=
 not specifying that has a portability impact for<br class=3D"">any type th=
at uses<br class=3D"">unwinding_state. That difference is potentially rathe=
r significant.<br class=3D""></div></blockquote></div><div class=3D""><br c=
lass=3D""></div><div class=3D"">I meant that it doesn=E2=80=99t seem to be =
much of a performance difference. Are you saying that it should not be unsp=
ecified?</div><div class=3D""><br class=3D""></div><div class=3D"">To be su=
re, several things have unspecified (and actually ambiguous) copy construct=
ibility. Scanning through the standard: iterators besides pointers, lambda =
and <font face=3D"Courier" class=3D"">bind</font> objects,&nbsp;=E2=80=A6 n=
ot much else, treating constexpr copy constructors as trivial.</div><div cl=
ass=3D""><br class=3D""></div><div class=3D"">I=E2=80=99ll just require tri=
viality. It doesn=E2=80=99t seem to rule out anything worthwhile.</div><div=
 class=3D""><br class=3D""></div></body></html>

<p></p>

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

--Apple-Mail=_FCEFF056-8A84-4D3A-A9D3-8A3ECE9674F0--

.

On 14 September 2015 at 17:06, David Krauss <potswa@gmail.com> wrote:
> Specifying that or not specifying that has a portability impact for
> any type that uses
> unwinding_state. That difference is potentially rather significant.
>
>
> I meant that it doesn=E2=80=99t seem to be much of a performance differen=
ce. Are you
> saying that it should not be unspecified?

I think it should not be unspecified, yes - because it seems likely that th=
is
facility would be used as a non-static data member.

> To be sure, several things have unspecified (and actually ambiguous) copy
> constructibility. Scanning through the standard: iterators besides pointe=
rs,
> lambda and bind objects, =E2=80=A6 not much else, treating constexpr copy
> constructors as trivial.

I don't quite grasp what you're enumerating there, because the triviality o=
f
the copy operations of a lambda is not unspecified nor ambiguous.

> I=E2=80=99ll just require triviality. It doesn=E2=80=99t seem to rule out=
 anything
> worthwhile.

+1.

I was asked off-line to mention that my request to initially target
EWG with this
proposal is the official view of the EWG chair. Yes, it'll potentially
go to LEWG/LWG
after that, but the first WG to go to is EWG.

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

.

> On 2015=E2=80=9309=E2=80=9314, at 10:33 PM, Ville Voutilainen <ville.vout=
ilainen@gmail.com> wrote:
>=20
> I don't quite grasp what you're enumerating there, because the triviality=
 of
> the copy operations of a lambda is not unspecified nor ambiguous.

=C2=A75.1.2/3.2 says that an implementation is free to make a lambda copy c=
onstructor nontrivial. It=E2=80=99s behind an odd double negative. Anyhow, =
it=E2=80=99s moot.

> I was asked off-line to mention that my request to initially target
> EWG with this
> proposal is the official view of the EWG chair. Yes, it'll potentially
> go to LEWG/LWG
> after that, but the first WG to go to is EWG.

Sorry, I neglected to apply that change earlier. Fixed now, and unless ther=
e are more comments, I=E2=80=99ll submit it tomorrow.

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

.

On 14 September 2015 at 17:50, David Krauss <potswa@gmail.com> wrote:
>
>> On 2015=E2=80=9309=E2=80=9314, at 10:33 PM, Ville Voutilainen <ville.vou=
tilainen@gmail.com> wrote:
>>
>> I don't quite grasp what you're enumerating there, because the trivialit=
y of
>> the copy operations of a lambda is not unspecified nor ambiguous.
>
> =C2=A75.1.2/3.2 says that an implementation is free to make a lambda copy=
 constructor nontrivial. It=E2=80=99s behind an odd double negative. Anyhow=
, it=E2=80=99s moot.

Oops, heh, indeed, that's the list of things that are allowed. :)

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

.