Topic: Exception stack trace information.
Author: redradist@gmail.com
Date: Sat, 30 Jul 2016 17:14:19 -0700 (PDT)
Raw View
------=_Part_345_400100639.1469924059076
Content-Type: multipart/alternative;
boundary="----=_Part_346_1538343984.1469924059077"
------=_Part_346_1538343984.1469924059077
Content-Type: text/plain; charset=UTF-8
In *C++17* will be added a lot of new features, but no of them features
improve quality of code and quickly fixing of the code.
If in program exist a bug then the best that program can do is crash.
Exception is a good conception for error handling, but is useless in C++
implementation, 'cause we do not know where the problem happens. That mean
catching of exception is useless, because additional information is so
small that better allow program simple crash.
This is the main reason that even in debug mode exception is used not often.
*PROBLEM *is no standard on it about providing to user *backtrace*.
Operation system can get stack trace when exception was used. We can
implement getting stack trace even in dummy implementation by adding to
every function in compile time meta information with name of this function
and code that will put this name in stack object that implicitly exists
from starting the program. We can add scpecial flag *BACK_TRACE* or *BTRACE*
..
Sorry for straightforward speech but I tired. In we can implement
*backtrace*, but are thinking about coroutine. Without strong *base *we
cannot implement something good.
*Thanks,Best regards.*
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/a758ce2c-3750-4b9d-99e0-e9e1e3dcdb6d%40isocpp.org.
------=_Part_346_1538343984.1469924059077
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">In <b>C++17</b> will be added a lot of new features, but n=
o of them features improve quality of code and quickly fixing of the code.<=
br>If in program exist a bug then the best that program can do is crash. Ex=
ception is a good conception for error handling, but is useless in C++ impl=
ementation, 'cause we do not know where the problem happens. That mean =
catching of exception is useless, because additional information is so smal=
l that better allow program simple crash.<br>This is the main reason that e=
ven in debug mode exception is used not often.<br><br><b>PROBLEM </b>is no =
standard on it about providing to user <b>backtrace</b>.<br>Operation syste=
m can get stack trace when exception was used. We can implement getting sta=
ck trace even in dummy implementation by adding to every function in compil=
e time meta information with name of this function and code that will put t=
his name in stack object that implicitly exists from starting the program. =
We can add scpecial flag <b>BACK_TRACE</b> or <b>BTRACE</b>.<br><br>Sorry f=
or straightforward speech but I tired. In we can implement <b>backtrace</b>=
, but are thinking about coroutine. Without strong <b>base </b>we cannot im=
plement something good.<br><br><b>Thanks,<br>Best regards.<br><br></b></div=
>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a758ce2c-3750-4b9d-99e0-e9e1e3dcdb6d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a758ce2c-3750-4b9d-99e0-e9e1e3dcdb6d=
%40isocpp.org</a>.<br />
------=_Part_346_1538343984.1469924059077--
------=_Part_345_400100639.1469924059076--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Sat, 30 Jul 2016 20:41:07 -0400
Raw View
<html><head></head><body lang=3D"en-US" style=3D"background-color: rgb(255,=
255, 255); line-height: initial;"> =
<div style=3D"width: 100%; fo=
nt-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif=
; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, =
255, 255);">Exceptions have nothing to do with bugs. Exceptions are a way t=
o handle problems caused by external conditions (out of memory, file not fo=
und,...), not internal conditions =3D=3D bugs. </div><div style=3D"width: 1=
00%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, san=
s-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rg=
b(255, 255, 255);"><br></div><div style=3D"width: 100%; font-size: initial;=
font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, =
73, 125); text-align: initial; background-color: rgb(255, 255, 255);">But h=
aving a stack trace facility in the language would be useful. </div><d=
iv style=3D"width: 100%; font-size: initial; font-family: Calibri, 'Slate P=
ro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; =
background-color: rgb(255, 255, 255);"><br></div> =
=
<div style=3D"width: 100%; font-size: initi=
al; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(3=
1, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);"><b=
r style=3D"display:initial"></div> =
=
=
<div style=3D"font-size: initial; font-family: Calibri, 'Slate Pro', sa=
ns-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; backgro=
und-color: rgb(255, 255, 255);">Sent from my BlackBerry =
;portable Babbage Device</div> =
=
<table =
width=3D"100%" style=3D"background-color:white;border-spacing:0px;"> <tbody=
><tr><td colspan=3D"2" style=3D"font-size: initial; text-align: initial; ba=
ckground-color: rgb(255, 255, 255);"> <div style=
=3D"border-style: solid none none; border-top-color: rgb(181, 196, 223); bo=
rder-top-width: 1pt; padding: 3pt 0in 0in; font-family: Tahoma, 'BB Alpha S=
ans', 'Slate Pro'; font-size: 10pt;"> <div><b>From: </b>redradist@gmail.co=
m</div><div><b>Sent: </b>Saturday, July 30, 2016 8:14 PM</div><div><b>To: <=
/b>ISO C++ Standard - Future Proposals</div><div><b>Reply To: </b>std-propo=
sals@isocpp.org</div><div><b>Subject: </b>[std-proposals] Exception stack t=
race information.</div></div></td></tr></tbody></table><div style=3D"border=
-style: solid none none; border-top-color: rgb(186, 188, 209); border-top-w=
idth: 1pt; font-size: initial; text-align: initial; background-color: rgb(2=
55, 255, 255);"></div><br><div id=3D"_originalContent" style=3D""><div dir=
=3D"ltr">In <b>C++17</b> will be added a lot of new features, but no of the=
m features improve quality of code and quickly fixing of the code.<br>If in=
program exist a bug then the best that program can do is crash. Exception =
is a good conception for error handling, but is useless in C++ implementati=
on, 'cause we do not know where the problem happens. That mean catching of =
exception is useless, because additional information is so small that bette=
r allow program simple crash.<br>This is the main reason that even in debug=
mode exception is used not often.<br><br><b>PROBLEM </b>is no standard on =
it about providing to user <b>backtrace</b>.<br>Operation system can get st=
ack trace when exception was used. We can implement getting stack trace eve=
n in dummy implementation by adding to every function in compile time meta =
information with name of this function and code that will put this name in =
stack object that implicitly exists from starting the program. We can add s=
cpecial flag <b>BACK_TRACE</b> or <b>BTRACE</b>.<br><br>Sorry for straightf=
orward speech but I tired. In we can implement <b>backtrace</b>, but are th=
inking about coroutine. Without strong <b>base </b>we cannot implement some=
thing good.<br><br><b>Thanks,<br>Best regards.<br><br></b></div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a758ce2c-3750-4b9d-99e0-e9e1e3dcdb6d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.goo=
gle.com/a/isocpp.org/d/msgid/std-proposals/a758ce2c-3750-4b9d-99e0-e9e1e3dc=
db6d%40isocpp.org</a>.<br>
<br><!--end of _originalContent --></div></body></html>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/20160731004107.4898897.76636.14874%40=
gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com=
/a/isocpp.org/d/msgid/std-proposals/20160731004107.4898897.76636.14874%40gm=
ail.com</a>.<br />
.
Author: Patrice Roy <patricer@gmail.com>
Date: Sat, 30 Jul 2016 22:22:19 -0400
Raw View
--001a113df52031eaf70538e52776
Content-Type: text/plain; charset=UTF-8
Stating that exceptions are useless when many of use use them to our
benefit is a bit... harsh :) I agree with Tony that for some use cases, the
stack trace would be nice. Please, feel free to prepare a proposal!
2016-07-30 20:41 GMT-04:00 Tony V E <tvaneerd@gmail.com>:
> Exceptions have nothing to do with bugs. Exceptions are a way to handle
> problems caused by external conditions (out of memory, file not found,...),
> not internal conditions == bugs.
>
> But having a stack trace facility in the language would be useful.
>
>
> Sent from my BlackBerry portable Babbage Device
> *From: *redradist@gmail.com
> *Sent: *Saturday, July 30, 2016 8:14 PM
> *To: *ISO C++ Standard - Future Proposals
> *Reply To: *std-proposals@isocpp.org
> *Subject: *[std-proposals] Exception stack trace information.
>
> In *C++17* will be added a lot of new features, but no of them features
> improve quality of code and quickly fixing of the code.
> If in program exist a bug then the best that program can do is crash.
> Exception is a good conception for error handling, but is useless in C++
> implementation, 'cause we do not know where the problem happens. That mean
> catching of exception is useless, because additional information is so
> small that better allow program simple crash.
> This is the main reason that even in debug mode exception is used not
> often.
>
> *PROBLEM *is no standard on it about providing to user *backtrace*.
> Operation system can get stack trace when exception was used. We can
> implement getting stack trace even in dummy implementation by adding to
> every function in compile time meta information with name of this function
> and code that will put this name in stack object that implicitly exists
> from starting the program. We can add scpecial flag *BACK_TRACE* or
> *BTRACE*.
>
> Sorry for straightforward speech but I tired. In we can implement
> *backtrace*, but are thinking about coroutine. Without strong *base *we
> cannot implement something good.
>
>
>
>
> *Thanks,Best regards.*
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/a758ce2c-3750-4b9d-99e0-e9e1e3dcdb6d%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/a758ce2c-3750-4b9d-99e0-e9e1e3dcdb6d%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/20160731004107.4898897.76636.14874%40gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/20160731004107.4898897.76636.14874%40gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKiZDp2HPTEtM_bV02OEFc03BsfiTW4BNJagEUYUwcZz2d_CQQ%40mail.gmail.com.
--001a113df52031eaf70538e52776
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Stating that exceptions are useless when many of use use t=
hem to our benefit is a bit... harsh :) I agree with Tony that for some use=
cases, the stack trace would be nice. Please, feel free to prepare a propo=
sal!<br></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">201=
6-07-30 20:41 GMT-04:00 Tony V E <span dir=3D"ltr"><<a href=3D"mailto:tv=
aneerd@gmail.com" target=3D"_blank">tvaneerd@gmail.com</a>></span>:<br><=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
#ccc solid;padding-left:1ex"><div style=3D"background-color:rgb(255,255,25=
5);line-height:initial" lang=3D"en-US"> =
<div style=3D"width:100%;=
font-size:initial;font-family:Calibri,'Slate Pro',sans-serif,sans-s=
erif;color:rgb(31,73,125);text-align:initial;background-color:rgb(255,255,2=
55)">Exceptions have nothing to do with bugs. Exceptions are a way to handl=
e problems caused by external conditions (out of memory, file not found,...=
), not internal conditions =3D=3D bugs. </div><div style=3D"width:100%;font=
-size:initial;font-family:Calibri,'Slate Pro',sans-serif,sans-serif=
;color:rgb(31,73,125);text-align:initial;background-color:rgb(255,255,255)"=
><br></div><div style=3D"width:100%;font-size:initial;font-family:Calibri,&=
#39;Slate Pro',sans-serif,sans-serif;color:rgb(31,73,125);text-align:in=
itial;background-color:rgb(255,255,255)">But having a stack trace facility =
in the language would be useful.=C2=A0</div><div style=3D"width:100%;font-s=
ize:initial;font-family:Calibri,'Slate Pro',sans-serif,sans-serif;c=
olor:rgb(31,73,125);text-align:initial;background-color:rgb(255,255,255)"><=
br></div> =
<div sty=
le=3D"width:100%;font-size:initial;font-family:Calibri,'Slate Pro',=
sans-serif,sans-serif;color:rgb(31,73,125);text-align:initial;background-co=
lor:rgb(255,255,255)"><br style=3D"display:initial"></div> =
=
=
<div style=3D"font-size:initial;font-family:Cal=
ibri,'Slate Pro',sans-serif,sans-serif;color:rgb(31,73,125);text-al=
ign:initial;background-color:rgb(255,255,255)">Sent=C2=A0from=C2=A0my=C2=A0=
BlackBerry=C2=A0portable=C2=A0Babbage=C2=A0Device</div> =
=
=
<table style=3D"background-color:white;border-spacing:0px" width=3D=
"100%"> <tbody><tr><td colspan=3D"2" style=3D"font-size:initial;text-align:=
initial;background-color:rgb(255,255,255)"> <div =
style=3D"border-style:solid none none;border-top-color:rgb(181,196,223);bor=
der-top-width:1pt;padding:3pt 0in 0in;font-family:Tahoma,'BB Alpha Sans=
','Slate Pro';font-size:10pt"> <div><b>From: </b><a href=3D"ma=
ilto:redradist@gmail.com" target=3D"_blank">redradist@gmail.com</a></div><d=
iv><b>Sent: </b>Saturday, July 30, 2016 8:14 PM</div><div><b>To: </b>ISO C+=
+ Standard - Future Proposals</div><div><b>Reply To: </b><a href=3D"mailto:=
std-proposals@isocpp.org" target=3D"_blank">std-proposals@isocpp.org</a></d=
iv><div><b>Subject: </b>[std-proposals] Exception stack trace information.<=
/div></div></td></tr></tbody></table><div><div class=3D"h5"><div style=3D"b=
order-style:solid none none;border-top-color:rgb(186,188,209);border-top-wi=
dth:1pt;font-size:initial;text-align:initial;background-color:rgb(255,255,2=
55)"></div><br><div><div dir=3D"ltr">In <b>C++17</b> will be added a lot of=
new features, but no of them features improve quality of code and quickly =
fixing of the code.<br>If in program exist a bug then the best that program=
can do is crash. Exception is a good conception for error handling, but is=
useless in C++ implementation, 'cause we do not know where the problem=
happens. That mean catching of exception is useless, because additional in=
formation is so small that better allow program simple crash.<br>This is th=
e main reason that even in debug mode exception is used not often.<br><br><=
b>PROBLEM </b>is no standard on it about providing to user <b>backtrace</b>=
..<br>Operation system can get stack trace when exception was used. We can i=
mplement getting stack trace even in dummy implementation by adding to ever=
y function in compile time meta information with name of this function and =
code that will put this name in stack object that implicitly exists from st=
arting the program. We can add scpecial flag <b>BACK_TRACE</b> or <b>BTRACE=
</b>.<br><br>Sorry for straightforward speech but I tired. In we can implem=
ent <b>backtrace</b>, but are thinking about coroutine. Without strong <b>b=
ase </b>we cannot implement something good.<br><br><b>Thanks,<br>Best regar=
ds.<br><br></b></div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a758ce2c-3750-4b9d-99e0-e9e1e3dcdb6d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/a758ce2c-3750-=
4b9d-99e0-e9e1e3dcdb6d%40isocpp.org</a>.<br>
<br></div></div></div></div><div><div class=3D"h5">
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></div></div>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/20160731004107.4898897.76636.14874%40=
gmail.com?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/20160731004107.48=
98897.76636.14874%40gmail.com</a>.<br>
</blockquote></div><br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAKiZDp2HPTEtM_bV02OEFc03BsfiTW4BNJag=
EUYUwcZz2d_CQQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKiZDp2HPTEtM_bV=
02OEFc03BsfiTW4BNJagEUYUwcZz2d_CQQ%40mail.gmail.com</a>.<br />
--001a113df52031eaf70538e52776--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Sat, 30 Jul 2016 22:54:00 -0700
Raw View
On s=C3=A1bado, 30 de julho de 2016 17:14:19 PDT redradist@gmail.com wrote:
> In *C++17* will be added a lot of new features, but no of them features
> improve quality of code and quickly fixing of the code.
I'm pretty sure a lot of people dispute that statement. Just look at the wh=
ole=20
discussion happening right now about evaluation ordere of arguments and in=
=20
expressions. That's supposed to improve the quality of code. The new classe=
s,=20
when used in new code, also improve the quality.
> If in program exist a bug then the best that program can do is crash.
> Exception is a good conception for error handling, but is useless in C++
> implementation, 'cause we do not know where the problem happens. That mea=
n
> catching of exception is useless, because additional information is so
> small that better allow program simple crash.
You misunderstand what exceptions are for. You're not supposed to catch the=
m=20
to find out where the error occurred. You catch them so you handle the=20
condition wherever it happened, then continue execution because you've=20
corrected the problem.
> This is the main reason that even in debug mode exception is used not oft=
en.
I don't know any program that enables or disables exceptions according to=
=20
debug mode or release mode. This statement of yours lacks proof and, couple=
d=20
with the misundersanding above, indicates you either completely misundersta=
nd=20
exceptions or you're talking about something else, something that is not=20
called "exceptions".
> *PROBLEM *is no standard on it about providing to user *backtrace*.
> Operation system can get stack trace when exception was used. We can
> implement getting stack trace even in dummy implementation by adding to
> every function in compile time meta information with name of this functio=
n
> and code that will put this name in stack object that implicitly exists
> from starting the program. We can add scpecial flag *BACK_TRACE* or *BTRA=
CE*
There was a discussion about backtraces a while ago. It's hard to have=20
something about it in the standard because then the standard needs to=20
understand the concept of "frame" and will constrain what the compiler is=
=20
allowed to do to optimise and inline functions. For example, will it be=20
allowed to omit the frame pointer?
> Sorry for straightforward speech but I tired. In we can implement
> *backtrace*, but are thinking about coroutine. Without strong *base *we
> cannot implement something good.
Again, many will dispute the implication that the base is not strong. It is=
..
Many will dispute that backtraces improve the base in any way. I am one of=
=20
those: I fail to see the value of standardising this fuctionality. It has=
=20
existed very well for 30 years in the realm of debuggers. The standard has =
no=20
concept of "bug", it simply declares that some behaviours are undefined and=
=20
that, under some conditions, the program is ill-formed. How those are expos=
ed=20
to the user, that's implementation-defined and so is the method of their=20
correction.
Tooling can be improved, of course. But I argue that it's constantly in=20
improvement and, more importantlu, the issue of backtraces is an *already*=
=20
solved problem.
Finally, I share some of your concern. There are many things that need to b=
e=20
added to the language and to the standard library to cover some of its=20
shortcomings. One of my biggest gripes of C++11 was the incomplete support =
for=20
the Unicode support that was added, including some basic steps, while a hug=
e=20
library for ratios and random was added. But since then, I've learned that =
you=20
can't stall progress in one area that has consensus because another doesn't=
=20
have it yet. Many things need more time for discussion and implementation a=
nd=20
they shouldn't hold back what has been already agreed upon.
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/4199692.Lme4QNKjjA%40tjmaciei-mobl1.
.
Author: redradist@gmail.com
Date: Sat, 30 Jul 2016 23:49:53 -0700 (PDT)
Raw View
------=_Part_1707_1438267394.1469947793797
Content-Type: multipart/alternative;
boundary="----=_Part_1708_1748926483.1469947793797"
------=_Part_1708_1748926483.1469947793797
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
I have prepared my first proposal. Please, dont bit hard for missing=20
details.
You can find it in attachment.
=D0=B2=D0=BE=D1=81=D0=BA=D1=80=D0=B5=D1=81=D0=B5=D0=BD=D1=8C=D0=B5, 31 =D0=
=B8=D1=8E=D0=BB=D1=8F 2016 =D0=B3., 5:22:21 UTC+3 =D0=BF=D0=BE=D0=BB=D1=8C=
=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Patrice Roy=20
=D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:
>
> Stating that exceptions are useless when many of use use them to our=20
> benefit is a bit... harsh :) I agree with Tony that for some use cases, t=
he=20
> stack trace would be nice. Please, feel free to prepare a proposal!
>
> 2016-07-30 20:41 GMT-04:00 Tony V E <tvan...@gmail.com <javascript:>>:
>
>> Exceptions have nothing to do with bugs. Exceptions are a way to handle=
=20
>> problems caused by external conditions (out of memory, file not found,..=
..),=20
>> not internal conditions =3D=3D bugs.=20
>>
>> But having a stack trace facility in the language would be useful.=20
>>
>>
>> Sent from my BlackBerry portable Babbage Device
>> *From: *redr...@gmail.com <javascript:>
>> *Sent: *Saturday, July 30, 2016 8:14 PM
>> *To: *ISO C++ Standard - Future Proposals
>> *Reply To: *std-pr...@isocpp.org <javascript:>
>> *Subject: *[std-proposals] Exception stack trace information.
>>
>> In *C++17* will be added a lot of new features, but no of them features=
=20
>> improve quality of code and quickly fixing of the code.
>> If in program exist a bug then the best that program can do is crash.=20
>> Exception is a good conception for error handling, but is useless in C++=
=20
>> implementation, 'cause we do not know where the problem happens. That me=
an=20
>> catching of exception is useless, because additional information is so=
=20
>> small that better allow program simple crash.
>> This is the main reason that even in debug mode exception is used not=20
>> often.
>>
>> *PROBLEM *is no standard on it about providing to user *backtrace*.
>> Operation system can get stack trace when exception was used. We can=20
>> implement getting stack trace even in dummy implementation by adding to=
=20
>> every function in compile time meta information with name of this functi=
on=20
>> and code that will put this name in stack object that implicitly exists=
=20
>> from starting the program. We can add scpecial flag *BACK_TRACE* or=20
>> *BTRACE*.
>>
>> Sorry for straightforward speech but I tired. In we can implement=20
>> *backtrace*, but are thinking about coroutine. Without strong *base *we=
=20
>> cannot implement something good.
>>
>>
>>
>>
>> *Thanks,Best regards.*
>>
>> --=20
>> You received this message because you are subscribed to the Google Group=
s=20
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n=20
>> email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> To view this discussion on the web visit=20
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/a758ce2c-37=
50-4b9d-99e0-e9e1e3dcdb6d%40isocpp.org=20
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/a758ce2c-3=
750-4b9d-99e0-e9e1e3dcdb6d%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoo=
ter>
>> .
>>
>> --=20
>> You received this message because you are subscribed to the Google Group=
s=20
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n=20
>> email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> To view this discussion on the web visit=20
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/20160731004=
107.4898897.76636.14874%40gmail.com=20
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2016073100=
4107.4898897.76636.14874%40gmail.com?utm_medium=3Demail&utm_source=3Dfooter=
>
>> .
>>
>
>
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/237863cb-3569-4784-b6f5-db80ac069ff6%40isocpp.or=
g.
------=_Part_1708_1748926483.1469947793797
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I have prepared my first proposal. Please, dont bit hard f=
or missing details.<br>You can find it in attachment.<br><br>=D0=B2=D0=BE=
=D1=81=D0=BA=D1=80=D0=B5=D1=81=D0=B5=D0=BD=D1=8C=D0=B5, 31 =D0=B8=D1=8E=D0=
=BB=D1=8F 2016 =D0=B3., 5:22:21 UTC+3 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=
=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Patrice Roy =D0=BD=D0=B0=D0=BF=D0=B8=
=D1=81=D0=B0=D0=BB:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr">Stating that exceptions are useless when many of use use them to our =
benefit is a bit... harsh :) I agree with Tony that for some use cases, the=
stack trace would be nice. Please, feel free to prepare a proposal!<br></d=
iv><div><br><div class=3D"gmail_quote">2016-07-30 20:41 GMT-04:00 Tony V E =
<span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfusca=
ted-mailto=3D"eFo7LIc2BgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D=
9;javascript:';return true;" onclick=3D"this.href=3D'javascript:=
9;;return true;">tvan...@gmail.com</a>></span>:<br><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex"><div style=3D"background-color:rgb(255,255,255);line-height:initi=
al" lang=3D"en-US"> =
<div style=3D"width:100%;font-size:initial;fo=
nt-family:Calibri,'Slate Pro',sans-serif,sans-serif;color:rgb(31,73=
,125);text-align:initial;background-color:rgb(255,255,255)">Exceptions have=
nothing to do with bugs. Exceptions are a way to handle problems caused by=
external conditions (out of memory, file not found,...), not internal cond=
itions =3D=3D bugs. </div><div style=3D"width:100%;font-size:initial;font-f=
amily:Calibri,'Slate Pro',sans-serif,sans-serif;color:rgb(31,73,125=
);text-align:initial;background-color:rgb(255,255,255)"><br></div><div styl=
e=3D"width:100%;font-size:initial;font-family:Calibri,'Slate Pro',s=
ans-serif,sans-serif;color:rgb(31,73,125);text-align:initial;background-col=
or:rgb(255,255,255)">But having a stack trace facility in the language woul=
d be useful.=C2=A0</div><div style=3D"width:100%;font-size:initial;font-fam=
ily:Calibri,'Slate Pro',sans-serif,sans-serif;color:rgb(31,73,125);=
text-align:initial;background-color:rgb(255,255,255)"><br></div> =
=
<div style=3D"width:100%;fon=
t-size:initial;font-family:Calibri,'Slate Pro',sans-serif,sans-seri=
f;color:rgb(31,73,125);text-align:initial;background-color:rgb(255,255,255)=
"><br style=3D"display:initial"></div> =
=
=
<div style=3D"font-size:initial;font-family:Calibri,'Slate Pro&=
#39;,sans-serif,sans-serif;color:rgb(31,73,125);text-align:initial;backgrou=
nd-color:rgb(255,255,255)">Sent=C2=A0from=C2=A0my=C2=A0BlackBerry=C2=A0<wbr=
>portable=C2=A0Babbage=C2=A0Device</div> =
=
<table =
style=3D"background-color:white;border-spacing:0px" width=3D"100%"> <tbody>=
<tr><td colspan=3D"2" style=3D"font-size:initial;text-align:initial;backgro=
und-color:rgb(255,255,255)"> <div style=3D"border=
-style:solid none none;border-top-color:rgb(181,196,223);border-top-width:1=
pt;padding:3pt 0in 0in;font-family:Tahoma,'BB Alpha Sans','Slat=
e Pro';font-size:10pt"> <div><b>From: </b><a href=3D"javascript:" targ=
et=3D"_blank" gdf-obfuscated-mailto=3D"eFo7LIc2BgAJ" rel=3D"nofollow" onmou=
sedown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.h=
ref=3D'javascript:';return true;">redr...@gmail.com</a></div><div><=
b>Sent: </b>Saturday, July 30, 2016 8:14 PM</div><div><b>To: </b>ISO C++ St=
andard - Future Proposals</div><div><b>Reply To: </b><a href=3D"javascript:=
" target=3D"_blank" gdf-obfuscated-mailto=3D"eFo7LIc2BgAJ" rel=3D"nofollow"=
onmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"=
this.href=3D'javascript:';return true;">std-pr...@isocpp.org</a></d=
iv><div><b>Subject: </b>[std-proposals] Exception stack trace information.<=
/div></div></td></tr></tbody></table><div><div><div style=3D"border-style:s=
olid none none;border-top-color:rgb(186,188,209);border-top-width:1pt;font-=
size:initial;text-align:initial;background-color:rgb(255,255,255)"></div><b=
r><div><div dir=3D"ltr">In <b>C++17</b> will be added a lot of new features=
, but no of them features improve quality of code and quickly fixing of the=
code.<br>If in program exist a bug then the best that program can do is cr=
ash. Exception is a good conception for error handling, but is useless in C=
++ implementation, 'cause we do not know where the problem happens. Tha=
t mean catching of exception is useless, because additional information is =
so small that better allow program simple crash.<br>This is the main reason=
that even in debug mode exception is used not often.<br><br><b>PROBLEM </b=
>is no standard on it about providing to user <b>backtrace</b>.<br>Operatio=
n system can get stack trace when exception was used. We can implement gett=
ing stack trace even in dummy implementation by adding to every function in=
compile time meta information with name of this function and code that wil=
l put this name in stack object that implicitly exists from starting the pr=
ogram. We can add scpecial flag <b>BACK_TRACE</b> or <b>BTRACE</b>.<br><br>=
Sorry for straightforward speech but I tired. In we can implement <b>backtr=
ace</b>, but are thinking about coroutine. Without strong <b>base </b>we ca=
nnot implement something good.<br><br><b>Thanks,<br>Best regards.<br><br></=
b></div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
eFo7LIc2BgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:&=
#39;;return true;" onclick=3D"this.href=3D'javascript:';return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"eFo7LIc2BgAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'=
;javascript:';return true;">std-pr...@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a758ce2c-3750-4b9d-99e0-e9e1e3dcdb6d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank" =
rel=3D"nofollow" onmousedown=3D"this.href=3D'https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/a758ce2c-3750-4b9d-99e0-e9e1e3dcdb6d%40i=
socpp.org?utm_medium\x3demail\x26utm_source\x3dfooter';return true;" on=
click=3D"this.href=3D'https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/a758ce2c-3750-4b9d-99e0-e9e1e3dcdb6d%40isocpp.org?utm_medium\x3=
demail\x26utm_source\x3dfooter';return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/a758ce2c-3750-4b9d-<wbr>99e0-=
e9e1e3dcdb6d%40isocpp.org</a><wbr>.<br>
<br></div></div></div></div><div><div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
eFo7LIc2BgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:&=
#39;;return true;" onclick=3D"this.href=3D'javascript:';return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"eFo7LIc2BgAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'=
;javascript:';return true;">std-pr...@isocpp.org</a>.<br></div></div>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/20160731004107.4898897.76636.14874%40=
gmail.com?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank" rel=
=3D"nofollow" onmousedown=3D"this.href=3D'https://groups.google.com/a/i=
socpp.org/d/msgid/std-proposals/20160731004107.4898897.76636.14874%40gmail.=
com?utm_medium\x3demail\x26utm_source\x3dfooter';return true;" onclick=
=3D"this.href=3D'https://groups.google.com/a/isocpp.org/d/msgid/std-pro=
posals/20160731004107.4898897.76636.14874%40gmail.com?utm_medium\x3demail\x=
26utm_source\x3dfooter';return true;">https://groups.google.com/a/<wbr>=
isocpp.org/d/msgid/std-<wbr>proposals/20160731004107.<wbr>4898897.76636.148=
74%40gmail.<wbr>com</a>.<br>
</blockquote></div><br></div>
</blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/237863cb-3569-4784-b6f5-db80ac069ff6%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/237863cb-3569-4784-b6f5-db80ac069ff6=
%40isocpp.org</a>.<br />
------=_Part_1708_1748926483.1469947793797--
------=_Part_1707_1438267394.1469947793797
Content-Type: text/html; charset=US-ASCII;
name="A Proposal to Add a Stack Trace to Exception.htm"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="A Proposal to Add a Stack Trace to Exception.htm"
X-Attachment-Id: 8d0f7765-dc2a-44eb-b449-fb6806712d83
Content-ID: <8d0f7765-dc2a-44eb-b449-fb6806712d83>
<!DOCTYPE html><head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<title>A Proposal to Add a Stack Trace to Exception</title>
</head><body>b
<font size="-1">Denis Kotov <redradist@gmail.com> <br>31 Jul 2016
<br>Doc number ???</font>
<h1>A Proposal to Add a Stack Trace to Exception</h1>
<h2>I. Overview</h2>
<p>When you work on big project, the posibility of making by somebody mistake is very big.</p>
<p>To feedback user about this error the best way throw <strong><em>exception</em> </strong>instead of <strong><em>return -1.</em></strong></p>
<p>But when you desided to use exception in your program, you will face with the issue: <em>"Where this exception was throwed ?"</em></p>
<h2>II. Motivation</h2>
<p>To understand the problem let's consider the following code:</p>
<blockquote>
<pre>Socket *open_socket( void ) <br />{<br /> Socket *socket = new Socket();<br /> if (socket->open("", 80))<br /> {<br /> ....<br /> }<br /> else<br /> {<br /> throw socket_error("Cannot open socket !");<br /> }<br />}</pre>
</blockquote>
<blockquote>
<pre>void main( void )
{
....<br /> try {<br /> Socket *socket = open_socket( void );<br /> }<br /> catch(socket_error &error)<br /> {<br /> // How to print stack trace<br /> std::cout << error.(...) << std::endl;<br /> }<br />}</pre>
</blockquote>
<p>In this code the main question is:</p>
<p><em> "How to know in which function, in which file exception happens ?"</em></p>
<p>If we have such code it is easy to find the palce, but what if you have a hundered file:</p>
<p><em> "In which of this files and in which exactly function exception happens ?"</em></p>
<p> Let's consider the posibly solution for this issue:</p>
<blockquote>
<pre>Socket *open_socket( void ) <br />{<br /> Socket *socket = new Socket();<br /> if (socket->open("", 80))<br /> {<br /> ....<br /> }<br /> else<br /> {<br /> throw socket_error("Cannot open socket !");<br /> }<br />}</pre>
</blockquote>
<blockquote>
<pre>void main( void )
{
....<br /> try {<br /> Socket *socket = open_socket( void );<br /> }<br /> catch(socket_error &error)<br /> {<br /> std<span class="sy4">::</span><span class="me2">exception_ptr </span>eptr <span class="sy1">=</span> std::current_exception<span class="br0">(</span><span class="br0">)</span><span class="sy4">;</span> <span class="co1">// capture</span><br /> std::cout << eptr.print_stack_trace() << std::endl;<br /> }<br />}</pre>
</blockquote>
<p>This solution will work even in the following example:</p>
<p> Socket *open_socket( void )</p>
<p> {</p>
<blockquote>
<pre> Socket *socket = new Socket();<br /> if (socket->open("", 80))<br /> {<br /> ....<br /> }<br /> else<br /> {<br /> int error = 2; // Error code<br /> throw error;<br /> }<br />}</pre>
</blockquote>
<blockquote>
<pre>void main( void )
{
....<br /> try {<br /> Socket *socket = open_socket( void );<br /> }<br /> catch(...)<br /> {<br /> std<span class="sy4">::</span><span class="me2">exception_ptr </span>eptr <span class="sy1">=</span> std::current_exception<span class="br0">(</span><span class="br0">)</span><span class="sy4">;</span> <span class="co1">// capture</span><br /> std::cout << eptr.print_stack_trace() << std::endl;<br /> }<br />}</pre>
</blockquote>
<h2>III. Impact On the Standard</h2>
<p>Extending <code>std::</code><span class="me2">exception_ptr</span> as proposed is compatible with existing code and does not affect any other parts of the standard library, we only need extend meaning of <code>exception_ptr</code> like class and some functionality<code>.</code></p>
<h2>IV. Design Decisions</h2>
<p>The meaning of type <em>exception_ptr</em> should extended with providing contract.</p>
<blockquote><tt>typedef /*unspecified*/ exception_ptr;</tt></blockquote>
<blockquote>should be changed on</blockquote>
<blockquote><tt>typedef class _<tt>exception</tt> exception_ptr;</tt></blockquote>
<blockquote>or</blockquote>
<blockquote><tt>typedef class <tt>/*compiler specific name*/</tt> exception_ptr;</tt></blockquote>
<blockquote>class <tt>_<tt>exception</tt></tt></blockquote>
<blockquote>{</blockquote>
<blockquote>public:</blockquote>
<blockquote> // stack_trace_item is a class that is not defined yet</blockquote>
<blockquote> stack_trace_item *stack_trace() const;</blockquote>
<blockquote> char const *print_stack_trace() const;</blockquote>
<blockquote>}</blockquote>
<p>The meaning of type <em>exception_ptr</em> should extended with providing contract.</p>
<h2>V. Implementability</h2>
<p>A proof of concept implementation is available in StackWalker and BackTrace library for Linux.</p>
<h2>VI. References</h2>
<ul>
<li>[1] StackWaker on Windows, <a href="https://msdn.microsoft.com/en-us/library/windows/desktop/ms680650(v=vs.85).aspx">https://msdn.microsoft.com/en-us/library/windows/desktop/ms680650(v=vs.85).aspx</a></li>
<li>[2] BackTrace, <a href="http://man7.org/linux/man-pages/man3/backtrace.3.html">http://man7.org/linux/man-pages/man3/backtrace.3.html</a></li>
</ul></body></html>
------=_Part_1707_1438267394.1469947793797--
.
Author: =?UTF-8?B?0JTQtdC90LjRgSDQmtC+0YLQvtCy?= <redradist@gmail.com>
Date: Sun, 31 Jul 2016 02:57:35 -0700 (PDT)
Raw View
------=_Part_2169_466334969.1469959055247
Content-Type: multipart/alternative;
boundary="----=_Part_2170_1545219492.1469959055247"
------=_Part_2170_1545219492.1469959055247
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
> You misunderstand what exceptions are for. You're not supposed to catch=
=20
them
> to find out where the error occurred. You catch them so you handle the
> condition wherever it happened, then continue execution because you've
> corrected the problem.
I think this is incorrect.
How can I correct the problem or bug if I do not know where the problem=20
happened.
It is impossible or I need put *try ... catch* statement in every place of=
=20
my program. But it is wasting of time. Better when exception has all needed=
=20
information for analyzing where it happened.
=D0=B2=D0=BE=D1=81=D0=BA=D1=80=D0=B5=D1=81=D0=B5=D0=BD=D1=8C=D0=B5, 31 =D0=
=B8=D1=8E=D0=BB=D1=8F 2016 =D0=B3., 8:54:04 UTC+3 =D0=BF=D0=BE=D0=BB=D1=8C=
=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Thiago Macieira=20
=D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:
>
> On s=C3=A1bado, 30 de julho de 2016 17:14:19 PDT redr...@gmail.com=20
> <javascript:> wrote:=20
> > In *C++17* will be added a lot of new features, but no of them features=
=20
> > improve quality of code and quickly fixing of the code.=20
>
> I'm pretty sure a lot of people dispute that statement. Just look at the=
=20
> whole=20
> discussion happening right now about evaluation ordere of arguments and i=
n=20
> expressions. That's supposed to improve the quality of code. The new=20
> classes,=20
> when used in new code, also improve the quality.=20
>
> > If in program exist a bug then the best that program can do is crash.=
=20
> > Exception is a good conception for error handling, but is useless in C+=
+=20
> > implementation, 'cause we do not know where the problem happens. That=
=20
> mean=20
> > catching of exception is useless, because additional information is so=
=20
> > small that better allow program simple crash.=20
>
> You misunderstand what exceptions are for. You're not supposed to catch=
=20
> them=20
> to find out where the error occurred. You catch them so you handle the=20
> condition wherever it happened, then continue execution because you've=20
> corrected the problem.=20
>
> > This is the main reason that even in debug mode exception is used not=
=20
> often.=20
>
> I don't know any program that enables or disables exceptions according to=
=20
> debug mode or release mode. This statement of yours lacks proof and,=20
> coupled=20
> with the misundersanding above, indicates you either completely=20
> misunderstand=20
> exceptions or you're talking about something else, something that is not=
=20
> called "exceptions".=20
>
> > *PROBLEM *is no standard on it about providing to user *backtrace*.=20
> > Operation system can get stack trace when exception was used. We can=20
> > implement getting stack trace even in dummy implementation by adding to=
=20
> > every function in compile time meta information with name of this=20
> function=20
> > and code that will put this name in stack object that implicitly exists=
=20
> > from starting the program. We can add scpecial flag *BACK_TRACE* or=20
> *BTRACE*=20
>
> There was a discussion about backtraces a while ago. It's hard to have=20
> something about it in the standard because then the standard needs to=20
> understand the concept of "frame" and will constrain what the compiler is=
=20
> allowed to do to optimise and inline functions. For example, will it be=
=20
> allowed to omit the frame pointer?=20
>
> > Sorry for straightforward speech but I tired. In we can implement=20
> > *backtrace*, but are thinking about coroutine. Without strong *base *we=
=20
> > cannot implement something good.=20
>
> Again, many will dispute the implication that the base is not strong. It=
=20
> is.=20
>
> Many will dispute that backtraces improve the base in any way. I am one o=
f=20
> those: I fail to see the value of standardising this fuctionality. It has=
=20
> existed very well for 30 years in the realm of debuggers. The standard ha=
s=20
> no=20
> concept of "bug", it simply declares that some behaviours are undefined=
=20
> and=20
> that, under some conditions, the program is ill-formed. How those are=20
> exposed=20
> to the user, that's implementation-defined and so is the method of their=
=20
> correction.=20
>
> Tooling can be improved, of course. But I argue that it's constantly in=
=20
> improvement and, more importantlu, the issue of backtraces is an *already=
*=20
> solved problem.=20
>
> Finally, I share some of your concern. There are many things that need to=
=20
> be=20
> added to the language and to the standard library to cover some of its=20
> shortcomings. One of my biggest gripes of C++11 was the incomplete suppor=
t=20
> for=20
> the Unicode support that was added, including some basic steps, while a=
=20
> huge=20
> library for ratios and random was added. But since then, I've learned tha=
t=20
> you=20
> can't stall progress in one area that has consensus because another=20
> doesn't=20
> have it yet. Many things need more time for discussion and implementation=
=20
> and=20
> they shouldn't hold back what has been already agreed upon.=20
>
> --=20
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org=20
> Software Architect - Intel Open Source Technology Center=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/ce19670c-441d-4707-b460-ea9c82f61bb3%40isocpp.or=
g.
------=_Part_2170_1545219492.1469959055247
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">> You misunderstand what exceptions are for. You're=
not supposed to catch them<br>> to find out where the error occurred. Y=
ou catch them so you handle the<br>> condition wherever it happened, the=
n continue execution because you've<br>> corrected the problem.<br><=
br>I think this is incorrect.<br>How can I correct the problem or bug if I =
do not know where the problem happened.<br>It is impossible or I need put <=
b>try ... catch</b> statement in every place of my program. But it is wasti=
ng of time. Better when exception has all needed information for analyzing =
where it happened.<br><br>=D0=B2=D0=BE=D1=81=D0=BA=D1=80=D0=B5=D1=81=D0=B5=
=D0=BD=D1=8C=D0=B5, 31 =D0=B8=D1=8E=D0=BB=D1=8F 2016 =D0=B3., 8:54:04 UTC+3=
=D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C T=
hiago Macieira =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:<blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;">On s=C3=A1bado, 30 de julho de 2016 17:14:19 PD=
T <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"B4DL2B=
RCBgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';r=
eturn true;" onclick=3D"this.href=3D'javascript:';return true;">red=
r...@gmail.com</a> wrote:
<br>> In *C++17* will be added a lot of new features, but no of them fea=
tures
<br>> improve quality of code and quickly fixing of the code.
<br>
<br>I'm pretty sure a lot of people dispute that statement. Just look a=
t the whole=20
<br>discussion happening right now about evaluation ordere of arguments and=
in=20
<br>expressions. That's supposed to improve the quality of code. The ne=
w classes,=20
<br>when used in new code, also improve the quality.
<br>
<br>> If in program exist a bug then the best that program can do is cra=
sh.
<br>> Exception is a good conception for error handling, but is useless =
in C++
<br>> implementation, 'cause we do not know where the problem happen=
s. That mean
<br>> catching of exception is useless, because additional information i=
s so
<br>> small that better allow program simple crash.
<br>
<br>You misunderstand what exceptions are for. You're not supposed to c=
atch them=20
<br>to find out where the error occurred. You catch them so you handle the=
=20
<br>condition wherever it happened, then continue execution because you'=
;ve=20
<br>corrected the problem.
<br>
<br>> This is the main reason that even in debug mode exception is used =
not often.
<br>
<br>I don't know any program that enables or disables exceptions accord=
ing to=20
<br>debug mode or release mode. This statement of yours lacks proof and, co=
upled=20
<br>with the misundersanding above, indicates you either completely misunde=
rstand=20
<br>exceptions or you're talking about something else, something that i=
s not=20
<br>called "exceptions".
<br>
<br>> *PROBLEM *is no standard on it about providing to user *backtrace*=
..
<br>> Operation system can get stack trace when exception was used. We c=
an
<br>> implement getting stack trace even in dummy implementation by addi=
ng to
<br>> every function in compile time meta information with name of this =
function
<br>> and code that will put this name in stack object that implicitly e=
xists
<br>> from starting the program. We can add scpecial flag *BACK_TRACE* o=
r *BTRACE*
<br>
<br>There was a discussion about backtraces a while ago. It's hard to h=
ave=20
<br>something about it in the standard because then the standard needs to=
=20
<br>understand the concept of "frame" and will constrain what the=
compiler is=20
<br>allowed to do to optimise and inline functions. For example, will it be=
=20
<br>allowed to omit the frame pointer?
<br>
<br>> Sorry for straightforward speech but I tired. In we can implement
<br>> *backtrace*, but are thinking about coroutine. Without strong *bas=
e *we
<br>> cannot implement something good.
<br>
<br>Again, many will dispute the implication that the base is not strong. I=
t is.
<br>
<br>Many will dispute that backtraces improve the base in any way. I am one=
of=20
<br>those: I fail to see the value of standardising this fuctionality. It h=
as=20
<br>existed very well for 30 years in the realm of debuggers. The standard =
has no=20
<br>concept of "bug", it simply declares that some behaviours are=
undefined and=20
<br>that, under some conditions, the program is ill-formed. How those are e=
xposed=20
<br>to the user, that's implementation-defined and so is the method of =
their=20
<br>correction.
<br>
<br>Tooling can be improved, of course. But I argue that it's constantl=
y in=20
<br>improvement and, more importantlu, the issue of backtraces is an *alrea=
dy*=20
<br>solved problem.
<br>
<br>Finally, I share some of your concern. There are many things that need =
to be=20
<br>added to the language and to the standard library to cover some of its=
=20
<br>shortcomings. One of my biggest gripes of C++11 was the incomplete supp=
ort for=20
<br>the Unicode support that was added, including some basic steps, while a=
huge=20
<br>library for ratios and random was added. But since then, I've learn=
ed that you=20
<br>can't stall progress in one area that has consensus because another=
doesn't=20
<br>have it yet. Many things need more time for discussion and implementati=
on and=20
<br>they shouldn't hold back what has been already agreed upon.
<br>
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.goo=
gle.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x3dD\x26sntz\x3d1\x26usg\=
x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return true;" onclick=3D"this.hr=
ef=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x=
3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return t=
rue;">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" target=3D"=
_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google.=
com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH=
GRJdo5_JYG1DowztwAHAKs80XSA';return true;" onclick=3D"this.href=3D'=
http://www.google.com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1=
\x26usg\x3dAFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return true;">kde.org</a=
>
<br>=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center
<br>
<br></blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/ce19670c-441d-4707-b460-ea9c82f61bb3%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ce19670c-441d-4707-b460-ea9c82f61bb3=
%40isocpp.org</a>.<br />
------=_Part_2170_1545219492.1469959055247--
------=_Part_2169_466334969.1469959055247--
.
Author: =?UTF-8?Q?=27Bernd_L=C3=B6rwald=27_via_ISO_C=2B=2B_Standard_=2D_Future_Proposal?=
Date: Sun, 31 Jul 2016 12:39:45 +0200
Raw View
--Apple-Mail-4237024B-08DC-426E-AD59-94FB3452AB78
Content-Type: text/plain; charset=UTF-8
> How can I correct the problem or bug if I do not know where the problem happened.
> It is impossible or I need put try ... catch statement in every place of my program.
gdb offers "catch throw" to break on thrown exceptions, allowing you to get a backtrace etc. I'm sure your debugger/IDE has a similar feature.
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/F24B46CD-93AC-4C03-8BF6-F310D0E286C7%40googlemail.com.
--Apple-Mail-4237024B-08DC-426E-AD59-94FB3452AB78
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=
=3Dutf-8"></head><body dir=3D"auto"><div></div><br><blockquote type=3D"cite=
"><div dir=3D"ltr">How can I correct the problem or bug if I do not know wh=
ere the problem happened.<br>It is impossible or I need put <b>try ... catc=
h</b> statement in every place of my program. </div>
</blockquote><br><div>gdb offers "catch throw" to break on thrown exception=
s, allowing you to get a backtrace etc. I'm sure your debugger/IDE has a si=
milar feature.</div></body></html>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/F24B46CD-93AC-4C03-8BF6-F310D0E286C7%=
40googlemail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.goo=
gle.com/a/isocpp.org/d/msgid/std-proposals/F24B46CD-93AC-4C03-8BF6-F310D0E2=
86C7%40googlemail.com</a>.<br />
--Apple-Mail-4237024B-08DC-426E-AD59-94FB3452AB78--
.
Author: =?UTF-8?B?0JTQtdC90LjRgSDQmtC+0YLQvtCy?= <redradist@gmail.com>
Date: Sun, 31 Jul 2016 03:51:53 -0700 (PDT)
Raw View
------=_Part_2122_1686226115.1469962313625
Content-Type: multipart/alternative;
boundary="----=_Part_2123_133880649.1469962313625"
------=_Part_2123_133880649.1469962313625
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Bernd L=C3=B6rwald:
> gdb offers "catch throw" to break on thrown exceptions, allowing you to=
=20
get a backtrace etc. I'm sure your debugger/IDE has a similar feature.
Yes, you are right. But a lot of mistakes happens in real work, for real=20
use-cases.
And it is only for this compiler and this envoriment. On *Windows *platform=
=20
we have another solution: *StackWalker *or *SEH *exception handling.
Problem, there is no standard in c++ to get stack trace when exception was=
=20
thrown and program becomes inconsistent.
=D0=B2=D0=BE=D1=81=D0=BA=D1=80=D0=B5=D1=81=D0=B5=D0=BD=D1=8C=D0=B5, 31 =D0=
=B8=D1=8E=D0=BB=D1=8F 2016 =D0=B3., 13:39:49 UTC+3 =D0=BF=D0=BE=D0=BB=D1=8C=
=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Bernd L=C3=B6rwald=20
=D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:
>
>
> How can I correct the problem or bug if I do not know where the problem=
=20
> happened.
> It is impossible or I need put *try ... catch* statement in every place=
=20
> of my program.=20
>
>
> gdb offers "catch throw" to break on thrown exceptions, allowing you to=
=20
> get a backtrace etc. I'm sure your debugger/IDE has a similar feature.
>
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/06c4e754-1492-4075-b5d3-eddc586fa0d8%40isocpp.or=
g.
------=_Part_2123_133880649.1469962313625
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><span class=3D"_username"><span style=3D"color: rgb(34, 34=
, 34);" class=3D"IVILX2C-D-a">Bernd L=C3=B6rwald:</span></span><br>> gdb=
offers "catch throw" to break on thrown exceptions, allowing you=
to=20
get a backtrace etc. I'm sure your debugger/IDE has a similar feature.<=
br><br>Yes, you are right. But a lot of mistakes happens in real work, for =
real use-cases.<br>And it is only for this compiler and this envoriment. On=
<b>Windows </b>platform we have another solution: <b>StackWalker </b>or <b=
>SEH </b>exception handling.<br>Problem, there is no standard in c++ to get=
stack trace when exception was thrown and program becomes inconsistent.<br=
><br>=D0=B2=D0=BE=D1=81=D0=BA=D1=80=D0=B5=D1=81=D0=B5=D0=BD=D1=8C=D0=B5, 31=
=D0=B8=D1=8E=D0=BB=D1=8F 2016 =D0=B3., 13:39:49 UTC+3 =D0=BF=D0=BE=D0=BB=
=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Bernd L=C3=B6rwald =
=D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:<blockquote class=3D"gmail_quote=
" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding=
-left: 1ex;"><div dir=3D"auto"><div></div><br><blockquote type=3D"cite"><di=
v dir=3D"ltr">How can I correct the problem or bug if I do not know where t=
he problem happened.<br>It is impossible or I need put <b>try ... catch</b>=
statement in every place of my program.=C2=A0</div>
</blockquote><br><div>gdb offers "catch throw" to break on thrown=
exceptions, allowing you to get a backtrace etc. I'm sure your debugge=
r/IDE has a similar feature.</div></div></blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/06c4e754-1492-4075-b5d3-eddc586fa0d8%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/06c4e754-1492-4075-b5d3-eddc586fa0d8=
%40isocpp.org</a>.<br />
------=_Part_2123_133880649.1469962313625--
------=_Part_2122_1686226115.1469962313625--
.
Author: Patrice Roy <patricer@gmail.com>
Date: Sun, 31 Jul 2016 11:16:06 -0400
Raw View
--001a114e30dc73a5a30538eff606
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Hi!
Be careful: void main() is illegal in C++. Passing =C2=ABvoid=C2=BB as argu=
ment,
while not illegal, brings you nothing; I'd personally avoid it, but you're
the boss :)
Your proposal might carry more weight if it was more idiomatic: I'd
envision returning unique_ptr<Socket> instead of Socket* from
open_socket(), for example, as the example code currently leaks.
Someone's bound to point out that replacing this:
throw socket_error("Cannot open socket !");
.... by something like this (just an example, not a proposal :) ):
class socket_open_exception{};
// ...
throw socket_open_exception{};
....would go a long way making the code better, and giving a better handle
on what failed. That said, by more precise exception types, the need for a
stack trace is probably not as strong.
If looking for source code-related info on the source of the problem, there
are macros that provide file, line and function information which can be
supplied as exception construction arguments. There's also some work by
Robert Douglas (my memory might be faulty here) that would lead compilers
to provide this in non-macro form. That's not the same thing as a stack
trace, that being said.
It would be a good idea to provide more info on what is expected from
stack_trace_item, IMHO.
Cheers!
2016-07-31 2:49 GMT-04:00 <redradist@gmail.com>:
> I have prepared my first proposal. Please, dont bit hard for missing
> details.
> You can find it in attachment.
>
> =D0=B2=D0=BE=D1=81=D0=BA=D1=80=D0=B5=D1=81=D0=B5=D0=BD=D1=8C=D0=B5, 31 =
=D0=B8=D1=8E=D0=BB=D1=8F 2016 =D0=B3., 5:22:21 UTC+3 =D0=BF=D0=BE=D0=BB=D1=
=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Patrice Roy
> =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:
>>
>> Stating that exceptions are useless when many of use use them to our
>> benefit is a bit... harsh :) I agree with Tony that for some use cases, =
the
>> stack trace would be nice. Please, feel free to prepare a proposal!
>>
>> 2016-07-30 20:41 GMT-04:00 Tony V E <tvan...@gmail.com>:
>>
>>> Exceptions have nothing to do with bugs. Exceptions are a way to handle
>>> problems caused by external conditions (out of memory, file not found,.=
...),
>>> not internal conditions =3D=3D bugs.
>>>
>>> But having a stack trace facility in the language would be useful.
>>>
>>>
>>> Sent from my BlackBerry portable Babbage Device
>>> *From: *redr...@gmail.com
>>> *Sent: *Saturday, July 30, 2016 8:14 PM
>>> *To: *ISO C++ Standard - Future Proposals
>>> *Reply To: *std-pr...@isocpp.org
>>> *Subject: *[std-proposals] Exception stack trace information.
>>>
>>> In *C++17* will be added a lot of new features, but no of them features
>>> improve quality of code and quickly fixing of the code.
>>> If in program exist a bug then the best that program can do is crash.
>>> Exception is a good conception for error handling, but is useless in C+=
+
>>> implementation, 'cause we do not know where the problem happens. That m=
ean
>>> catching of exception is useless, because additional information is so
>>> small that better allow program simple crash.
>>> This is the main reason that even in debug mode exception is used not
>>> often.
>>>
>>> *PROBLEM *is no standard on it about providing to user *backtrace*.
>>> Operation system can get stack trace when exception was used. We can
>>> implement getting stack trace even in dummy implementation by adding to
>>> every function in compile time meta information with name of this funct=
ion
>>> and code that will put this name in stack object that implicitly exists
>>> from starting the program. We can add scpecial flag *BACK_TRACE* or
>>> *BTRACE*.
>>>
>>> Sorry for straightforward speech but I tired. In we can implement
>>> *backtrace*, but are thinking about coroutine. Without strong *base *we
>>> cannot implement something good.
>>>
>>>
>>>
>>>
>>> *Thanks,Best regards.*
>>>
>>> --
>>> 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-proposal...@isocpp.org.
>>> To post to this group, send email to std-pr...@isocpp.org.
>>> To view this discussion on the web visit
>>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/a758ce2c-3=
750-4b9d-99e0-e9e1e3dcdb6d%40isocpp.org
>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/a758ce2c-=
3750-4b9d-99e0-e9e1e3dcdb6d%40isocpp.org?utm_medium=3Demail&utm_source=3Dfo=
oter>
>>> .
>>>
>>> --
>>> 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-proposal...@isocpp.org.
>>> To post to this group, send email to std-pr...@isocpp.org.
>>> To view this discussion on the web visit
>>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2016073100=
4107.4898897.76636.14874%40gmail.com
>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/201607310=
04107.4898897.76636.14874%40gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r>
>>> .
>>>
>>
>> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/237863cb-356=
9-4784-b6f5-db80ac069ff6%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/237863cb-35=
69-4784-b6f5-db80ac069ff6%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAKiZDp3AuqireTRBb814bh23igbzNcOYmg-qNOvA_Pt4p2J=
w9g%40mail.gmail.com.
--001a114e30dc73a5a30538eff606
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div><div><div><div><div><div><div><div><div>Hi!<br><=
br></div>Be careful: void main() is illegal in C++. Passing =C2=ABvoid=C2=
=BB as argument, while not illegal, brings you nothing; I'd personally =
avoid it, but you're the boss :)<br><br></div>Your proposal might carry=
more weight if it was more idiomatic: I'd envision returning unique_pt=
r<Socket> instead of Socket* from open_socket(), for example, as the =
example code currently leaks.<br><br></div>Someone's bound to point out=
that replacing this:<br><br><pre>throw socket_error("Cannot open sock=
et !");</pre><br></div>... by something like this (just an example, no=
t a proposal :) ):<br><br></div>class socket_open_exception{};<br>// ...<br=
></div>throw socket_open_exception{};<br><br></div>...would go a long way m=
aking the code better, and giving a better handle on what failed. That said=
, by more precise exception types, the need for a stack trace is probably n=
ot as strong.<br><br></div>If looking for source code-related info on the s=
ource of the problem, there are macros that provide file, line and function=
information which can be supplied as exception construction arguments. The=
re's also some work by Robert Douglas (my memory might be faulty here) =
that would lead compilers to provide this in non-macro form. That's not=
the same thing as a stack trace, that being said.<br><br></div>It would be=
a good idea to provide more info on what is expected from stack_trace_item=
, IMHO.<br><br></div>Cheers!<br><div><div><br><br><div><div><div><div><div>=
<div><br><br></div></div></div></div></div></div></div></div></div><div cla=
ss=3D"gmail_extra"><br><div class=3D"gmail_quote">2016-07-31 2:49 GMT-04:00=
<span dir=3D"ltr"><<a href=3D"mailto:redradist@gmail.com" target=3D"_b=
lank">redradist@gmail.com</a>></span>:<br><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr">I have prepared my first proposal. Please, dont bit hard =
for missing details.<br>You can find it in attachment.<br><br>=D0=B2=D0=BE=
=D1=81=D0=BA=D1=80=D0=B5=D1=81=D0=B5=D0=BD=D1=8C=D0=B5, 31 =D0=B8=D1=8E=D0=
=BB=D1=8F 2016 =D0=B3., 5:22:21 UTC+3 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=
=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Patrice Roy =D0=BD=D0=B0=D0=BF=D0=B8=
=D1=81=D0=B0=D0=BB:<blockquote class=3D"gmail_quote" style=3D"margin:0;marg=
in-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D""=
><div dir=3D"ltr">Stating that exceptions are useless when many of use use =
them to our benefit is a bit... harsh :) I agree with Tony that for some us=
e cases, the stack trace would be nice. Please, feel free to prepare a prop=
osal!<br></div></span><div><br><div class=3D"gmail_quote"><span class=3D"">=
2016-07-30 20:41 GMT-04:00 Tony V E <span dir=3D"ltr"><<a rel=3D"nofollo=
w">tvan...@gmail.com</a>></span>:<br></span><blockquote class=3D"gmail_q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x"><div style=3D"background-color:rgb(255,255,255);line-height:initial" lan=
g=3D"en-US"><span class=3D""> =
<div style=3D"width:100%;font-size:=
initial;font-family:Calibri,'Slate Pro',sans-serif,sans-serif;color=
:rgb(31,73,125);text-align:initial;background-color:rgb(255,255,255)">Excep=
tions have nothing to do with bugs. Exceptions are a way to handle problems=
caused by external conditions (out of memory, file not found,...), not int=
ernal conditions =3D=3D bugs. </div><div style=3D"width:100%;font-size:init=
ial;font-family:Calibri,'Slate Pro',sans-serif,sans-serif;color:rgb=
(31,73,125);text-align:initial;background-color:rgb(255,255,255)"><br></div=
><div style=3D"width:100%;font-size:initial;font-family:Calibri,'Slate =
Pro',sans-serif,sans-serif;color:rgb(31,73,125);text-align:initial;back=
ground-color:rgb(255,255,255)">But having a stack trace facility in the lan=
guage would be useful.=C2=A0</div><div style=3D"width:100%;font-size:initia=
l;font-family:Calibri,'Slate Pro',sans-serif,sans-serif;color:rgb(3=
1,73,125);text-align:initial;background-color:rgb(255,255,255)"><br></div> =
=
<div style=3D"widt=
h:100%;font-size:initial;font-family:Calibri,'Slate Pro',sans-serif=
,sans-serif;color:rgb(31,73,125);text-align:initial;background-color:rgb(25=
5,255,255)"><br style=3D"display:initial"></div> =
=
=
<div style=3D"font-size:initial;font-family:Calibri,'=
Slate Pro',sans-serif,sans-serif;color:rgb(31,73,125);text-align:initia=
l;background-color:rgb(255,255,255)">Sent=C2=A0from=C2=A0my=C2=A0BlackBerry=
=C2=A0portable=C2=A0Babbage=C2=A0Device</div> =
=
</=
span><table style=3D"background-color:white;border-spacing:0px" width=3D"10=
0%"> <tbody><tr><td colspan=3D"2" style=3D"font-size:initial;text-align:ini=
tial;background-color:rgb(255,255,255)"> <div sty=
le=3D"border-style:solid none none;border-top-color:rgb(181,196,223);border=
-top-width:1pt;padding:3pt 0in 0in;font-family:Tahoma,'BB Alpha Sans=
9;,'Slate Pro';font-size:10pt"> <div><b>From: </b><a rel=3D"nofoll=
ow">redr...@gmail.com</a></div><span class=3D""><div><b>Sent: </b>Saturday,=
July 30, 2016 8:14 PM</div><div><b>To: </b>ISO C++ Standard - Future Propo=
sals</div></span><div><b>Reply To: </b><a rel=3D"nofollow">std-pr...@isocpp=
..org</a></div><span class=3D""><div><b>Subject: </b>[std-proposals] Excepti=
on stack trace information.</div></span></div></td></tr></tbody></table><di=
v><div><div style=3D"border-style:solid none none;border-top-color:rgb(186,=
188,209);border-top-width:1pt;font-size:initial;text-align:initial;backgrou=
nd-color:rgb(255,255,255)"></div><br><div><span class=3D""><div dir=3D"ltr"=
>In <b>C++17</b> will be added a lot of new features, but no of them featur=
es improve quality of code and quickly fixing of the code.<br>If in program=
exist a bug then the best that program can do is crash. Exception is a goo=
d conception for error handling, but is useless in C++ implementation, '=
;cause we do not know where the problem happens. That mean catching of exce=
ption is useless, because additional information is so small that better al=
low program simple crash.<br>This is the main reason that even in debug mod=
e exception is used not often.<br><br><b>PROBLEM </b>is no standard on it a=
bout providing to user <b>backtrace</b>.<br>Operation system can get stack =
trace when exception was used. We can implement getting stack trace even in=
dummy implementation by adding to every function in compile time meta info=
rmation with name of this function and code that will put this name in stac=
k object that implicitly exists from starting the program. We can add scpec=
ial flag <b>BACK_TRACE</b> or <b>BTRACE</b>.<br><br>Sorry for straightforwa=
rd speech but I tired. In we can implement <b>backtrace</b>, but are thinki=
ng about coroutine. Without strong <b>base </b>we cannot implement somethin=
g good.<br><br><b>Thanks,<br>Best regards.<br><br></b></div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br></span>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</a>.<span class=3D""><br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a758ce2c-3750-4b9d-99e0-e9e1e3dcdb6d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" rel=3D"nofollow" t=
arget=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-proposa=
ls/a758ce2c-3750-4b9d-99e0-e9e1e3dcdb6d%40isocpp.org</a>.<br>
<br></span></div></div></div></div><div><div><span class=3D"">
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br></span>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</a>.<br></div></div><span class=3D"">
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/20160731004107.4898897.76636.14874%40=
gmail.com?utm_medium=3Demail&utm_source=3Dfooter" rel=3D"nofollow" targ=
et=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/=
20160731004107.4898897.76636.14874%40gmail.com</a>.<br>
</span></blockquote></div><br></div>
</blockquote></div><span class=3D"">
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/237863cb-3569-4784-b6f5-db80ac069ff6%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/237863cb-3569-=
4784-b6f5-db80ac069ff6%40isocpp.org</a>.<br>
</blockquote></div><br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAKiZDp3AuqireTRBb814bh23igbzNcOYmg-q=
NOvA_Pt4p2Jw9g%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKiZDp3AuqireTRB=
b814bh23igbzNcOYmg-qNOvA_Pt4p2Jw9g%40mail.gmail.com</a>.<br />
--001a114e30dc73a5a30538eff606--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Sun, 31 Jul 2016 09:09:46 -0700
Raw View
On domingo, 31 de julho de 2016 02:57:35 PDT =D0=94=D0=B5=D0=BD=D0=B8=D1=81=
=D0=9A=D0=BE=D1=82=D0=BE=D0=B2 wrote:
> > You misunderstand what exceptions are for. You're not supposed to catch
>=20
> them
>=20
> > to find out where the error occurred. You catch them so you handle the
> > condition wherever it happened, then continue execution because you've
> > corrected the problem.
>=20
> I think this is incorrect.
> How can I correct the problem or bug if I do not know where the problem
> happened.
There was no bug. Exceptions are not used to signal bugs. They are used to=
=20
signal perfectly fine, if exceptional, conditions. A file not being found i=
s not=20
a bug.
If there's a bug, you can't guarantee that the exception will be thrown=20
properly nor that it will be caught, much less that anything it contains wi=
ll=20
be correct. That's because after the first bug, all bets are off.
> It is impossible or I need put *try ... catch* statement in every place o=
f
> my program. But it is wasting of time. Better when exception has all need=
ed
> information for analyzing where it happened.
You put it around any place that can throw and that your founction isn't=20
expected to throw that exception.
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/2612719.7ZaQRHIfLc%40tjmaciei-mobl1.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Sun, 31 Jul 2016 09:10:49 -0700
Raw View
On domingo, 31 de julho de 2016 03:51:53 PDT =D0=94=D0=B5=D0=BD=D0=B8=D1=81=
=D0=9A=D0=BE=D1=82=D0=BE=D0=B2 wrote:
> Yes, you are right. But a lot of mistakes happens in real work, for real=
=20
> use-cases.
> And it is only for this compiler and this envoriment. On *Windows *platfo=
rm=20
> we have another solution: *StackWalker *or *SEH *exception handling.
> Problem, there is no standard in c++ to get stack trace when exception wa=
s
> thrown and program becomes inconsistent.
You know why that is? Because the program has become inconsistent. Once you=
've=20
stepped out of the standard, the standard has no say.
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/4074653.H6aTAbYWL6%40tjmaciei-mobl1.
.
Author: =?UTF-8?B?0JTQtdC90LjRgSDQmtC+0YLQvtCy?= <redradist@gmail.com>
Date: Sun, 31 Jul 2016 09:20:42 -0700 (PDT)
Raw View
------=_Part_2005_2008805983.1469982042417
Content-Type: multipart/alternative;
boundary="----=_Part_2006_848018967.1469982042417"
------=_Part_2006_848018967.1469982042417
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Patrice Roy:
Sorry me. I wrote this proposal in the morning and as you has shown me, not=
=20
very carefully,
inattentively. I wanted to show an idea in general.
Maybe I forgot drink few cups of coffee =3D)
I will correct document with proposal more carefully and more attentively.
> That said, by more precise exception types, the need for a stack trace is=
=20
probably not as strong.
But if we want more general solution we need support more precise exception=
=20
types like throwing interger.
Could you suggest me where I can get proposal number like N3256 ?
=D0=B2=D0=BE=D1=81=D0=BA=D1=80=D0=B5=D1=81=D0=B5=D0=BD=D1=8C=D0=B5, 31 =D0=
=B8=D1=8E=D0=BB=D1=8F 2016 =D0=B3., 18:16:08 UTC+3 =D0=BF=D0=BE=D0=BB=D1=8C=
=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Patrice Roy=20
=D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:
>
> Hi!
>
> Be careful: void main() is illegal in C++. Passing =C2=ABvoid=C2=BB as ar=
gument,=20
> while not illegal, brings you nothing; I'd personally avoid it, but you'r=
e=20
> the boss :)
>
> Your proposal might carry more weight if it was more idiomatic: I'd=20
> envision returning unique_ptr<Socket> instead of Socket* from=20
> open_socket(), for example, as the example code currently leaks.
>
> Someone's bound to point out that replacing this:
>
> throw socket_error("Cannot open socket !");
>
>
> ... by something like this (just an example, not a proposal :) ):
>
> class socket_open_exception{};
> // ...
> throw socket_open_exception{};
>
> ...would go a long way making the code better, and giving a better handle=
=20
> on what failed. That said, by more precise exception types, the need for =
a=20
> stack trace is probably not as strong.
>
> If looking for source code-related info on the source of the problem,=20
> there are macros that provide file, line and function information which c=
an=20
> be supplied as exception construction arguments. There's also some work b=
y=20
> Robert Douglas (my memory might be faulty here) that would lead compilers=
=20
> to provide this in non-macro form. That's not the same thing as a stack=
=20
> trace, that being said.
>
> It would be a good idea to provide more info on what is expected from=20
> stack_trace_item, IMHO.
>
> Cheers!
>
>
>
>
>
> 2016-07-31 2:49 GMT-04:00 <redr...@gmail.com <javascript:>>:
>
>> I have prepared my first proposal. Please, dont bit hard for missing=20
>> details.
>> You can find it in attachment.
>>
>> =D0=B2=D0=BE=D1=81=D0=BA=D1=80=D0=B5=D1=81=D0=B5=D0=BD=D1=8C=D0=B5, 31 =
=D0=B8=D1=8E=D0=BB=D1=8F 2016 =D0=B3., 5:22:21 UTC+3 =D0=BF=D0=BE=D0=BB=D1=
=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Patrice Roy=20
>> =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:
>>>
>>> Stating that exceptions are useless when many of use use them to our=20
>>> benefit is a bit... harsh :) I agree with Tony that for some use cases,=
the=20
>>> stack trace would be nice. Please, feel free to prepare a proposal!
>>>
>>> 2016-07-30 20:41 GMT-04:00 Tony V E <tvan...@gmail.com>:
>>>
>>>> Exceptions have nothing to do with bugs. Exceptions are a way to handl=
e=20
>>>> problems caused by external conditions (out of memory, file not found,=
....),=20
>>>> not internal conditions =3D=3D bugs.=20
>>>>
>>>> But having a stack trace facility in the language would be useful.=20
>>>>
>>>>
>>>> Sent from my BlackBerry portable Babbage Device
>>>> *From: *redr...@gmail.com
>>>> *Sent: *Saturday, July 30, 2016 8:14 PM
>>>> *To: *ISO C++ Standard - Future Proposals
>>>> *Reply To: *std-pr...@isocpp.org
>>>> *Subject: *[std-proposals] Exception stack trace information.
>>>>
>>>> In *C++17* will be added a lot of new features, but no of them=20
>>>> features improve quality of code and quickly fixing of the code.
>>>> If in program exist a bug then the best that program can do is crash.=
=20
>>>> Exception is a good conception for error handling, but is useless in C=
++=20
>>>> implementation, 'cause we do not know where the problem happens. That =
mean=20
>>>> catching of exception is useless, because additional information is so=
=20
>>>> small that better allow program simple crash.
>>>> This is the main reason that even in debug mode exception is used not=
=20
>>>> often.
>>>>
>>>> *PROBLEM *is no standard on it about providing to user *backtrace*.
>>>> Operation system can get stack trace when exception was used. We can=
=20
>>>> implement getting stack trace even in dummy implementation by adding t=
o=20
>>>> every function in compile time meta information with name of this func=
tion=20
>>>> and code that will put this name in stack object that implicitly exist=
s=20
>>>> from starting the program. We can add scpecial flag *BACK_TRACE* or=20
>>>> *BTRACE*.
>>>>
>>>> Sorry for straightforward speech but I tired. In we can implement=20
>>>> *backtrace*, but are thinking about coroutine. Without strong *base *w=
e=20
>>>> cannot implement something good.
>>>>
>>>>
>>>>
>>>>
>>>> *Thanks,Best regards.*
>>>>
>>>> --=20
>>>> You received this message because you are subscribed to the Google=20
>>>> Groups "ISO C++ Standard - Future Proposals" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send=
=20
>>>> an email to std-proposal...@isocpp.org.
>>>> To post to this group, send email to std-pr...@isocpp.org.
>>>> To view this discussion on the web visit=20
>>>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/a758ce2c-=
3750-4b9d-99e0-e9e1e3dcdb6d%40isocpp.org=20
>>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/a758ce2c=
-3750-4b9d-99e0-e9e1e3dcdb6d%40isocpp.org?utm_medium=3Demail&utm_source=3Df=
ooter>
>>>> .
>>>>
>>>> --=20
>>>> You received this message because you are subscribed to the Google=20
>>>> Groups "ISO C++ Standard - Future Proposals" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send=
=20
>>>> an email to std-proposal...@isocpp.org.
>>>> To post to this group, send email to std-pr...@isocpp.org.
>>>> To view this discussion on the web visit=20
>>>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/201607310=
04107.4898897.76636.14874%40gmail.com=20
>>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/20160731=
004107.4898897.76636.14874%40gmail.com?utm_medium=3Demail&utm_source=3Dfoot=
er>
>>>> .
>>>>
>>>
>>> --=20
>> You received this message because you are subscribed to the Google Group=
s=20
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n=20
>> email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> To view this discussion on the web visit=20
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/237863cb-35=
69-4784-b6f5-db80ac069ff6%40isocpp.org=20
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/237863cb-3=
569-4784-b6f5-db80ac069ff6%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoo=
ter>
>> .
>>
>
>
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/7d241d3c-caca-43ca-9a01-840f048dc643%40isocpp.or=
g.
------=_Part_2006_848018967.1469982042417
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><span class=3D"_username"><span data-name=3D"Patrice Roy" =
data-userid=3D"101854579704662350526" style=3D"color: rgb(34, 34, 34);" cla=
ss=3D"IVILX2C-D-a g-hovercard">Patrice Roy:<br>Sorry me. I wrote this propo=
sal in the morning and as you has shown me, not very carefully,<br>inattent=
ively. I wanted to show an idea in general.<br>Maybe I forgot drink few cup=
s of coffee =3D)<br>I will correct document with proposal more carefully an=
d more attentively.<br><br>> That said, by more precise exception types,=
the need for a stack trace is probably not as strong.<br>But if we want mo=
re general solution we need support more precise exception types like throw=
ing interger.<br><br>Could you suggest me where I can get proposal number l=
ike N3256 ?<br><br></span></span>=D0=B2=D0=BE=D1=81=D0=BA=D1=80=D0=B5=D1=81=
=D0=B5=D0=BD=D1=8C=D0=B5, 31 =D0=B8=D1=8E=D0=BB=D1=8F 2016 =D0=B3., 18:16:0=
8 UTC+3 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=
=D1=8C Patrice Roy =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:<blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px=
#ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div><div><div><div><=
div><div><div><div><div>Hi!<br><br></div>Be careful: void main() is illegal=
in C++. Passing =C2=ABvoid=C2=BB as argument, while not illegal, brings yo=
u nothing; I'd personally avoid it, but you're the boss :)<br><br><=
/div>Your proposal might carry more weight if it was more idiomatic: I'=
d envision returning unique_ptr<Socket> instead of Socket* from open_=
socket(), for example, as the example code currently leaks.<br><br></div>So=
meone's bound to point out that replacing this:<br><br><pre>throw socke=
t_error("Cannot open socket !");</pre><br></div>... by something =
like this (just an example, not a proposal :) ):<br><br></div>class socket_=
open_exception{};<br>// ...<br></div>throw socket_open_exception{};<br><br>=
</div>...would go a long way making the code better, and giving a better ha=
ndle on what failed. That said, by more precise exception types, the need f=
or a stack trace is probably not as strong.<br><br></div>If looking for sou=
rce code-related info on the source of the problem, there are macros that p=
rovide file, line and function information which can be supplied as excepti=
on construction arguments. There's also some work by Robert Douglas (my=
memory might be faulty here) that would lead compilers to provide this in =
non-macro form. That's not the same thing as a stack trace, that being =
said.<br><br></div>It would be a good idea to provide more info on what is =
expected from stack_trace_item, IMHO.<br><br></div>Cheers!<br><div><div><br=
><br><div><div><div><div><div><div><br><br></div></div></div></div></div></=
div></div></div></div><div><br><div class=3D"gmail_quote">2016-07-31 2:49 G=
MT-04:00 <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" g=
df-obfuscated-mailto=3D"k2WcvsBgBgAJ" rel=3D"nofollow" onmousedown=3D"this.=
href=3D'javascript:';return true;" onclick=3D"this.href=3D'java=
script:';return true;">redr...@gmail.com</a>></span>:<br><blockquote=
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex"><div dir=3D"ltr">I have prepared my first proposal. Ple=
ase, dont bit hard for missing details.<br>You can find it in attachment.<b=
r><br>=D0=B2=D0=BE=D1=81=D0=BA=D1=80=D0=B5=D1=81=D0=B5=D0=BD=D1=8C=D0=B5, 3=
1 =D0=B8=D1=8E=D0=BB=D1=8F 2016 =D0=B3., 5:22:21 UTC+3 =D0=BF=D0=BE=D0=BB=
=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Patrice Roy =D0=BD=
=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:<blockquote class=3D"gmail_quote" styl=
e=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex=
"><span><div dir=3D"ltr">Stating that exceptions are useless when many of u=
se use them to our benefit is a bit... harsh :) I agree with Tony that for =
some use cases, the stack trace would be nice. Please, feel free to prepare=
a proposal!<br></div></span><div><br><div class=3D"gmail_quote"><span>2016=
-07-30 20:41 GMT-04:00 Tony V E <span dir=3D"ltr"><<a rel=3D"nofollow">t=
van...@gmail.com</a>></span>:<br></span><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><=
div style=3D"background-color:rgb(255,255,255);line-height:initial" lang=3D=
"en-US"><span> =
<div style=3D"width:100%;font-size:initial;font-fa=
mily:Calibri,'Slate Pro',sans-serif,sans-serif;color:rgb(31,73,125)=
;text-align:initial;background-color:rgb(255,255,255)">Exceptions have noth=
ing to do with bugs. Exceptions are a way to handle problems caused by exte=
rnal conditions (out of memory, file not found,...), not internal condition=
s =3D=3D bugs. </div><div style=3D"width:100%;font-size:initial;font-family=
:Calibri,'Slate Pro',sans-serif,sans-serif;color:rgb(31,73,125);tex=
t-align:initial;background-color:rgb(255,255,255)"><br></div><div style=3D"=
width:100%;font-size:initial;font-family:Calibri,'Slate Pro',sans-s=
erif,sans-serif;color:rgb(31,73,125);text-align:initial;background-color:rg=
b(255,255,255)">But having a stack trace facility in the language would be =
useful.=C2=A0</div><div style=3D"width:100%;font-size:initial;font-family:C=
alibri,'Slate Pro',sans-serif,sans-serif;color:rgb(31,73,125);text-=
align:initial;background-color:rgb(255,255,255)"><br></div> =
=
<div style=3D"width:100%;font-siz=
e:initial;font-family:Calibri,'Slate Pro',sans-serif,sans-serif;col=
or:rgb(31,73,125);text-align:initial;background-color:rgb(255,255,255)"><br=
style=3D"display:initial"></div> =
=
=
<div style=3D"font-size:initial;font-family:Calibri,'Slate Pro',=
sans-serif,sans-serif;color:rgb(31,73,125);text-align:initial;background-co=
lor:rgb(255,255,255)">Sent=C2=A0from=C2=A0my=C2=A0BlackBerry=C2=A0<wbr>port=
able=C2=A0Babbage=C2=A0Device</div> =
=
</span><tabl=
e style=3D"background-color:white;border-spacing:0px" width=3D"100%"> <tbod=
y><tr><td colspan=3D"2" style=3D"font-size:initial;text-align:initial;backg=
round-color:rgb(255,255,255)"> <div style=3D"bord=
er-style:solid none none;border-top-color:rgb(181,196,223);border-top-width=
:1pt;padding:3pt 0in 0in;font-family:Tahoma,'BB Alpha Sans','Sl=
ate Pro';font-size:10pt"> <div><b>From: </b><a rel=3D"nofollow">redr..=
..@gmail.com</a></div><span><div><b>Sent: </b>Saturday, July 30, 2016 8:14 P=
M</div><div><b>To: </b>ISO C++ Standard - Future Proposals</div></span><div=
><b>Reply To: </b><a rel=3D"nofollow">std-pr...@isocpp.org</a></div><span><=
div><b>Subject: </b>[std-proposals] Exception stack trace information.</div=
></span></div></td></tr></tbody></table><div><div><div style=3D"border-styl=
e:solid none none;border-top-color:rgb(186,188,209);border-top-width:1pt;fo=
nt-size:initial;text-align:initial;background-color:rgb(255,255,255)"></div=
><br><div><span><div dir=3D"ltr">In <b>C++17</b> will be added a lot of new=
features, but no of them features improve quality of code and quickly fixi=
ng of the code.<br>If in program exist a bug then the best that program can=
do is crash. Exception is a good conception for error handling, but is use=
less in C++ implementation, 'cause we do not know where the problem hap=
pens. That mean catching of exception is useless, because additional inform=
ation is so small that better allow program simple crash.<br>This is the ma=
in reason that even in debug mode exception is used not often.<br><br><b>PR=
OBLEM </b>is no standard on it about providing to user <b>backtrace</b>.<br=
>Operation system can get stack trace when exception was used. We can imple=
ment getting stack trace even in dummy implementation by adding to every fu=
nction in compile time meta information with name of this function and code=
that will put this name in stack object that implicitly exists from starti=
ng the program. We can add scpecial flag <b>BACK_TRACE</b> or <b>BTRACE</b>=
..<br><br>Sorry for straightforward speech but I tired. In we can implement =
<b>backtrace</b>, but are thinking about coroutine. Without strong <b>base =
</b>we cannot implement something good.<br><br><b>Thanks,<br>Best regards.<=
br><br></b></div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br></span>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</a>.<span><br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a758ce2c-3750-4b9d-99e0-e9e1e3dcdb6d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" rel=3D"nofollow" t=
arget=3D"_blank" onmousedown=3D"this.href=3D'https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/a758ce2c-3750-4b9d-99e0-e9e1e3dcdb6d%40i=
socpp.org?utm_medium\x3demail\x26utm_source\x3dfooter';return true;" on=
click=3D"this.href=3D'https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/a758ce2c-3750-4b9d-99e0-e9e1e3dcdb6d%40isocpp.org?utm_medium\x3=
demail\x26utm_source\x3dfooter';return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/a758ce2c-3750-4b9d-<wbr>99e0-=
e9e1e3dcdb6d%40isocpp.org</a><wbr>.<br>
<br></span></div></div></div></div><div><div><span>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br></span>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</a>.<br></div></div><span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/20160731004107.4898897.76636.14874%40=
gmail.com?utm_medium=3Demail&utm_source=3Dfooter" rel=3D"nofollow" targ=
et=3D"_blank" onmousedown=3D"this.href=3D'https://groups.google.com/a/i=
socpp.org/d/msgid/std-proposals/20160731004107.4898897.76636.14874%40gmail.=
com?utm_medium\x3demail\x26utm_source\x3dfooter';return true;" onclick=
=3D"this.href=3D'https://groups.google.com/a/isocpp.org/d/msgid/std-pro=
posals/20160731004107.4898897.76636.14874%40gmail.com?utm_medium\x3demail\x=
26utm_source\x3dfooter';return true;">https://groups.google.com/a/<wbr>=
isocpp.org/d/msgid/std-<wbr>proposals/20160731004107.<wbr>4898897.76636.148=
74%40gmail.<wbr>com</a>.<br>
</span></blockquote></div><br></div>
</blockquote></div><span>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
k2WcvsBgBgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:&=
#39;;return true;" onclick=3D"this.href=3D'javascript:';return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"k2WcvsBgBgAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'=
;javascript:';return true;">std-pr...@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/237863cb-3569-4784-b6f5-db80ac069ff6%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank" =
rel=3D"nofollow" onmousedown=3D"this.href=3D'https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/237863cb-3569-4784-b6f5-db80ac069ff6%40i=
socpp.org?utm_medium\x3demail\x26utm_source\x3dfooter';return true;" on=
click=3D"this.href=3D'https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/237863cb-3569-4784-b6f5-db80ac069ff6%40isocpp.org?utm_medium\x3=
demail\x26utm_source\x3dfooter';return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/237863cb-3569-4784-<wbr>b6f5-=
db80ac069ff6%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></div>
</blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/7d241d3c-caca-43ca-9a01-840f048dc643%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7d241d3c-caca-43ca-9a01-840f048dc643=
%40isocpp.org</a>.<br />
------=_Part_2006_848018967.1469982042417--
------=_Part_2005_2008805983.1469982042417--
.
Author: =?UTF-8?B?0JTQtdC90LjRgSDQmtC+0YLQvtCy?= <redradist@gmail.com>
Date: Sun, 31 Jul 2016 09:38:25 -0700 (PDT)
Raw View
------=_Part_34_1070943946.1469983105879
Content-Type: multipart/alternative;
boundary="----=_Part_35_2007778957.1469983105883"
------=_Part_35_2007778957.1469983105883
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=D0=B2=D0=BE=D1=81=D0=BA=D1=80=D0=B5=D1=81=D0=B5=D0=BD=D1=8C=D0=B5, 31 =D0=
=B8=D1=8E=D0=BB=D1=8F 2016 =D0=B3., 19:09:51 UTC+3 =D0=BF=D0=BE=D0=BB=D1=8C=
=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Thiago Macieira=20
=D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:
> On domingo, 31 de julho de 2016 02:57:35 PDT =D0=94=D0=B5=D0=BD=D0=B8=D1=
=81 =D0=9A=D0=BE=D1=82=D0=BE=D0=B2 wrote:
> > > You misunderstand what exceptions are for. You're not supposed to=20
catch
> >
> > them
> >
> > > to find out where the error occurred. You catch them so you handle th=
e
> > > condition wherever it happened, then continue execution because you'v=
e
> > > corrected the problem.
>> >
> > > I think this is incorrect.
> > > How can I correct the problem or bug if I do not know where the=20
problem
> > > happened.
> There was no bug. Exceptions are not used to signal bugs. They are used t=
o
> signal perfectly fine, if exceptional, conditions. A file not being found=
=20
is not
> a bug.
I said problem or bug. If somebody try get element using *arr.at(1000)* it=
=20
will throw exception.
*Is it bug or problem ?*
If we want to show user that something goes wrong we throw exception *(for=
=20
example file not found as you wrote)* we need show user where it happened.
> If there's a bug, you can't guarantee that the exception will be thrown
> properly nor that it will be caught, much less that anything it contains=
=20
will
> be correct. That's because after the first bug, all bets are off.
> > It is impossible or I need put *try ... catch* statement in every place=
=20
of
> > my program. But it is wasting of time. Better when exception has all=20
needed
> > information for analyzing where it happened.
> You put it around any place that can throw and that your founction isn't
> expected to throw that exception.
*Unfortunately big programs writes by many people and people make mistakes.=
*=20
Every time somebody forgets put *try ... catch* and then happens weird=20
things. You try finding problem place 2h, 4h, 1day or more ... depends how=
=20
big project is.
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/6b654960-9ba3-4d49-b03a-d41b0992df64%40isocpp.or=
g.
------=_Part_35_2007778957.1469983105883
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">=D0=B2=D0=BE=D1=81=D0=BA=D1=80=D0=B5=D1=81=D0=B5=D0=BD=D1=
=8C=D0=B5, 31 =D0=B8=D1=8E=D0=BB=D1=8F 2016 =D0=B3., 19:09:51 UTC+3 =D0=BF=
=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Thiago M=
acieira =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:<br>> On domingo, 31 =
de julho de 2016 02:57:35 PDT =D0=94=D0=B5=D0=BD=D0=B8=D1=81 =D0=9A=D0=BE=
=D1=82=D0=BE=D0=B2 wrote:<br>> > > You misunderstand what exceptio=
ns are for. You're not supposed to catch<br>> ><br>> > them=
<br>> ><br>> > > to find out where the error occurred. You c=
atch them so you handle the<br>> > > condition wherever it happene=
d, then continue execution because you've<br>> > > corrected t=
he problem.<br>>> ><br>> > > I think this is incorrect.<b=
r>> > > How can I correct the problem or bug if I do not know wher=
e the problem<br>> > > happened.<br><br>> There was no bug. Exc=
eptions are not used to signal bugs. They are used to<br>> signal perfec=
tly fine, if exceptional, conditions. A file not being found is not<br>>=
a bug.<br><br>I said problem or bug. If somebody try get element using <b>=
arr.at(1000)</b> it will throw exception.<br><b>Is it bug or problem ?</b><=
br>If we want to show user that something goes wrong we throw exception <b>=
(for example file not found as you wrote)</b> we need show user where it ha=
ppened.<br><br>> If there's a bug, you can't guarantee that the =
exception will be thrown<br>> properly nor that it will be caught, much =
less that anything it contains will<br>> be correct. That's because =
after the first bug, all bets are off.<br><br>> > It is impossible or=
I need put *try ... catch* statement in every place of<br>> > my pro=
gram. But it is wasting of time. Better when exception has all needed<br>&g=
t; > information for analyzing where it happened.<br><br>> You put it=
around any place that can throw and that your founction isn't<br>> =
expected to throw that exception.<br><br><b>Unfortunately big programs writ=
es by many people and people make mistakes.</b> Every time somebody forgets=
put <b>try ... catch</b> and then happens weird things. You try finding pr=
oblem place 2h, 4h, 1day or more ... depends how big project is.<br><br></d=
iv>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/6b654960-9ba3-4d49-b03a-d41b0992df64%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/6b654960-9ba3-4d49-b03a-d41b0992df64=
%40isocpp.org</a>.<br />
------=_Part_35_2007778957.1469983105883--
------=_Part_34_1070943946.1469983105879--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sun, 31 Jul 2016 10:23:21 -0700 (PDT)
Raw View
------=_Part_716_49410767.1469985801368
Content-Type: multipart/alternative;
boundary="----=_Part_717_544260755.1469985801368"
------=_Part_717_544260755.1469985801368
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Sunday, July 31, 2016 at 12:38:26 PM UTC-4, =D0=94=D0=B5=D0=BD=D0=B8=D1=
=81 =D0=9A=D0=BE=D1=82=D0=BE=D0=B2 wrote:
>
> =D0=B2=D0=BE=D1=81=D0=BA=D1=80=D0=B5=D1=81=D0=B5=D0=BD=D1=8C=D0=B5, 31 =
=D0=B8=D1=8E=D0=BB=D1=8F 2016 =D0=B3., 19:09:51 UTC+3 =D0=BF=D0=BE=D0=BB=D1=
=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Thiago Macieira=20
> =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:
> > On domingo, 31 de julho de 2016 02:57:35 PDT =D0=94=D0=B5=D0=BD=D0=B8=
=D1=81 =D0=9A=D0=BE=D1=82=D0=BE=D0=B2 wrote:
> > > > You misunderstand what exceptions are for. You're not supposed to=
=20
> catch
> > >
> > > them
> > >
> > > > to find out where the error occurred. You catch them so you handle=
=20
> the
> > > > condition wherever it happened, then continue execution because=20
> you've
> > > > corrected the problem.
> >> >
> > > > I think this is incorrect.
> > > > How can I correct the problem or bug if I do not know where the=20
> problem
> > > > happened.
>
> > There was no bug. Exceptions are not used to signal bugs. They are used=
=20
> to
> > signal perfectly fine, if exceptional, conditions. A file not being=20
> found is not
> > a bug.
>
> I said problem or bug. If somebody try get element using *arr.at=20
> <http://arr.at>(1000)* it will throw exception.
> *Is it bug or problem ?*
> If we want to show user that something goes wrong we throw exception *(fo=
r=20
> example file not found as you wrote)* we need show user where it happened=
..
>
If I'm *using* a GUI application, I don't know or *care* what function=20
caused a "file not found as you wrote" exception. I don't want a stack=20
trace; it would be of utterly *no value* to me. I don't have the code; I=20
don't know what those functions mean. What I care about is whether the=20
application can handle that circumstance or not.
Crashing because of a missing file may be reasonable for some applications.=
=20
In those cases, a stack trace would still not be helpful. Simply stopping,=
=20
perhaps with an error message, is sufficient.
Stack traces are only of value to *programmers*, and generally, only to the=
=20
programmers who wrote the system in question. So what you show to "the=20
user" is irrelevant.
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/b5374163-7850-412e-b319-646e2a2a471e%40isocpp.or=
g.
------=_Part_717_544260755.1469985801368
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Sunday, July 31, 2016 at 12:38:26 PM UTC-4, =D0=94=D0=
=B5=D0=BD=D0=B8=D1=81 =D0=9A=D0=BE=D1=82=D0=BE=D0=B2 wrote:<blockquote clas=
s=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #c=
cc solid;padding-left: 1ex;"><div dir=3D"ltr">=D0=B2=D0=BE=D1=81=D0=BA=D1=
=80=D0=B5=D1=81=D0=B5=D0=BD=D1=8C=D0=B5, 31 =D0=B8=D1=8E=D0=BB=D1=8F 2016 =
=D0=B3., 19:09:51 UTC+3 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=
=82=D0=B5=D0=BB=D1=8C Thiago Macieira =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=
=D0=BB:<br>> On domingo, 31 de julho de 2016 02:57:35 PDT =D0=94=D0=B5=
=D0=BD=D0=B8=D1=81 =D0=9A=D0=BE=D1=82=D0=BE=D0=B2 wrote:<br>> > > =
You misunderstand what exceptions are for. You're not supposed to catch=
<br>> ><br>> > them<br>> ><br>> > > to find out =
where the error occurred. You catch them so you handle the<br>> > >=
; condition wherever it happened, then continue execution because you'v=
e<br>> > > corrected the problem.<br>>> ><br>> > &g=
t; I think this is incorrect.<br>> > > How can I correct the probl=
em or bug if I do not know where the problem<br>> > > happened.<br=
><br>> There was no bug. Exceptions are not used to signal bugs. They ar=
e used to<br>> signal perfectly fine, if exceptional, conditions. A file=
not being found is not<br>> a bug.<br><br>I said problem or bug. If som=
ebody try get element using <b><a href=3D"http://arr.at" target=3D"_blank" =
rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google.com/url?=
q\x3dhttp%3A%2F%2Farr.at\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFxLPUpJfWQ=
vLx7capIm4lnJf7xtw';return true;" onclick=3D"this.href=3D'http://ww=
w.google.com/url?q\x3dhttp%3A%2F%2Farr.at\x26sa\x3dD\x26sntz\x3d1\x26usg\x3=
dAFQjCNFxLPUpJfWQvLx7capIm4lnJf7xtw';return true;">arr.at</a>(1000)</b>=
it will throw exception.<br><b>Is it bug or problem ?</b><br>If we want to=
show user that something goes wrong we throw exception <b>(for example fil=
e not found as you wrote)</b> we need show user where it happened.<br></div=
></blockquote><div dir=3D"ltr"><br>If I'm <i>using</i> a GUI applicatio=
n, I don't know or <i>care</i> what function caused a "file not fo=
und as you wrote" exception. I don't want a stack trace; it would =
be of utterly <i>no value</i> to me. I don't have the code; I don't=
know what those functions mean. What I care about is whether the applicati=
on can handle that circumstance or not.<br><br>Crashing because of a missin=
g file may be reasonable for some applications. In those cases, a stack tra=
ce would still not be helpful. Simply stopping, perhaps with an error messa=
ge, is sufficient.<br><br>Stack traces are only of value to <i>programmers<=
/i>, and generally, only to the programmers who wrote the system in questio=
n. So what you show to "the user" is irrelevant.<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/b5374163-7850-412e-b319-646e2a2a471e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b5374163-7850-412e-b319-646e2a2a471e=
%40isocpp.org</a>.<br />
------=_Part_717_544260755.1469985801368--
------=_Part_716_49410767.1469985801368--
.
Author: =?UTF-8?B?0JTQtdC90LjRgSDQmtC+0YLQvtCy?= <redradist@gmail.com>
Date: Sun, 31 Jul 2016 10:35:42 -0700 (PDT)
Raw View
------=_Part_48_523716334.1469986542879
Content-Type: multipart/alternative;
boundary="----=_Part_49_789798592.1469986542880"
------=_Part_49_789798592.1469986542880
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=D0=B2=D0=BE=D1=81=D0=BA=D1=80=D0=B5=D1=81=D0=B5=D0=BD=D1=8C=D0=B5, 31 =D0=
=B8=D1=8E=D0=BB=D1=8F 2016 =D0=B3., 20:23:21 UTC+3 =D0=BF=D0=BE=D0=BB=D1=8C=
=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Nicol Bolas=20
=D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:
>
> On Sunday, July 31, 2016 at 12:38:26 PM UTC-4, =D0=94=D0=B5=D0=BD=D0=B8=
=D1=81 =D0=9A=D0=BE=D1=82=D0=BE=D0=B2 wrote:
>>
>> =D0=B2=D0=BE=D1=81=D0=BA=D1=80=D0=B5=D1=81=D0=B5=D0=BD=D1=8C=D0=B5, 31 =
=D0=B8=D1=8E=D0=BB=D1=8F 2016 =D0=B3., 19:09:51 UTC+3 =D0=BF=D0=BE=D0=BB=D1=
=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Thiago Macieira=20
>> =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:
>> > On domingo, 31 de julho de 2016 02:57:35 PDT =D0=94=D0=B5=D0=BD=D0=B8=
=D1=81 =D0=9A=D0=BE=D1=82=D0=BE=D0=B2 wrote:
>> > > > You misunderstand what exceptions are for. You're not supposed to=
=20
>> catch
>> > >
>> > > them
>> > >
>> > > > to find out where the error occurred. You catch them so you handle=
=20
>> the
>> > > > condition wherever it happened, then continue execution because=20
>> you've
>> > > > corrected the problem.
>> >> >
>> > > > I think this is incorrect.
>> > > > How can I correct the problem or bug if I do not know where the=20
>> problem
>> > > > happened.
>>
>> > There was no bug. Exceptions are not used to signal bugs. They are use=
d=20
>> to
>> > signal perfectly fine, if exceptional, conditions. A file not being=20
>> found is not
>> > a bug.
>>
>> I said problem or bug. If somebody try get element using *arr.at=20
>> <http://arr.at>(1000)* it will throw exception.
>> *Is it bug or problem ?*
>> If we want to show user that something goes wrong we throw exception *(f=
or=20
>> example file not found as you wrote)* we need show user where it=20
>> happened.
>>
>
> If I'm *using* a GUI application, I don't know or *care* what function=20
> caused a "file not found as you wrote" exception. I don't want a stack=20
> trace; it would be of utterly *no value* to me. I don't have the code; I=
=20
> don't know what those functions mean. What I care about is whether the=20
> application can handle that circumstance or not.
>
> Crashing because of a missing file may be reasonable for some=20
> applications. In those cases, a stack trace would still not be helpful.=
=20
> Simply stopping, perhaps with an error message, is sufficient.
>
> Stack traces are only of value to *programmers*, and generally, only to=
=20
> the programmers who wrote the system in question. So what you show to "th=
e=20
> user" is irrelevant.
>
=20
> If I'm *using* a GUI application, I don't know or *care* what function=20
caused a "file not found as you wrote" exception. I don't want a stack=20
trace; it would be of utterly *> no value* to me. I don't have the code; I=
=20
don't know what those functions mean. What I care about is whether the=20
application can handle that circumstance or not.
It is not needed for you, but do not say in general that this is useless.=
=20
If C++ has exceptions we should make them more frendly for users.
In Embedded programming this is very helpful feature *(stack trace)*.=20
Modern Programming Languages have had already it (Java, C#, Python and so=
=20
on).
Guys has already mentioned that *stack trace* will be usefull, but only you=
=20
do not like this idea, because you do not use it.
*How can you know whether it usefull or not if you have never use this=20
feature in C++ ?*
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/cdf9532d-8f9e-404b-b389-e73190b286d7%40isocpp.or=
g.
------=_Part_49_789798592.1469986542880
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">=D0=B2=D0=BE=D1=81=D0=BA=D1=80=D0=B5=D1=81=D0=B5=D0=BD=D1=
=8C=D0=B5, 31 =D0=B8=D1=8E=D0=BB=D1=8F 2016 =D0=B3., 20:23:21 UTC+3 =D0=BF=
=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Nicol Bo=
las =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:<blockquote class=3D"gmail_q=
uote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pad=
ding-left: 1ex;"><div dir=3D"ltr">On Sunday, July 31, 2016 at 12:38:26 PM U=
TC-4, =D0=94=D0=B5=D0=BD=D0=B8=D1=81 =D0=9A=D0=BE=D1=82=D0=BE=D0=B2 wrote:<=
blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border=
-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=D0=B2=D0=BE=D1=81=
=D0=BA=D1=80=D0=B5=D1=81=D0=B5=D0=BD=D1=8C=D0=B5, 31 =D0=B8=D1=8E=D0=BB=D1=
=8F 2016 =D0=B3., 19:09:51 UTC+3 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=
=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Thiago Macieira =D0=BD=D0=B0=D0=BF=D0=B8=D1=
=81=D0=B0=D0=BB:<br>> On domingo, 31 de julho de 2016 02:57:35 PDT =D0=
=94=D0=B5=D0=BD=D0=B8=D1=81 =D0=9A=D0=BE=D1=82=D0=BE=D0=B2 wrote:<br>> &=
gt; > You misunderstand what exceptions are for. You're not supposed=
to catch<br>> ><br>> > them<br>> ><br>> > > to =
find out where the error occurred. You catch them so you handle the<br>>=
> > condition wherever it happened, then continue execution because =
you've<br>> > > corrected the problem.<br>>> ><br>>=
; > > I think this is incorrect.<br>> > > How can I correct =
the problem or bug if I do not know where the problem<br>> > > hap=
pened.<br><br>> There was no bug. Exceptions are not used to signal bugs=
.. They are used to<br>> signal perfectly fine, if exceptional, condition=
s. A file not being found is not<br>> a bug.<br><br>I said problem or bu=
g. If somebody try get element using <b><a href=3D"http://arr.at" rel=3D"no=
follow" target=3D"_blank" onmousedown=3D"this.href=3D'http://www.google=
..com/url?q\x3dhttp%3A%2F%2Farr.at\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNF=
xLPUpJfWQvLx7capIm4lnJf7xtw';return true;" onclick=3D"this.href=3D'=
http://www.google.com/url?q\x3dhttp%3A%2F%2Farr.at\x26sa\x3dD\x26sntz\x3d1\=
x26usg\x3dAFQjCNFxLPUpJfWQvLx7capIm4lnJf7xtw';return true;">arr.at</a>(=
1000)</b> it will throw exception.<br><b>Is it bug or problem ?</b><br>If w=
e want to show user that something goes wrong we throw exception <b>(for ex=
ample file not found as you wrote)</b> we need show user where it happened.=
<br></div></blockquote><div dir=3D"ltr"><br>If I'm <i>using</i> a GUI a=
pplication, I don't know or <i>care</i> what function caused a "fi=
le not found as you wrote" exception. I don't want a stack trace; =
it would be of utterly <i>no value</i> to me. I don't have the code; I =
don't know what those functions mean. What I care about is whether the =
application can handle that circumstance or not.<br><br>Crashing because of=
a missing file may be reasonable for some applications. In those cases, a =
stack trace would still not be helpful. Simply stopping, perhaps with an er=
ror message, is sufficient.<br><br>Stack traces are only of value to <i>pro=
grammers</i>, and generally, only to the programmers who wrote the system i=
n question. So what you show to "the user" is irrelevant.<br></di=
v></div></blockquote><div>=C2=A0</div><div>> If I'm <i>using</i> a G=
UI application, I don't know or <i>care</i> what function caused a &quo=
t;file not found as you wrote" exception. I don't want a stack tra=
ce; it would be of utterly <i>> no value</i>
to me. I don't have the code; I don't know what those functions me=
an.=20
What I care about is whether the application can handle that=20
circumstance or not.<br><br>It is not needed for you, but do not say in gen=
eral that this is useless. If C++ has exceptions we should make them more f=
rendly for users.<br>In Embedded programming this is very helpful feature <=
b>(stack trace)</b>. Modern Programming Languages have had already it (Jav=
a, C#, Python and so on).<br>Guys has already mentioned that <b>stack trace=
</b> will be usefull, but only you do not like this idea, because you do no=
t use it.<br><b>How can you know whether it usefull or not if you have neve=
r use this feature in C++ ?</b><br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/cdf9532d-8f9e-404b-b389-e73190b286d7%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/cdf9532d-8f9e-404b-b389-e73190b286d7=
%40isocpp.org</a>.<br />
------=_Part_49_789798592.1469986542880--
------=_Part_48_523716334.1469986542879--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Sun, 31 Jul 2016 11:39:54 -0700
Raw View
On domingo, 31 de julho de 2016 09:38:25 PDT =D0=94=D0=B5=D0=BD=D0=B8=D1=81=
=D0=9A=D0=BE=D1=82=D0=BE=D0=B2 wrote:
> I said problem or bug. If somebody try get element using *arr.at(1000)* i=
t
> will throw exception.
> *Is it bug or problem ?*
> If we want to show user that something goes wrong we throw exception *(fo=
r
> example file not found as you wrote)* we need show user where it happened=
..
First of all, like Nicol replied, "showing to the user" is often an incorre=
ct=20
step to do. The application should not display its problems to the user. If=
=20
they are unrecoverable, log it somewhere for the user to pass the informati=
on=20
along to the developer, then simply report to the user that the unrecoverab=
le=20
error happened. If the error was recoverable, recover.
The whole point of catching exceptions is to *recover*. If at(1000) throws =
an=20
exception and that exception is caught, then the problem was recovered and =
you=20
don't need to know (much less display) where the exception was thrown from.
If the exception wasn't caught, then it was an unrecoverable error. In that=
=20
case, the uncaught exception handler is called and the program terminates.=
=20
Often, ABI-specific information is still available at this point to help=20
diagnose the issue, including the stack trace. But, as I said, stacks and=
=20
frames are concepts that exist only in the ABI, so the standard simply can'=
t=20
say anything about them.
> > You put it around any place that can throw and that your founction isn'=
t
> > expected to throw that exception.
>=20
> *Unfortunately big programs writes by many people and people make mistake=
s.*
> Every time somebody forgets put *try ... catch* and then happens weird
> things. You try finding problem place 2h, 4h, 1day or more ... depends ho=
w
> big project is.
I understand, but the point is remains: if a bug occurred, then you've step=
ped=20
outside the realm of the standard. The standard can't say what happens outs=
ide=20
of the standard.
Like I said above, though, most ABIs can log more ABI-dependent information=
in=20
the event of an uncaught exception. Yes, that often requires debug mode bui=
lds=20
and debugging symbols to be present.
Assuming that you've been using those facilities provided by your toolchain=
, I=20
have to ask: why do you want to standardise them? Why can't you continue to=
=20
use the ABI-dependent ones?
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/7324487.f2akqxC18G%40tjmaciei-mobl1.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Sun, 31 Jul 2016 11:43:49 -0700
Raw View
On domingo, 31 de julho de 2016 10:35:42 PDT =D0=94=D0=B5=D0=BD=D0=B8=D1=81=
=D0=9A=D0=BE=D1=82=D0=BE=D0=B2 wrote:
> It is not needed for you, but do not say in general that this is useless.=
=20
> If C++ has exceptions we should make them more frendly for users.
No, we shouldn't. Users don't care how your program is structured. Users do=
n't=20
care if the failure happened by way of an exception or an assertion or errn=
o=20
being set to a value.
Displaying technical information to the user, unprompted, is often bad UX. =
You=20
shouldn't do it. It is useful to record it, though, so that the information=
=20
can be passed along to the developer (maybe the developer is the user).=20
Moreover, you want to log other states that are completely outside of the=
=20
standard too, like which shared libraries are loaded, what addresses they w=
ere=20
loaded at, which other threads were running and what their stack traces are=
,=20
even what the value of processor registers were at the time of the crash.
In summary: information is useful, but don't overwhelm the user. And the=20
information the developer wants is more than just an exception throw locati=
on.
> In Embedded programming this is very helpful feature *(stack trace)*.=20
> Modern Programming Languages have had already it (Java, C#, Python and so=
=20
> on).
> Guys has already mentioned that *stack trace* will be usefull, but only y=
ou=20
> do not like this idea, because you do not use it.
> *How can you know whether it usefull or not if you have never use this=20
> feature in C++ ?*
Funny, I thought I was using it for 15 years.
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/66865062.Esra4tjKrk%40tjmaciei-mobl1.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sun, 31 Jul 2016 11:49:39 -0700 (PDT)
Raw View
------=_Part_667_1228858478.1469990980046
Content-Type: multipart/alternative;
boundary="----=_Part_668_1919857766.1469990980047"
------=_Part_668_1919857766.1469990980047
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Sunday, July 31, 2016 at 1:35:43 PM UTC-4, =D0=94=D0=B5=D0=BD=D0=B8=D1=
=81 =D0=9A=D0=BE=D1=82=D0=BE=D0=B2 wrote:
>
> =D0=B2=D0=BE=D1=81=D0=BA=D1=80=D0=B5=D1=81=D0=B5=D0=BD=D1=8C=D0=B5, 31 =
=D0=B8=D1=8E=D0=BB=D1=8F 2016 =D0=B3., 20:23:21 UTC+3 =D0=BF=D0=BE=D0=BB=D1=
=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Nicol Bolas=20
> =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:
>>
>> On Sunday, July 31, 2016 at 12:38:26 PM UTC-4, =D0=94=D0=B5=D0=BD=D0=B8=
=D1=81 =D0=9A=D0=BE=D1=82=D0=BE=D0=B2 wrote:
>>>
>>> =D0=B2=D0=BE=D1=81=D0=BA=D1=80=D0=B5=D1=81=D0=B5=D0=BD=D1=8C=D0=B5, 31 =
=D0=B8=D1=8E=D0=BB=D1=8F 2016 =D0=B3., 19:09:51 UTC+3 =D0=BF=D0=BE=D0=BB=D1=
=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Thiago=20
>>> Macieira =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:
>>> > On domingo, 31 de julho de 2016 02:57:35 PDT =D0=94=D0=B5=D0=BD=D0=B8=
=D1=81 =D0=9A=D0=BE=D1=82=D0=BE=D0=B2 wrote:
>>> > > > You misunderstand what exceptions are for. You're not supposed to=
=20
>>> catch
>>> > >
>>> > > them
>>> > >
>>> > > > to find out where the error occurred. You catch them so you handl=
e=20
>>> the
>>> > > > condition wherever it happened, then continue execution because=
=20
>>> you've
>>> > > > corrected the problem.
>>> >> >
>>> > > > I think this is incorrect.
>>> > > > How can I correct the problem or bug if I do not know where the=
=20
>>> problem
>>> > > > happened.
>>>
>>> > There was no bug. Exceptions are not used to signal bugs. They are=20
>>> used to
>>> > signal perfectly fine, if exceptional, conditions. A file not being=
=20
>>> found is not
>>> > a bug.
>>>
>>> I said problem or bug. If somebody try get element using *arr.at=20
>>> <http://arr.at>(1000)* it will throw exception.
>>> *Is it bug or problem ?*
>>> If we want to show user that something goes wrong we throw exception *(=
for=20
>>> example file not found as you wrote)* we need show user where it=20
>>> happened.
>>>
>>
>> If I'm *using* a GUI application, I don't know or *care* what function=
=20
>> caused a "file not found as you wrote" exception. I don't want a stack=
=20
>> trace; it would be of utterly *no value* to me. I don't have the code; I=
=20
>> don't know what those functions mean. What I care about is whether the=
=20
>> application can handle that circumstance or not.
>>
>> Crashing because of a missing file may be reasonable for some=20
>> applications. In those cases, a stack trace would still not be helpful.=
=20
>> Simply stopping, perhaps with an error message, is sufficient.
>>
>> Stack traces are only of value to *programmers*, and generally, only to=
=20
>> the programmers who wrote the system in question. So what you show to "t=
he=20
>> user" is irrelevant.
>>
> =20
> > If I'm *using* a GUI application, I don't know or *care* what function=
=20
> caused a "file not found as you wrote" exception. I don't want a stack=20
> trace; it would be of utterly *> no value* to me. I don't have the code;=
=20
> I don't know what those functions mean. What I care about is whether the=
=20
> application can handle that circumstance or not.
>
> It is not needed for you, but do not say in general that this is useless.=
=20
> If C++ has exceptions we should make them more frendly for users.
>
If an application is displaying a stack trace spew to the user, that=20
application is not "frendly[sic] for users" at all.
In Embedded programming this is very helpful feature *(stack trace)*.
>
What kind of embedded programming have you been doing where you can=20
generate a stack trace that contains anything more than addresses? I=20
assumed most embedded environments didn't have the memory to waste on=20
loading string data for function/type names and so forth.
Modern Programming Languages have had already it (Java, C#, Python and so=
=20
> on).
>
They also have garbage collection. What's your point?
Guys has already mentioned that *stack trace* will be usefull,
>
Yes, stack traces are useful. That doesn't mean that:
1. We should standardize them in some way.
2. Every exception should bear the weight of a stack trace.
Even if you believe in #1, it's a lot harder to justify #2.
but only you do not like this idea, because you do not use it.
> *How can you know whether it usefull or not if you have never use this=20
> feature in C++ ?*
>
I've never tried guaranteed elision, fold expressions, `if constexpr` or=20
most other features of C++17 either. But that doesn't mean I can't tell if=
=20
they'd be useful.=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/9bc4756b-8648-40ec-b726-4fee25acc998%40isocpp.or=
g.
------=_Part_668_1919857766.1469990980047
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Sunday, July 31, 2016 at 1:35:43 PM UTC-4, =D0=94=D0=B5=
=D0=BD=D0=B8=D1=81 =D0=9A=D0=BE=D1=82=D0=BE=D0=B2 wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"ltr">=D0=B2=D0=BE=D1=81=D0=BA=D1=80=
=D0=B5=D1=81=D0=B5=D0=BD=D1=8C=D0=B5, 31 =D0=B8=D1=8E=D0=BB=D1=8F 2016 =D0=
=B3., 20:23:21 UTC+3 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=
=D0=B5=D0=BB=D1=8C Nicol Bolas =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:<=
blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border=
-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Sunday, July 31,=
2016 at 12:38:26 PM UTC-4, =D0=94=D0=B5=D0=BD=D0=B8=D1=81 =D0=9A=D0=BE=D1=
=82=D0=BE=D0=B2 wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;m=
argin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"l=
tr">=D0=B2=D0=BE=D1=81=D0=BA=D1=80=D0=B5=D1=81=D0=B5=D0=BD=D1=8C=D0=B5, 31 =
=D0=B8=D1=8E=D0=BB=D1=8F 2016 =D0=B3., 19:09:51 UTC+3 =D0=BF=D0=BE=D0=BB=D1=
=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Thiago Macieira =D0=BD=
=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:<br>> On domingo, 31 de julho de 20=
16 02:57:35 PDT =D0=94=D0=B5=D0=BD=D0=B8=D1=81 =D0=9A=D0=BE=D1=82=D0=BE=D0=
=B2 wrote:<br>> > > You misunderstand what exceptions are for. You=
're not supposed to catch<br>> ><br>> > them<br>> ><b=
r>> > > to find out where the error occurred. You catch them so yo=
u handle the<br>> > > condition wherever it happened, then continu=
e execution because you've<br>> > > corrected the problem.<br>=
>> ><br>> > > I think this is incorrect.<br>> > >=
; How can I correct the problem or bug if I do not know where the problem<b=
r>> > > happened.<br><br>> There was no bug. Exceptions are not=
used to signal bugs. They are used to<br>> signal perfectly fine, if ex=
ceptional, conditions. A file not being found is not<br>> a bug.<br><br>=
I said problem or bug. If somebody try get element using <b><a href=3D"http=
://arr.at" rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=3D&#=
39;http://www.google.com/url?q\x3dhttp%3A%2F%2Farr.at\x26sa\x3dD\x26sntz\x3=
d1\x26usg\x3dAFQjCNFxLPUpJfWQvLx7capIm4lnJf7xtw';return true;" onclick=
=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Farr.at\x26=
sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFxLPUpJfWQvLx7capIm4lnJf7xtw';retu=
rn true;">arr.at</a>(1000)</b> it will throw exception.<br><b>Is it bug or =
problem ?</b><br>If we want to show user that something goes wrong we throw=
exception <b>(for example file not found as you wrote)</b> we need show us=
er where it happened.<br></div></blockquote><div dir=3D"ltr"><br>If I'm=
<i>using</i> a GUI application, I don't know or <i>care</i> what funct=
ion caused a "file not found as you wrote" exception. I don't=
want a stack trace; it would be of utterly <i>no value</i> to me. I don=
9;t have the code; I don't know what those functions mean. What I care =
about is whether the application can handle that circumstance or not.<br><b=
r>Crashing because of a missing file may be reasonable for some application=
s. In those cases, a stack trace would still not be helpful. Simply stoppin=
g, perhaps with an error message, is sufficient.<br><br>Stack traces are on=
ly of value to <i>programmers</i>, and generally, only to the programmers w=
ho wrote the system in question. So what you show to "the user" i=
s irrelevant.<br></div></div></blockquote><div>=C2=A0</div><div>> If I&#=
39;m <i>using</i> a GUI application, I don't know or <i>care</i> what f=
unction caused a "file not found as you wrote" exception. I don&#=
39;t want a stack trace; it would be of utterly <i>> no value</i>
to me. I don't have the code; I don't know what those functions me=
an.=20
What I care about is whether the application can handle that=20
circumstance or not.<br><br>It is not needed for you, but do not say in gen=
eral that this is useless. If C++ has exceptions we should make them more f=
rendly for users.<br></div></div></blockquote><div><br>If an application is=
displaying a stack trace spew to the user, that application is not "f=
rendly[sic] for users" at all.<br><br></div><blockquote class=3D"gmail=
_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;p=
adding-left: 1ex;"><div dir=3D"ltr"><div>In Embedded programming this is ve=
ry helpful feature <b>(stack trace)</b>.</div></div></blockquote><div><br>W=
hat kind of embedded programming have you been doing where you can generate=
a stack trace that contains anything more than addresses? I assumed most e=
mbedded environments didn't have the memory to waste on loading string =
data for function/type names and so forth.<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 dir=3D"ltr"><div>Modern Programming Langua=
ges have had already it (Java, C#, Python and so on).<br></div></div></blo=
ckquote><div><br>They also have garbage collection. What's your point?<=
br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
<div>Guys has already mentioned that <b>stack trace</b> will be usefull,</d=
iv></div></blockquote><div><br>Yes, stack traces are useful. That doesn'=
;t mean that:<br><br>1. We should standardize them in some way.<br><br>2. E=
very exception should bear the weight of a stack trace.<br><br>Even if you =
believe in #1, it's a lot harder to justify #2.<br><br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>but only you do no=
t like this idea, because you do not use it.<br><b>How can you know whether=
it usefull or not if you have never use this feature in C++ ?</b></div></d=
iv></blockquote><div><br>I've never tried guaranteed elision, fold expr=
essions, `if constexpr` or most other features of C++17 either. But that do=
esn't mean I can't tell if they'd be useful. <br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/9bc4756b-8648-40ec-b726-4fee25acc998%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9bc4756b-8648-40ec-b726-4fee25acc998=
%40isocpp.org</a>.<br />
------=_Part_668_1919857766.1469990980047--
------=_Part_667_1228858478.1469990980046--
.
Author: =?UTF-8?B?0JTQtdC90LjRgSDQmtC+0YLQvtCy?= <redradist@gmail.com>
Date: Sun, 31 Jul 2016 11:56:23 -0700 (PDT)
Raw View
------=_Part_2348_346535084.1469991383468
Content-Type: multipart/alternative;
boundary="----=_Part_2349_1429042087.1469991383478"
------=_Part_2349_1429042087.1469991383478
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=D0=B2=D0=BE=D1=81=D0=BA=D1=80=D0=B5=D1=81=D0=B5=D0=BD=D1=8C=D0=B5, 31 =D0=
=B8=D1=8E=D0=BB=D1=8F 2016 =D0=B3., 21:39:58 UTC+3 =D0=BF=D0=BE=D0=BB=D1=8C=
=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Thiago Macieira=20
=D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:
>
> On domingo, 31 de julho de 2016 09:38:25 PDT =D0=94=D0=B5=D0=BD=D0=B8=D1=
=81 =D0=9A=D0=BE=D1=82=D0=BE=D0=B2 wrote:=20
> > I said problem or bug. If somebody try get element using *arr.at(1000)*=
=20
> it=20
> > will throw exception.=20
> > *Is it bug or problem ?*=20
> > If we want to show user that something goes wrong we throw exception=20
> *(for=20
> > example file not found as you wrote)* we need show user where it=20
> happened.=20
>
> First of all, like Nicol replied, "showing to the user" is often an=20
> incorrect=20
> step to do. The application should not display its problems to the user.=
=20
> If=20
> they are unrecoverable, log it somewhere for the user to pass the=20
> information=20
> along to the developer, then simply report to the user that the=20
> unrecoverable=20
> error happened. If the error was recoverable, recover.=20
>
> The whole point of catching exceptions is to *recover*. If at(1000) throw=
s=20
> an=20
> exception and that exception is caught, then the problem was recovered an=
d=20
> you=20
> don't need to know (much less display) where the exception was thrown=20
> from.=20
>
> If the exception wasn't caught, then it was an unrecoverable error. In=20
> that=20
> case, the uncaught exception handler is called and the program terminates=
..=20
> Often, ABI-specific information is still available at this point to help=
=20
> diagnose the issue, including the stack trace. But, as I said, stacks and=
=20
> frames are concepts that exist only in the ABI, so the standard simply=20
> can't=20
> say anything about them.=20
>
> > > You put it around any place that can throw and that your founction=20
> isn't=20
> > > expected to throw that exception.=20
> >=20
> > *Unfortunately big programs writes by many people and people make=20
> mistakes.*=20
> > Every time somebody forgets put *try ... catch* and then happens weird=
=20
> > things. You try finding problem place 2h, 4h, 1day or more ... depends=
=20
> how=20
> > big project is.=20
>
> I understand, but the point is remains: if a bug occurred, then you've=20
> stepped=20
> outside the realm of the standard. The standard can't say what happens=20
> outside=20
> of the standard.=20
>
> Like I said above, though, most ABIs can log more ABI-dependent=20
> information in=20
> the event of an uncaught exception. Yes, that often requires debug mode=
=20
> builds=20
> and debugging symbols to be present.=20
>
> Assuming that you've been using those facilities provided by your=20
> toolchain, I=20
> have to ask: why do you want to standardise them? Why can't you continue=
=20
> to=20
> use the ABI-dependent ones?=20
>
> --=20
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org=20
> Software Architect - Intel Open Source Technology Center=20
>
>
By "user" - I mean programmers. Programmers is the first user of standard=
=20
library.
> Assuming that you've been using those facilities provided by your=20
toolchain, I
> have to ask: why do you want to standardise them? Why can't you continue=
=20
to
> use the ABI-dependent ones?
Because everybody implement their own bicycle if you understand what I mean=
..
All programmers implement their own bicycle, because standard library does=
=20
not provide. Should be standard way for handling such situation.
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/ae125e90-9978-4cb9-8081-abe508cb1819%40isocpp.or=
g.
------=_Part_2349_1429042087.1469991383478
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">=D0=B2=D0=BE=D1=81=D0=BA=D1=80=D0=B5=D1=81=D0=B5=D0=BD=D1=
=8C=D0=B5, 31 =D0=B8=D1=8E=D0=BB=D1=8F 2016 =D0=B3., 21:39:58 UTC+3 =D0=BF=
=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Thiago M=
acieira =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:<blockquote class=3D"gma=
il_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid=
;padding-left: 1ex;">On domingo, 31 de julho de 2016 09:38:25 PDT =D0=94=D0=
=B5=D0=BD=D0=B8=D1=81 =D0=9A=D0=BE=D1=82=D0=BE=D0=B2 wrote:
<br>> I said problem or bug. If somebody try get element using *<a href=
=3D"http://arr.at" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.h=
ref=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Farr.at\x26sa\x3dD\x2=
6sntz\x3d1\x26usg\x3dAFQjCNFxLPUpJfWQvLx7capIm4lnJf7xtw';return true;" =
onclick=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Farr=
..at\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFxLPUpJfWQvLx7capIm4lnJf7xtw=
9;;return true;">arr.at</a>(1000)* it
<br>> will throw exception.
<br>> *Is it bug or problem ?*
<br>> If we want to show user that something goes wrong we throw excepti=
on *(for
<br>> example file not found as you wrote)* we need show user where it h=
appened.
<br>
<br>First of all, like Nicol replied, "showing to the user" is of=
ten an incorrect=20
<br>step to do. The application should not display its problems to the user=
.. If=20
<br>they are unrecoverable, log it somewhere for the user to pass the infor=
mation=20
<br>along to the developer, then simply report to the user that the unrecov=
erable=20
<br>error happened. If the error was recoverable, recover.
<br>
<br>The whole point of catching exceptions is to *recover*. If at(1000) thr=
ows an=20
<br>exception and that exception is caught, then the problem was recovered =
and you=20
<br>don't need to know (much less display) where the exception was thro=
wn from.
<br>
<br>If the exception wasn't caught, then it was an unrecoverable error.=
In that=20
<br>case, the uncaught exception handler is called and the program terminat=
es.=20
<br>Often, ABI-specific information is still available at this point to hel=
p=20
<br>diagnose the issue, including the stack trace. But, as I said, stacks a=
nd=20
<br>frames are concepts that exist only in the ABI, so the standard simply =
can't=20
<br>say anything about them.
<br>
<br>> > You put it around any place that can throw and that your foun=
ction isn't
<br>> > expected to throw that exception.
<br>>=20
<br>> *Unfortunately big programs writes by many people and people make =
mistakes.*
<br>> Every time somebody forgets put *try ... catch* and then happens w=
eird
<br>> things. You try finding problem place 2h, 4h, 1day or more ... dep=
ends how
<br>> big project is.
<br>
<br>I understand, but the point is remains: if a bug occurred, then you'=
;ve stepped=20
<br>outside the realm of the standard. The standard can't say what happ=
ens outside=20
<br>of the standard.
<br>
<br>Like I said above, though, most ABIs can log more ABI-dependent informa=
tion in=20
<br>the event of an uncaught exception. Yes, that often requires debug mode=
builds=20
<br>and debugging symbols to be present.
<br>
<br>Assuming that you've been using those facilities provided by your t=
oolchain, I=20
<br>have to ask: why do you want to standardise them? Why can't you con=
tinue to=20
<br>use the ABI-dependent ones?
<br>
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.goo=
gle.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x3dD\x26sntz\x3d1\x26usg\=
x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return true;" onclick=3D"this.hr=
ef=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x=
3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return t=
rue;">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" target=3D"=
_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google.=
com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH=
GRJdo5_JYG1DowztwAHAKs80XSA';return true;" onclick=3D"this.href=3D'=
http://www.google.com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1=
\x26usg\x3dAFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return true;">kde.org</a=
>
<br>=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center
<br>
<br></blockquote><div><br>By "user" - I mean programmers. Program=
mers is the first user of standard library.<br><br>> Assuming that you&#=
39;ve been using those facilities provided by your toolchain, I<br>> hav=
e to ask: why do you want to standardise them? Why can't you continue t=
o<br>> use the ABI-dependent ones?<br><br>Because everybody implement th=
eir own bicycle if you understand what I mean.<br>All programmers implement=
their own bicycle, because standard library does not provide. Should be st=
andard way for handling such situation.<br><br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/ae125e90-9978-4cb9-8081-abe508cb1819%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ae125e90-9978-4cb9-8081-abe508cb1819=
%40isocpp.org</a>.<br />
------=_Part_2349_1429042087.1469991383478--
------=_Part_2348_346535084.1469991383468--
.
Author: =?UTF-8?B?0JTQtdC90LjRgSDQmtC+0YLQvtCy?= <redradist@gmail.com>
Date: Sun, 31 Jul 2016 12:12:11 -0700 (PDT)
Raw View
------=_Part_2242_574239736.1469992331283
Content-Type: multipart/alternative;
boundary="----=_Part_2243_719572735.1469992331284"
------=_Part_2243_719572735.1469992331284
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=D0=B2=D0=BE=D1=81=D0=BA=D1=80=D0=B5=D1=81=D0=B5=D0=BD=D1=8C=D0=B5, 31 =D0=
=B8=D1=8E=D0=BB=D1=8F 2016 =D0=B3., 21:49:40 UTC+3 =D0=BF=D0=BE=D0=BB=D1=8C=
=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Nicol Bolas=20
=D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:
>
> On Sunday, July 31, 2016 at 1:35:43 PM UTC-4, =D0=94=D0=B5=D0=BD=D0=B8=D1=
=81 =D0=9A=D0=BE=D1=82=D0=BE=D0=B2 wrote:
>>
>> =D0=B2=D0=BE=D1=81=D0=BA=D1=80=D0=B5=D1=81=D0=B5=D0=BD=D1=8C=D0=B5, 31 =
=D0=B8=D1=8E=D0=BB=D1=8F 2016 =D0=B3., 20:23:21 UTC+3 =D0=BF=D0=BE=D0=BB=D1=
=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Nicol Bolas=20
>> =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:
>>>
>>> On Sunday, July 31, 2016 at 12:38:26 PM UTC-4, =D0=94=D0=B5=D0=BD=D0=B8=
=D1=81 =D0=9A=D0=BE=D1=82=D0=BE=D0=B2 wrote:
>>>>
>>>> =D0=B2=D0=BE=D1=81=D0=BA=D1=80=D0=B5=D1=81=D0=B5=D0=BD=D1=8C=D0=B5, 31=
=D0=B8=D1=8E=D0=BB=D1=8F 2016 =D0=B3., 19:09:51 UTC+3 =D0=BF=D0=BE=D0=BB=
=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Thiago=20
>>>> Macieira =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:
>>>> > On domingo, 31 de julho de 2016 02:57:35 PDT =D0=94=D0=B5=D0=BD=D0=
=B8=D1=81 =D0=9A=D0=BE=D1=82=D0=BE=D0=B2 wrote:
>>>> > > > You misunderstand what exceptions are for. You're not supposed t=
o=20
>>>> catch
>>>> > >
>>>> > > them
>>>> > >
>>>> > > > to find out where the error occurred. You catch them so you=20
>>>> handle the
>>>> > > > condition wherever it happened, then continue execution because=
=20
>>>> you've
>>>> > > > corrected the problem.
>>>> >> >
>>>> > > > I think this is incorrect.
>>>> > > > How can I correct the problem or bug if I do not know where the=
=20
>>>> problem
>>>> > > > happened.
>>>>
>>>> > There was no bug. Exceptions are not used to signal bugs. They are=
=20
>>>> used to
>>>> > signal perfectly fine, if exceptional, conditions. A file not being=
=20
>>>> found is not
>>>> > a bug.
>>>>
>>>> I said problem or bug. If somebody try get element using *arr.at=20
>>>> <http://arr.at>(1000)* it will throw exception.
>>>> *Is it bug or problem ?*
>>>> If we want to show user that something goes wrong we throw exception *=
(for=20
>>>> example file not found as you wrote)* we need show user where it=20
>>>> happened.
>>>>
>>>
>>> If I'm *using* a GUI application, I don't know or *care* what function=
=20
>>> caused a "file not found as you wrote" exception. I don't want a stack=
=20
>>> trace; it would be of utterly *no value* to me. I don't have the code;=
=20
>>> I don't know what those functions mean. What I care about is whether th=
e=20
>>> application can handle that circumstance or not.
>>>
>>> Crashing because of a missing file may be reasonable for some=20
>>> applications. In those cases, a stack trace would still not be helpful.=
=20
>>> Simply stopping, perhaps with an error message, is sufficient.
>>>
>>> Stack traces are only of value to *programmers*, and generally, only to=
=20
>>> the programmers who wrote the system in question. So what you show to "=
the=20
>>> user" is irrelevant.
>>>
>> =20
>> > If I'm *using* a GUI application, I don't know or *care* what function=
=20
>> caused a "file not found as you wrote" exception. I don't want a stack=
=20
>> trace; it would be of utterly *> no value* to me. I don't have the code;=
=20
>> I don't know what those functions mean. What I care about is whether the=
=20
>> application can handle that circumstance or not.
>>
>> It is not needed for you, but do not say in general that this is useless=
..=20
>> If C++ has exceptions we should make them more frendly for users.
>>
>
> If an application is displaying a stack trace spew to the user, that=20
> application is not "frendly[sic] for users" at all.
>
> In Embedded programming this is very helpful feature *(stack trace)*.
>>
>
> What kind of embedded programming have you been doing where you can=20
> generate a stack trace that contains anything more than addresses? I=20
> assumed most embedded environments didn't have the memory to waste on=20
> loading string data for function/type names and so forth.
>
> Modern Programming Languages have had already it (Java, C#, Python and so=
=20
>> on).
>>
>
> They also have garbage collection. What's your point?
>
> Guys has already mentioned that *stack trace* will be usefull,
>>
>
> Yes, stack traces are useful. That doesn't mean that:
>
> 1. We should standardize them in some way.
>
> 2. Every exception should bear the weight of a stack trace.
>
> Even if you believe in #1, it's a lot harder to justify #2.
>
> but only you do not like this idea, because you do not use it.
>> *How can you know whether it usefull or not if you have never use this=
=20
>> feature in C++ ?*
>>
>
> I've never tried guaranteed elision, fold expressions, `if constexpr` or=
=20
> most other features of C++17 either. But that doesn't mean I can't tell i=
f=20
> they'd be useful.=20
>
> Yes, stack traces are useful. That doesn't mean that:
> 1. We should standardize them in some way.
*No, we should.* Please, count number of questions about stack trace on=20
StackOverflow.
If something become so needed it is time to standardize it, otherwise we=20
would code a class without keyword *"class"*, but using keyword *"struct"*=
=20
right now.
*And somebody would say: "Why should we standatize keyword "class" ?=20
"struct" is enough for long term."*
=20
> 2. Every exception should bear the weight of a stack trace.
It is not so hard to do if there was standard on it. Allow programmer to=20
choice if they need compile program with additional information (in every=
=20
function put meta information with name, class and etc.)
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/c1de3721-e82f-4eb4-8d5f-ed4938282877%40isocpp.or=
g.
------=_Part_2243_719572735.1469992331284
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">=D0=B2=D0=BE=D1=81=D0=BA=D1=80=D0=B5=D1=81=D0=B5=D0=BD=D1=
=8C=D0=B5, 31 =D0=B8=D1=8E=D0=BB=D1=8F 2016 =D0=B3., 21:49:40 UTC+3 =D0=BF=
=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Nicol Bo=
las =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:<blockquote class=3D"gmail_q=
uote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pad=
ding-left: 1ex;"><div dir=3D"ltr">On Sunday, July 31, 2016 at 1:35:43 PM UT=
C-4, =D0=94=D0=B5=D0=BD=D0=B8=D1=81 =D0=9A=D0=BE=D1=82=D0=BE=D0=B2 wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-=
left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=D0=B2=D0=BE=D1=81=
=D0=BA=D1=80=D0=B5=D1=81=D0=B5=D0=BD=D1=8C=D0=B5, 31 =D0=B8=D1=8E=D0=BB=D1=
=8F 2016 =D0=B3., 20:23:21 UTC+3 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=
=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Nicol Bolas =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=
=D0=B0=D0=BB:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-lef=
t:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Su=
nday, July 31, 2016 at 12:38:26 PM UTC-4, =D0=94=D0=B5=D0=BD=D0=B8=D1=81 =
=D0=9A=D0=BE=D1=82=D0=BE=D0=B2 wrote:<blockquote class=3D"gmail_quote" styl=
e=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex=
"><div dir=3D"ltr">=D0=B2=D0=BE=D1=81=D0=BA=D1=80=D0=B5=D1=81=D0=B5=D0=BD=
=D1=8C=D0=B5, 31 =D0=B8=D1=8E=D0=BB=D1=8F 2016 =D0=B3., 19:09:51 UTC+3 =D0=
=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Thiag=
o Macieira =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:<br>> On domingo, =
31 de julho de 2016 02:57:35 PDT =D0=94=D0=B5=D0=BD=D0=B8=D1=81 =D0=9A=D0=
=BE=D1=82=D0=BE=D0=B2 wrote:<br>> > > You misunderstand what excep=
tions are for. You're not supposed to catch<br>> ><br>> > t=
hem<br>> ><br>> > > to find out where the error occurred. Yo=
u catch them so you handle the<br>> > > condition wherever it happ=
ened, then continue execution because you've<br>> > > correcte=
d the problem.<br>>> ><br>> > > I think this is incorrect=
..<br>> > > How can I correct the problem or bug if I do not know w=
here the problem<br>> > > happened.<br><br>> There was no bug. =
Exceptions are not used to signal bugs. They are used to<br>> signal per=
fectly fine, if exceptional, conditions. A file not being found is not<br>&=
gt; a bug.<br><br>I said problem or bug. If somebody try get element using =
<b><a href=3D"http://arr.at" rel=3D"nofollow" target=3D"_blank" onmousedown=
=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Farr.at\x26=
sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFxLPUpJfWQvLx7capIm4lnJf7xtw';retu=
rn true;" onclick=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3=
A%2F%2Farr.at\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFxLPUpJfWQvLx7capIm4l=
nJf7xtw';return true;">arr.at</a>(1000)</b> it will throw exception.<br=
><b>Is it bug or problem ?</b><br>If we want to show user that something go=
es wrong we throw exception <b>(for example file not found as you wrote)</b=
> we need show user where it happened.<br></div></blockquote><div dir=3D"lt=
r"><br>If I'm <i>using</i> a GUI application, I don't know or <i>ca=
re</i> what function caused a "file not found as you wrote" excep=
tion. I don't want a stack trace; it would be of utterly <i>no value</i=
> to me. I don't have the code; I don't know what those functions m=
ean. What I care about is whether the application can handle that circumsta=
nce or not.<br><br>Crashing because of a missing file may be reasonable for=
some applications. In those cases, a stack trace would still not be helpfu=
l. Simply stopping, perhaps with an error message, is sufficient.<br><br>St=
ack traces are only of value to <i>programmers</i>, and generally, only to =
the programmers who wrote the system in question. So what you show to "=
;the user" is irrelevant.<br></div></div></blockquote><div>=C2=A0</div=
><div>> If I'm <i>using</i> a GUI application, I don't know or <=
i>care</i> what function caused a "file not found as you wrote" e=
xception. I don't want a stack trace; it would be of utterly <i>> no=
value</i>
to me. I don't have the code; I don't know what those functions me=
an.=20
What I care about is whether the application can handle that=20
circumstance or not.<br><br>It is not needed for you, but do not say in gen=
eral that this is useless. If C++ has exceptions we should make them more f=
rendly for users.<br></div></div></blockquote><div><br>If an application is=
displaying a stack trace spew to the user, that application is not "f=
rendly[sic] for users" at all.<br><br></div><blockquote class=3D"gmail=
_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><div>In Embedded programming this is very he=
lpful feature <b>(stack trace)</b>.</div></div></blockquote><div><br>What k=
ind of embedded programming have you been doing where you can generate a st=
ack trace that contains anything more than addresses? I assumed most embedd=
ed environments didn't have the memory to waste on loading string data =
for function/type names and so forth.<br><br></div><blockquote class=3D"gma=
il_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><div dir=3D"ltr"><div>Modern Programming Languages have had=
already it (Java, C#, Python and so on).<br></div></div></blockquote><div=
><br>They also have garbage collection. What's your point?<br><br></div=
><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Guys has alr=
eady mentioned that <b>stack trace</b> will be usefull,</div></div></blockq=
uote><div><br>Yes, stack traces are useful. That doesn't mean that:<br>=
<br>1. We should standardize them in some way.<br><br>2. Every exception sh=
ould bear the weight of a stack trace.<br><br>Even if you believe in #1, it=
's a lot harder to justify #2.<br><br></div><blockquote class=3D"gmail_=
quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddi=
ng-left:1ex"><div dir=3D"ltr"><div>but only you do not like this idea, beca=
use you do not use it.<br><b>How can you know whether it usefull or not if =
you have never use this feature in C++ ?</b></div></div></blockquote><div><=
br>I've never tried guaranteed elision, fold expressions, `if constexpr=
` or most other features of C++17 either. But that doesn't mean I can&#=
39;t tell if they'd be useful. <br></div></div></blockquote><div><br>&g=
t; Yes, stack traces are useful. That doesn't mean that:<br><br>> 1.=
We should standardize them in some way.<br><b>No, we should.</b> Please, c=
ount number of questions about stack trace on StackOverflow.<br>If somethin=
g become so needed it is time to standardize it, otherwise we would code a =
class without keyword <b>"class"</b>, but using keyword <b>"=
struct"</b> right now.<br><b>And somebody would say: "Why should =
we standatize keyword "class" ? "struct" is enough for =
long term."</b><br>=C2=A0<br>> 2. Every exception should bear the w=
eight of a stack trace.<br>It is not so hard to do if there was standard on=
it. Allow programmer to choice if they need compile program with additiona=
l information (in every function put meta information with name, class and =
etc.)<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/c1de3721-e82f-4eb4-8d5f-ed4938282877%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c1de3721-e82f-4eb4-8d5f-ed4938282877=
%40isocpp.org</a>.<br />
------=_Part_2243_719572735.1469992331284--
------=_Part_2242_574239736.1469992331283--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Sun, 31 Jul 2016 14:22:23 -0500
Raw View
--001a1140a86c9950c10538f36935
Content-Type: text/plain; charset=UTF-8
On 31 July 2016 at 13:49, Nicol Bolas <jmckesson@gmail.com> wrote:
> 1. We should standardize them in some way.
>
> 2. Every exception should bear the weight of a stack trace.
>
>
I agree with 2. Exceptions are not for programming errors. Any stack
tracing facility should be independent of exceptions.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> +1-847-691-1404
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BNVT%3DhSnW-nO%2BoitSk1kMeTFfc2HieXV8WssECdzGcNMA%40mail.gmail.com.
--001a1140a86c9950c10538f36935
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra">On 31 July 2016 at 13:49, Nicol=
Bolas <span dir=3D"ltr"><<a href=3D"mailto:jmckesson@gmail.com" target=
=3D"_blank">jmckesson@gmail.com</a>></span> wrote:<br><div class=3D"gmai=
l_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div>1. We should standardize them =
in some way.<br><br>2. Every exception should bear the weight of a stack tr=
ace.<br><br></div></blockquote></div><br>I agree with 2.=C2=A0 Exceptions a=
re not for programming errors.=C2=A0 Any stack tracing facility should be i=
ndependent of exceptions.<br>-- <br><div class=3D"gmail_signature" data-sma=
rtmail=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><div>=C2=
=A0Nevin ":-)" Liber=C2=A0 <mailto:<a href=3D"mailto:nevin@evi=
loverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>> =C2=A0+1-84=
7-691-1404</div></div></div></div></div>
</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BNVT%3DhSnW-nO%2BoitSk1kMeTFf=
c2HieXV8WssECdzGcNMA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BNV=
T%3DhSnW-nO%2BoitSk1kMeTFfc2HieXV8WssECdzGcNMA%40mail.gmail.com</a>.<br />
--001a1140a86c9950c10538f36935--
.
Author: "D. B." <db0451@gmail.com>
Date: Sun, 31 Jul 2016 20:32:55 +0100
Raw View
--089e0122ea38ef216c0538f38c9a
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Sun, Jul 31, 2016 at 8:12 PM, =D0=94=D0=B5=D0=BD=D0=B8=D1=81 =D0=9A=D0=
=BE=D1=82=D0=BE=D0=B2 <redradist@gmail.com> wrote:
> =D0=B2=D0=BE=D1=81=D0=BA=D1=80=D0=B5=D1=81=D0=B5=D0=BD=D1=8C=D0=B5, 31 =
=D0=B8=D1=8E=D0=BB=D1=8F 2016 =D0=B3., 21:49:40 UTC+3 =D0=BF=D0=BE=D0=BB=D1=
=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Nicol Bolas
> =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:
> > Yes, stack traces are useful. That doesn't mean that:
>
> > 1. We should standardize them in some way.
> *No, we should.* Please, count number of questions about stack trace on
> StackOverflow.
> If something become so needed it is time to standardize it, otherwise we
> would code a class without keyword *"class"*, but using keyword *"struct"=
*
> right now.
> *And somebody would say: "Why should we standatize keyword "class" ?
> "struct" is enough for long term."*
>
On Stack Overflow? *We should be so lucky* that people would know what a
stack trace is. Most of them don't and ask horrible, incomplete,
undiagnosable questions about the segfaults caused by their rubbishy code.
Firstly, show me these many, many questions.
Secondly, show me how they are directly aided by burdening exceptions with
stack trace info, even if most exceptions don't need it.
Thirdly, please stop drawing meaningless analogies to completely unrelated
other areas of the language. It doesn't promote whatever point you're
trying to make.
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CACGiwhEdTTcxnRvED9kZmRB24gNz1WqkTWZNeUYF5EV9tD%=
3Dx2Q%40mail.gmail.com.
--089e0122ea38ef216c0538f38c9a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
un, Jul 31, 2016 at 8:12 PM, =D0=94=D0=B5=D0=BD=D0=B8=D1=81 =D0=9A=D0=BE=D1=
=82=D0=BE=D0=B2 <span dir=3D"ltr"><<a href=3D"mailto:redradist@gmail.com=
" target=3D"_blank">redradist@gmail.com</a>></span> wrote:<br><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex"><div dir=3D"ltr">=D0=B2=D0=BE=D1=81=D0=BA=D1=80=D0=B5=
=D1=81=D0=B5=D0=BD=D1=8C=D0=B5, 31 =D0=B8=D1=8E=D0=BB=D1=8F 2016 =D0=B3., 2=
1:49:40 UTC+3 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=
=D0=BB=D1=8C Nicol Bolas =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:<br><di=
v><div><div class=3D"h5">> Yes, stack traces are useful. That doesn'=
t mean that:<br><br>> 1. We should standardize them in some way.<br></di=
v></div><b>No, we should.</b> Please, count number of questions about stack=
trace on StackOverflow.<br>If something become so needed it is time to sta=
ndardize it, otherwise we would code a class without keyword <b>"class=
"</b>, but using keyword <b>"struct"</b> right now.<br><b>An=
d somebody would say: "Why should we standatize keyword "class&qu=
ot; ? "struct" is enough for long term."</b><span class=3D""=
>=C2=A0</span><br></div></div></blockquote><div><br></div><div>On Stack Ove=
rflow? <i>We should be so lucky</i> that people would know what a stack tra=
ce is. Most of them don't and ask horrible, incomplete, undiagnosable q=
uestions about the segfaults caused by their rubbishy code.<br><br></div><d=
iv>Firstly, show me these many, many questions.<br><br>Secondly, show me ho=
w they are directly aided by burdening exceptions with stack trace info, ev=
en if most exceptions don't need it. <br><br></div><div>Thirdly, please=
stop drawing meaningless analogies to completely unrelated other areas of =
the language. It doesn't promote whatever point you're trying to ma=
ke.<br></div></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CACGiwhEdTTcxnRvED9kZmRB24gNz1WqkTWZN=
eUYF5EV9tD%3Dx2Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhEdTTcxnR=
vED9kZmRB24gNz1WqkTWZNeUYF5EV9tD%3Dx2Q%40mail.gmail.com</a>.<br />
--089e0122ea38ef216c0538f38c9a--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Sun, 31 Jul 2016 13:14:46 -0700
Raw View
On domingo, 31 de julho de 2016 11:56:23 PDT =D0=94=D0=B5=D0=BD=D0=B8=D1=81=
=D0=9A=D0=BE=D1=82=D0=BE=D0=B2 wrote:
> > Assuming that you've been using those facilities provided by your=20
>=20
> toolchain, I
>=20
> > have to ask: why do you want to standardise them? Why can't you continu=
e=20
>=20
> to
>=20
> > use the ABI-dependent ones?
>=20
> Because everybody implement their own bicycle if you understand what I me=
an.
> All programmers implement their own bicycle, because standard library doe=
s
> not provide. Should be standard way for handling such situation.
I really don't see how that works and I think your analogy is faulty. A=20
standard way of making bicycles exists because the circumstances for bicycl=
es=20
are mostly the same.
That's not the same for diagnosing problems in ABI. Each ABI is different, =
and=20
will be able to do different things, log different things. What's important=
in=20
one ABI may be superfluous or completely inexistent in another. It's hard t=
o=20
standardise what's completely different.
You're arguing for stack traces. I'm saying that stack traces isn't enough=
=20
*and* that the functionality already exists and is good enough. I don't see=
=20
the point of standardising them.
I also don't see the point of duplicating the ICU library or 2D graphics in=
=20
the standard. The standard does not need to be all-encompassing.
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/1572199.Il2bGME009%40tjmaciei-mobl1.
.
Author: =?UTF-8?B?0JTQtdC90LjRgSDQmtC+0YLQvtCy?= <redradist@gmail.com>
Date: Sun, 31 Jul 2016 13:41:36 -0700 (PDT)
Raw View
------=_Part_2474_1021942893.1469997696604
Content-Type: multipart/alternative;
boundary="----=_Part_2475_1396970259.1469997696604"
------=_Part_2475_1396970259.1469997696604
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=D0=B2=D0=BE=D1=81=D0=BA=D1=80=D0=B5=D1=81=D0=B5=D0=BD=D1=8C=D0=B5, 31 =D0=
=B8=D1=8E=D0=BB=D1=8F 2016 =D0=B3., 23:14:50 UTC+3 =D0=BF=D0=BE=D0=BB=D1=8C=
=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Thiago Macieira=20
=D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:
>
> On domingo, 31 de julho de 2016 11:56:23 PDT =D0=94=D0=B5=D0=BD=D0=B8=D1=
=81 =D0=9A=D0=BE=D1=82=D0=BE=D0=B2 wrote:=20
> > > Assuming that you've been using those facilities provided by your=20
> >=20
> > toolchain, I=20
> >=20
> > > have to ask: why do you want to standardise them? Why can't you=20
> continue=20
> >=20
> > to=20
> >=20
> > > use the ABI-dependent ones?=20
> >=20
> > Because everybody implement their own bicycle if you understand what I=
=20
> mean.=20
> > All programmers implement their own bicycle, because standard library=
=20
> does=20
> > not provide. Should be standard way for handling such situation.=20
>
> I really don't see how that works and I think your analogy is faulty. A=
=20
> standard way of making bicycles exists because the circumstances for=20
> bicycles=20
> are mostly the same.=20
>
> That's not the same for diagnosing problems in ABI. Each ABI is different=
,=20
> and=20
> will be able to do different things, log different things. What's=20
> important in=20
> one ABI may be superfluous or completely inexistent in another. It's hard=
=20
> to=20
> standardise what's completely different.=20
>
> You're arguing for stack traces. I'm saying that stack traces isn't enoug=
h=20
> *and* that the functionality already exists and is good enough. I don't=
=20
> see=20
> the point of standardising them.=20
>
> I also don't see the point of duplicating the ICU library or 2D graphics=
=20
> in=20
> the standard. The standard does not need to be all-encompassing.=20
>
> --=20
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org=20
> Software Architect - Intel Open Source Technology Center=20
>
>
We could implement it even without ABI. Just by adding meta-information and=
=20
code for function for Debug mode.
When you call function in it first of all become to execute meta-code which=
=20
put meta-information of function in to the stack object.
This meta-information and meta-code will exist only for Debug Mode.
It can be implemented differentlly, we need desire to implement it.
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/b149c9bd-6ccd-4ba1-8d94-2428d508bdda%40isocpp.or=
g.
------=_Part_2475_1396970259.1469997696604
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">=D0=B2=D0=BE=D1=81=D0=BA=D1=80=D0=B5=D1=81=D0=B5=D0=BD=D1=
=8C=D0=B5, 31 =D0=B8=D1=8E=D0=BB=D1=8F 2016 =D0=B3., 23:14:50 UTC+3 =D0=BF=
=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Thiago M=
acieira =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:<blockquote class=3D"gma=
il_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid=
;padding-left: 1ex;">On domingo, 31 de julho de 2016 11:56:23 PDT =D0=94=D0=
=B5=D0=BD=D0=B8=D1=81 =D0=9A=D0=BE=D1=82=D0=BE=D0=B2 wrote:
<br>> > Assuming that you've been using those facilities provided=
by your=20
<br>>=20
<br>> toolchain, I
<br>>=20
<br>> > have to ask: why do you want to standardise them? Why can'=
;t you continue=20
<br>>=20
<br>> to
<br>>=20
<br>> > use the ABI-dependent ones?
<br>>=20
<br>> Because everybody implement their own bicycle if you understand wh=
at I mean.
<br>> All programmers implement their own bicycle, because standard libr=
ary does
<br>> not provide. Should be standard way for handling such situation.
<br>
<br>I really don't see how that works and I think your analogy is fault=
y. A=20
<br>standard way of making bicycles exists because the circumstances for bi=
cycles=20
<br>are mostly the same.
<br>
<br>That's not the same for diagnosing problems in ABI. Each ABI is dif=
ferent, and=20
<br>will be able to do different things, log different things. What's i=
mportant in=20
<br>one ABI may be superfluous or completely inexistent in another. It'=
s hard to=20
<br>standardise what's completely different.
<br>
<br>You're arguing for stack traces. I'm saying that stack traces i=
sn't enough=20
<br>*and* that the functionality already exists and is good enough. I don&#=
39;t see=20
<br>the point of standardising them.
<br>
<br>I also don't see the point of duplicating the ICU library or 2D gra=
phics in=20
<br>the standard. The standard does not need to be all-encompassing.
<br>
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.goo=
gle.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x3dD\x26sntz\x3d1\x26usg\=
x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return true;" onclick=3D"this.hr=
ef=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x=
3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return t=
rue;">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" target=3D"=
_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google.=
com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH=
GRJdo5_JYG1DowztwAHAKs80XSA';return true;" onclick=3D"this.href=3D'=
http://www.google.com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1=
\x26usg\x3dAFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return true;">kde.org</a=
>
<br>=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center
<br>
<br></blockquote><div><br>We could implement it even without ABI. Just by a=
dding meta-information and code for function for Debug mode.<br>When you ca=
ll function in it first of all become to execute meta-code which put meta-i=
nformation of function in to the stack object.<br><br>This meta-information=
and meta-code will exist only for Debug Mode.<br>It can be implemented dif=
ferentlly, we need desire to implement it.<br><br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/b149c9bd-6ccd-4ba1-8d94-2428d508bdda%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b149c9bd-6ccd-4ba1-8d94-2428d508bdda=
%40isocpp.org</a>.<br />
------=_Part_2475_1396970259.1469997696604--
------=_Part_2474_1021942893.1469997696604--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sun, 31 Jul 2016 16:13:42 -0700 (PDT)
Raw View
------=_Part_2503_2044840509.1470006822223
Content-Type: multipart/alternative;
boundary="----=_Part_2504_1488716824.1470006822223"
------=_Part_2504_1488716824.1470006822223
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Sunday, July 31, 2016 at 4:41:37 PM UTC-4, =D0=94=D0=B5=D0=BD=D0=B8=D1=
=81 =D0=9A=D0=BE=D1=82=D0=BE=D0=B2 wrote:
>
> =D0=B2=D0=BE=D1=81=D0=BA=D1=80=D0=B5=D1=81=D0=B5=D0=BD=D1=8C=D0=B5, 31 =
=D0=B8=D1=8E=D0=BB=D1=8F 2016 =D0=B3., 23:14:50 UTC+3 =D0=BF=D0=BE=D0=BB=D1=
=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Thiago Macieira=20
> =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:
>>
>> On domingo, 31 de julho de 2016 11:56:23 PDT =D0=94=D0=B5=D0=BD=D0=B8=D1=
=81 =D0=9A=D0=BE=D1=82=D0=BE=D0=B2 wrote:=20
>> > > Assuming that you've been using those facilities provided by your=20
>> >=20
>> > toolchain, I=20
>> >=20
>> > > have to ask: why do you want to standardise them? Why can't you=20
>> continue=20
>> >=20
>> > to=20
>> >=20
>> > > use the ABI-dependent ones?=20
>> >=20
>> > Because everybody implement their own bicycle if you understand what I=
=20
>> mean.=20
>> > All programmers implement their own bicycle, because standard library=
=20
>> does=20
>> > not provide. Should be standard way for handling such situation.=20
>>
>> I really don't see how that works and I think your analogy is faulty. A=
=20
>> standard way of making bicycles exists because the circumstances for=20
>> bicycles=20
>> are mostly the same.=20
>>
>> That's not the same for diagnosing problems in ABI. Each ABI is=20
>> different, and=20
>> will be able to do different things, log different things. What's=20
>> important in=20
>> one ABI may be superfluous or completely inexistent in another. It's har=
d=20
>> to=20
>> standardise what's completely different.=20
>>
>> You're arguing for stack traces. I'm saying that stack traces isn't=20
>> enough=20
>> *and* that the functionality already exists and is good enough. I don't=
=20
>> see=20
>> the point of standardising them.=20
>>
>> I also don't see the point of duplicating the ICU library or 2D graphics=
=20
>> in=20
>> the standard. The standard does not need to be all-encompassing.=20
>>
>> --=20
>> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org=20
>> Software Architect - Intel Open Source Technology Center=20
>>
>>
> We could implement it even without ABI. Just by adding meta-information=
=20
> and code for function for Debug mode.
>
What is "Debug Mode"? I ask this question because the C++ standard does not=
=20
mention any such thing.
It sounds like what you want is a function that generates a string that has=
=20
contents which are implementation-dependent, but should in some way report=
=20
a sequence of function calls that may or may not have happened from this=20
function to the top of its current execution context.
Why do we need to standardize something so utterly nebulous?
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/b2441b19-9398-433d-9db8-34f9869b9348%40isocpp.or=
g.
------=_Part_2504_1488716824.1470006822223
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Sunday, July 31, 2016 at 4:41:37 PM UTC-4, =D0=94=D0=B5=
=D0=BD=D0=B8=D1=81 =D0=9A=D0=BE=D1=82=D0=BE=D0=B2 wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"ltr">=D0=B2=D0=BE=D1=81=D0=BA=D1=80=
=D0=B5=D1=81=D0=B5=D0=BD=D1=8C=D0=B5, 31 =D0=B8=D1=8E=D0=BB=D1=8F 2016 =D0=
=B3., 23:14:50 UTC+3 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=
=D0=B5=D0=BB=D1=8C Thiago Macieira =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=
=BB:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;b=
order-left:1px #ccc solid;padding-left:1ex">On domingo, 31 de julho de 2016=
11:56:23 PDT =D0=94=D0=B5=D0=BD=D0=B8=D1=81 =D0=9A=D0=BE=D1=82=D0=BE=D0=B2=
wrote:
<br>> > Assuming that you've been using those facilities provided=
by your=20
<br>>=20
<br>> toolchain, I
<br>>=20
<br>> > have to ask: why do you want to standardise them? Why can'=
;t you continue=20
<br>>=20
<br>> to
<br>>=20
<br>> > use the ABI-dependent ones?
<br>>=20
<br>> Because everybody implement their own bicycle if you understand wh=
at I mean.
<br>> All programmers implement their own bicycle, because standard libr=
ary does
<br>> not provide. Should be standard way for handling such situation.
<br>
<br>I really don't see how that works and I think your analogy is fault=
y. A=20
<br>standard way of making bicycles exists because the circumstances for bi=
cycles=20
<br>are mostly the same.
<br>
<br>That's not the same for diagnosing problems in ABI. Each ABI is dif=
ferent, and=20
<br>will be able to do different things, log different things. What's i=
mportant in=20
<br>one ABI may be superfluous or completely inexistent in another. It'=
s hard to=20
<br>standardise what's completely different.
<br>
<br>You're arguing for stack traces. I'm saying that stack traces i=
sn't enough=20
<br>*and* that the functionality already exists and is good enough. I don&#=
39;t see=20
<br>the point of standardising them.
<br>
<br>I also don't see the point of duplicating the ICU library or 2D gra=
phics in=20
<br>the standard. The standard does not need to be all-encompassing.
<br>
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"n=
ofollow" target=3D"_blank" onmousedown=3D"this.href=3D'http://www.googl=
e.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x3dD\x26sntz\x3d1\x26usg\x3=
dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return true;" onclick=3D"this.href=
=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x3d=
D\x26sntz\x3d1\x26usg\x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return tru=
e;">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" rel=3D"nofol=
low" target=3D"_blank" onmousedown=3D"this.href=3D'http://www.google.co=
m/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHGR=
Jdo5_JYG1DowztwAHAKs80XSA';return true;" onclick=3D"this.href=3D'ht=
tp://www.google.com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1\x=
26usg\x3dAFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return true;">kde.org</a>
<br>=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center
<br>
<br></blockquote><div><br>We could implement it even without ABI. Just by a=
dding meta-information and code for function for Debug mode.<br></div></div=
></blockquote><div><br>What is "Debug Mode"? I ask this question =
because the C++ standard does not mention any such thing.<br><br>It sounds =
like what you want is a function that generates a string that has contents =
which are implementation-dependent, but should in some way report a sequenc=
e of function calls that may or may not have happened from this function to=
the top of its current execution context.<br><br>Why do we need to standar=
dize something so utterly nebulous?<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/b2441b19-9398-433d-9db8-34f9869b9348%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b2441b19-9398-433d-9db8-34f9869b9348=
%40isocpp.org</a>.<br />
------=_Part_2504_1488716824.1470006822223--
------=_Part_2503_2044840509.1470006822223--
.
Author: =?UTF-8?B?0JTQtdC90LjRgSDQmtC+0YLQvtCy?= <redradist@gmail.com>
Date: Sun, 31 Jul 2016 20:03:03 -0700 (PDT)
Raw View
------=_Part_2534_1713276907.1470020583391
Content-Type: multipart/alternative;
boundary="----=_Part_2535_2054797981.1470020583391"
------=_Part_2535_2054797981.1470020583391
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=D0=BF=D0=BE=D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D1=8C=D0=BD=D0=B8=D0=BA, 1 =D0=
=B0=D0=B2=D0=B3=D1=83=D1=81=D1=82=D0=B0 2016 =D0=B3., 2:13:42 UTC+3 =D0=BF=
=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Nicol Bo=
las=20
=D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:
>
> On Sunday, July 31, 2016 at 4:41:37 PM UTC-4, =D0=94=D0=B5=D0=BD=D0=B8=D1=
=81 =D0=9A=D0=BE=D1=82=D0=BE=D0=B2 wrote:
>>
>> =D0=B2=D0=BE=D1=81=D0=BA=D1=80=D0=B5=D1=81=D0=B5=D0=BD=D1=8C=D0=B5, 31 =
=D0=B8=D1=8E=D0=BB=D1=8F 2016 =D0=B3., 23:14:50 UTC+3 =D0=BF=D0=BE=D0=BB=D1=
=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Thiago Macieira=20
>> =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:
>>>
>>> On domingo, 31 de julho de 2016 11:56:23 PDT =D0=94=D0=B5=D0=BD=D0=B8=
=D1=81 =D0=9A=D0=BE=D1=82=D0=BE=D0=B2 wrote:=20
>>> > > Assuming that you've been using those facilities provided by your=
=20
>>> >=20
>>> > toolchain, I=20
>>> >=20
>>> > > have to ask: why do you want to standardise them? Why can't you=20
>>> continue=20
>>> >=20
>>> > to=20
>>> >=20
>>> > > use the ABI-dependent ones?=20
>>> >=20
>>> > Because everybody implement their own bicycle if you understand what =
I=20
>>> mean.=20
>>> > All programmers implement their own bicycle, because standard library=
=20
>>> does=20
>>> > not provide. Should be standard way for handling such situation.=20
>>>
>>> I really don't see how that works and I think your analogy is faulty. A=
=20
>>> standard way of making bicycles exists because the circumstances for=20
>>> bicycles=20
>>> are mostly the same.=20
>>>
>>> That's not the same for diagnosing problems in ABI. Each ABI is=20
>>> different, and=20
>>> will be able to do different things, log different things. What's=20
>>> important in=20
>>> one ABI may be superfluous or completely inexistent in another. It's=20
>>> hard to=20
>>> standardise what's completely different.=20
>>>
>>> You're arguing for stack traces. I'm saying that stack traces isn't=20
>>> enough=20
>>> *and* that the functionality already exists and is good enough. I don't=
=20
>>> see=20
>>> the point of standardising them.=20
>>>
>>> I also don't see the point of duplicating the ICU library or 2D graphic=
s=20
>>> in=20
>>> the standard. The standard does not need to be all-encompassing.=20
>>>
>>> --=20
>>> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org=20
>>> Software Architect - Intel Open Source Technology Center=20
>>>
>>>
>> We could implement it even without ABI. Just by adding meta-information=
=20
>> and code for function for Debug mode.
>>
>
> What is "Debug Mode"? I ask this question because the C++ standard does=
=20
> not mention any such thing.
>
> It sounds like what you want is a function that generates a string that=
=20
> has contents which are implementation-dependent, but should in some way=
=20
> report a sequence of function calls that may or may not have happened fro=
m=20
> this function to the top of its current execution context.
>
> Why do we need to standardize something so utterly nebulous?
>
> What is "Debug Mode"? I ask this question because the C++ standard does=
=20
not mention any such thing.
If NDEBUG is not defined that is mean we in debug mode.
And please, stop arguing with me. Make some correction of my proposal. It=
=20
would be constructively.
I waste my time arguing: "This is good - no, we do not need it. This is=20
usefull - no, I do not use it that's mean it is not usefull. We need it -=
=20
no, just put in every place of your program try ... catch, make your code=
=20
like spaghetti ... if somebody forgot put try ... catch statement, hit his=
=20
hands."
*I got tired. I want a constructive dialog.*
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/9b3a28be-e9e7-4f42-a8b6-e66527a1b854%40isocpp.or=
g.
------=_Part_2535_2054797981.1470020583391
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">=D0=BF=D0=BE=D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D1=8C=D0=BD=D0=
=B8=D0=BA, 1 =D0=B0=D0=B2=D0=B3=D1=83=D1=81=D1=82=D0=B0 2016 =D0=B3., 2:13:=
42 UTC+3 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=
=D1=8C Nicol Bolas =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:<blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px=
#ccc solid;padding-left: 1ex;"><div dir=3D"ltr">On Sunday, July 31, 2016 a=
t 4:41:37 PM UTC-4, =D0=94=D0=B5=D0=BD=D0=B8=D1=81 =D0=9A=D0=BE=D1=82=D0=BE=
=D0=B2 wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-lef=
t:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=D0=
=B2=D0=BE=D1=81=D0=BA=D1=80=D0=B5=D1=81=D0=B5=D0=BD=D1=8C=D0=B5, 31 =D0=B8=
=D1=8E=D0=BB=D1=8F 2016 =D0=B3., 23:14:50 UTC+3 =D0=BF=D0=BE=D0=BB=D1=8C=D0=
=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Thiago Macieira =D0=BD=D0=B0=
=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:<blockquote class=3D"gmail_quote" style=3D"m=
argin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">On d=
omingo, 31 de julho de 2016 11:56:23 PDT =D0=94=D0=B5=D0=BD=D0=B8=D1=81 =D0=
=9A=D0=BE=D1=82=D0=BE=D0=B2 wrote:
<br>> > Assuming that you've been using those facilities provided=
by your=20
<br>>=20
<br>> toolchain, I
<br>>=20
<br>> > have to ask: why do you want to standardise them? Why can'=
;t you continue=20
<br>>=20
<br>> to
<br>>=20
<br>> > use the ABI-dependent ones?
<br>>=20
<br>> Because everybody implement their own bicycle if you understand wh=
at I mean.
<br>> All programmers implement their own bicycle, because standard libr=
ary does
<br>> not provide. Should be standard way for handling such situation.
<br>
<br>I really don't see how that works and I think your analogy is fault=
y. A=20
<br>standard way of making bicycles exists because the circumstances for bi=
cycles=20
<br>are mostly the same.
<br>
<br>That's not the same for diagnosing problems in ABI. Each ABI is dif=
ferent, and=20
<br>will be able to do different things, log different things. What's i=
mportant in=20
<br>one ABI may be superfluous or completely inexistent in another. It'=
s hard to=20
<br>standardise what's completely different.
<br>
<br>You're arguing for stack traces. I'm saying that stack traces i=
sn't enough=20
<br>*and* that the functionality already exists and is good enough. I don&#=
39;t see=20
<br>the point of standardising them.
<br>
<br>I also don't see the point of duplicating the ICU library or 2D gra=
phics in=20
<br>the standard. The standard does not need to be all-encompassing.
<br>
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"n=
ofollow" target=3D"_blank" onmousedown=3D"this.href=3D'http://www.googl=
e.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x3dD\x26sntz\x3d1\x26usg\x3=
dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return true;" onclick=3D"this.href=
=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x3d=
D\x26sntz\x3d1\x26usg\x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return tru=
e;">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" rel=3D"nofol=
low" target=3D"_blank" onmousedown=3D"this.href=3D'http://www.google.co=
m/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHGR=
Jdo5_JYG1DowztwAHAKs80XSA';return true;" onclick=3D"this.href=3D'ht=
tp://www.google.com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1\x=
26usg\x3dAFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return true;">kde.org</a>
<br>=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center
<br>
<br></blockquote><div><br>We could implement it even without ABI. Just by a=
dding meta-information and code for function for Debug mode.<br></div></div=
></blockquote><div><br>What is "Debug Mode"? I ask this question =
because the C++ standard does not mention any such thing.<br><br>It sounds =
like what you want is a function that generates a string that has contents =
which are implementation-dependent, but should in some way report a sequenc=
e of function calls that may or may not have happened from this function to=
the top of its current execution context.<br><br>Why do we need to standar=
dize something so utterly nebulous?<br></div></div></blockquote><div><br>&g=
t; What is "Debug Mode"? I ask this question because the C++ stan=
dard does not mention any such thing.<br>If NDEBUG=C2=A0 is not defined tha=
t is mean we in debug mode.<br><br>And please, stop arguing=C2=A0 with me. =
Make some correction of my proposal. It would be constructively.<br>I waste=
my time arguing: "This is good - no, we do not need it. This is usefu=
ll - no, I do not use it that's mean it is not usefull. We need it - no=
, just put in every place of your program try ... catch, make your code lik=
e spaghetti ... if somebody forgot put try ... catch statement, hit his han=
ds."<br><br><b>I got tired. I want a constructive dialog.</b><span id=
=3D"result_box" class=3D"short_text" lang=3D"en"><span><br></span></span></=
div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/9b3a28be-e9e7-4f42-a8b6-e66527a1b854%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9b3a28be-e9e7-4f42-a8b6-e66527a1b854=
%40isocpp.org</a>.<br />
------=_Part_2535_2054797981.1470020583391--
------=_Part_2534_1713276907.1470020583391--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Sun, 31 Jul 2016 21:12:13 -0700
Raw View
On domingo, 31 de julho de 2016 13:41:36 PDT =D0=94=D0=B5=D0=BD=D0=B8=D1=81=
=D0=9A=D0=BE=D1=82=D0=BE=D0=B2 wrote:
> > You're arguing for stack traces. I'm saying that stack traces isn't eno=
ugh
> > *and* that the functionality already exists and is good enough. I don't
> > see
> > the point of standardising them.
> >=20
> > I also don't see the point of duplicating the ICU library or 2D graphic=
s
> > in
> > the standard. The standard does not need to be all-encompassing.
>=20
> We could implement it even without ABI. Just by adding meta-information a=
nd
> code for function for Debug mode.
First of all, no, we can't. This is exactly what I said before: we'd have t=
o=20
standardise what a frame is before we can have a list of stack frames. That=
=20
will inhibit a lot of possible optimisations.
Second, we can't do it for debug mode. There's absolutely no such thing as=
=20
"debug mode" in the standard. And third, you yourself said that this should=
n't=20
be restricted to debug mode or release mode.
> When you call function in it first of all become to execute meta-code whi=
ch
> put meta-information of function in to the stack object.
That's exactly what we don't want to standardise. It constrains what an=20
implementation can do.
> This meta-information and meta-code will exist only for Debug Mode.
> It can be implemented differentlly, we need desire to implement it.
And you still did not reply to my argument that this already exists and is=
=20
good enough, just not part of the standard.
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/2924067.ZVbMAcMJMX%40tjmaciei-mobl1.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Sun, 31 Jul 2016 21:16:40 -0700
Raw View
On domingo, 31 de julho de 2016 20:03:03 PDT =D0=94=D0=B5=D0=BD=D0=B8=D1=81=
=D0=9A=D0=BE=D1=82=D0=BE=D0=B2 wrote:
> > What is "Debug Mode"? I ask this question because the C++ standard does
> > not mention any such thing.
> If NDEBUG is not defined that is mean we in debug mode.
What's NDEBUG? I never set that in my programs, since I almost never need=
=20
them. I'm being serious, I never set them. Qt doesn't react to NDEBUG and=
=20
since all my programs are written with Qt...
No, Nicol is right: there's no such thing as "debug mode" in the standard.=
=20
Please find some other condition to enable your feature in.
> And please, stop arguing with me. Make some correction of my proposal. I=
t
> would be constructively.
We have: this exists and works just fine. Use your debugger and you can get=
the=20
entire stack trace, the values of all local variables and those passed as=
=20
parameters, the state of all the registers, etc.
There's also the backtrace() function in <execinfo.h>.
None of those are part of the standard. We're arguing that they don't need =
to=20
be.
> I waste my time arguing: "This is good - no, we do not need it. This is
> usefull - no, I do not use it that's mean it is not usefull. We need it -
> no, just put in every place of your program try ... catch, make your code
> like spaghetti ... if somebody forgot put try ... catch statement, hit hi=
s
> hands."
This is useful, but the feature already exists. We don't need what you're=
=20
suggestion because it cannot be standardised and it will just be a poor=20
comparison to the tools that already exist.
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/8399721.o9Zjoek9VR%40tjmaciei-mobl1.
.
Author: =?UTF-8?B?0JTQtdC90LjRgSDQmtC+0YLQvtCy?= <redradist@gmail.com>
Date: Sun, 31 Jul 2016 21:26:58 -0700 (PDT)
Raw View
------=_Part_2223_1068871913.1470025618161
Content-Type: multipart/alternative;
boundary="----=_Part_2224_327632692.1470025618162"
------=_Part_2224_327632692.1470025618162
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=D0=BF=D0=BE=D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D1=8C=D0=BD=D0=B8=D0=BA, 1 =D0=
=B0=D0=B2=D0=B3=D1=83=D1=81=D1=82=D0=B0 2016 =D0=B3., 7:16:54 UTC+3 =D0=BF=
=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Thiago M=
acieira=20
=D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:
>
> On domingo, 31 de julho de 2016 20:03:03 PDT =D0=94=D0=B5=D0=BD=D0=B8=D1=
=81 =D0=9A=D0=BE=D1=82=D0=BE=D0=B2 wrote:=20
> > > What is "Debug Mode"? I ask this question because the C++ standard=20
> does=20
> > > not mention any such thing.=20
> > If NDEBUG is not defined that is mean we in debug mode.=20
>
> What's NDEBUG? I never set that in my programs, since I almost never need=
=20
> them. I'm being serious, I never set them. Qt doesn't react to NDEBUG and=
=20
> since all my programs are written with Qt...=20
>
> No, Nicol is right: there's no such thing as "debug mode" in the standard=
..=20
> Please find some other condition to enable your feature in.=20
>
> > And please, stop arguing with me. Make some correction of my proposal.=
=20
> It=20
> > would be constructively.=20
>
> We have: this exists and works just fine. Use your debugger and you can=
=20
> get the=20
> entire stack trace, the values of all local variables and those passed as=
=20
> parameters, the state of all the registers, etc.=20
>
> There's also the backtrace() function in <execinfo.h>.=20
>
> None of those are part of the standard. We're arguing that they don't nee=
d=20
> to=20
> be.=20
>
> > I waste my time arguing: "This is good - no, we do not need it. This is=
=20
> > usefull - no, I do not use it that's mean it is not usefull. We need it=
=20
> -=20
> > no, just put in every place of your program try ... catch, make your=20
> code=20
> > like spaghetti ... if somebody forgot put try ... catch statement, hit=
=20
> his=20
> > hands."=20
>
> This is useful, but the feature already exists. We don't need what you're=
=20
> suggestion because it cannot be standardised and it will just be a poor=
=20
> comparison to the tools that already exist.=20
>
> --=20
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org=20
> Software Architect - Intel Open Source Technology Center=20
>
>
> This is useful, but the feature already exists. We don't need what you're=
=20
> suggestion because it cannot be standardised and it will just be a poor=
=20
> comparison to the tools that already exist.=20
Could you enumerate them ? For different compilers, please ?=20
And how catch for different compilers stack in moment when exception was=20
thrown ?
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/0b007804-b1e0-47ce-a889-1da9bb432474%40isocpp.or=
g.
------=_Part_2224_327632692.1470025618162
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">=D0=BF=D0=BE=D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D1=8C=D0=BD=D0=
=B8=D0=BA, 1 =D0=B0=D0=B2=D0=B3=D1=83=D1=81=D1=82=D0=B0 2016 =D0=B3., 7:16:=
54 UTC+3 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=
=D1=8C Thiago Macieira =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:<blockquo=
te class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left:=
1px #ccc solid;padding-left: 1ex;">On domingo, 31 de julho de 2016 20:03:0=
3 PDT =D0=94=D0=B5=D0=BD=D0=B8=D1=81 =D0=9A=D0=BE=D1=82=D0=BE=D0=B2 wrote:
<br>> > What is "Debug Mode"? I ask this question because t=
he C++ standard does
<br>> > not mention any such thing.
<br>> If NDEBUG =C2=A0is not defined that is mean we in debug mode.
<br>
<br>What's NDEBUG? I never set that in my programs, since I almost neve=
r need=20
<br>them. I'm being serious, I never set them. Qt doesn't react to =
NDEBUG and=20
<br>since all my programs are written with Qt...
<br>
<br>No, Nicol is right: there's no such thing as "debug mode"=
in the standard.=20
<br>Please find some other condition to enable your feature in.
<br>
<br>> And please, stop arguing =C2=A0with me. Make some correction of my=
proposal. It
<br>> would be constructively.
<br>
<br>We have: this exists and works just fine. Use your debugger and you can=
get the=20
<br>entire stack trace, the values of all local variables and those passed =
as=20
<br>parameters, the state of all the registers, etc.
<br>
<br>There's also the backtrace() function in <execinfo.h>.
<br>
<br>None of those are part of the standard. We're arguing that they don=
't need to=20
<br>be.
<br>
<br>> I waste my time arguing: "This is good - no, we do not need i=
t. This is
<br>> usefull - no, I do not use it that's mean it is not usefull. W=
e need it -
<br>> no, just put in every place of your program try ... catch, make yo=
ur code
<br>> like spaghetti ... if somebody forgot put try ... catch statement,=
hit his
<br>> hands."
<br>
<br>This is useful, but the feature already exists. We don't need what =
you're=20
<br>suggestion because it cannot be standardised and it will just be a poor=
=20
<br>comparison to the tools that already exist.
<br>
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.goo=
gle.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x3dD\x26sntz\x3d1\x26usg\=
x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return true;" onclick=3D"this.hr=
ef=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x=
3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return t=
rue;">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" target=3D"=
_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google.=
com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH=
GRJdo5_JYG1DowztwAHAKs80XSA';return true;" onclick=3D"this.href=3D'=
http://www.google.com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1=
\x26usg\x3dAFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return true;">kde.org</a=
>
<br>=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center
<br>
<br></blockquote><div><br>> This is useful, but the feature already exis=
ts. We don't need what you're=20
<br>> suggestion because it cannot be standardised and it will just be a=
poor=20
<br>> comparison to the tools that already exist.
<br><br>Could you enumerate them ? For different compilers, please ? <br>An=
d how catch for different compilers stack in moment when exception was thro=
wn ?<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/0b007804-b1e0-47ce-a889-1da9bb432474%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/0b007804-b1e0-47ce-a889-1da9bb432474=
%40isocpp.org</a>.<br />
------=_Part_2224_327632692.1470025618162--
------=_Part_2223_1068871913.1470025618161--
.
Author: =?UTF-8?B?0JTQtdC90LjRgSDQmtC+0YLQvtCy?= <redradist@gmail.com>
Date: Sun, 31 Jul 2016 21:29:22 -0700 (PDT)
Raw View
------=_Part_2346_534755624.1470025762302
Content-Type: multipart/alternative;
boundary="----=_Part_2347_811739602.1470025762302"
------=_Part_2347_811739602.1470025762302
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=D0=BF=D0=BE=D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D1=8C=D0=BD=D0=B8=D0=BA, 1 =D0=
=B0=D0=B2=D0=B3=D1=83=D1=81=D1=82=D0=B0 2016 =D0=B3., 7:16:54 UTC+3 =D0=BF=
=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Thiago M=
acieira=20
=D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:
>
> On domingo, 31 de julho de 2016 20:03:03 PDT =D0=94=D0=B5=D0=BD=D0=B8=D1=
=81 =D0=9A=D0=BE=D1=82=D0=BE=D0=B2 wrote:=20
> > > What is "Debug Mode"? I ask this question because the C++ standard=20
> does=20
> > > not mention any such thing.=20
> > If NDEBUG is not defined that is mean we in debug mode.=20
>
> What's NDEBUG? I never set that in my programs, since I almost never need=
=20
> them. I'm being serious, I never set them. Qt doesn't react to NDEBUG and=
=20
> since all my programs are written with Qt...=20
>
> No, Nicol is right: there's no such thing as "debug mode" in the standard=
..=20
> Please find some other condition to enable your feature in.=20
>
> > And please, stop arguing with me. Make some correction of my proposal.=
=20
> It=20
> > would be constructively.=20
>
> We have: this exists and works just fine. Use your debugger and you can=
=20
> get the=20
> entire stack trace, the values of all local variables and those passed as=
=20
> parameters, the state of all the registers, etc.=20
>
> There's also the backtrace() function in <execinfo.h>.=20
>
> None of those are part of the standard. We're arguing that they don't nee=
d=20
> to=20
> be.=20
>
> > I waste my time arguing: "This is good - no, we do not need it. This is=
=20
> > usefull - no, I do not use it that's mean it is not usefull. We need it=
=20
> -=20
> > no, just put in every place of your program try ... catch, make your=20
> code=20
> > like spaghetti ... if somebody forgot put try ... catch statement, hit=
=20
> his=20
> > hands."=20
>
> This is useful, but the feature already exists. We don't need what you're=
=20
> suggestion because it cannot be standardised and it will just be a poor=
=20
> comparison to the tools that already exist.=20
>
> --=20
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org=20
> Software Architect - Intel Open Source Technology Center=20
>
>
> There's also the backtrace() function in <execinfo.h>.=20
This header is Linux specific.
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/0b73ccc1-a873-441b-ad74-8bb44d6b28e0%40isocpp.or=
g.
------=_Part_2347_811739602.1470025762302
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">=D0=BF=D0=BE=D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D1=8C=D0=BD=D0=
=B8=D0=BA, 1 =D0=B0=D0=B2=D0=B3=D1=83=D1=81=D1=82=D0=B0 2016 =D0=B3., 7:16:=
54 UTC+3 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=
=D1=8C Thiago Macieira =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:<blockquo=
te class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left:=
1px #ccc solid;padding-left: 1ex;">On domingo, 31 de julho de 2016 20:03:0=
3 PDT =D0=94=D0=B5=D0=BD=D0=B8=D1=81 =D0=9A=D0=BE=D1=82=D0=BE=D0=B2 wrote:
<br>> > What is "Debug Mode"? I ask this question because t=
he C++ standard does
<br>> > not mention any such thing.
<br>> If NDEBUG =C2=A0is not defined that is mean we in debug mode.
<br>
<br>What's NDEBUG? I never set that in my programs, since I almost neve=
r need=20
<br>them. I'm being serious, I never set them. Qt doesn't react to =
NDEBUG and=20
<br>since all my programs are written with Qt...
<br>
<br>No, Nicol is right: there's no such thing as "debug mode"=
in the standard.=20
<br>Please find some other condition to enable your feature in.
<br>
<br>> And please, stop arguing =C2=A0with me. Make some correction of my=
proposal. It
<br>> would be constructively.
<br>
<br>We have: this exists and works just fine. Use your debugger and you can=
get the=20
<br>entire stack trace, the values of all local variables and those passed =
as=20
<br>parameters, the state of all the registers, etc.
<br>
<br>There's also the backtrace() function in <execinfo.h>.
<br>
<br>None of those are part of the standard. We're arguing that they don=
't need to=20
<br>be.
<br>
<br>> I waste my time arguing: "This is good - no, we do not need i=
t. This is
<br>> usefull - no, I do not use it that's mean it is not usefull. W=
e need it -
<br>> no, just put in every place of your program try ... catch, make yo=
ur code
<br>> like spaghetti ... if somebody forgot put try ... catch statement,=
hit his
<br>> hands."
<br>
<br>This is useful, but the feature already exists. We don't need what =
you're=20
<br>suggestion because it cannot be standardised and it will just be a poor=
=20
<br>comparison to the tools that already exist.
<br>
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.goo=
gle.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x3dD\x26sntz\x3d1\x26usg\=
x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return true;" onclick=3D"this.hr=
ef=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x=
3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return t=
rue;">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" target=3D"=
_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google.=
com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH=
GRJdo5_JYG1DowztwAHAKs80XSA';return true;" onclick=3D"this.href=3D'=
http://www.google.com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1=
\x26usg\x3dAFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return true;">kde.org</a=
>
<br>=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center
<br>
<br></blockquote><div><br>> There's also the backtrace() function in=
<execinfo.h>.
<br>This header is Linux specific.<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/0b73ccc1-a873-441b-ad74-8bb44d6b28e0%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/0b73ccc1-a873-441b-ad74-8bb44d6b28e0=
%40isocpp.org</a>.<br />
------=_Part_2347_811739602.1470025762302--
------=_Part_2346_534755624.1470025762302--
.
Author: Ren Industries <renindustries@gmail.com>
Date: Mon, 1 Aug 2016 01:07:53 -0400
Raw View
--001a1149d21628749a0538fb95c8
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Of course it is Linux specific; it has to be ABI specific. That's what
everyone has been telling you.
On Mon, Aug 1, 2016 at 12:29 AM, =D0=94=D0=B5=D0=BD=D0=B8=D1=81 =D0=9A=D0=
=BE=D1=82=D0=BE=D0=B2 <redradist@gmail.com> wrote:
> =D0=BF=D0=BE=D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D1=8C=D0=BD=D0=B8=D0=BA, 1 =D0=
=B0=D0=B2=D0=B3=D1=83=D1=81=D1=82=D0=B0 2016 =D0=B3., 7:16:54 UTC+3 =D0=BF=
=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Thiago M=
acieira
> =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:
>
>> On domingo, 31 de julho de 2016 20:03:03 PDT =D0=94=D0=B5=D0=BD=D0=B8=D1=
=81 =D0=9A=D0=BE=D1=82=D0=BE=D0=B2 wrote:
>> > > What is "Debug Mode"? I ask this question because the C++ standard
>> does
>> > > not mention any such thing.
>> > If NDEBUG is not defined that is mean we in debug mode.
>>
>> What's NDEBUG? I never set that in my programs, since I almost never nee=
d
>> them. I'm being serious, I never set them. Qt doesn't react to NDEBUG an=
d
>> since all my programs are written with Qt...
>>
>> No, Nicol is right: there's no such thing as "debug mode" in the
>> standard.
>> Please find some other condition to enable your feature in.
>>
>> > And please, stop arguing with me. Make some correction of my proposal=
..
>> It
>> > would be constructively.
>>
>> We have: this exists and works just fine. Use your debugger and you can
>> get the
>> entire stack trace, the values of all local variables and those passed a=
s
>> parameters, the state of all the registers, etc.
>>
>> There's also the backtrace() function in <execinfo.h>.
>>
>> None of those are part of the standard. We're arguing that they don't
>> need to
>> be.
>>
>> > I waste my time arguing: "This is good - no, we do not need it. This i=
s
>> > usefull - no, I do not use it that's mean it is not usefull. We need i=
t
>> -
>> > no, just put in every place of your program try ... catch, make your
>> code
>> > like spaghetti ... if somebody forgot put try ... catch statement, hit
>> his
>> > hands."
>>
>> This is useful, but the feature already exists. We don't need what you'r=
e
>> suggestion because it cannot be standardised and it will just be a poor
>> comparison to the tools that already exist.
>>
>> --
>> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>> Software Architect - Intel Open Source Technology Center
>>
>>
> > There's also the backtrace() function in <execinfo.h>.
> This header is Linux specific.
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/0b73ccc1-a87=
3-441b-ad74-8bb44d6b28e0%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/0b73ccc1-a8=
73-441b-ad74-8bb44d6b28e0%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAMD6iD-88mGP220z4m33-9jbsoxXV19WkDdOj8RRuBVNNmQ=
3MQ%40mail.gmail.com.
--001a1149d21628749a0538fb95c8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Of course it is Linux specific; it has to be ABI specific.=
That's what everyone has been telling you.</div><div class=3D"gmail_ex=
tra"><br><div class=3D"gmail_quote">On Mon, Aug 1, 2016 at 12:29 AM, =D0=94=
=D0=B5=D0=BD=D0=B8=D1=81 =D0=9A=D0=BE=D1=82=D0=BE=D0=B2 <span dir=3D"ltr">&=
lt;<a href=3D"mailto:redradist@gmail.com" target=3D"_blank">redradist@gmail=
..com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"lt=
r">=D0=BF=D0=BE=D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D1=8C=D0=BD=D0=B8=D0=BA, 1 =
=D0=B0=D0=B2=D0=B3=D1=83=D1=81=D1=82=D0=B0 2016 =D0=B3., 7:16:54 UTC+3 =D0=
=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Thiag=
o Macieira =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:<div><div class=3D"h5=
"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bor=
der-left:1px #ccc solid;padding-left:1ex">On domingo, 31 de julho de 2016 2=
0:03:03 PDT =D0=94=D0=B5=D0=BD=D0=B8=D1=81 =D0=9A=D0=BE=D1=82=D0=BE=D0=B2 w=
rote:
<br>> > What is "Debug Mode"? I ask this question because t=
he C++ standard does
<br>> > not mention any such thing.
<br>> If NDEBUG =C2=A0is not defined that is mean we in debug mode.
<br>
<br>What's NDEBUG? I never set that in my programs, since I almost neve=
r need=20
<br>them. I'm being serious, I never set them. Qt doesn't react to =
NDEBUG and=20
<br>since all my programs are written with Qt...
<br>
<br>No, Nicol is right: there's no such thing as "debug mode"=
in the standard.=20
<br>Please find some other condition to enable your feature in.
<br>
<br>> And please, stop arguing =C2=A0with me. Make some correction of my=
proposal. It
<br>> would be constructively.
<br>
<br>We have: this exists and works just fine. Use your debugger and you can=
get the=20
<br>entire stack trace, the values of all local variables and those passed =
as=20
<br>parameters, the state of all the registers, etc.
<br>
<br>There's also the backtrace() function in <execinfo.h>.
<br>
<br>None of those are part of the standard. We're arguing that they don=
't need to=20
<br>be.
<br>
<br>> I waste my time arguing: "This is good - no, we do not need i=
t. This is
<br>> usefull - no, I do not use it that's mean it is not usefull. W=
e need it -
<br>> no, just put in every place of your program try ... catch, make yo=
ur code
<br>> like spaghetti ... if somebody forgot put try ... catch statement,=
hit his
<br>> hands."
<br>
<br>This is useful, but the feature already exists. We don't need what =
you're=20
<br>suggestion because it cannot be standardised and it will just be a poor=
=20
<br>comparison to the tools that already exist.
<br>
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"n=
ofollow" target=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http:=
//kde.org" rel=3D"nofollow" target=3D"_blank">kde.org</a>
<br>=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center
<br>
<br></blockquote></div></div><div><div><div class=3D"h5"><br>> There'=
;s also the backtrace() function in <execinfo.h>.
<br></div></div>This header is Linux specific.<br></div></div><span class=
=3D"">
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/0b73ccc1-a873-441b-ad74-8bb44d6b28e0%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/0b73ccc1-a873-=
441b-ad74-8bb44d6b28e0%40isocpp.org</a>.<br>
</blockquote></div><br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAMD6iD-88mGP220z4m33-9jbsoxXV19WkDdO=
j8RRuBVNNmQ3MQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAMD6iD-88mGP220z=
4m33-9jbsoxXV19WkDdOj8RRuBVNNmQ3MQ%40mail.gmail.com</a>.<br />
--001a1149d21628749a0538fb95c8--
.
Author: gmisocpp@gmail.com
Date: Sun, 31 Jul 2016 23:54:11 -0700 (PDT)
Raw View
------=_Part_53_82603991.1470034451816
Content-Type: multipart/alternative;
boundary="----=_Part_54_1504970465.1470034451816"
------=_Part_54_1504970465.1470034451816
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Sunday, July 31, 2016 at 12:14:19 PM UTC+12, =D0=94=D0=B5=D0=BD=D0=B8=D1=
=81 =D0=9A=D0=BE=D1=82=D0=BE=D0=B2 wrote:
> In *C++17* will be added a lot of new features, but no of them features=
=20
> improve quality of code and quickly fixing of the code.
> If in program exist a bug then the best that program can do is crash.=20
> Exception is a good conception for error handling, but is useless in C++=
=20
> implementation, 'cause we do not know where the problem happens. That mea=
n=20
> catching of exception is useless, because additional information is so=20
> small that better allow program simple crash.
> This is the main reason that even in debug mode exception is used not=20
> often.
>
> *PROBLEM *is no standard on it about providing to user *backtrace*.
> Operation system can get stack trace when exception was used. We can=20
> implement getting stack trace even in dummy implementation by adding to=
=20
> every function in compile time meta information with name of this functio=
n=20
> and code that will put this name in stack object that implicitly exists=
=20
> from starting the program. We can add scpecial flag *BACK_TRACE* or=20
> *BTRACE*.
>
> Sorry for straightforward speech but I tired. In we can implement=20
> *backtrace*, but are thinking about coroutine. Without strong *base *we=
=20
> cannot implement something good.
>
>
>
>
> *Thanks,Best regards.*
>
The idea has merit to me. But why is debug mode anything other than=20
slightly relevant to tbe proposal let alone a reason to derail it? Even if=
=20
debug mode is relevant, won't the Standard have to wakeup to debug mode=20
anyway for Contracts, so what's the big deal?
So why can't the Standard suggest something like what the OP says e.g.: "if=
=20
BTRACE is defined as 1, the compiler might emit extra trace information=20
that might aid debugging. If that information is generated, an exit via an=
=20
unhandled exception will cause std::dump_stacktrace to be automatically=20
called. If BTRACE=3D=3D0 or not defined, std::dump_stacktrace will not be=
=20
called."
Enabling the facility in "release mode" seems to be another reason why=20
debug mode seems mostly irrelevant to the debate.
If this means someone could configure a program to get a basic stack trace=
=20
on program failure and also be able to dump that on demand and all without=
=20
having to know anything special about the platform or compiler or debug=20
options and without a lot of stress on vendors to power it, what's so=20
unreasonable?
One could spice up the options or the mechanism but I don't see why the=20
basic idea isn't workable as a starting or ending point. I also don't=20
see debug mode as a reason to reject the idea.=20
=20
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/a5817a96-36e4-412d-9d30-99bc34d28075%40isocpp.or=
g.
------=_Part_54_1504970465.1470034451816
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><br>On Sunday, July 31, 2016 at 12:14:19 PM UTC+12, =
=D0=94=D0=B5=D0=BD=D0=B8=D1=81 =D0=9A=D0=BE=D1=82=D0=BE=D0=B2 wrote:</div><=
blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; paddin=
g-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px;=
border-left-style: solid;"><div dir=3D"ltr">In <b>C++17</b> will be added =
a lot of new features, but no of them features improve quality of code and =
quickly fixing of the code.<br>If in program exist a bug then the best that=
program can do is crash. Exception is a good conception for error handling=
, but is useless in C++ implementation, 'cause we do not know where the=
problem happens. That mean catching of exception is useless, because addit=
ional information is so small that better allow program simple crash.<br>Th=
is is the main reason that even in debug mode exception is used not often.<=
br><br><b>PROBLEM </b>is no standard on it about providing to user <b>backt=
race</b>.<br>Operation system can get stack trace when exception was used. =
We can implement getting stack trace even in dummy implementation by adding=
to every function in compile time meta information with name of this funct=
ion and code that will put this name in stack object that implicitly exists=
from starting the program. We can add scpecial flag <b>BACK_TRACE</b> or <=
b>BTRACE</b>.<br><br>Sorry for straightforward speech but I tired. In we ca=
n implement <b>backtrace</b>, but are thinking about coroutine. Without str=
ong <b>base </b>we cannot implement something good.<br><br><b>Thanks,<br>Be=
st regards.<br><br></b></div></blockquote><div><br></div><div><p>The idea h=
as merit to me. But why is debug mode anything other than slightly relevant=
to tbe proposal let alone a reason to derail it? Even if debug mode is rel=
evant, won't the Standard have to wakeup to debug mode anyway for Contr=
acts, so what's the big deal?</p><p><br></p><p>So why can't the Sta=
ndard suggest something like what the OP says e.g.: "if BTRACE is defi=
ned as 1, the compiler might emit extra trace information that might aid de=
bugging. If that information is generated, an exit via an unhandled excepti=
on will cause std::dump_stacktrace to be automatically called. If BTRACE=3D=
=3D0 or not defined, std::dump_stacktrace will not be called."</p><p><=
br></p><p>Enabling the facility in "release mode" seems to be ano=
ther reason why debug mode seems mostly irrelevant to the debate.</p><p><br=
></p><p>If this means someone could configure a program to get a basic stac=
k trace on program failure and also be able to=C2=A0dump that on demand and=
all=C2=A0without having to know anything special about the platform or com=
piler or debug options=C2=A0and without a lot of stress on vendors to power=
it, what's so unreasonable?</p><p><br></p><div>One could spice up the =
options or the mechanism but I don't see why the basic idea isn't w=
orkable as a starting or ending point.=C2=A0I also don't see=C2=A0debug=
mode as a=C2=A0reason to=C2=A0reject the=C2=A0idea.=C2=A0</div>=C2=A0</div=
></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a5817a96-36e4-412d-9d30-99bc34d28075%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a5817a96-36e4-412d-9d30-99bc34d28075=
%40isocpp.org</a>.<br />
------=_Part_54_1504970465.1470034451816--
------=_Part_53_82603991.1470034451816--
.
Author: Viacheslav Usov <via.usov@gmail.com>
Date: Mon, 1 Aug 2016 12:31:27 +0200
Raw View
--001a1141169e5a53ba0539001a74
Content-Type: text/plain; charset=UTF-8
It looks like this thread started just like this one:
https://groups.google.com/a/isocpp.org/forum/#!topic/std-discussion/A17G1ram9ns
To quote:
To find the root cause of bugs easier, it is very helpful to have stack
trace from the location where the exception is thrown.
Surely I can throw an exception class derived from std:exception and use
backtrace on Linux or StackWalk64 on Windows, with the appropriate symbols
(=> not portable),
or have a try catch "everywhere" and add file and line information (=> too
much code to add),
or not to catch the exception at all and let the Operation System write the
dump file(=>not portable, some exceptions can be handled inside the
program).
I thought there should be an easy portable way to add stack information to
a std::exception. Does anybody have some ideas?
(end)
It then morphed into a discussion of just getting the stack trace, not
necessarily in an exception context, but some of what we discussed there,
in particular the separation of capture/parse functionality, is applicable
in any case.
In this new thread, more than one participant have mentioned they they find
it undesirable to have exceptions carry the weight of stack tracing.
This sentiment is understandable, but I have the following two points to be
considered in this respect:
1. Is the performance of exception handling really an overriding concern?
It is very easy to overgeneralise, of course, but I'd say it is widely
understood[1] that exceptions are not really a mechanism to be used to
control execution under "normal circumstances", in which case worrying more
about performance than utility seems strange.
2. Is it true that "the weight of stack tracing" is really that much weight
to carry? Modern C++ implementations essentially just need only the
instruction pointer to describe fully where the exception originated[2, 3].
Compared to the cost of unwinding the stack in those implementations, the
cost of storing just one pointer in the exception structure seems strictly
negligible.
Cheers,
V.
[1] http://www.stroustrup.com/bs_faq2.html#exceptions-what-not
[2] http://stackoverflow.com/a/18672447
[3] https://msdn.microsoft.com/en-us/library/8ydc79k6.aspx
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg29wob5_hM55%3DQ2O6Xc96SU-bsGQhePt0W0EX28cQWhuw%40mail.gmail.com.
--001a1141169e5a53ba0539001a74
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">It looks like this thread started just like this one: <a h=
ref=3D"https://groups.google.com/a/isocpp.org/forum/#!topic/std-discussion/=
A17G1ram9ns" target=3D"_blank">https://groups.google.com/a/isocpp.org/forum=
/#!topic/std-discussion/A17G1ram9ns</a><div><br></div><div>To quote:</div><=
div><br></div><div><div style=3D"margin:0px;padding:0px;border:0px;font-fam=
ily:arial,helvetica,sans-serif;font-size:13px">To find the root cause of bu=
gs easier, it is very helpful to have stack trace from the location where t=
he exception is thrown.<br></div><div style=3D"margin:0px;padding:0px;borde=
r:0px;font-family:arial,helvetica,sans-serif;font-size:13px"><br></div><div=
style=3D"margin:0px;padding:0px;border:0px;font-family:arial,helvetica,san=
s-serif;font-size:13px">Surely I can throw an exception class derived from =
std:exception and use backtrace on Linux or StackWalk64 on Windows, with th=
e appropriate symbols (=3D> not portable),=C2=A0<br><div style=3D"margin=
:0px;padding:0px;border:0px">or have a try catch "everywhere" and=
add file and line information (=3D> too much code to add),=C2=A0</div><=
/div><div style=3D"margin:0px;padding:0px;border:0px;font-family:arial,helv=
etica,sans-serif;font-size:13px">or not to catch the exception at all and l=
et the Operation System write the dump file(=3D>not portable, some excep=
tions can be handled inside the program).</div><div style=3D"margin:0px;pad=
ding:0px;border:0px;font-family:arial,helvetica,sans-serif;font-size:13px">=
<br></div><div style=3D"margin:0px;padding:0px;border:0px;font-family:arial=
,helvetica,sans-serif;font-size:13px">I thought there should be an easy por=
table way to add stack information to a std::exception. Does anybody have s=
ome ideas?</div></div><div style=3D"margin:0px;padding:0px;border:0px;font-=
family:arial,helvetica,sans-serif;font-size:13px"><br></div><div>(end)</div=
><div><br></div><div>It then morphed into a discussion of just getting the =
stack trace, not necessarily in an exception context, but some of what we d=
iscussed there, in particular the separation of capture/parse functionality=
, is applicable in any case.</div><div><br></div><div>In this new thread, m=
ore than one participant have mentioned they they find it undesirable to ha=
ve exceptions carry the weight of stack tracing.</div><div><br></div><div>T=
his sentiment is understandable, but I have the following two points to be =
considered in this respect:</div><div><br></div><div>1. Is the performance =
of exception handling really an overriding concern? It is very easy to over=
generalise, of course, but I'd say it is widely understood[1] that exce=
ptions are not really a mechanism to be used to control execution under &qu=
ot;normal circumstances", in which case worrying more about performanc=
e than utility seems strange.=C2=A0</div><div><br></div><div><div>2. Is it =
true that "the weight of stack tracing" is really that much weigh=
t to carry? Modern C++ implementations essentially just need only the instr=
uction pointer to describe fully where the exception originated[2, 3]. Comp=
ared to the cost of unwinding the stack in those implementations, the cost =
of storing just one pointer in the exception structure seems strictly negli=
gible.</div><div><br></div><div>Cheers,</div></div><div>V.</div><div><br></=
div><div>[1] <a href=3D"http://www.stroustrup.com/bs_faq2.html#exceptions-w=
hat-not">http://www.stroustrup.com/bs_faq2.html#exceptions-what-not</a><br>=
</div><div>[2]=C2=A0<a href=3D"http://stackoverflow.com/a/18672447">http://=
stackoverflow.com/a/18672447</a><br></div><div>[3] <a href=3D"https://msdn.=
microsoft.com/en-us/library/8ydc79k6.aspx">https://msdn.microsoft.com/en-us=
/library/8ydc79k6.aspx</a><br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAA7YVg29wob5_hM55%3DQ2O6Xc96SU-bsGQh=
ePt0W0EX28cQWhuw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg29wob5_h=
M55%3DQ2O6Xc96SU-bsGQhePt0W0EX28cQWhuw%40mail.gmail.com</a>.<br />
--001a1141169e5a53ba0539001a74--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 1 Aug 2016 07:02:23 -0700 (PDT)
Raw View
------=_Part_36_688770467.1470060143167
Content-Type: multipart/alternative;
boundary="----=_Part_37_2126814913.1470060143167"
------=_Part_37_2126814913.1470060143167
Content-Type: text/plain; charset=UTF-8
On Monday, August 1, 2016 at 6:31:31 AM UTC-4, Viacheslav Usov wrote:
>
> It looks like this thread started just like this one:
> https://groups.google.com/a/isocpp.org/forum/#!topic/std-discussion/A17G1ram9ns
>
> To quote:
>
> To find the root cause of bugs easier, it is very helpful to have stack
> trace from the location where the exception is thrown.
>
> Surely I can throw an exception class derived from std:exception and use
> backtrace on Linux or StackWalk64 on Windows, with the appropriate symbols
> (=> not portable),
> or have a try catch "everywhere" and add file and line information (=> too
> much code to add),
> or not to catch the exception at all and let the Operation System write
> the dump file(=>not portable, some exceptions can be handled inside the
> program).
>
> I thought there should be an easy portable way to add stack information to
> a std::exception. Does anybody have some ideas?
>
> (end)
>
> It then morphed into a discussion of just getting the stack trace, not
> necessarily in an exception context, but some of what we discussed there,
> in particular the separation of capture/parse functionality, is applicable
> in any case.
>
> In this new thread, more than one participant have mentioned they they
> find it undesirable to have exceptions carry the weight of stack tracing.
>
> This sentiment is understandable, but I have the following two points to
> be considered in this respect:
>
> 1. Is the performance of exception handling really an overriding concern?
>
.... *Yes*!
One of the primary reasons why SG14 wants to find alternatives to
exceptions for C++ errors
<http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0364r0.pdf> is
because exceptions *cost too much* at runtime. There are whole classes of
applications that are built without exception handling of any kind,
primarily because it's too expensive. You now want to take an already
costly tool and make it *more expensive*. That's moving in the wrong
direction.
It is very easy to overgeneralise, of course, but I'd say it is widely
> understood[1] that exceptions are not really a mechanism to be used to
> control execution under "normal circumstances", in which case worrying more
> about performance than utility seems strange.
>
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/26e65947-b2a6-4786-9f8a-3a8307ff48a2%40isocpp.org.
------=_Part_37_2126814913.1470060143167
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, August 1, 2016 at 6:31:31 AM UTC-4, Viacheslav =
Usov wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">It=
looks like this thread started just like this one: <a href=3D"https://grou=
ps.google.com/a/isocpp.org/forum/#!topic/std-discussion/A17G1ram9ns" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'https://groups=
..google.com/a/isocpp.org/forum/#!topic/std-discussion/A17G1ram9ns';retu=
rn true;" onclick=3D"this.href=3D'https://groups.google.com/a/isocpp.or=
g/forum/#!topic/std-discussion/A17G1ram9ns';return true;">https://group=
s.google.com/a/<wbr>isocpp.org/forum/#!topic/std-<wbr>discussion/A17G1ram9n=
s</a><div><br></div><div>To quote:</div><div><br></div><div><div style=3D"m=
argin:0px;padding:0px;border:0px;font-family:arial,helvetica,sans-serif;fon=
t-size:13px">To find the root cause of bugs easier, it is very helpful to h=
ave stack trace from the location where the exception is thrown.<br></div><=
div style=3D"margin:0px;padding:0px;border:0px;font-family:arial,helvetica,=
sans-serif;font-size:13px"><br></div><div style=3D"margin:0px;padding:0px;b=
order:0px;font-family:arial,helvetica,sans-serif;font-size:13px">Surely I c=
an throw an exception class derived from std:exception and use backtrace on=
Linux or StackWalk64 on Windows, with the appropriate symbols (=3D> not=
portable),=C2=A0<br><div style=3D"margin:0px;padding:0px;border:0px">or ha=
ve a try catch "everywhere" and add file and line information (=
=3D> too much code to add),=C2=A0</div></div><div style=3D"margin:0px;pa=
dding:0px;border:0px;font-family:arial,helvetica,sans-serif;font-size:13px"=
>or not to catch the exception at all and let the Operation System write th=
e dump file(=3D>not portable, some exceptions can be handled inside the =
program).</div><div style=3D"margin:0px;padding:0px;border:0px;font-family:=
arial,helvetica,sans-serif;font-size:13px"><br></div><div style=3D"margin:0=
px;padding:0px;border:0px;font-family:arial,helvetica,sans-serif;font-size:=
13px">I thought there should be an easy portable way to add stack informati=
on to a std::exception. Does anybody have some ideas?</div></div><div style=
=3D"margin:0px;padding:0px;border:0px;font-family:arial,helvetica,sans-seri=
f;font-size:13px"><br></div><div>(end)</div><div><br></div><div>It then mor=
phed into a discussion of just getting the stack trace, not necessarily in =
an exception context, but some of what we discussed there, in particular th=
e separation of capture/parse functionality, is applicable in any case.</di=
v><div><br></div><div>In this new thread, more than one participant have me=
ntioned they they find it undesirable to have exceptions carry the weight o=
f stack tracing.</div><div><br></div><div>This sentiment is understandable,=
but I have the following two points to be considered in this respect:</div=
><div><br></div><div>1. Is the performance of exception handling really an =
overriding concern?</div></div></blockquote><div><br>... <i>Yes</i>!<br><br=
>One of the primary reasons why <a href=3D"http://www.open-std.org/JTC1/SC2=
2/WG21/docs/papers/2016/p0364r0.pdf">SG14 wants to find alternatives to exc=
eptions for C++ errors</a> is because exceptions <i>cost too much</i> at ru=
ntime. There are whole classes of applications that are built without excep=
tion handling of any kind, primarily because it's too expensive. You no=
w want to take an already costly tool and make it <i>more expensive</i>. Th=
at's moving in the wrong direction.<br><br></div><blockquote class=3D"g=
mail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc sol=
id;padding-left: 1ex;"><div dir=3D"ltr"><div>It is very easy to overgeneral=
ise, of course, but I'd say it is widely understood[1] that exceptions =
are not really a mechanism to be used to control execution under "norm=
al circumstances", in which case worrying more about performance than =
utility seems strange.</div></div></blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/26e65947-b2a6-4786-9f8a-3a8307ff48a2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/26e65947-b2a6-4786-9f8a-3a8307ff48a2=
%40isocpp.org</a>.<br />
------=_Part_37_2126814913.1470060143167--
------=_Part_36_688770467.1470060143167--
.
Author: Wil Evers <wileversmod@gmail.com>
Date: Mon, 1 Aug 2016 07:19:23 -0700 (PDT)
Raw View
------=_Part_404_667025328.1470061164030
Content-Type: multipart/alternative;
boundary="----=_Part_405_1187199459.1470061164030"
------=_Part_405_1187199459.1470061164030
Content-Type: text/plain; charset=UTF-8
On Monday, August 1, 2016 at 6:16:54 AM UTC+2, Thiago Macieira wrote:
> What's NDEBUG? I never set that in my programs, since I almost never need
> them. I'm being serious, I never set them. Qt doesn't react to NDEBUG and
> since all my programs are written with Qt...
>
> No, Nicol is right: there's no such thing as "debug mode" in the standard.
> Please find some other condition to enable your feature in.
>
You should know what NDEBUG is; it is a standard C++ feature. #defining
NDEBUG disables assertions.
Given that, it seems quite reasonable to think of a build where NDEBUG is
not defined as a "debug build". Even if Qt doesn't react to NDEBUG,
conforming user code can.
Wil
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/15763a31-efa1-47e3-b206-e91056c19251%40isocpp.org.
------=_Part_405_1187199459.1470061164030
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, August 1, 2016 at 6:16:54 AM UTC+2, Thiago Maci=
eira wrote:<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Wh=
at's NDEBUG? I never set that in my programs, since I almost never need=
=20
<br>them. I'm being serious, I never set them. Qt doesn't react to =
NDEBUG and=20
<br>since all my programs are written with Qt...
<br>
<br>No, Nicol is right: there's no such thing as "debug mode"=
in the standard.=20
<br>Please find some other condition to enable your feature in.
<br></blockquote><div><br>You should know what NDEBUG is; it is a standard =
C++ feature. #defining NDEBUG disables assertions. <br><br>Given that, it s=
eems quite reasonable to think of a build where NDEBUG is not defined as a =
"debug build". Even if Qt doesn't react to NDEBUG, conforming=
user code can.<br><br>Wil<br><br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/15763a31-efa1-47e3-b206-e91056c19251%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/15763a31-efa1-47e3-b206-e91056c19251=
%40isocpp.org</a>.<br />
------=_Part_405_1187199459.1470061164030--
------=_Part_404_667025328.1470061164030--
.
Author: Viacheslav Usov <via.usov@gmail.com>
Date: Mon, 1 Aug 2016 16:20:14 +0200
Raw View
--001a1141169e92627f0539034ce7
Content-Type: text/plain; charset=UTF-8
On Mon, Aug 1, 2016 at 4:02 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> One of the primary reasons why SG14 wants to find alternatives to
exceptions for C++ errors
<http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0364r0.pdf> is
because exceptions *cost too much* at runtime.
A. If you have read and understood the paper, then you misrepresent it
purposely[1].
B. Otherwise, go do your homework.
Cheers,
V.
[1] "Still, given this rule of thumb, and the way game programmers have
been doing things (i.e., not using exceptions at all), I think it is the
second item that is more important for SG14: The cost of exceptions in
programs that never, or rarely, throw exceptions. Most existing game code
fits in this second category."
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg2LLegKqt_1ofhN%2BP6EYiD-u0eKG3hywoPqO2PRUCKq_w%40mail.gmail.com.
--001a1141169e92627f0539034ce7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Aug 1, 2016 at 4:02 PM, Nicol Bolas <span dir=3D"ltr"><<a href=3D"ma=
ilto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>></sp=
an> wrote:<br><div><br></div><div>> One of the primary reasons why <a hr=
ef=3D"http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0364r0.pdf" =
target=3D"_blank">SG14 wants to find alternatives to exceptions for C++ err=
ors</a> is because exceptions <i>cost too much</i> at runtime.</div><div><b=
r></div><div>A. If you have read and understood the paper, then you misrepr=
esent it purposely[1].</div><div><br></div><div>B. Otherwise, go do your ho=
mework.</div><div><br></div><div>Cheers,</div><div>V.</div><div><br></div><=
div>[1] "Still, given this rule of thumb, and the way game programmers=
have been doing things (i.e., not using exceptions at all), I think it is =
the second item that is more important for SG14: The cost of exceptions in =
programs that never, or rarely, throw exceptions. Most existing game code f=
its in this second category."</div></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAA7YVg2LLegKqt_1ofhN%2BP6EYiD-u0eKG3=
hywoPqO2PRUCKq_w%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg2LLegKqt=
_1ofhN%2BP6EYiD-u0eKG3hywoPqO2PRUCKq_w%40mail.gmail.com</a>.<br />
--001a1141169e92627f0539034ce7--
.
Author: Tom Honermann <tom@honermann.net>
Date: Mon, 1 Aug 2016 10:21:58 -0400
Raw View
On 8/1/2016 6:31 AM, Viacheslav Usov wrote:
> 2. Is it true that "the weight of stack tracing" is really that much
> weight to carry? Modern C++ implementations essentially just need only
> the instruction pointer to describe fully where the exception
> originated[2, 3]. Compared to the cost of unwinding the stack in those
> implementations, the cost of storing just one pointer in the exception
> structure seems strictly negligible.
How would you make use of the pointer stored in the exception
structure? It will have been invalidated once a catch handler starts
executing as the stack will have been unwound already. Likewise,
attempts to use it during stack unwinding (e.g., from a destructor) are
similarly nonviable. Making use of it would require additional features
analogous to exception filters as provided by Microsoft's Structured
Exception Handling (SEH) so that it can be queried and used prior to
stack unwinding.
Tom.
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1f47dab8-e238-d01f-f7c5-7c84399b78cf%40honermann.net.
.
Author: Viacheslav Usov <via.usov@gmail.com>
Date: Mon, 1 Aug 2016 16:43:34 +0200
Raw View
--001a114065c0054b83053903a099
Content-Type: text/plain; charset=UTF-8
On Mon, Aug 1, 2016 at 4:21 PM, Tom Honermann <tom@honermann.net> wrote:
> On 8/1/2016 6:31 AM, Viacheslav Usov wrote:
>
>> 2. Is it true that "the weight of stack tracing" is really that much
>> weight to carry? Modern C++ implementations essentially just need only the
>> instruction pointer to describe fully where the exception originated[2, 3].
>> Compared to the cost of unwinding the stack in those implementations, the
>> cost of storing just one pointer in the exception structure seems strictly
>> negligible.
>>
>
> How would you make use of the pointer stored in the exception structure?
> It will have been invalidated once a catch handler starts executing as the
> stack will have been unwound already. Likewise, attempts to use it during
> stack unwinding (e.g., from a destructor) are similarly nonviable. Making
> use of it would require additional features analogous to exception filters
> as provided by Microsoft's Structured Exception Handling (SEH) so that it
> can be queried and used prior to stack unwinding.
I see that I mistyped my message. It should read "... just one pointer per
frame ...". The chain of those instruction pointers is established by the
implementation while it unwinds the stack, as described in the material
referenced in my previous message. I would not even be surprised if certain
implementations kept that list till the exception is fully handled,
specifically to aid debugging, in which case the cost of accessing the info
would be zero.
In the above, I assume that the capture/parse separation, as discussed in
the previous thread, is in effect.
Cheers,
V.
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg2xNWrR4Roe4vEBiOqFO2BXyBvspCbvms%2B_vexJK7L7Vg%40mail.gmail.com.
--001a114065c0054b83053903a099
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Aug 1, 2016 at 4:21 PM, Tom Honermann <span dir=3D"ltr"><<a href=3D"=
mailto:tom@honermann.net" target=3D"_blank">tom@honermann.net</a>></span=
> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
..8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(20=
4,204,204);padding-left:1ex">On 8/1/2016 6:31 AM, Viacheslav Usov wrote:<br=
>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);p=
adding-left:1ex">
2. Is it true that "the weight of stack tracing" is really that m=
uch weight to carry? Modern C++ implementations essentially just need only =
the instruction pointer to describe fully where the exception originated[2,=
3]. Compared to the cost of unwinding the stack in those implementations, =
the cost of storing just one pointer in the exception structure seems stric=
tly negligible.<br>
</blockquote>
<br>
How would you make use of the pointer stored in the exception structure?=C2=
=A0 It will have been invalidated once a catch handler starts executing as =
the stack will have been unwound already. Likewise, attempts to use it duri=
ng stack unwinding (e.g., from a destructor) are similarly nonviable.=C2=A0=
Making use of it would require additional features analogous to exception =
filters as provided by Microsoft's Structured Exception Handling (SEH) =
so that it can be queried and used prior to stack unwinding.</blockquote><d=
iv><br></div><div>I see that I mistyped my message. It should read "..=
.. just one pointer per frame ...". The chain of those instruction poin=
ters is established by the implementation while it unwinds the stack, as de=
scribed in the material referenced in my previous message. I would not even=
be surprised if certain implementations kept that list till the exception =
is fully handled, specifically to aid debugging, in which case the cost of =
accessing the info would be zero.</div><div><br></div><div>In the above, I =
assume that the capture/parse separation, as discussed in the previous thre=
ad, is in effect.</div><div><br></div><div>Cheers,</div><div>V.</div><div><=
br></div></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAA7YVg2xNWrR4Roe4vEBiOqFO2BXyBvspCbv=
ms%2B_vexJK7L7Vg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg2xNWrR4R=
oe4vEBiOqFO2BXyBvspCbvms%2B_vexJK7L7Vg%40mail.gmail.com</a>.<br />
--001a114065c0054b83053903a099--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 1 Aug 2016 07:45:38 -0700 (PDT)
Raw View
------=_Part_1000_378706333.1470062738344
Content-Type: multipart/alternative;
boundary="----=_Part_1001_304484694.1470062738344"
------=_Part_1001_304484694.1470062738344
Content-Type: text/plain; charset=UTF-8
On Monday, August 1, 2016 at 10:20:18 AM UTC-4, Viacheslav Usov wrote:
>
> On Mon, Aug 1, 2016 at 4:02 PM, Nicol Bolas <jmck...@gmail.com
> <javascript:>> wrote:
>
> > One of the primary reasons why SG14 wants to find alternatives to
> exceptions for C++ errors
> <http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0364r0.pdf> is
> because exceptions *cost too much* at runtime.
>
> A. If you have read and understood the paper, then you misrepresent it
> purposely[1].
>
> B. Otherwise, go do your homework.
>
> Cheers,
> V.
>
> [1] "Still, given this rule of thumb, and the way game programmers have
> been doing things (i.e., not using exceptions at all), I think it is the
> second item that is more important for SG14: The cost of exceptions in
> programs that never, or rarely, throw exceptions. Most existing game code
> fits in this second category."
>
And the primary reason "most existing game code fits in this second
category" is *because* of the first category.
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/d60c51c0-25c2-4542-997d-bd8378917d63%40isocpp.org.
------=_Part_1001_304484694.1470062738344
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Monday, August 1, 2016 at 10:20:18 AM UTC-4, Vi=
acheslav Usov wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div><div class=3D"gmail_quote">On Mon, Aug 1, 2016 at 4:02 PM, Ni=
col Bolas <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" g=
df-obfuscated-mailto=3D"uIGAlkmsBgAJ" rel=3D"nofollow" onmousedown=3D"this.=
href=3D'javascript:';return true;" onclick=3D"this.href=3D'java=
script:';return true;">jmck...@gmail.com</a>></span> wrote:<br><div>=
<br></div><div>> One of the primary reasons why <a href=3D"http://www.op=
en-std.org/JTC1/SC22/WG21/docs/papers/2016/p0364r0.pdf" target=3D"_blank" r=
el=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google.com/url?q=
\x3dhttp%3A%2F%2Fwww.open-std.org%2FJTC1%2FSC22%2FWG21%2Fdocs%2Fpapers%2F20=
16%2Fp0364r0.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHIQHYM_nLgci2TBZkb=
rEeyef62Sw';return true;" onclick=3D"this.href=3D'http://www.google=
..com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2FJTC1%2FSC22%2FWG21%2Fdocs%2Fp=
apers%2F2016%2Fp0364r0.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHIQHYM_n=
Lgci2TBZkbrEeyef62Sw';return true;">SG14 wants to find alternatives to =
exceptions for C++ errors</a> is because exceptions <i>cost too much</i> at=
runtime.</div><div><br></div><div>A. If you have read and understood the p=
aper, then you misrepresent it purposely[1].</div><div><br></div><div>B. Ot=
herwise, go do your homework.</div><div><br></div><div>Cheers,</div><div>V.=
</div><div><br></div><div>[1] "Still, given this rule of thumb, and th=
e way game programmers have been doing things (i.e., not using exceptions a=
t all), I think it is the second item that is more important for SG14: The =
cost of exceptions in programs that never, or rarely, throw exceptions. Mos=
t existing game code fits in this second category."</div></div></div><=
/div></blockquote><div><br>And the primary reason "most existing game =
code fits in this second category" is <i>because</i> of the first cate=
gory.<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/d60c51c0-25c2-4542-997d-bd8378917d63%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d60c51c0-25c2-4542-997d-bd8378917d63=
%40isocpp.org</a>.<br />
------=_Part_1001_304484694.1470062738344--
------=_Part_1000_378706333.1470062738344--
.
Author: Tom Honermann <tom@honermann.net>
Date: Mon, 1 Aug 2016 10:46:02 -0400
Raw View
On 7/31/2016 2:49 AM, redradist@gmail.com wrote:
> I have prepared my first proposal. Please, dont bit hard for missing
> details.
> You can find it in attachment.
Regarding implementability in section V: StackWalk64 and Linux
backtrace() do not constitute a proof-of-concept implementation since
they don't actually implement the interface you proposed.
I do think a standard method of obtaining a stack trace would be
useful. I've worked on multiple products that have rolled their own and
the results have not been very good. The most successful approach
involved the process spawning a debugger to run a script to attach back
to itself to produce a stack trace. In this case, the desire for a
stack trace was only present when the process was going to terminate
anyway, so the (high) performance cost of spawning a debugger was
acceptable.
There are many ABI specific details that make obtaining a stack trace
range from difficult to impossible depending on how you define what a
valid stack trace is. On x86, if you compile with frame pointer
omission, you're not going to get a useful stack trace. On Windows, if
you don't have the right debug symbols available (which you won't in a
production environment), you're not going to get a useful stack trace
(you might get one that you can later use to reconstruct a useful stack
trace later when debug symbols are available). When functions are
inlined by the compiler, or functions use tail recursion, then you're
going to have missing frames in your stack trace which will make them
look invalid (even though they aren't). Assuming an implementation
based on Microsoft's StackWalk64 with an environment properly configured
for debug symbols, construction of a useful stack trace will require
connecting to Microsoft's symbol server, possibly accepting an EULA (I'm
not joking, that is required today), downloading symbol (.pdb) files
somewhere, loading them into the process, and then, finally, walking the
stack.
I think tying a stack trace to the C++ exception system is a non-starter
without some ability to execute code without first unwinding the stack.
See my other response to Viacheslav Usov.
Finally, if you do want to propose a standard interface for walking the
stack and/or producing a stack trace, I recommend you survey many more
platforms before coming back with a proposal (and include evaluations of
the capabilities of those platforms). The libunwind variants provide
the most comprehensive cross platform stack walking support I've seen,
so basing the interface on what is provided by them seems like a good
starting place.
Tom.
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/d000d636-e805-f2fe-5c2c-b06e0208c0a9%40honermann.net.
.
Author: Tom Honermann <tom@honermann.net>
Date: Mon, 1 Aug 2016 10:52:22 -0400
Raw View
This is a multi-part message in MIME format.
--------------C0E8CB0524C7F5C22D3E85BF
Content-Type: text/plain; charset=UTF-8; format=flowed
On 8/1/2016 10:43 AM, Viacheslav Usov wrote:
> On Mon, Aug 1, 2016 at 4:21 PM, Tom Honermann <tom@honermann.net
> <mailto:tom@honermann.net>> wrote:
>
> On 8/1/2016 6:31 AM, Viacheslav Usov wrote:
>
> 2. Is it true that "the weight of stack tracing" is really
> that much weight to carry? Modern C++ implementations
> essentially just need only the instruction pointer to describe
> fully where the exception originated[2, 3]. Compared to the
> cost of unwinding the stack in those implementations, the cost
> of storing just one pointer in the exception structure seems
> strictly negligible.
>
>
> How would you make use of the pointer stored in the exception
> structure? It will have been invalidated once a catch handler
> starts executing as the stack will have been unwound already.
> Likewise, attempts to use it during stack unwinding (e.g., from a
> destructor) are similarly nonviable. Making use of it would
> require additional features analogous to exception filters as
> provided by Microsoft's Structured Exception Handling (SEH) so
> that it can be queried and used prior to stack unwinding.
>
>
> I see that I mistyped my message. It should read "... just one pointer
> per frame ...". The chain of those instruction pointers is established
> by the implementation while it unwinds the stack, as described in the
> material referenced in my previous message. I would not even be
> surprised if certain implementations kept that list till the exception
> is fully handled, specifically to aid debugging, in which case the
> cost of accessing the info would be zero.
So, you would require dynamic memory allocation, or require a thread
specific statically sized buffer (multiple buffers actually since
exceptions can nest) that limits the number of supported frames, in
order to throw an exception?
Tom.
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b7eb829d-1527-0008-71fc-ab0931471d4c%40honermann.net.
--------------C0E8CB0524C7F5C22D3E85BF
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<div class=3D"moz-cite-prefix">On 8/1/2016 10:43 AM, Viacheslav Usov
wrote:<br>
</div>
<blockquote
cite=3D"mid:CAA7YVg2xNWrR4Roe4vEBiOqFO2BXyBvspCbvms+_vexJK7L7Vg@mail.gmail.=
com"
type=3D"cite">
<div dir=3D"ltr">
<div class=3D"gmail_extra">
<div class=3D"gmail_quote">On Mon, Aug 1, 2016 at 4:21 PM, Tom
Honermann <span dir=3D"ltr"><<a moz-do-not-send=3D"true"
href=3D"mailto:tom@honermann.net" target=3D"_blank">tom@hon=
ermann.net</a>></span>
wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(2=
04,204,204);padding-left:1ex">On
8/1/2016 6:31 AM, Viacheslav Usov wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(2=
04,204,204);padding-left:1ex">
2. Is it true that "the weight of stack tracing" is
really that much weight to carry? Modern C++
implementations essentially just need only the
instruction pointer to describe fully where the
exception originated[2, 3]. Compared to the cost of
unwinding the stack in those implementations, the cost
of storing just one pointer in the exception structure
seems strictly negligible.<br>
</blockquote>
<br>
How would you make use of the pointer stored in the
exception structure?=C2=A0 It will have been invalidated once=
a
catch handler starts executing as the stack will have been
unwound already. Likewise, attempts to use it during stack
unwinding (e.g., from a destructor) are similarly
nonviable.=C2=A0 Making use of it would require additional
features analogous to exception filters as provided by
Microsoft's Structured Exception Handling (SEH) so that it
can be queried and used prior to stack unwinding.</blockquote=
>
<div><br>
</div>
<div>I see that I mistyped my message. It should read "...
just one pointer per frame ...". The chain of those
instruction pointers is established by the implementation
while it unwinds the stack, as described in the material
referenced in my previous message. I would not even be
surprised if certain implementations kept that list till
the exception is fully handled, specifically to aid
debugging, in which case the cost of accessing the info
would be zero.</div>
</div>
</div>
</div>
</blockquote>
So, you would require dynamic memory allocation, or require a thread
specific statically sized buffer (multiple buffers actually since
exceptions can nest) that limits the number of supported frames, in
order to throw an exception?<br>
<br>
Tom.<br>
</body>
</html>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/b7eb829d-1527-0008-71fc-ab0931471d4c%=
40honermann.net?utm_medium=3Demail&utm_source=3Dfooter">https://groups.goog=
le.com/a/isocpp.org/d/msgid/std-proposals/b7eb829d-1527-0008-71fc-ab0931471=
d4c%40honermann.net</a>.<br />
--------------C0E8CB0524C7F5C22D3E85BF--
.
Author: Viacheslav Usov <via.usov@gmail.com>
Date: Mon, 1 Aug 2016 17:07:51 +0200
Raw View
--001a114a72fed97d41053903f646
Content-Type: text/plain; charset=UTF-8
On Mon, Aug 1, 2016 at 4:45 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> And the primary reason "most existing game code fits in this second
category" is *because* of the first category.
You have some very special idea on the meaning of "primary". The document
talks at length how exceptions are difficult for exception-unaware code and
how making code exception aware is such an impossible task; how the
exception support data/code bloats the application and interacts badly with
the branch predictor. Your "primary reason" is mentioned in passing.
Cheers,
V.
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg0bKkunbEL70AAXSZeiR%3DCiUTvwa%3Db%3DYjH5Lir3zaoZBw%40mail.gmail.com.
--001a114a72fed97d41053903f646
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Aug 1, 2016 at 4:45 PM, Nicol Bolas <span dir=3D"ltr"><<a href=3D"ma=
ilto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>></sp=
an> wrote:<br><div><br></div><div>> And the primary reason "most ex=
isting game code fits in this second category" is <i>because</i> of th=
e first category.</div><div><br></div><div>You have some very special idea =
on the meaning of "primary". The document talks at length how exc=
eptions are difficult for exception-unaware code and how making code except=
ion aware is such an impossible task; how the exception support data/code b=
loats the application and interacts badly with the branch predictor. Your &=
quot;primary reason" is mentioned in passing.</div><div><br></div><div=
>Cheers,</div><div>V.</div><div><br></div></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAA7YVg0bKkunbEL70AAXSZeiR%3DCiUTvwa%=
3Db%3DYjH5Lir3zaoZBw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg0bKk=
unbEL70AAXSZeiR%3DCiUTvwa%3Db%3DYjH5Lir3zaoZBw%40mail.gmail.com</a>.<br />
--001a114a72fed97d41053903f646--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Mon, 01 Aug 2016 08:33:57 -0700
Raw View
On segunda-feira, 1 de agosto de 2016 07:19:23 PDT Wil Evers wrote:
> You should know what NDEBUG is; it is a standard C++ feature. #defining
> NDEBUG disables assertions.
I was slightly exagerating my ignorance. But it has happened, more than once,
that I see assert() left in my release code until I remember that I needed to
set it.
> Given that, it seems quite reasonable to think of a build where NDEBUG is
> not defined as a "debug build". Even if Qt doesn't react to NDEBUG,
> conforming user code can.
We could have inline features and other macros that react to NDEBUG. But that
can't affect code generation by the compiler.
We could have the opposite though: compiler switches that affect code
generation get a predefined macro added or suppressed.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/20752456.l1X6niOAoP%40tjmaciei-mobl1.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Mon, 01 Aug 2016 08:57:04 -0700
Raw View
On segunda-feira, 1 de agosto de 2016 07:54:36 PDT
loic.actarus.joly@numericable.fr wrote:
> - It is easy to implement, since a compiler could just return an empty
> string, everything else being a question of QOI.
Then someone should write a paper that standardises <execinfo.h> or something
very similar to it.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/3215554.EEeHd6nsX8%40tjmaciei-mobl1.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Mon, 01 Aug 2016 08:51:32 -0700
Raw View
On segunda-feira, 1 de agosto de 2016 10:46:02 PDT Tom Honermann wrote:
> I've worked on multiple products that have rolled their own and
> the results have not been very good. The most successful approach
> involved the process spawning a debugger to run a script to attach back
> to itself to produce a stack trace.
Off-topic, but explaining:
That's because the backtrace() function in <execinfo.h> only reads the symbol
table that is avaialble to the dynamic linker. That table lacks completely the
symbols from the executable, as nothing usually links to the executable, and
all the internal functions (static and hidden visibility).
The debugger, on the other hand, reads the debug symbols, which on modern
Linux distros, are not contained in the libraries themselves, but in a
separate file in /usr/lib/debug. Or, in the case of Microsoft debuggers, it can
also download the symbol tables from Microsoft servers. Moreover, debugger-
produced backtraces are superior because they often contain the values of
local variables and parameters to functions, file names and line numbers.
I have solved numerous problems just by following the value of "this" in the
parameter list, or by noticing pointer values that shouldn't exist.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5297545.FfNoM3ARHf%40tjmaciei-mobl1.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Mon, 01 Aug 2016 08:36:16 -0700
Raw View
On domingo, 31 de julho de 2016 21:26:58 PDT =D0=94=D0=B5=D0=BD=D0=B8=D1=81=
=D0=9A=D0=BE=D1=82=D0=BE=D0=B2 wrote:
> =D0=BF=D0=BE=D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D1=8C=D0=BD=D0=B8=D0=BA, 1 =D0=
=B0=D0=B2=D0=B3=D1=83=D1=81=D1=82=D0=B0 2016 =D0=B3., 7:16:54 UTC+3 =D0=BF=
=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Thiago M=
acieira
> > This is useful, but the feature already exists. We don't need what you'=
re
> > suggestion because it cannot be standardised and it will just be a poor
> > comparison to the tools that already exist.
>=20
> Could you enumerate them ? For different compilers, please ?
> And how catch for different compilers stack in moment when exception was
> thrown ?
With gdb, as others have told you, the command is "catch throw".=20
With older versions of gdb nor supporting that or other debuggers for the s=
ame=20
ABI (the IA-64 portable ABI), put a breakpoint in __cxa_throw.
For MSVC, I don't know, never having needed that. I don't throw exceptions =
in=20
my code. But when other mistakes happen in my code, the debugger is very=20
helpful.
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/2526338.ptYJhz87nK%40tjmaciei-mobl1.
.
Author: Viacheslav Usov <via.usov@gmail.com>
Date: Mon, 1 Aug 2016 17:40:13 +0200
Raw View
--001a113fb874a1e6050539046a3d
Content-Type: text/plain; charset=UTF-8
On Mon, Aug 1, 2016 at 4:52 PM, Tom Honermann <tom@honermann.net> wrote:
> So, you would require dynamic memory allocation, or require a thread
specific statically sized buffer (multiple buffers actually since
exceptions can nest) that limits the number of supported frames, in order
to throw an exception?
Memory allocation for exception objects is already explicitly unspecified
by [except.throw], so discussing this further would be discussing how a
*hypothetical* implementation *could* optimise that. Are we going to
achieve anything substantial by going there?
Cheers,
V.
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg2t1sLK5oHW0bTq28rMHtvnTp5mGBmZVWuM0dGFkR2f1Q%40mail.gmail.com.
--001a113fb874a1e6050539046a3d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Aug 1, 2016 at 4:52 PM, Tom Honermann <span dir=3D"ltr"><<a href=3D"=
mailto:tom@honermann.net" target=3D"_blank">tom@honermann.net</a>></span=
> wrote:<br><div><br></div><div>> So, you would require dynamic memory a=
llocation, or require a thread
specific statically sized buffer (multiple buffers actually since
exceptions can nest) that limits the number of supported frames, in
order to throw an exception?</div><div><br></div><div>Memory allocation=
for exception objects is already explicitly unspecified by [except.throw],=
so discussing this further would be discussing how a <i>hypothetical</i> i=
mplementation <i>could</i> optimise that. Are we going to achieve anything =
substantial by going there?</div><div><br></div><div>Cheers,</div><div>V.</=
div><div><br></div></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAA7YVg2t1sLK5oHW0bTq28rMHtvnTp5mGBmZ=
VWuM0dGFkR2f1Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg2t1sLK5oHW=
0bTq28rMHtvnTp5mGBmZVWuM0dGFkR2f1Q%40mail.gmail.com</a>.<br />
--001a113fb874a1e6050539046a3d--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Mon, 01 Aug 2016 08:41:09 -0700
Raw View
On domingo, 31 de julho de 2016 23:54:11 PDT gmisocpp@gmail.com wrote:
> If this means someone could configure a program to get a basic stack trace
> on program failure and also be able to dump that on demand and all without
> having to know anything special about the platform or compiler or debug
> options and without a lot of stress on vendors to power it, what's so
> unreasonable?
You know what could be a reasonable suggestion:
a) add a function std::dump_backtrace, whose behaviour is suggested by the
standard, but a compliant implementation could simply do nothing.
b) let the user do:
std::set_terminate_handler(std::dump_backtrace);
Note that this won't catch Unix signals, like SIGSEGV or SIGABRT. If you want
that, you should instead use signal(2) or sigaction(2). That will also catch
uncaught exceptions, since the termination handler usually raises SIGABRT.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5594726.EyycHGBq91%40tjmaciei-mobl1.
.
Author: Tom Honermann <tom@honermann.net>
Date: Mon, 1 Aug 2016 12:24:06 -0400
Raw View
This is a multi-part message in MIME format.
--------------06D4D1A90900D850B6FB89EC
Content-Type: text/plain; charset=UTF-8; format=flowed
On 8/1/2016 11:40 AM, Viacheslav Usov wrote:
> On Mon, Aug 1, 2016 at 4:52 PM, Tom Honermann <tom@honermann.net
> <mailto:tom@honermann.net>> wrote:
>
> > So, you would require dynamic memory allocation, or require a thread
> specific statically sized buffer (multiple buffers actually since
> exceptions can nest) that limits the number of supported frames, in
> order to throw an exception?
>
> Memory allocation for exception objects is already explicitly
> unspecified by [except.throw], so discussing this further would be
> discussing how a /hypothetical/ implementation /could/ optimise that.
Yes, but today, the amount of memory required for the exception object
is statically knowable. That would no longer be true if the depth of
the stack at the point of the throw were a consideration.
> Are we going to achieve anything substantial by going there?
Probably not.
Tom.
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9005e708-9f4d-fb56-9ded-bcb255b9dcef%40honermann.net.
--------------06D4D1A90900D850B6FB89EC
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<div class=3D"moz-cite-prefix">On 8/1/2016 11:40 AM, Viacheslav Usov
wrote:<br>
</div>
<blockquote
cite=3D"mid:CAA7YVg2t1sLK5oHW0bTq28rMHtvnTp5mGBmZVWuM0dGFkR2f1Q@mail.gmail.=
com"
type=3D"cite">
<div dir=3D"ltr">
<div class=3D"gmail_extra">
<div class=3D"gmail_quote">On Mon, Aug 1, 2016 at 4:52 PM, Tom
Honermann <span dir=3D"ltr"><<a moz-do-not-send=3D"true"
href=3D"mailto:tom@honermann.net" target=3D"_blank">tom@hon=
ermann.net</a>></span>
wrote:<br>
<div><br>
</div>
<div>> So, you would require dynamic memory allocation,
or require a thread specific statically sized buffer
(multiple buffers actually since exceptions can nest) that
limits the number of supported frames, in order to throw
an exception?</div>
<div><br>
</div>
<div>Memory allocation for exception objects is already
explicitly unspecified by [except.throw], so discussing
this further would be discussing how a <i>hypothetical</i>
implementation <i>could</i> optimise that.</div>
</div>
</div>
</div>
</blockquote>
Yes, but today, the amount of memory required for the exception
object is statically knowable.=C2=A0 That would no longer be true if th=
e
depth of the stack at the point of the throw were a consideration.<br>
<blockquote
cite=3D"mid:CAA7YVg2t1sLK5oHW0bTq28rMHtvnTp5mGBmZVWuM0dGFkR2f1Q@mail.gmail.=
com"
type=3D"cite">
<div dir=3D"ltr">
<div class=3D"gmail_extra">
<div class=3D"gmail_quote">
<div> Are we going to achieve anything substantial by going
there?</div>
</div>
</div>
</div>
</blockquote>
Probably not.<br>
<br>
Tom.<br>
</body>
</html>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/9005e708-9f4d-fb56-9ded-bcb255b9dcef%=
40honermann.net?utm_medium=3Demail&utm_source=3Dfooter">https://groups.goog=
le.com/a/isocpp.org/d/msgid/std-proposals/9005e708-9f4d-fb56-9ded-bcb255b9d=
cef%40honermann.net</a>.<br />
--------------06D4D1A90900D850B6FB89EC--
.
Author: Viacheslav Usov <via.usov@gmail.com>
Date: Mon, 1 Aug 2016 18:27:48 +0200
Raw View
--001a114025ccc4f33a0539051434
Content-Type: text/plain; charset=UTF-8
On Mon, Aug 1, 2016 at 6:24 PM, Tom Honermann <tom@honermann.net> wrote:
> Yes, but today, the amount of memory required for the exception object is
statically knowable.
True, but at least one major implementation does not seem to use that and
allocates memory dynamically anyway [1, 2, search for
__cxa_allocate_exception in both].
Cheers,
V.
[1] https://monoinfinito.wordpress.com/series/exception-handling-in-c/
[2]
https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/libsupc%2B%2B/eh_alloc.cc
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg2iON%2BcuqzWkN%3DCQVz5x9_iAEako_SmxCD48GMh6GSxbA%40mail.gmail.com.
--001a114025ccc4f33a0539051434
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Aug 1, 2016 at 6:24 PM, Tom Honermann <span dir=3D"ltr"><<a href=3D"=
mailto:tom@honermann.net" target=3D"_blank">tom@honermann.net</a>></span=
> wrote:<br><div><br></div><div>> Yes, but today, the amount of memory r=
equired for the exception
object is statically knowable.</div><div><br></div><div>True, but at le=
ast one major implementation does not seem to use that and allocates memory=
dynamically anyway [1, 2, search for __cxa_allocate_exception in both].</d=
iv><div><br></div><div>Cheers,</div><div>V.</div><div><br></div><div>[1]=C2=
=A0<a href=3D"https://monoinfinito.wordpress.com/series/exception-handling-=
in-c/">https://monoinfinito.wordpress.com/series/exception-handling-in-c/</=
a></div><div><br></div><div>[2]=C2=A0<a href=3D"https://github.com/gcc-mirr=
or/gcc/blob/master/libstdc%2B%2B-v3/libsupc%2B%2B/eh_alloc.cc">https://gith=
ub.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/libsupc%2B%2B/eh_alloc.c=
c</a></div><div><br></div></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAA7YVg2iON%2BcuqzWkN%3DCQVz5x9_iAEak=
o_SmxCD48GMh6GSxbA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg2iON%2=
BcuqzWkN%3DCQVz5x9_iAEako_SmxCD48GMh6GSxbA%40mail.gmail.com</a>.<br />
--001a114025ccc4f33a0539051434--
.
Author: Tom Honermann <tom@honermann.net>
Date: Mon, 1 Aug 2016 12:28:03 -0400
Raw View
On 8/1/2016 11:51 AM, Thiago Macieira wrote:
> On segunda-feira, 1 de agosto de 2016 10:46:02 PDT Tom Honermann wrote:
>> I've worked on multiple products that have rolled their own and
>> the results have not been very good. The most successful approach
>> involved the process spawning a debugger to run a script to attach back
>> to itself to produce a stack trace.
> Off-topic, but explaining:
>
> That's because the backtrace() function in <execinfo.h> only reads the symbol
> table that is avaialble to the dynamic linker. That table lacks completely the
> symbols from the executable, as nothing usually links to the executable, and
> all the internal functions (static and hidden visibility).
In our case, that isn't why. We weren't using backtrace(), we really
rolled our own. But yes, the absence of debug info makes generation of
a useful stack trace effectively impossible for some ABIs.
Tom.
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/86472356-4da7-d5c4-1f21-1d23d6078595%40honermann.net.
.
Author: Tom Honermann <tom@honermann.net>
Date: Mon, 1 Aug 2016 12:38:16 -0400
Raw View
This is a multi-part message in MIME format.
--------------349F6348265A7AE14645F026
Content-Type: text/plain; charset=UTF-8; format=flowed
On 8/1/2016 12:27 PM, Viacheslav Usov wrote:
> On Mon, Aug 1, 2016 at 6:24 PM, Tom Honermann <tom@honermann.net
> <mailto:tom@honermann.net>> wrote:
>
> > Yes, but today, the amount of memory required for the exception
> object is statically knowable.
>
> True, but at least one major implementation does not seem to use that
> and allocates memory dynamically anyway [1, 2, search for
> __cxa_allocate_exception in both].
The signature for that function follows. Note that it is invoked with
the statically known size. Yes, in this case, it could then compute
additional storage required for the stack and add that to the allocation
request without (I think) an ABI change. But do you really want to
require that of all ABIs? I'm willing to bet some could not accommodate
that change without an ABI change.
|void||* __cxa_allocate_exception(||size_t| |thrown_size)|
>
> Cheers,
> V.
>
> [1] https://monoinfinito.wordpress.com/series/exception-handling-in-c/
>
> [2]
> https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/libsupc%2B%2B/eh_alloc.cc
>
> --
> 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
> <mailto:std-proposals+unsubscribe@isocpp.org>.
> To post to this group, send email to std-proposals@isocpp.org
> <mailto:std-proposals@isocpp.org>.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg2iON%2BcuqzWkN%3DCQVz5x9_iAEako_SmxCD48GMh6GSxbA%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg2iON%2BcuqzWkN%3DCQVz5x9_iAEako_SmxCD48GMh6GSxbA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/3bb05048-97fa-19b9-feec-2ddd06ff08fe%40honermann.net.
--------------349F6348265A7AE14645F026
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<div class=3D"moz-cite-prefix">On 8/1/2016 12:27 PM, Viacheslav Usov
wrote:<br>
</div>
<blockquote
cite=3D"mid:CAA7YVg2iON+cuqzWkN=3DCQVz5x9_iAEako_SmxCD48GMh6GSxbA@mail.gmai=
l.com"
type=3D"cite">
<div dir=3D"ltr">
<div class=3D"gmail_extra">
<div class=3D"gmail_quote">On Mon, Aug 1, 2016 at 6:24 PM, Tom
Honermann <span dir=3D"ltr"><<a moz-do-not-send=3D"true"
href=3D"mailto:tom@honermann.net" target=3D"_blank">tom@hon=
ermann.net</a>></span>
wrote:<br>
<div><br>
</div>
<div>> Yes, but today, the amount of memory required for
the exception object is statically knowable.</div>
<div><br>
</div>
<div>True, but at least one major implementation does not
seem to use that and allocates memory dynamically anyway
[1, 2, search for __cxa_allocate_exception in both].</div>
</div>
</div>
</div>
</blockquote>
<br>
The signature for that function follows.=C2=A0 Note that it is invoked
with the statically known size.=C2=A0 Yes, in this case, it could then
compute additional storage required for the stack and add that to
the allocation request without (I think) an ABI change.=C2=A0 But do yo=
u
really want to require that of all ABIs?=C2=A0 I'm willing to bet some
could not accommodate that change without an ABI change.<br>
<br>
<div class=3D"line number16 index15 alt1"><code class=3D"cpp keyword
bold">void</code><code class=3D"cpp plain">*
__cxa_allocate_exception(</code><code class=3D"cpp color1 bold">siz=
e_t</code>
<code class=3D"cpp plain">thrown_size)</code></div>
<br>
<blockquote
cite=3D"mid:CAA7YVg2iON+cuqzWkN=3DCQVz5x9_iAEako_SmxCD48GMh6GSxbA@mail.gmai=
l.com"
type=3D"cite">
<div dir=3D"ltr">
<div class=3D"gmail_extra">
<div class=3D"gmail_quote">
<div><br>
</div>
<div>Cheers,</div>
<div>V.</div>
<div><br>
</div>
<div>[1]=C2=A0<a moz-do-not-send=3D"true"
href=3D"https://monoinfinito.wordpress.com/series/exception-handling-in-c/"=
>https://monoinfinito.wordpress.com/series/exception-handling-in-c/</a></di=
v>
<div><br>
</div>
<div>[2]=C2=A0<a moz-do-not-send=3D"true"
href=3D"https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/libs=
upc%2B%2B/eh_alloc.cc">https://github.com/gcc-mirror/gcc/blob/master/libstd=
c%2B%2B-v3/libsupc%2B%2B/eh_alloc.cc</a></div>
<div><br>
</div>
</div>
</div>
</div>
-- <br>
You received this message because you are subscribed to the Google
Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it,
send an email to <a moz-do-not-send=3D"true"
href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+=
unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a moz-do-not-send=3D"true"
href=3D"mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</=
a>.<br>
To view this discussion on the web visit <a
moz-do-not-send=3D"true"
href=3D"https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YV=
g2iON%2BcuqzWkN%3DCQVz5x9_iAEako_SmxCD48GMh6GSxbA%40mail.gmail.com?utm_medi=
um=3Demail&utm_source=3Dfooter">https://groups.google.com/a/isocpp.org/=
d/msgid/std-proposals/CAA7YVg2iON%2BcuqzWkN%3DCQVz5x9_iAEako_SmxCD48GMh6GSx=
bA%40mail.gmail.com</a>.<br>
</blockquote>
<p><br>
</p>
</body>
</html>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/3bb05048-97fa-19b9-feec-2ddd06ff08fe%=
40honermann.net?utm_medium=3Demail&utm_source=3Dfooter">https://groups.goog=
le.com/a/isocpp.org/d/msgid/std-proposals/3bb05048-97fa-19b9-feec-2ddd06ff0=
8fe%40honermann.net</a>.<br />
--------------349F6348265A7AE14645F026--
.
Author: Viacheslav Usov <via.usov@gmail.com>
Date: Mon, 1 Aug 2016 18:49:56 +0200
Raw View
--001a1142500ef33c3f05390563eb
Content-Type: text/plain; charset=UTF-8
On Mon, Aug 1, 2016 at 6:38 PM, Tom Honermann <tom@honermann.net> wrote:
> The signature for that function follows. Note that it is invoked with
the statically known size.
Your earlier argument was about the need for dynamic allocation, which I
interpreted as if you had thought that existing implementations could
dispense with that. I mentioned that was unspecified by the standard, and I
have demonstrated that at least one major implementation does perform
dynamic memory allocation when an exception is thrown.
I am not really sure what you argument is now. Is it about that more than
one dynamic memory allocation may be required? But many, if not all,
standard exception classes would need that, too, because they have to hold
arbitrary strings passed into their constructors. So is it now three
allocations vs two? I'm pretty sure the implementation could trivially
collapse subsequent memory allocations into one, but even if we assume they
are dumb, is that really a deal breaker at this stage?
Cheers,
V.
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg3mRyh7eO4g%2BbaY%3DYUW0OLRpNdKQRN4%3DF8AcCEoLYEu4w%40mail.gmail.com.
--001a1142500ef33c3f05390563eb
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Aug 1, 2016 at 6:38 PM, Tom Honermann <span dir=3D"ltr"><<a href=3D"=
mailto:tom@honermann.net" target=3D"_blank">tom@honermann.net</a>></span=
> wrote:<br><div><br></div><div>> The signature for that function follow=
s.=C2=A0 Note that it is invoked
with the statically known size.</div><div><br></div><div>Your earlier a=
rgument was about the need for dynamic allocation, which I interpreted as i=
f you had thought that existing implementations could dispense with that. I=
mentioned that was unspecified by the standard, and I have demonstrated th=
at at least one major implementation does perform dynamic memory allocation=
when an exception is thrown.</div><div><br></div><div>I am not really sure=
what you argument is now. Is it about that more than one dynamic memory al=
location may be required? But many, if not all, standard exception classes =
would need that, too, because they have to hold arbitrary strings passed in=
to their constructors. So is it now three allocations vs two? I'm prett=
y sure the implementation could trivially collapse subsequent memory alloca=
tions into one, but even if we assume they are dumb, is that really a deal =
breaker at this stage?</div><div><br></div><div>Cheers,</div><div>V.</div><=
/div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAA7YVg3mRyh7eO4g%2BbaY%3DYUW0OLRpNdK=
QRN4%3DF8AcCEoLYEu4w%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg3mRy=
h7eO4g%2BbaY%3DYUW0OLRpNdKQRN4%3DF8AcCEoLYEu4w%40mail.gmail.com</a>.<br />
--001a1142500ef33c3f05390563eb--
.
Author: Bjorn Reese <breese@mail1.stofanet.dk>
Date: Mon, 1 Aug 2016 19:28:38 +0200
Raw View
On 08/01/2016 05:51 PM, Thiago Macieira wrote:
> That's because the backtrace() function in <execinfo.h> only reads the symbol
Bringing it slightly back on-topic, there seems to be two fundamentally
different solutions.
The first solution is to extract the call stack frames via some kind of
platform-dependent functionality (whether that is backtrace() or
attaching a debugger as described in the comp.unix.programmer FAQ
section 6.5.)
The second solution is to let the C++ compiler annotate the code with
information that can be collected and displayed.
The suggestions in this forum (both in this and earlier threads) have
mainly been about the annotation solution.
The discussions on the Boost mailing-list about a portable stack trace
library have been about the extraction solution:
http://lists.boost.org/Archives/boost/2016/06/230264.php
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9e25ca4f-1b09-491b-26d2-525f182a5d4b%40mail1.stofanet.dk.
.
Author: Tom Honermann <tom@honermann.net>
Date: Mon, 1 Aug 2016 13:45:49 -0400
Raw View
This is a multi-part message in MIME format.
--------------450B413715A5E257992E6421
Content-Type: text/plain; charset=UTF-8; format=flowed
On 8/1/2016 12:49 PM, Viacheslav Usov wrote:
> On Mon, Aug 1, 2016 at 6:38 PM, Tom Honermann <tom@honermann.net
> <mailto:tom@honermann.net>> wrote:
>
> > The signature for that function follows. Note that it is invoked
> with the statically known size.
>
> Your earlier argument was about the need for dynamic allocation, which
> I interpreted as if you had thought that existing implementations
> could dispense with that. I mentioned that was unspecified by the
> standard, and I have demonstrated that at least one major
> implementation does perform dynamic memory allocation when an
> exception is thrown.
I do think that existing implementations can dispense with dynamic
allocation, at least for non-nested exceptions. Such implementations
would necessarily dynamically allocate for copying an exception object
to satisfy lifetime requirements for std::current_exception(), so I do
accept that dynamic allocation is required in some cases. The fact that
one implementation unconditionally uses dynamic allocation does not
imply that they all do.
>
> I am not really sure what you argument is now.
My initial response was to your claim that the cost overhead of
including the stack trace for exception objects is negligible. I claim
that it may not be; that some ABIs may require changes to support a
dynamically dependent allocation size. I don't know of any particular
ABIs that would require changes.
> Is it about that more than one dynamic memory allocation may be
> required? But many, if not all, standard exception classes would need
> that, too, because they have to hold arbitrary strings passed into
> their constructors. So is it now three allocations vs two? I'm pretty
> sure the implementation could trivially collapse subsequent memory
> allocations into one, but even if we assume they are dumb, is that
> really a deal breaker at this stage?
There is a distinction between dynamic allocation performed by the
constructor of a thrown object vs the allocation for the thrown object
itself.
Tom.
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4fae4ae4-2770-1abd-beda-b59394f31a7c%40honermann.net.
--------------450B413715A5E257992E6421
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<div class=3D"moz-cite-prefix">On 8/1/2016 12:49 PM, Viacheslav Usov
wrote:<br>
</div>
<blockquote
cite=3D"mid:CAA7YVg3mRyh7eO4g+baY=3DYUW0OLRpNdKQRN4=3DF8AcCEoLYEu4w@mail.gm=
ail.com"
type=3D"cite">
<div dir=3D"ltr">
<div class=3D"gmail_extra">
<div class=3D"gmail_quote">On Mon, Aug 1, 2016 at 6:38 PM, Tom
Honermann <span dir=3D"ltr"><<a moz-do-not-send=3D"true"
href=3D"mailto:tom@honermann.net" target=3D"_blank">tom@hon=
ermann.net</a>></span>
wrote:<br>
<div><br>
</div>
<div>> The signature for that function follows.=C2=A0 Note
that it is invoked with the statically known size.</div>
<div><br>
</div>
<div>Your earlier argument was about the need for dynamic
allocation, which I interpreted as if you had thought that
existing implementations could dispense with that. I
mentioned that was unspecified by the standard, and I have
demonstrated that at least one major implementation does
perform dynamic memory allocation when an exception is
thrown.</div>
</div>
</div>
</div>
</blockquote>
I do think that existing implementations can dispense with dynamic
allocation, at least for non-nested exceptions.=C2=A0 Such
implementations would necessarily dynamically allocate for copying
an exception object to satisfy lifetime requirements for
std::current_exception(), so I do accept that dynamic allocation is
required in some cases.=C2=A0 The fact that one implementation
unconditionally uses dynamic allocation does not imply that they all
do.<br>
<blockquote
cite=3D"mid:CAA7YVg3mRyh7eO4g+baY=3DYUW0OLRpNdKQRN4=3DF8AcCEoLYEu4w@mail.gm=
ail.com"
type=3D"cite">
<div dir=3D"ltr">
<div class=3D"gmail_extra">
<div class=3D"gmail_quote">
<div><br>
</div>
<div>I am not really sure what you argument is now.</div>
</div>
</div>
</div>
</blockquote>
My initial response was to your claim that the cost overhead of
including the stack trace for exception objects is negligible.=C2=A0 I
claim that it may not be; that some ABIs may require changes to
support a dynamically dependent allocation size.=C2=A0 I don't know of
any particular ABIs that would require changes.<br>
<blockquote
cite=3D"mid:CAA7YVg3mRyh7eO4g+baY=3DYUW0OLRpNdKQRN4=3DF8AcCEoLYEu4w@mail.gm=
ail.com"
type=3D"cite">
<div dir=3D"ltr">
<div class=3D"gmail_extra">
<div class=3D"gmail_quote">
<div> Is it about that more than one dynamic memory
allocation may be required? But many, if not all, standard
exception classes would need that, too, because they have
to hold arbitrary strings passed into their constructors.
So is it now three allocations vs two? I'm pretty sure the
implementation could trivially collapse subsequent memory
allocations into one, but even if we assume they are dumb,
is that really a deal breaker at this stage?</div>
</div>
</div>
</div>
</blockquote>
There is a distinction between dynamic allocation performed by the
constructor of a thrown object vs the allocation for the thrown
object itself.<br>
<br>
Tom.<br>
</body>
</html>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/4fae4ae4-2770-1abd-beda-b59394f31a7c%=
40honermann.net?utm_medium=3Demail&utm_source=3Dfooter">https://groups.goog=
le.com/a/isocpp.org/d/msgid/std-proposals/4fae4ae4-2770-1abd-beda-b59394f31=
a7c%40honermann.net</a>.<br />
--------------450B413715A5E257992E6421--
.
Author: =?UTF-8?B?0JTQtdC90LjRgSDQmtC+0YLQvtCy?= <redradist@gmail.com>
Date: Mon, 1 Aug 2016 10:47:04 -0700 (PDT)
Raw View
------=_Part_3436_927989613.1470073625031
Content-Type: multipart/alternative;
boundary="----=_Part_3437_1950773386.1470073625031"
------=_Part_3437_1950773386.1470073625031
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=D0=BF=D0=BE=D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D1=8C=D0=BD=D0=B8=D0=BA, 1 =D0=
=B0=D0=B2=D0=B3=D1=83=D1=81=D1=82=D0=B0 2016 =D0=B3., 17:02:23 UTC+3 =D0=BF=
=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Nicol Bo=
las=20
=D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:
>
> On Monday, August 1, 2016 at 6:31:31 AM UTC-4, Viacheslav Usov wrote:
>>
>> It looks like this thread started just like this one:=20
>> https://groups.google.com/a/isocpp.org/forum/#!topic/std-discussion/A17G=
1ram9ns
>>
>> To quote:
>>
>> To find the root cause of bugs easier, it is very helpful to have stack=
=20
>> trace from the location where the exception is thrown.
>>
>> Surely I can throw an exception class derived from std:exception and use=
=20
>> backtrace on Linux or StackWalk64 on Windows, with the appropriate symbo=
ls=20
>> (=3D> not portable),=20
>> or have a try catch "everywhere" and add file and line information (=3D>=
=20
>> too much code to add),=20
>> or not to catch the exception at all and let the Operation System write=
=20
>> the dump file(=3D>not portable, some exceptions can be handled inside th=
e=20
>> program).
>>
>> I thought there should be an easy portable way to add stack information=
=20
>> to a std::exception. Does anybody have some ideas?
>>
>> (end)
>>
>> It then morphed into a discussion of just getting the stack trace, not=
=20
>> necessarily in an exception context, but some of what we discussed there=
,=20
>> in particular the separation of capture/parse functionality, is applicab=
le=20
>> in any case.
>>
>> In this new thread, more than one participant have mentioned they they=
=20
>> find it undesirable to have exceptions carry the weight of stack tracing=
..
>>
>> This sentiment is understandable, but I have the following two points to=
=20
>> be considered in this respect:
>>
>> 1. Is the performance of exception handling really an overriding concern=
?
>>
>
> ... *Yes*!
>
> One of the primary reasons why SG14 wants to find alternatives to=20
> exceptions for C++ errors=20
> <http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0364r0.pdf> is=
=20
> because exceptions *cost too much* at runtime. There are whole classes of=
=20
> applications that are built without exception handling of any kind,=20
> primarily because it's too expensive. You now want to take an already=20
> costly tool and make it *more expensive*. That's moving in the wrong=20
> direction.
>
> It is very easy to overgeneralise, of course, but I'd say it is widely=20
>> understood[1] that exceptions are not really a mechanism to be used to=
=20
>> control execution under "normal circumstances", in which case worrying m=
ore=20
>> about performance than utility seems strange.
>>
>
If Standard committee has been thinking about it since last century, maybe=
=20
that can mean there is no better solution ?
If you have possibility to handle an issue you have to pay for this=20
possibility ! Another way, compile *-fno-exceptions* with flag.
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/a9ed14ec-3a6e-45e4-ac30-0fe35245713a%40isocpp.or=
g.
------=_Part_3437_1950773386.1470073625031
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">=D0=BF=D0=BE=D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D1=8C=D0=BD=D0=
=B8=D0=BA, 1 =D0=B0=D0=B2=D0=B3=D1=83=D1=81=D1=82=D0=B0 2016 =D0=B3., 17:02=
:23 UTC+3 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=
=BB=D1=8C Nicol Bolas =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:<blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">On Monday, August 1, 20=
16 at 6:31:31 AM UTC-4, Viacheslav Usov wrote:<blockquote class=3D"gmail_qu=
ote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding=
-left:1ex"><div dir=3D"ltr">It looks like this thread started just like thi=
s one: <a href=3D"https://groups.google.com/a/isocpp.org/forum/#!topic/std-=
discussion/A17G1ram9ns" rel=3D"nofollow" target=3D"_blank" onmousedown=3D"t=
his.href=3D'https://groups.google.com/a/isocpp.org/forum/#!topic/std-di=
scussion/A17G1ram9ns';return true;" onclick=3D"this.href=3D'https:/=
/groups.google.com/a/isocpp.org/forum/#!topic/std-discussion/A17G1ram9ns=
9;;return true;">https://groups.google.com/a/<wbr>isocpp.org/forum/#!topic/=
std-<wbr>discussion/A17G1ram9ns</a><div><br></div><div>To quote:</div><div>=
<br></div><div><div style=3D"margin:0px;padding:0px;border:0px;font-family:=
arial,helvetica,sans-serif;font-size:13px">To find the root cause of bugs e=
asier, it is very helpful to have stack trace from the location where the e=
xception is thrown.<br></div><div style=3D"margin:0px;padding:0px;border:0p=
x;font-family:arial,helvetica,sans-serif;font-size:13px"><br></div><div sty=
le=3D"margin:0px;padding:0px;border:0px;font-family:arial,helvetica,sans-se=
rif;font-size:13px">Surely I can throw an exception class derived from std:=
exception and use backtrace on Linux or StackWalk64 on Windows, with the ap=
propriate symbols (=3D> not portable),=C2=A0<br><div style=3D"margin:0px=
;padding:0px;border:0px">or have a try catch "everywhere" and add=
file and line information (=3D> too much code to add),=C2=A0</div></div=
><div style=3D"margin:0px;padding:0px;border:0px;font-family:arial,helvetic=
a,sans-serif;font-size:13px">or not to catch the exception at all and let t=
he Operation System write the dump file(=3D>not portable, some exception=
s can be handled inside the program).</div><div style=3D"margin:0px;padding=
:0px;border:0px;font-family:arial,helvetica,sans-serif;font-size:13px"><br>=
</div><div style=3D"margin:0px;padding:0px;border:0px;font-family:arial,hel=
vetica,sans-serif;font-size:13px">I thought there should be an easy portabl=
e way to add stack information to a std::exception. Does anybody have some =
ideas?</div></div><div style=3D"margin:0px;padding:0px;border:0px;font-fami=
ly:arial,helvetica,sans-serif;font-size:13px"><br></div><div>(end)</div><di=
v><br></div><div>It then morphed into a discussion of just getting the stac=
k trace, not necessarily in an exception context, but some of what we discu=
ssed there, in particular the separation of capture/parse functionality, is=
applicable in any case.</div><div><br></div><div>In this new thread, more =
than one participant have mentioned they they find it undesirable to have e=
xceptions carry the weight of stack tracing.</div><div><br></div><div>This =
sentiment is understandable, but I have the following two points to be cons=
idered in this respect:</div><div><br></div><div>1. Is the performance of e=
xception handling really an overriding concern?</div></div></blockquote><di=
v><br>... <i>Yes</i>!<br><br>One of the primary reasons why <a href=3D"http=
://www.open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0364r0.pdf" target=3D"=
_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google.=
com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2FJTC1%2FSC22%2FWG21%2Fdocs%2Fpa=
pers%2F2016%2Fp0364r0.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHIQHYM_nL=
gci2TBZkbrEeyef62Sw';return true;" onclick=3D"this.href=3D'http://w=
ww.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2FJTC1%2FSC22%2FWG21%2=
Fdocs%2Fpapers%2F2016%2Fp0364r0.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjC=
NHIQHYM_nLgci2TBZkbrEeyef62Sw';return true;">SG14 wants to find alterna=
tives to exceptions for C++ errors</a> is because exceptions <i>cost too mu=
ch</i> at runtime. There are whole classes of applications that are built w=
ithout exception handling of any kind, primarily because it's too expen=
sive. You now want to take an already costly tool and make it <i>more expen=
sive</i>. That's moving in the wrong direction.<br><br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px=
#ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>It is very easy to over=
generalise, of course, but I'd say it is widely understood[1] that exce=
ptions are not really a mechanism to be used to control execution under &qu=
ot;normal circumstances", in which case worrying more about performanc=
e than utility seems strange.</div></div></blockquote></div></blockquote><d=
iv><br>If Standard committee has been thinking about it since last century,=
maybe that can mean there is no better solution ?<br>If you have possibili=
ty to handle an issue you have to pay for this possibility ! Another way, c=
ompile <b>-fno-exceptions</b> with flag.<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a9ed14ec-3a6e-45e4-ac30-0fe35245713a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a9ed14ec-3a6e-45e4-ac30-0fe35245713a=
%40isocpp.org</a>.<br />
------=_Part_3437_1950773386.1470073625031--
------=_Part_3436_927989613.1470073625031--
.
Author: =?UTF-8?B?0JTQtdC90LjRgSDQmtC+0YLQvtCy?= <redradist@gmail.com>
Date: Mon, 1 Aug 2016 11:03:33 -0700 (PDT)
Raw View
------=_Part_3285_771467319.1470074613796
Content-Type: multipart/alternative;
boundary="----=_Part_3286_345036498.1470074613796"
------=_Part_3286_345036498.1470074613796
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=D0=BF=D0=BE=D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D1=8C=D0=BD=D0=B8=D0=BA, 1 =D0=
=B0=D0=B2=D0=B3=D1=83=D1=81=D1=82=D0=B0 2016 =D0=B3., 20:27:23 UTC+3 =D0=BF=
=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Bjorn Re=
ese=20
=D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:
>
> On 08/01/2016 05:51 PM, Thiago Macieira wrote:=20
>
> > That's because the backtrace() function in <execinfo.h> only reads the=
=20
> symbol=20
>
> Bringing it slightly back on-topic, there seems to be two fundamentally=
=20
> different solutions.=20
>
> The first solution is to extract the call stack frames via some kind of=
=20
> platform-dependent functionality (whether that is backtrace() or=20
> attaching a debugger as described in the comp.unix.programmer FAQ=20
> section 6.5.)=20
>
> The second solution is to let the C++ compiler annotate the code with=20
> information that can be collected and displayed.=20
>
> The suggestions in this forum (both in this and earlier threads) have=20
> mainly been about the annotation solution.=20
>
> The discussions on the Boost mailing-list about a portable stack trace=20
> library have been about the extraction solution:=20
>
> http://lists.boost.org/Archives/boost/2016/06/230264.php=20
>
>
> The first solution is to extract the call stack frames via some kind of=
=20
> platform-dependent functionality (whether that is backtrace() or=20
> attaching a debugger as described in the comp.unix.programmer FAQ=20
> section 6.5.)
This will be little-bit hard to implement and get a consistent look on=20
different platforms.
> The second solution is to let the C++ compiler annotate the code with
> information that can be collected and displayed.
This one is pretty good too. Maybe it is the better solution, in this case=
=20
we will have the same behavior on different platforms.
=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/3425179a-1584-49e6-b27d-56e0b766bb42%40isocpp.or=
g.
------=_Part_3286_345036498.1470074613796
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">=D0=BF=D0=BE=D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D1=8C=D0=BD=D0=
=B8=D0=BA, 1 =D0=B0=D0=B2=D0=B3=D1=83=D1=81=D1=82=D0=B0 2016 =D0=B3., 20:27=
:23 UTC+3 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=
=BB=D1=8C Bjorn Reese =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:<blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;">On 08/01/2016 05:51 PM, Thiago Macieira =
wrote:
<br>
<br>> That's because the backtrace() function in <execinfo.h> =
only reads the symbol
<br>
<br>Bringing it slightly back on-topic, there seems to be two fundamentally
<br>different solutions.
<br>
<br>The first solution is to extract the call stack frames via some kind of
<br>platform-dependent functionality (whether that is backtrace() or
<br>attaching a debugger as described in the comp.unix.programmer FAQ
<br>section 6.5.)
<br>
<br>The second solution is to let the C++ compiler annotate the code with
<br>information that can be collected and displayed.
<br>
<br>The suggestions in this forum (both in this and earlier threads) have
<br>mainly been about the annotation solution.
<br>
<br>The discussions on the Boost mailing-list about a portable stack trace
<br>library have been about the extraction solution:
<br>
<br>=C2=A0 =C2=A0<a href=3D"http://lists.boost.org/Archives/boost/2016/06/2=
30264.php" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#=
39;http://www.google.com/url?q\x3dhttp%3A%2F%2Flists.boost.org%2FArchives%2=
Fboost%2F2016%2F06%2F230264.php\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHv_=
5UoHoVpNsLg_bd-9mRp6Uzx8g';return true;" onclick=3D"this.href=3D'ht=
tp://www.google.com/url?q\x3dhttp%3A%2F%2Flists.boost.org%2FArchives%2Fboos=
t%2F2016%2F06%2F230264.php\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHv_5UoHo=
VpNsLg_bd-9mRp6Uzx8g';return true;">http://lists.boost.org/<wbr>Archive=
s/boost/2016/06/230264.<wbr>php</a>
<br>
<br></blockquote><div><br>> The first solution is to extract the call st=
ack frames via some kind of
<br>> platform-dependent functionality (whether that is backtrace() or
<br>> attaching a debugger as described in the comp.unix.programmer FAQ
<br>> section 6.5.)<br><br>This will be little-bit hard to implement and=
get a consistent look on different platforms.<br><br>> The second solut=
ion is to let the C++ compiler annotate the code with<br>> information t=
hat can be collected and displayed.<br><br>This one is pretty good too. May=
be it is the better solution, in this case we will have the same behavior o=
n different platforms.<br>=C2=A0</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/3425179a-1584-49e6-b27d-56e0b766bb42%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/3425179a-1584-49e6-b27d-56e0b766bb42=
%40isocpp.org</a>.<br />
------=_Part_3286_345036498.1470074613796--
------=_Part_3285_771467319.1470074613796--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Mon, 01 Aug 2016 12:11:28 -0700
Raw View
On segunda-feira, 1 de agosto de 2016 19:28:38 PDT Bjorn Reese wrote:
> Bringing it slightly back on-topic, there seems to be two fundamentally
> different solutions.
>
> The first solution is to extract the call stack frames via some kind of
> platform-dependent functionality (whether that is backtrace() or
> attaching a debugger as described in the comp.unix.programmer FAQ
> section 6.5.)
>
> The second solution is to let the C++ compiler annotate the code with
> information that can be collected and displayed.
It would be nice if this information were out-of-line, stored in sections of
the file that weren't loaded at all during normal conditions. Since this isn't
loaded, it can contain a lot more detailed information, such as file names and
line numbers, location of variables, their names and types, etc.
This exists and is called "debug symbols".
So, no, I don't think we're talking about two different solutions.
> The suggestions in this forum (both in this and earlier threads) have
> mainly been about the annotation solution.
>
> The discussions on the Boost mailing-list about a portable stack trace
> library have been about the extraction solution:
>
> http://lists.boost.org/Archives/boost/2016/06/230264.php
That's basically standardising the backtrace() function from <execinfo.h> in a
C++ form. I suggest that if we do this, we start with C functions that the C
committee could adopt. A C++ wrapper might be nice, but it's not required.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1558179.SSIDO0IH7E%40tjmaciei-mobl1.
.
Author: Wil Evers <wileversmod@gmail.com>
Date: Mon, 1 Aug 2016 12:13:10 -0700 (PDT)
Raw View
------=_Part_2105_862233441.1470078790447
Content-Type: multipart/alternative;
boundary="----=_Part_2106_740625631.1470078790448"
------=_Part_2106_740625631.1470078790448
Content-Type: text/plain; charset=UTF-8
On Monday, August 1, 2016 at 5:34:11 PM UTC+2, Thiago Macieira wrote:
>
> On segunda-feira, 1 de agosto de 2016 07:19:23 PDT Wil Evers wrote:
> > You should know what NDEBUG is; it is a standard C++ feature. #defining
> > NDEBUG disables assertions.
>
> I was slightly exagerating my ignorance. But it has happened, more than
> once,
> that I see assert() left in my release code until I remember that I needed
> to
> set it.
>
Sounds like you need to fix your build system. Since the effect of NDEBUG
is defined in the standard, I would expect any build system, on any
platform, do #define NDEBUG in release builds, it it makes such a
distinction. If it doesn't, you have more serious problems to worry about.
>
> > Given that, it seems quite reasonable to think of a build where NDEBUG
> is
> > not defined as a "debug build". Even if Qt doesn't react to NDEBUG,
> > conforming user code can.
>
> We could have inline features and other macros that react to NDEBUG. But
> that
> can't affect code generation by the compiler.
>
Huh? The point of NDEBUG is to generate *different code* in different
build configurations.
>
> We could have the opposite though: compiler switches that affect code
> generation get a predefined macro added or suppressed.
>
How would that differ from what NDEBUG currently has to offer?
Wil
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/3006869f-8c8b-4b80-bec4-724726a1b6da%40isocpp.org.
------=_Part_2106_740625631.1470078790448
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, August 1, 2016 at 5:34:11 PM UTC+2, Thiago Maci=
eira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On segunda-feira, 1=
de agosto de 2016 07:19:23 PDT Wil Evers wrote:
<br>> You should know what NDEBUG is; it is a standard C++ feature. #def=
ining
<br>> NDEBUG disables assertions.
<br>
<br>I was slightly exagerating my ignorance. But it has happened, more than=
once,=20
<br>that I see assert() left in my release code until I remember that I nee=
ded to=20
<br>set it.<br></blockquote><div><br>Sounds like you need to fix your build=
system. Since the effect of NDEBUG is defined in the standard, I would exp=
ect any build system, on any platform, do #define NDEBUG in release builds,=
it it makes such a distinction. If it doesn't, you have more serious p=
roblems to worry about. <br></div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;">
<br>> Given that, it seems quite reasonable to think of a build where ND=
EBUG is
<br>> not defined as a "debug build". Even if Qt doesn't r=
eact to NDEBUG,
<br>> conforming user code can.
<br>
<br>We could have inline features and other macros that react to NDEBUG. Bu=
t that=20
<br>can't affect code generation by the compiler.<br></blockquote><div>=
<br>Huh?=C2=A0 The point of NDEBUG is to generate *different code* in diffe=
rent build configurations.<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;">
<br>We could have the opposite though: compiler switches that affect code=
=20
<br>generation get a predefined macro added or suppressed.
<br></blockquote><div><br>How would that differ from what NDEBUG currently =
has to offer? <br><br>Wil<br><br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/3006869f-8c8b-4b80-bec4-724726a1b6da%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/3006869f-8c8b-4b80-bec4-724726a1b6da=
%40isocpp.org</a>.<br />
------=_Part_2106_740625631.1470078790448--
------=_Part_2105_862233441.1470078790447--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Mon, 01 Aug 2016 12:38:30 -0700
Raw View
On segunda-feira, 1 de agosto de 2016 12:13:10 PDT Wil Evers wrote:
> On Monday, August 1, 2016 at 5:34:11 PM UTC+2, Thiago Macieira wrote:
> Sounds like you need to fix your build system. Since the effect of NDEBUG
> is defined in the standard, I would expect any build system, on any
> platform, do #define NDEBUG in release builds, it it makes such a
> distinction. If it doesn't, you have more serious problems to worry about.
I disagree. The standard only talks about assert.h, not other features. That
has nothing to do with release mode and debug mode. And maybe I want
assertions left in my code, even in release mode, so automatically doing it is
not a good idea.
The buildsystem should be agnostic and not define things I don't want it to.
And besides, in a Qt-centric buildsystem (like qmake), it would define
QT_NO_DEBUG, not NDEBUG.
> > > Given that, it seems quite reasonable to think of a build where NDEBUG
> >
> > is
> >
> > > not defined as a "debug build". Even if Qt doesn't react to NDEBUG,
> > > conforming user code can.
> >
> > We could have inline features and other macros that react to NDEBUG. But
> > that
> > can't affect code generation by the compiler.
>
> Huh? The point of NDEBUG is to generate *different code* in different
> build configurations.
And so is QT_NO_DEBUG, QT_NO_DEBUG_OUTPUT, QT_FORCE_ASSERTS,
QT_NO_CAST_FROM_ASCII, QT_NO_CAST_TO_ASCII, and many other flags.
My point is the compiler reacting to NDEBUG is putting the cart ahead of the
oxen. In a traditional compiler, the compiler doesn't see the code until it's
been fully preprocessed, so it can't react to a macro being defined or not. The
macro can expand to different code that you could call, but it can't change my
generic function that didn't use the macro.
At worst, someone could #define throw and do something "evil" with it, to
accomplish what was discussed.
I would advise instead for a #pragma.
> > We could have the opposite though: compiler switches that affect code
> > generation get a predefined macro added or suppressed.
>
> How would that differ from what NDEBUG currently has to offer?
Cart ahead of the oxen.
For example, the -O option with any value except 0 with GCC causes the
__OPTIMIZE__ macro to be defined. But defining or undefinining it in my code will
not change how the compiler generates code. Same for __i386__, __x86_64__,
__SSE2__, __SSE_MATH__, etc.
"#pragma GCC optimize" and "#pragma GCC target" do change how the compiler
generates code, like their equivalent __attribute__ attributes do.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4176746.l6UKp6CGP7%40tjmaciei-mobl1.
.
Author: Patrice Roy <patricer@gmail.com>
Date: Mon, 1 Aug 2016 16:06:53 -0400
Raw View
--001a11431d3448b48b05390824bd
Content-Type: text/plain; charset=UTF-8
>
> At worst, someone could #define throw and do something "evil" with it, to
> accomplish what was discussed.
According to 17.6.4.3.2 p2, no, they will not, at least on a conforming
implementation :)
2016-08-01 15:38 GMT-04:00 Thiago Macieira <thiago@macieira.org>:
> On segunda-feira, 1 de agosto de 2016 12:13:10 PDT Wil Evers wrote:
> > On Monday, August 1, 2016 at 5:34:11 PM UTC+2, Thiago Macieira wrote:
> > Sounds like you need to fix your build system. Since the effect of NDEBUG
> > is defined in the standard, I would expect any build system, on any
> > platform, do #define NDEBUG in release builds, it it makes such a
> > distinction. If it doesn't, you have more serious problems to worry
> about.
>
> I disagree. The standard only talks about assert.h, not other features.
> That
> has nothing to do with release mode and debug mode. And maybe I want
> assertions left in my code, even in release mode, so automatically doing
> it is
> not a good idea.
>
> The buildsystem should be agnostic and not define things I don't want it
> to.
> And besides, in a Qt-centric buildsystem (like qmake), it would define
> QT_NO_DEBUG, not NDEBUG.
>
> > > > Given that, it seems quite reasonable to think of a build where
> NDEBUG
> > >
> > > is
> > >
> > > > not defined as a "debug build". Even if Qt doesn't react to NDEBUG,
> > > > conforming user code can.
> > >
> > > We could have inline features and other macros that react to NDEBUG.
> But
> > > that
> > > can't affect code generation by the compiler.
> >
> > Huh? The point of NDEBUG is to generate *different code* in different
> > build configurations.
>
> And so is QT_NO_DEBUG, QT_NO_DEBUG_OUTPUT, QT_FORCE_ASSERTS,
> QT_NO_CAST_FROM_ASCII, QT_NO_CAST_TO_ASCII, and many other flags.
>
> My point is the compiler reacting to NDEBUG is putting the cart ahead of
> the
> oxen. In a traditional compiler, the compiler doesn't see the code until
> it's
> been fully preprocessed, so it can't react to a macro being defined or
> not. The
> macro can expand to different code that you could call, but it can't
> change my
> generic function that didn't use the macro.
>
> At worst, someone could #define throw and do something "evil" with it, to
> accomplish what was discussed.
>
> I would advise instead for a #pragma.
>
> > > We could have the opposite though: compiler switches that affect code
> > > generation get a predefined macro added or suppressed.
> >
> > How would that differ from what NDEBUG currently has to offer?
>
> Cart ahead of the oxen.
>
> For example, the -O option with any value except 0 with GCC causes the
> __OPTIMIZE__ macro to be defined. But defining or undefinining it in my
> code will
> not change how the compiler generates code. Same for __i386__, __x86_64__,
> __SSE2__, __SSE_MATH__, etc.
>
> "#pragma GCC optimize" and "#pragma GCC target" do change how the compiler
> generates code, like their equivalent __attribute__ attributes do.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Software Architect - Intel Open Source Technology Center
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4176746.l6UKp6CGP7%40tjmaciei-mobl1
> .
>
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKiZDp0saTmi0gD1i5OZsbdy172pXL%3DscvUmxmRpKxSKap9N0Q%40mail.gmail.com.
--001a11431d3448b48b05390824bd
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">At worst=
, someone could #define throw and do something "evil" with it, to=
<br>
accomplish what was discussed.</blockquote><div><br></div><div>According to=
17.6.4.3.2 p2, no, they will not, at least on a conforming implementation =
:) <br></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote=
">2016-08-01 15:38 GMT-04:00 Thiago Macieira <span dir=3D"ltr"><<a href=
=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@macieira.org</a>&g=
t;</span>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On segunda-fe=
ira, 1 de agosto de 2016 12:13:10 PDT Wil Evers wrote:<br>
> On Monday, August 1, 2016 at 5:34:11 PM UTC+2, Thiago Macieira wrote:<=
br>
</span><span class=3D"">> Sounds like you need to fix your build system.=
Since the effect of NDEBUG<br>
> is defined in the standard, I would expect any build system, on any<br=
>
> platform, do #define NDEBUG in release builds, it it makes such a<br>
> distinction. If it doesn't, you have more serious problems to worr=
y about.<br>
<br>
</span>I disagree. The standard only talks about assert.h, not other featur=
es. That<br>
has nothing to do with release mode and debug mode. And maybe I want<br>
assertions left in my code, even in release mode, so automatically doing it=
is<br>
not a good idea.<br>
<br>
The buildsystem should be agnostic and not define things I don't want i=
t to.<br>
And besides, in a Qt-centric buildsystem (like qmake), it would define<br>
QT_NO_DEBUG,=C2=A0 not NDEBUG.<br>
<span class=3D""><br>
> > > Given that, it seems quite reasonable to think of a build wh=
ere NDEBUG<br>
> ><br>
> > is<br>
> ><br>
> > > not defined as a "debug build". Even if Qt doesn&#=
39;t react to NDEBUG,<br>
> > > conforming user code can.<br>
> ><br>
> > We could have inline features and other macros that react to NDEB=
UG. But<br>
> > that<br>
> > can't affect code generation by the compiler.<br>
><br>
> Huh?=C2=A0 The point of NDEBUG is to generate *different code* in diff=
erent<br>
> build configurations.<br>
<br>
</span>And so is QT_NO_DEBUG, QT_NO_DEBUG_OUTPUT, QT_FORCE_ASSERTS,<br>
QT_NO_CAST_FROM_ASCII, QT_NO_CAST_TO_ASCII, and many other flags.<br>
<br>
My point is the compiler reacting to NDEBUG is putting the cart ahead of th=
e<br>
oxen. In a traditional compiler, the compiler doesn't see the code unti=
l it's<br>
been fully preprocessed, so it can't react to a macro being defined or =
not. The<br>
macro can expand to different code that you could call, but it can't ch=
ange my<br>
generic function that didn't use the macro.<br>
<br>
At worst, someone could #define throw and do something "evil" wit=
h it, to<br>
accomplish what was discussed.<br>
<br>
I would advise instead for a #pragma.<br>
<span class=3D""><br>
> > We could have the opposite though: compiler switches that affect =
code<br>
> > generation get a predefined macro added or suppressed.<br>
><br>
> How would that differ from what NDEBUG currently has to offer?<br>
<br>
</span>Cart ahead of the oxen.<br>
<br>
For example, the -O option with any value except 0 with GCC causes the<br>
__OPTIMIZE__ macro to be defined. But defining or undefinining it in my cod=
e will<br>
not change how the compiler generates code.=C2=A0 Same for __i386__, __x86_=
64__,<br>
__SSE2__, __SSE_MATH__, etc.<br>
<br>
"#pragma GCC optimize" and "#pragma GCC target" do chan=
ge how the compiler<br>
generates code, like their equivalent __attribute__ attributes do.<br>
<span class=3D""><br>
--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"noref=
errer" target=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://=
kde.org" rel=3D"noreferrer" target=3D"_blank">kde.org</a><br>
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<br>
<br>
</span><span class=3D"">--<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+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>
</span>To view this discussion on the web visit <a href=3D"https://groups.g=
oogle.com/a/isocpp.org/d/msgid/std-proposals/4176746.l6UKp6CGP7%40tjmaciei-=
mobl1" rel=3D"noreferrer" target=3D"_blank">https://groups.google.com/a/iso=
cpp.org/d/msgid/std-proposals/4176746.l6UKp6CGP7%40tjmaciei-mobl1</a>.<br>
</blockquote></div><br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAKiZDp0saTmi0gD1i5OZsbdy172pXL%3Dscv=
UmxmRpKxSKap9N0Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKiZDp0saTmi0g=
D1i5OZsbdy172pXL%3DscvUmxmRpKxSKap9N0Q%40mail.gmail.com</a>.<br />
--001a11431d3448b48b05390824bd--
.
Author: Wil Evers <wileversmod@gmail.com>
Date: Mon, 1 Aug 2016 13:17:39 -0700 (PDT)
Raw View
------=_Part_648_616353570.1470082659406
Content-Type: multipart/alternative;
boundary="----=_Part_649_1708208607.1470082659407"
------=_Part_649_1708208607.1470082659407
Content-Type: text/plain; charset=UTF-8
On Monday, August 1, 2016 at 9:38:34 PM UTC+2, Thiago Macieira wrote:
>
> On segunda-feira, 1 de agosto de 2016 12:13:10 PDT Wil Evers wrote:
> > On Monday, August 1, 2016 at 5:34:11 PM UTC+2, Thiago Macieira wrote:
> > Sounds like you need to fix your build system. Since the effect of
> NDEBUG
> > is defined in the standard, I would expect any build system, on any
> > platform, do #define NDEBUG in release builds, it it makes such a
> > distinction. If it doesn't, you have more serious problems to worry
> about.
>
> I disagree. The standard only talks about assert.h, not other features.
> That
> has nothing to do with release mode and debug mode. And maybe I want
> assertions left in my code, even in release mode, so automatically doing
> it is
> not a good idea.
>
You were complaining about your build system not disabling assertions when
you expected it to. To me, that still sounds like a problem in your build
system.
That said, I agree that it should allow for an override to enable
(standard) assertions in release mode (possibly for a specific set of
source files), but only when explicitly told to do so.
> The buildsystem should be agnostic and not define things I don't want it
> to.
> And besides, in a Qt-centric buildsystem (like qmake), it would define
> QT_NO_DEBUG, not NDEBUG.
>
Qt is not the standard. The standard only talks about the NDEBUG macro. If
Qt ignores its intended usage, then that's a compliance issue, among a few
others, with Qt.
[snip]
> The point of NDEBUG is to generate *different code* in different
> > build configurations.
>
> And so is QT_NO_DEBUG, QT_NO_DEBUG_OUTPUT, QT_FORCE_ASSERTS,
> QT_NO_CAST_FROM_ASCII, QT_NO_CAST_TO_ASCII, and many other flags.
Interesting, but irrelevant as far as standard conformance is concerned.
[snip]
Wil
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/762b759e-76e8-4ade-9fd0-0582d9e5112c%40isocpp.org.
------=_Part_649_1708208607.1470082659407
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br>On Monday, August 1, 2016 at 9:38:34 PM UTC+2, Thiago =
Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On segunda-feir=
a, 1 de agosto de 2016 12:13:10 PDT Wil Evers wrote:
<br>> On Monday, August 1, 2016 at 5:34:11 PM UTC+2, Thiago Macieira wro=
te:
<br>> Sounds like you need to fix your build system. Since the effect of=
NDEBUG
<br>> is defined in the standard, I would expect any build system, on an=
y
<br>> platform, do #define NDEBUG in release builds, it it makes such a
<br>> distinction. If it doesn't, you have more serious problems to =
worry about.
<br>
<br>I disagree. The standard only talks about assert.h, not other features.=
That=20
<br>has nothing to do with release mode and debug mode. And maybe I want=20
<br>assertions left in my code, even in release mode, so automatically doin=
g it is=20
<br>not a good idea.<br></blockquote><div><br>You were complaining about yo=
ur build system not disabling assertions when you expected it to. To me, th=
at still sounds like a problem in your build system.<br><br>That said, I ag=
ree that it should allow for an override to enable (standard) assertions in=
release mode (possibly for a specific set of source files), but only when =
explicitly told=C2=A0 to do so.=C2=A0<br></div><div>=C2=A0</div><blockquote=
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1=
px #ccc solid;padding-left: 1ex;">The buildsystem should be agnostic and no=
t define things I don't want it to.=20
<br>And besides, in a Qt-centric buildsystem (like qmake), it would define=
=20
<br>QT_NO_DEBUG, =C2=A0not NDEBUG.<br></blockquote><div><br>Qt is not the s=
tandard. The standard only talks about the NDEBUG macro. If Qt ignores its =
intended usage, then that's a compliance issue, among a few others, wit=
h Qt.<br><br>[snip]<br><br></div><blockquote class=3D"gmail_quote" style=3D=
"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex=
;">> The point of NDEBUG is to generate *different code* in different
<br>> build configurations.
<br>
<br>And so is QT_NO_DEBUG, QT_NO_DEBUG_OUTPUT, QT_FORCE_ASSERTS,=20
<br>QT_NO_CAST_FROM_ASCII, QT_NO_CAST_TO_ASCII, and many other flags.</bloc=
kquote><div><br>Interesting, but irrelevant as far as standard conformance =
is concerned.<br><br>[snip]<br><br>Wil<br><br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/762b759e-76e8-4ade-9fd0-0582d9e5112c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/762b759e-76e8-4ade-9fd0-0582d9e5112c=
%40isocpp.org</a>.<br />
------=_Part_649_1708208607.1470082659407--
------=_Part_648_616353570.1470082659406--
.
Author: gmisocpp@gmail.com
Date: Mon, 1 Aug 2016 15:34:41 -0700 (PDT)
Raw View
------=_Part_4868_363282526.1470090881373
Content-Type: multipart/alternative;
boundary="----=_Part_4869_1040314597.1470090881373"
------=_Part_4869_1040314597.1470090881373
Content-Type: text/plain; charset=UTF-8
Hi Thiagp
On Tuesday, August 2, 2016 at 3:41:19 AM UTC+12, Thiago Macieira wrote:
>
> On domingo, 31 de julho de 2016 23:54:11 PDT gmis...@gmail.com
> <javascript:> wrote:
> > If this means someone could configure a program to get a basic stack
> trace
> > on program failure and also be able to dump that on demand and all
> without
> > having to know anything special about the platform or compiler or debug
> > options and without a lot of stress on vendors to power it, what's so
> > unreasonable?
>
> You know what could be a reasonable suggestion:
>
> a) add a function std::dump_backtrace, whose behaviour is suggested by the
> standard, but a compliant implementation could simply do nothing.
>
> b) let the user do:
> std::set_terminate_handler(std::dump_backtrace);
>
> Note that this won't catch Unix signals, like SIGSEGV or SIGABRT. If you
> want
> that, you should instead use signal(2) or sigaction(2). That will also
> catch
> uncaught exceptions, since the termination handler usually raises SIGABRT.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Software Architect - Intel Open Source Technology Center
>
a) is exactly what I was proposing.
b) would come under what I referred to as spicing things up. But I agree.
But to elaborate I purposely didn't dig into b) yet - spicing things up
- because I wanted to avoid people using it to prove that a minimum viable
product was not possible. Because I think it is and the start of this
thread was beginning to go like most of the threads on here go with people
saying "oh that's not possible" because they are overly focusing on what
people say rather than helping them achieve what they are trying to achieve
or inching towards their goal.
For example, Nicols initial responses more or less read (to me) as
saying "Hey OP why would you want that kind of useless vague voodoo and in
any case it's not possible because the Standard doesn't do black magic."
Yet with a bit of support people are now (starting) to look at the OP's
idea as viable or at least more favourably.
I know everyone has bad days (me too) but I'd generally like to see this
forum adopt a more nurturing tone to posters. I think that starts by more
people embracing the concept that you can nurture an idea without having to
adopt it, nor kill it or even agree with it. And not getting overly tied up
nit picking too early. Perhaps it's like interviewing with the style of
helping people find out what people know by giving them the answers to what
they don't know instead of just going "ding, wrong answer, you fired" at
the first hurdle.
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/0879ca92-7492-43a3-8b1a-f123fd1d01a4%40isocpp.org.
------=_Part_4869_1040314597.1470090881373
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi Thiagp<br><br>On Tuesday, August 2, 2016 at 3:41:19 AM =
UTC+12, Thiago Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204=
, 204); border-left-width: 1px; border-left-style: solid;">On domingo, 31 d=
e julho de 2016 23:54:11 PDT <a onmousedown=3D"this.href=3D'javascript:=
';return true;" onclick=3D"this.href=3D'javascript:';return tru=
e;" href=3D"javascript:" target=3D"_blank" rel=3D"nofollow" gdf-obfuscated-=
mailto=3D"goPhVbWwBgAJ">gmis...@gmail.com</a> wrote:
<br>> If this means someone could configure a program to get a basic sta=
ck trace=20
<br>> on program failure and also be able to dump that on demand and all=
without=20
<br>> having to know anything special about the platform or compiler or =
debug=20
<br>> options and without a lot of stress on vendors to power it, what&#=
39;s so=20
<br>> unreasonable?
<br>
<br>You know what could be a reasonable suggestion:
<br>
<br>a) add a function std::dump_backtrace, whose behaviour is suggested by =
the=20
<br>standard, but a compliant implementation could simply do nothing.
<br>
<br>b) let the user do:
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0std::set_terminate_<wbr=
>handler(std::dump_backtrace);
<br>
<br>Note that this won't catch Unix signals, like SIGSEGV or SIGABRT. I=
f you want=20
<br>that, you should instead use signal(2) or sigaction(2). That will also =
catch=20
<br>uncaught exceptions, since the termination handler usually raises SIGAB=
RT.
<br>
<br>--=20
<br>Thiago Macieira - thiago (AT) <a onmousedown=3D"this.href=3D'http:/=
/www.google.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x3dD\x26sntz\x3d1=
\x26usg\x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return true;" onclick=3D=
"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fmacieira.info=
\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';=
return true;" href=3D"http://macieira.info" target=3D"_blank" rel=3D"nofoll=
ow">macieira.info</a> - thiago (AT) <a onmousedown=3D"this.href=3D'http=
://www.google.com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1\x26=
usg\x3dAFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return true;" onclick=3D"thi=
s.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3d=
D\x26sntz\x3d1\x26usg\x3dAFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return tru=
e;" href=3D"http://kde.org" target=3D"_blank" rel=3D"nofollow">kde.org</a>
<br>=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center
<br></blockquote><div><br></div><div>=C2=A0</div><div>a) is exactly=C2=A0wh=
at I was proposing.</div><div><br></div><div>b) would come under what I ref=
erred to as spicing things up. But I agree.</div><div><br></div><div>But to=
elaborate I purposely didn't dig into=C2=A0b) yet - spicing things up =
-=C2=A0because I wanted to=C2=A0avoid people using it to prove that a minim=
um viable product was not possible. Because I think=C2=A0it is and the star=
t of this thread was beginning to go like most of the threads on here go wi=
th people saying "oh that's not possible" because they are=C2=
=A0overly focusing on what people say rather than helping them achieve what=
they are trying to achieve or inching towards their goal.</div><div><br></=
div><div>For example, Nicols=C2=A0initial responses more or less read (to m=
e) as saying=C2=A0"Hey OP why would you want that kind of=C2=A0useless=
=C2=A0vague=C2=A0voodoo and=C2=A0in any=C2=A0case=C2=A0it's not possibl=
e because the Standard doesn't do black magic." Yet=C2=A0with a bi=
t of support people are now (starting) to look at the OP's idea as viab=
le or at least more favourably.</div><div><br></div><div>I=C2=A0 know every=
one has bad days (me too) but I'd generally like to see this forum adop=
t a more nurturing tone to posters.=C2=A0I think that starts by=C2=A0more p=
eople embracing the=C2=A0concept=C2=A0that you can nurture an idea without =
having to adopt it,=C2=A0nor kill it or even agree with it. And not getting=
overly tied up nit picking too early. Perhaps=C2=A0it's like interview=
ing with the style of helping people find out what people know=C2=A0by givi=
ng them the answers to what they don't know instead of just going "=
;ding, wrong answer, you fired" at the first hurdle.</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/0879ca92-7492-43a3-8b1a-f123fd1d01a4%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/0879ca92-7492-43a3-8b1a-f123fd1d01a4=
%40isocpp.org</a>.<br />
------=_Part_4869_1040314597.1470090881373--
------=_Part_4868_363282526.1470090881373--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Mon, 01 Aug 2016 16:33:26 -0700
Raw View
On segunda-feira, 1 de agosto de 2016 13:17:39 PDT Wil Evers wrote:
> > The buildsystem should be agnostic and not define things I don't want it
> > to.
> > And besides, in a Qt-centric buildsystem (like qmake), it would define
> > QT_NO_DEBUG, not NDEBUG.
>
> Qt is not the standard. The standard only talks about the NDEBUG macro. If
> Qt ignores its intended usage, then that's a compliance issue, among a few
> others, with Qt.
The standard does not say anything about NDEBUG except in connection to the
assert macro's behaviour ([assertions.assert], [using.headers] and in a note
in [dcl.attr.unused]). From the point of view of the standard, the NDEBUG
macro is exclusively related to NDEBUG.
Therefore, I can argue that using it for anything besides that would be wrong
and, therefore, Qt creating its own macro is more standards-compliant than
other code that reacts to NDEBUG. (Though I'm not going to)
What I will argue is that a library that is not the Standards Library is, by
the very definition, not part of the Standard. It needs to be written compliant
with the core language standard and using the Standard Library in a compliant
manner, but that library itself is never subject to the standard. Therefore,
talking about a "standard-compliant non-standard library" is nonsensical.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2879858.N9MJM9KVQt%40tjmaciei-mobl1.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Mon, 01 Aug 2016 16:39:53 -0700
Raw View
On segunda-feira, 1 de agosto de 2016 15:34:41 PDT gmisocpp@gmail.com wrote:
> > a) add a function std::dump_backtrace, whose behaviour is suggested by the
> > standard, but a compliant implementation could simply do nothing.
> >
> > b) let the user do:
> > std::set_terminate_handler(std::dump_backtrace);
> a) is exactly what I was proposing.
>
> b) would come under what I referred to as spicing things up. But I agree.
>
> But to elaborate I purposely didn't dig into b) yet - spicing things up
> - because I wanted to avoid people using it to prove that a minimum viable
> product was not possible. Because I think it is and the start of this
> thread was beginning to go like most of the threads on here go with people
> saying "oh that's not possible" because they are overly focusing on what
> people say rather than helping them achieve what they are trying to achieve
> or inching towards their goal.
That's not how I read it. This thread started talking about exceptions and
adding stack frame information to the exceptions, which adds cost and violates
the "don't pay for what you don't use" rule. Adding the function above has
nothing to do with exceptions and doesn't add cost if you don't ever use it.
Moreover, it's based on existing practice, tested and tried.
> I know everyone has bad days (me too) but I'd generally like to see this
> forum adopt a more nurturing tone to posters. I think that starts by more
> people embracing the concept that you can nurture an idea without having to
> adopt it, nor kill it or even agree with it. And not getting overly tied up
> nit picking too early. Perhaps it's like interviewing with the style of
> helping people find out what people know by giving them the answers to what
> they don't know instead of just going "ding, wrong answer, you fired" at
> the first hurdle.
You mean the OP that contained many factually incorrect statements and
insulted to the intelligence of the people in this list and the committee
members?
"In *C++17* will be added a lot of new features, but no of them features
improve quality of code and quickly fixing of the code."
"Exception is a good conception for error handling, but is useless in C++
implementation"
"This is the main reason that even in debug mode exception is used not often."
"In we can implement *backtrace*, but are thinking about coroutine. Without
strong *base *we cannot implement something good." (implies that the base
isn't strong and that coroutines are not good)
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2710522.gc8Iygxtk1%40tjmaciei-mobl1.
.
Author: gmisocpp@gmail.com
Date: Mon, 1 Aug 2016 19:22:35 -0700 (PDT)
Raw View
------=_Part_5567_1919500485.1470104555767
Content-Type: multipart/alternative;
boundary="----=_Part_5568_2106171269.1470104555768"
------=_Part_5568_2106171269.1470104555768
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Tuesday, August 2, 2016 at 11:39:56 AM UTC+12, Thiago Macieira wrote:
>
> On segunda-feira, 1 de agosto de 2016 15:34:41 PDT gmis...@gmail.com=20
> <javascript:> wrote:=20
> > > a) add a function std::dump_backtrace, whose behaviour is suggested b=
y=20
> the=20
> > > standard, but a compliant implementation could simply do nothing.=20
> > >=20
> > > b) let the user do:=20
> > > std::set_terminate_handler(std::dump_backtrace);=20
>
> > a) is exactly what I was proposing.=20
> >=20
> > b) would come under what I referred to as spicing things up. But I=20
> agree.=20
> >=20
> > But to elaborate I purposely didn't dig into b) yet - spicing things up=
=20
> > - because I wanted to avoid people using it to prove that a minimum=20
> viable=20
> > product was not possible. Because I think it is and the start of this=
=20
> > thread was beginning to go like most of the threads on here go with=20
> people=20
> > saying "oh that's not possible" because they are overly focusing on wha=
t=20
> > people say rather than helping them achieve what they are trying to=20
> achieve=20
> > or inching towards their goal.=20
>
> That's not how I read it. This thread started talking about exceptions an=
d=20
> adding stack frame information to the exceptions, which adds cost and=20
> violates=20
> the "don't pay for what you don't use" rule. Adding the function above ha=
s=20
> nothing to do with exceptions and doesn't add cost if you don't ever use=
=20
> it.=20
> Moreover, it's based on existing practice, tested and tried.=20
>
I read it as the OP was trying to achieve the type of feature that=20
I described, they just framed it with things that didn't seem necessary to=
=20
their goal and then those things got picked up and used to defeat the whole=
=20
idea. That's not helpful nor it seems even correct either.
> > I know everyone has bad days (me too) but I'd generally like to see=20
> this=20
> > forum adopt a more nurturing tone to posters. I think that starts by=20
> more=20
> > people embracing the concept that you can nurture an idea without havin=
g=20
> to=20
> > adopt it, nor kill it or even agree with it. And not getting overly tie=
d=20
> up=20
> > nit picking too early. Perhaps it's like interviewing with the style of=
=20
> > helping people find out what people know by giving them the answers to=
=20
> what=20
> > they don't know instead of just going "ding, wrong answer, you fired" a=
t=20
> > the first hurdle.=20
>
> You mean the OP that contained many factually incorrect statements and=20
> insulted to the intelligence of the people in this list and the committee=
=20
> members?=20
>
Yes I'm sure the OP did make a few factually incorrect statements. As did=
=20
everyone it seems. I do it all the time. But I think we need to get in the=
=20
habit of not letting inaccuracies get in the way of progress. There was=20
good to be had from the OP's post and I hate we lose that too=20
often. Correctness must not be everything otherwise we all may as well quit=
=20
this forum as only Richard Smith or Daniel Kr=C3=BCgler could participate i=
n a=20
forum based on that criteria and we all know those guys weren't born they=
=20
were genetically engineered.
=20
>
> "In *C++17* will be added a lot of new features, but no of them features=
=20
> improve quality of code and quickly fixing of the code."=20
>
> "Exception is a good conception for error handling, but is useless in C++=
=20
> implementation"=20
>
> "This is the main reason that even in debug mode exception is used not=20
> often."=20
>
> "In we can implement *backtrace*, but are thinking about coroutine.=20
> Without=20
> strong *base *we cannot implement something good." (implies that the base=
=20
> isn't strong and that coroutines are not good)=20
>
> --=20
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org=20
> Software Architect - Intel Open Source Technology Center=20
>
FWIW, I do agree the OP was not appreciating how uncharitable he was=20
sounding with his C++17 comments, but I chose to overlook that so it didn't=
=20
detract him from his goal. I personally think C++17 is exactly what it=20
should be so I'm elated with it. I got what I thought was ready and didn't=
=20
get what I wasn't sure about. And I did get some nice surprises. The OP may=
=20
be somewhat correct that his areas of interest didn't get much love, I=20
don't know, but hey now's the chance to address that. But I love C++17's=20
new if statements and it's new guarantees. I'm just keen to see=20
the momentum sustained.
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/a87b7285-9e52-4224-b882-1b6f22114b6c%40isocpp.or=
g.
------=_Part_5568_2106171269.1470104555768
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Tuesday, August 2, 2016 at 11:39:56 AM UTC+12, =
Thiago Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0p=
x 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); =
border-left-width: 1px; border-left-style: solid;">On segunda-feira, 1 de a=
gosto de 2016 15:34:41 PDT <a onmousedown=3D"this.href=3D'javascript:&#=
39;;return true;" onclick=3D"this.href=3D'javascript:';return true;=
" href=3D"javascript:" target=3D"_blank" rel=3D"nofollow" gdf-obfuscated-ma=
ilto=3D"1PJ1d9PKBgAJ">gmis...@gmail.com</a> wrote:
<br>> > a) add a function std::dump_backtrace, whose behaviour is sug=
gested by the
<br>> > standard, but a compliant implementation could simply do noth=
ing.
<br>> >=20
<br>> > b) let the user do:
<br>> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 std::set_terminate_handler(<wbr>s=
td::dump_backtrace);
<br>
<br>> a) is exactly what I was proposing.
<br>>=20
<br>> b) would come under what I referred to as spicing things up. But I=
agree.
<br>>=20
<br>> But to elaborate I purposely didn't dig into b) yet - spicing =
things up
<br>> - because I wanted to avoid people using it to prove that a minimu=
m viable
<br>> product was not possible. Because I think it is and the start of t=
his
<br>> thread was beginning to go like most of the threads on here go wit=
h people
<br>> saying "oh that's not possible" because they are ove=
rly focusing on what
<br>> people say rather than helping them achieve what they are trying t=
o achieve
<br>> or inching towards their goal.
<br>
<br>That's not how I read it. This thread started talking about excepti=
ons and=20
<br>adding stack frame information to the exceptions, which adds cost and v=
iolates=20
<br>the "don't pay for what you don't use" rule. Adding t=
he function above has=20
<br>nothing to do with exceptions and doesn't add cost if you don't=
ever use it.=20
<br>Moreover, it's based on existing practice, tested and tried.
<br></blockquote><div><br></div><div>I=C2=A0read it as the OP was trying to=
achieve=C2=A0the type of feature that I=C2=A0described, they=C2=A0just fra=
med it with things that didn't seem necessary to their goal=C2=A0and=C2=
=A0then those things=C2=A0got picked up and used to defeat the whole idea. =
That's not helpful nor it seems even correct either.</div><div><br></di=
v><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; pad=
ding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1=
px; border-left-style: solid;">
<br>> I =C2=A0know everyone has bad days (me too) but I'd generally =
like to see this
<br>> forum adopt a more nurturing tone to posters. I think that starts =
by more
<br>> people embracing the concept that you can nurture an idea without =
having to
<br>> adopt it, nor kill it or even agree with it. And not getting overl=
y tied up
<br>> nit picking too early. Perhaps it's like interviewing with the=
style of
<br>> helping people find out what people know by giving them the answer=
s to what
<br>> they don't know instead of just going "ding, wrong answer=
, you fired" at
<br>> the first hurdle.
<br>
<br>You mean the OP that contained many factually incorrect statements and=
=20
<br>insulted to the intelligence of the people in this list and the committ=
ee=20
<br>members?
<br></blockquote><div><br></div><div>Yes I'm sure the OP=C2=A0did make=
=C2=A0a few factually incorrect statements. As did everyone it seems. I do =
it all the time. But I=C2=A0think we need to get in the habit of not lettin=
g inaccuracies get in the way of progress. There=C2=A0was good to be had fr=
om the OP's post and I hate we lose that too often.=C2=A0Correctness=C2=
=A0must not be=C2=A0everything otherwise=C2=A0we all may as well quit this =
forum=C2=A0as=C2=A0only Richard Smith or Daniel Kr=C3=BCgler could particip=
ate in=C2=A0a forum=C2=A0based on that criteria and we all know those guys =
weren't born they were genetically engineered.</div><div>=C2=A0</div><b=
lockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding=
-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; =
border-left-style: solid;">
<br>"In *C++17* will be added a lot of new features, but no of them fe=
atures=20
<br>improve quality of code and quickly fixing of the code."
<br>
<br>"Exception is a good conception for error handling, but is useless=
in C++=20
<br>implementation"
<br>
<br>"This is the main reason that even in debug mode exception is used=
not often."
<br>
<br>"In we can implement *backtrace*, but are thinking about coroutine=
.. Without=20
<br>strong *base *we cannot implement something good." (implies that t=
he base=20
<br>isn't strong and that coroutines are not good)
<br>
<br>--=20
<br>Thiago Macieira - thiago (AT) <a onmousedown=3D"this.href=3D'http:/=
/www.google.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x3dD\x26sntz\x3d1=
\x26usg\x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return true;" onclick=3D=
"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fmacieira.info=
\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';=
return true;" href=3D"http://macieira.info" target=3D"_blank" rel=3D"nofoll=
ow">macieira.info</a> - thiago (AT) <a onmousedown=3D"this.href=3D'http=
://www.google.com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1\x26=
usg\x3dAFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return true;" onclick=3D"thi=
s.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3d=
D\x26sntz\x3d1\x26usg\x3dAFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return tru=
e;" href=3D"http://kde.org" target=3D"_blank" rel=3D"nofollow">kde.org</a>
<br>=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center
<br></blockquote><div><br></div><div>FWIW,=C2=A0 I do agree the OP was=C2=
=A0not appreciating how uncharitable=C2=A0he was sounding with=C2=A0his C++=
17 comments,=C2=A0but I chose to overlook that so it didn't detract him=
from his=C2=A0goal. I personally=C2=A0think C++17 is exactly what it shoul=
d be so I'm elated with it.=C2=A0I got what I thought was ready and did=
n't get what I wasn't sure about.=C2=A0And I did=C2=A0get some nice=
surprises. The OP may be somewhat correct that his areas of interest didn&=
#39;t get much love, I don't know, but hey now's the chance to addr=
ess that. But I love C++17's new if statements and it's new guarant=
ees. I'm just keen to see the=C2=A0momentum=C2=A0sustained.</div><div><=
br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a87b7285-9e52-4224-b882-1b6f22114b6c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a87b7285-9e52-4224-b882-1b6f22114b6c=
%40isocpp.org</a>.<br />
------=_Part_5568_2106171269.1470104555768--
------=_Part_5567_1919500485.1470104555767--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Mon, 01 Aug 2016 21:06:41 -0700
Raw View
On segunda-feira, 1 de agosto de 2016 19:22:35 PDT gmisocpp@gmail.com wrote:
> FWIW, I do agree the OP was not appreciating how uncharitable he was
> sounding with his C++17 comments, but I chose to overlook that so it didn't
> detract him from his goal. I personally think C++17 is exactly what it
> should be so I'm elated with it. I got what I thought was ready and didn't
> get what I wasn't sure about. And I did get some nice surprises. The OP may
> be somewhat correct that his areas of interest didn't get much love, I
> don't know, but hey now's the chance to address that. But I love C++17's
> new if statements and it's new guarantees. I'm just keen to see
> the momentum sustained.
I'm not so kind, as you can see from my first reply to the OP.
There are a few people who have earned the right to be uncharitable. A few
others have earned the make sarcastic or ironic comments.
An unknown person in this list has not earned those rights yet. If you start
by insulting, intentionally or not, people will be on the defensive. It's up
to the poster to either prove the credentials or have the humility to admit
where gaps in his/her knowledge may exist.
And yes, technical discussion to this level often requires a good command of
English. Sorry, that's reality.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/29449523.5IumCeXOX0%40tjmaciei-mobl1.
.
Author: Wil Evers <wileversmod@gmail.com>
Date: Mon, 1 Aug 2016 23:12:06 -0700 (PDT)
Raw View
------=_Part_1767_1037402611.1470118326121
Content-Type: multipart/alternative;
boundary="----=_Part_1768_1501570015.1470118326121"
------=_Part_1768_1501570015.1470118326121
Content-Type: text/plain; charset=UTF-8
On Tuesday, August 2, 2016 at 1:33:29 AM UTC+2, Thiago Macieira wrote:
>
> On segunda-feira, 1 de agosto de 2016 13:17:39 PDT Wil Evers wrote:
> > > The buildsystem should be agnostic and not define things I don't want
> it
> > > to.
> > > And besides, in a Qt-centric buildsystem (like qmake), it would define
> > > QT_NO_DEBUG, not NDEBUG.
> >
> > Qt is not the standard. The standard only talks about the NDEBUG macro.
> If
> > Qt ignores its intended usage, then that's a compliance issue, among a
> few
> > others, with Qt.
>
> The standard does not say anything about NDEBUG except in connection to
> the
> assert macro's behaviour ([assertions.assert], [using.headers] and in a
> note
> in [dcl.attr.unused]). From the point of view of the standard, the NDEBUG
> macro is exclusively related to NDEBUG.
>
> Therefore, I can argue that using it for anything besides that would be
> wrong
> and, therefore, Qt creating its own macro is more standards-compliant than
> other code that reacts to NDEBUG. (Though I'm not going to)
>
> What I will argue is that a library that is not the Standards Library is,
> by
> the very definition, not part of the Standard. It needs to be written
> compliant
> with the core language standard and using the Standard Library in a
> compliant
> manner, but that library itself is never subject to the standard.
> Therefore,
> talking about a "standard-compliant non-standard library" is nonsensical.
>
I would argue that a library or build system that ignores common practice
backed by a standard specification is harder to use than it need be.
Wil
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/8e0780e1-f297-4c1a-8182-82d6c2423ecf%40isocpp.org.
------=_Part_1768_1501570015.1470118326121
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, August 2, 2016 at 1:33:29 AM UTC+2, Thiago Mac=
ieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On segunda-feira, =
1 de agosto de 2016 13:17:39 PDT Wil Evers wrote:
<br>> > The buildsystem should be agnostic and not define things I do=
n't want it
<br>> > to.
<br>> > And besides, in a Qt-centric buildsystem (like qmake), it wou=
ld define
<br>> > QT_NO_DEBUG, =C2=A0not NDEBUG.
<br>>=20
<br>> Qt is not the standard. The standard only talks about the NDEBUG m=
acro. If
<br>> Qt ignores its intended usage, then that's a compliance issue,=
among a few
<br>> others, with Qt.
<br>
<br>The standard does not say anything about NDEBUG except in connection to=
the=20
<br>assert macro's behaviour ([assertions.assert], [using.headers] and =
in a note=20
<br>in [dcl.attr.unused]). From the point of view of the standard, the NDEB=
UG=20
<br>macro is exclusively related to NDEBUG.=20
<br>
<br>Therefore, I can argue that using it for anything besides that would be=
wrong=20
<br>and, therefore, Qt creating its own macro is more standards-compliant t=
han=20
<br>other code that reacts to NDEBUG. (Though I'm not going to)
<br>
<br>What I will argue is that a library that is not the Standards Library i=
s, by=20
<br>the very definition, not part of the Standard. It needs to be written c=
ompliant=20
<br>with the core language standard and using the Standard Library in a com=
pliant=20
<br>manner, but that library itself is never subject to the standard. There=
fore,=20
<br>talking about a "standard-compliant non-standard library" is =
nonsensical.
<br></blockquote><div><br>I would argue that a library or build system that=
ignores common practice backed by a standard specification is harder to us=
e than it need be.<br><br>Wil<br>=C2=A0<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/8e0780e1-f297-4c1a-8182-82d6c2423ecf%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/8e0780e1-f297-4c1a-8182-82d6c2423ecf=
%40isocpp.org</a>.<br />
------=_Part_1768_1501570015.1470118326121--
------=_Part_1767_1037402611.1470118326121--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Mon, 01 Aug 2016 23:35:23 -0700
Raw View
On segunda-feira, 1 de agosto de 2016 23:12:06 PDT Wil Evers wrote:
> I would argue that a library or build system that ignores common practice
> backed by a standard specification is harder to use than it need be.
What common practice? Like I said, NDEBUG is only used for assert.h. Aside
from that, I see absolutely zero uses in the standard C or C++ libraries, in
glibc as a whole (so, POSIX and GNU extensions), and a couple of uses in
sqlite3.h, eigen3, plus google log, test, and protobuf. That hardly looks like
common practice to me.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1668166.mrsY1hefZ5%40tjmaciei-mobl1.
.
Author: Wil Evers <wileversmod@gmail.com>
Date: Tue, 2 Aug 2016 00:18:15 -0700 (PDT)
Raw View
------=_Part_21_103371964.1470122295259
Content-Type: multipart/alternative;
boundary="----=_Part_22_2136370436.1470122295259"
------=_Part_22_2136370436.1470122295259
Content-Type: text/plain; charset=UTF-8
On Tuesday, August 2, 2016 at 8:35:32 AM UTC+2, Thiago Macieira wrote:
>
> On segunda-feira, 1 de agosto de 2016 23:12:06 PDT Wil Evers wrote:
> > I would argue that a library or build system that ignores common
> practice
> > backed by a standard specification is harder to use than it need be.
>
> What common practice? Like I said, NDEBUG is only used for assert.h. Aside
> from that, I see absolutely zero uses in the standard C or C++ libraries,
> in
> glibc as a whole (so, POSIX and GNU extensions), and a couple of uses in
> sqlite3.h, eigen3, plus google log, test, and protobuf. That hardly looks
> like
> common practice to me.
>
NDEBUG is used all over the place, even when you don't see it. Every direct
or indirect call to the standard assert macro depends on the presence or
absence of a definition for NDEBUG. Are you arguing that using assert is
not common practice? I give up.
Wil
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/a0969adb-38b1-450c-b4b7-2c5cf3bef4db%40isocpp.org.
------=_Part_22_2136370436.1470122295259
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, August 2, 2016 at 8:35:32 AM UTC+2, Thiago Mac=
ieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On segunda-feira, =
1 de agosto de 2016 23:12:06 PDT Wil Evers wrote:
<br>> I would argue that a library or build system that ignores common p=
ractice=20
<br>> backed by a standard specification is harder to use than it need b=
e.
<br>
<br>What common practice? Like I said, NDEBUG is only used for assert.h. As=
ide=20
<br>from that, I see absolutely zero uses in the standard C or C++ librarie=
s, in=20
<br>glibc as a whole (so, POSIX and GNU extensions), and a couple of uses i=
n=20
<br>sqlite3.h, eigen3, plus google log, test, and protobuf. That hardly loo=
ks like=20
<br>common practice to me.
<br></blockquote><div><br>NDEBUG is used all over the place, even when you =
don't see it. Every direct or indirect call to the standard assert macr=
o depends on the presence or absence of a definition for NDEBUG. Are you ar=
guing that using assert is not common practice? I give up.<br><br>Wil<br><b=
r></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a0969adb-38b1-450c-b4b7-2c5cf3bef4db%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a0969adb-38b1-450c-b4b7-2c5cf3bef4db=
%40isocpp.org</a>.<br />
------=_Part_22_2136370436.1470122295259--
------=_Part_21_103371964.1470122295259--
.
Author: Reza Jahanbakhshi <reza.jahanbakhshi@gmail.com>
Date: Tue, 2 Aug 2016 16:20:44 +0800
Raw View
--047d7bacbfb6c6332305391264db
Content-Type: text/plain; charset=UTF-8
>
> What common practice? Like I said, NDEBUG is only used for assert.h. Aside
> from that, I see absolutely zero uses in the standard C or C++ libraries,
> in
> glibc as a whole (so, POSIX and GNU extensions), and a couple of uses in
> sqlite3.h, eigen3, plus google log, test, and protobuf. That hardly looks
> like
> common practice to me.
NDEBUG is also used in boost libraries to check debug/release configuration
at compile-time. For example I can name test, circular_buffer, concepts,
container, geometry, gil, hana, graph, interprocess, intrusive, python,
range, serialization, wave and preprocessor. And it's not only used to
enable/disable assertions as far as I can see. For example in gil, numeric
and multiprecision it is used to enable some optimization and in graph,
intrusive, python, range, serialization, wave and interprocess it's used to
enable/disable some sanity checks. I'm not saying it's a standard way to
check compile-time debug/release mode in general but if it was me I would
choose something that already exists instead of introducing new tools (As
far as it satisfies my requirements of course). And fortunately the name is
NDEBUG and not NASSERT so it doesn't look like a dirty hack too.
On Tue, Aug 2, 2016 at 3:18 PM, Wil Evers <wileversmod@gmail.com> wrote:
> On Tuesday, August 2, 2016 at 8:35:32 AM UTC+2, Thiago Macieira wrote:
>>
>> On segunda-feira, 1 de agosto de 2016 23:12:06 PDT Wil Evers wrote:
>> > I would argue that a library or build system that ignores common
>> practice
>> > backed by a standard specification is harder to use than it need be.
>>
>> What common practice? Like I said, NDEBUG is only used for assert.h.
>> Aside
>> from that, I see absolutely zero uses in the standard C or C++ libraries,
>> in
>> glibc as a whole (so, POSIX and GNU extensions), and a couple of uses in
>> sqlite3.h, eigen3, plus google log, test, and protobuf. That hardly looks
>> like
>> common practice to me.
>>
>
> NDEBUG is used all over the place, even when you don't see it. Every
> direct or indirect call to the standard assert macro depends on the
> presence or absence of a definition for NDEBUG. Are you arguing that using
> assert is not common practice? I give up.
>
> Wil
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/a0969adb-38b1-450c-b4b7-2c5cf3bef4db%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/a0969adb-38b1-450c-b4b7-2c5cf3bef4db%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALb3uoZg%2BK6YSQFcAcTF2y72_VvaEcnXYNt3%2Bh_nS%2Bz7WQYTgA%40mail.gmail.com.
--047d7bacbfb6c6332305391264db
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:r=
gb(204,204,204);padding-left:1ex"><span style=3D"font-size:12.8px">What com=
mon practice? Like I said, NDEBUG is only used for assert.h. Aside</span><b=
r style=3D"font-size:12.8px"><span style=3D"font-size:12.8px">from that, I =
see absolutely zero uses in the standard C or C++ libraries, in</span><br s=
tyle=3D"font-size:12.8px"><span style=3D"font-size:12.8px">glibc as a whole=
(so, POSIX and GNU extensions), and a couple of uses in</span><br style=3D=
"font-size:12.8px"><span style=3D"font-size:12.8px">sqlite3.h, eigen3, plus=
google log, test, and protobuf. That hardly looks like</span><br style=3D"=
font-size:12.8px"><span style=3D"font-size:12.8px">common practice to me.</=
span></blockquote><div>=C2=A0</div><div>NDEBUG is also used in boost librar=
ies to check debug/release configuration at compile-time. For example I can=
name test, circular_buffer, concepts, container, geometry, gil, hana, grap=
h, interprocess, intrusive, python, range, serialization, wave and preproce=
ssor. And it's not only used to enable/disable assertions as far as I c=
an see. For example in gil, numeric and multiprecision=C2=A0it is used to e=
nable some optimization and in graph, intrusive, python, range, serializati=
on, wave=C2=A0and interprocess it's used to enable/disable some sanity =
checks. I'm not saying it's a standard way to check compile-time de=
bug/release mode in general but if it was me I would choose something that =
already exists instead of introducing new tools (As far as it satisfies my =
requirements of course). And fortunately the name is NDEBUG and not NASSERT=
so it doesn't look like a dirty hack too.</div></div><div class=3D"gma=
il_extra"><br><div class=3D"gmail_quote">On Tue, Aug 2, 2016 at 3:18 PM, Wi=
l Evers <span dir=3D"ltr"><<a href=3D"mailto:wileversmod@gmail.com" targ=
et=3D"_blank">wileversmod@gmail.com</a>></span> wrote:<br><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><div dir=3D"ltr"><span class=3D"">On Tuesday, August 2, 20=
16 at 8:35:32 AM UTC+2, Thiago Macieira wrote:<blockquote class=3D"gmail_qu=
ote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding=
-left:1ex">On segunda-feira, 1 de agosto de 2016 23:12:06 PDT Wil Evers wro=
te:
<br>> I would argue that a library or build system that ignores common p=
ractice=20
<br>> backed by a standard specification is harder to use than it need b=
e.
<br>
<br>What common practice? Like I said, NDEBUG is only used for assert.h. As=
ide=20
<br>from that, I see absolutely zero uses in the standard C or C++ librarie=
s, in=20
<br>glibc as a whole (so, POSIX and GNU extensions), and a couple of uses i=
n=20
<br>sqlite3.h, eigen3, plus google log, test, and protobuf. That hardly loo=
ks like=20
<br>common practice to me.
<br></blockquote></span><div><br>NDEBUG is used all over the place, even wh=
en you don't see it. Every direct or indirect call to the standard asse=
rt macro depends on the presence or absence of a definition for NDEBUG. Are=
you arguing that using assert is not common practice? I give up.<br><br>Wi=
l<br><br></div></div><span class=3D"">
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a0969adb-38b1-450c-b4b7-2c5cf3bef4db%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/a0969adb-38b1-=
450c-b4b7-2c5cf3bef4db%40isocpp.org</a>.<br>
</blockquote></div><br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALb3uoZg%2BK6YSQFcAcTF2y72_VvaEcnXYN=
t3%2Bh_nS%2Bz7WQYTgA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALb3uoZg%2=
BK6YSQFcAcTF2y72_VvaEcnXYNt3%2Bh_nS%2Bz7WQYTgA%40mail.gmail.com</a>.<br />
--047d7bacbfb6c6332305391264db--
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Tue, 2 Aug 2016 09:25:02 -0400
Raw View
On 2016-08-01 19:33, Thiago Macieira wrote:
> On segunda-feira, 1 de agosto de 2016 13:17:39 PDT Wil Evers wrote:
>> Qt is not the standard. The standard only talks about the NDEBUG macro. If
>> Qt ignores its intended usage, then that's a compliance issue, among a few
>> others, with Qt.
>
> The standard does not say anything about NDEBUG except in connection to the
> assert macro's behaviour ([assertions.assert], [using.headers] and in a note
> in [dcl.attr.unused]). From the point of view of the standard, the NDEBUG
> macro is exclusively related to NDEBUG.
> [...]
> What I will argue is that a library that is not the Standards Library is, by
> the very definition, not part of the Standard. It needs to be written compliant
> with the core language standard and using the Standard Library in a compliant
> manner, but that library itself is never subject to the standard. Therefore,
> talking about a "standard-compliant non-standard library" is nonsensical.
I'll throw in another point here... maybe I want debugging stuff (e.g.
asserts) in my application *but not in the libraries I use* (e.g. Qt).
In fact, I will throw out a specific example: Python. Python has this
"wonderful" notion of providing a different ABI for debug and release
modes, but they also have a philosophical objection to providing debug
libraries. This means that the only (sane) way to build your
Python-using application with full debugging (i.e. not defining NDEBUG)
*is to also build Python yourself*.
This is sheer idiocy that does nothing but make developers' lives
harder, and I *applaud* Qt for not making the same boneheaded mistake.
If Python had done the *rational* thing and used some other symbol to
decide if Python itself has debugging enabled (like Qt's QT_NO_DEBUG),
this problem wouldn't exist.
So, please, drop this silly notion that the entire world must use the
exact same symbol to determine if debugging is enabled or not. Doing so
is unnecessarily restrictive, at best.
--
Matthew
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/57A09F2E.8090007%40gmail.com.
.
Author: Viacheslav Usov <via.usov@gmail.com>
Date: Tue, 2 Aug 2016 15:42:08 +0200
Raw View
--001a114102423d115f053916e2d4
Content-Type: text/plain; charset=UTF-8
On Mon, Aug 1, 2016 at 7:45 PM, Tom Honermann <tom@honermann.net> wrote:
> I do think that existing implementations can dispense with dynamic
allocation, at least for non-nested exceptions.
As I indicated earlier, this moves the discussion into a hypothetical
domain. If you think it acceptable to postulate that some implementations
dispense with *dynamic* allocation through the use of *magic* allocation,
then I could equally think it acceptable to postulate *magic* exceptions
that need no memory allocation at all to capture a stack trace. I do not
think either postulate is ultimately convincing.
Just to stay in the real domain, your postulate is true for one major
implementation, and mine can also be true for the same implementation. It
is MSVC, on the AMD64 architecture at least, where the underlying hardware
stack (as opposed to the abstract machine's stack) is not unwound till an
exception is fully handled (i.e., a catch clause exits normally), and the
exception object is constructed on the stack. I cannot reference my
sources, but this can be easily confirmed with a debugger.
Since the entire stack is present till exception handling is fully
complete, it can be captured directly without any intermediate allocations.
> Such implementations would necessarily dynamically allocate for copying
an exception object to satisfy lifetime requirements for
std::current_exception(), so I do accept that dynamic allocation is
required in some cases.
In which case an implementation can just have a statically-sized list that
handles "most common cases", and an overflow list that handles everything
else. Then your acceptance criterion is trivially met.
> There is a distinction between dynamic allocation performed by the
constructor of a thrown object vs the allocation for the thrown object
itself.
Does dynamic allocation solely in the constructor of a thrown object meet
your criteria? This can, again, be trivially accomplished for a
variable-length list of pointers.
Cheers,
V.
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg2Pqsi%2BehSQcZpuzeTcc85707cLyGgcVyJe6PhLvdOzsw%40mail.gmail.com.
--001a114102423d115f053916e2d4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Aug 1, 2016 at 7:45 PM, Tom Honermann <span dir=3D"ltr"><<a href=3D"=
mailto:tom@honermann.net" target=3D"_blank">tom@honermann.net</a>></span=
> wrote:<br><div><br></div><div>> I do think that existing implementatio=
ns can dispense with dynamic
allocation, at least for non-nested exceptions.</div><div><br></div><di=
v>As I indicated earlier, this moves the discussion into a hypothetical dom=
ain. If you think it acceptable to postulate that some implementations disp=
ense with <i>dynamic</i> allocation through the use of <i>magic</i>=C2=A0al=
location, then I could equally think it acceptable to postulate <i>magic</i=
>=C2=A0exceptions that need no memory allocation at all to capture a stack =
trace. I do not think either postulate is ultimately convincing.</div><div>=
<br></div><div>Just to stay in the real domain, your postulate is true for =
one major implementation, and mine can also be true for the same implementa=
tion. It is MSVC, on the AMD64 architecture at least, where the underlying =
hardware stack (as opposed to the abstract machine's stack) is not unwo=
und till an exception is fully handled (i.e., a catch clause exits normally=
), and the exception object is constructed on the stack. I cannot reference=
my sources, but this can be easily confirmed with a debugger.</div><div><b=
r></div><div>Since the entire stack is present till exception handling is f=
ully complete, it can be captured directly without any intermediate allocat=
ions.</div><div><br></div><div>> =C2=A0Such
implementations would necessarily dynamically allocate for copying
an exception object to satisfy lifetime requirements for
std::current_exception(), so I do accept that dynamic allocation is
required in some cases.<br></div><div><br></div><div>In which case an i=
mplementation can just have a statically-sized list that handles "most=
common cases", and an overflow list that handles everything else. The=
n your acceptance criterion is trivially met.</div><div><br></div><div>>=
=C2=A0There is a distinction between dynamic allocation performed by the
constructor of a thrown object vs the allocation for the thrown
object itself.</div><div><br></div><div>Does dynamic allocation solely =
in the constructor of a thrown object meet your criteria? This can, again, =
be trivially accomplished for a variable-length list of pointers.</div><div=
><br></div><div>Cheers,<br></div><div>V.</div><div><br></div></div></div></=
div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAA7YVg2Pqsi%2BehSQcZpuzeTcc85707cLyG=
gcVyJe6PhLvdOzsw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg2Pqsi%2B=
ehSQcZpuzeTcc85707cLyGgcVyJe6PhLvdOzsw%40mail.gmail.com</a>.<br />
--001a114102423d115f053916e2d4--
.
Author: Wil Evers <wileversmod@gmail.com>
Date: Tue, 2 Aug 2016 06:58:18 -0700 (PDT)
Raw View
------=_Part_447_1106530365.1470146298700
Content-Type: multipart/alternative;
boundary="----=_Part_448_155083028.1470146298700"
------=_Part_448_155083028.1470146298700
Content-Type: text/plain; charset=UTF-8
On Tuesday, August 2, 2016 at 3:25:05 PM UTC+2, Matthew Woehlke wrote:
>
> On 2016-08-01 19:33, Thiago Macieira wrote:
> > On segunda-feira, 1 de agosto de 2016 13:17:39 PDT Wil Evers wrote:
> >> Qt is not the standard. The standard only talks about the NDEBUG macro.
> If
> >> Qt ignores its intended usage, then that's a compliance issue, among a
> few
> >> others, with Qt.
> >
> > The standard does not say anything about NDEBUG except in connection to
> the
> > assert macro's behaviour ([assertions.assert], [using.headers] and in a
> note
> > in [dcl.attr.unused]). From the point of view of the standard, the
> NDEBUG
> > macro is exclusively related to NDEBUG.
> > [...]
> > What I will argue is that a library that is not the Standards Library
> is, by
> > the very definition, not part of the Standard. It needs to be written
> compliant
> > with the core language standard and using the Standard Library in a
> compliant
> > manner, but that library itself is never subject to the standard.
> Therefore,
> > talking about a "standard-compliant non-standard library" is
> nonsensical.
>
> I'll throw in another point here... maybe I want debugging stuff (e.g.
> asserts) in my application *but not in the libraries I use* (e.g. Qt).
>
> In fact, I will throw out a specific example: Python. Python has this
> "wonderful" notion of providing a different ABI for debug and release
> modes, but they also have a philosophical objection to providing debug
> libraries. This means that the only (sane) way to build your
> Python-using application with full debugging (i.e. not defining NDEBUG)
> *is to also build Python yourself*.
>
> This is sheer idiocy that does nothing but make developers' lives
> harder, and I *applaud* Qt for not making the same boneheaded mistake.
> If Python had done the *rational* thing and used some other symbol to
> decide if Python itself has debugging enabled (like Qt's QT_NO_DEBUG),
> this problem wouldn't exist.
>
> So, please, drop this silly notion that the entire world must use the
> exact same symbol to determine if debugging is enabled or not. Doing so
> is unnecessarily restrictive, at best.
>
I disagree. If I build a library without #defining NDEBUG, I expect
assertions to be enabled, and if I build it with NDEBUG defined, I expect
assertions to be disabled. The reason NDEBUG is in the standard is the
provide a uniform mechanism for controlling that, without having to know or
worry about any library-specific mechanism.
That said, I would have no objection to a library-specific override of that
default, which would only kick in if explicitly specified by the user.
Wil
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ac9fbf8d-3cf9-486a-b0ca-acd0a2874925%40isocpp.org.
------=_Part_448_155083028.1470146298700
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Tuesday, August 2, 2016 at 3:25:05 PM UTC+2, Ma=
tthew Woehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2016-08=
-01 19:33, Thiago Macieira wrote:
<br>> On segunda-feira, 1 de agosto de 2016 13:17:39 PDT Wil Evers wrote=
:
<br>>> Qt is not the standard. The standard only talks about the NDEB=
UG macro. If
<br>>> Qt ignores its intended usage, then that's a compliance is=
sue, among a few
<br>>> others, with Qt.
<br>>=20
<br>> The standard does not say anything about NDEBUG except in connecti=
on to the=20
<br>> assert macro's behaviour ([assertions.assert], [using.headers]=
and in a note=20
<br>> in [dcl.attr.unused]). From the point of view of the standard, the=
NDEBUG=20
<br>> macro is exclusively related to NDEBUG.
<br>> [...]
<br>> What I will argue is that a library that is not the Standards Libr=
ary is, by=20
<br>> the very definition, not part of the Standard. It needs to be writ=
ten compliant=20
<br>> with the core language standard and using the Standard Library in =
a compliant=20
<br>> manner, but that library itself is never subject to the standard. =
Therefore,=20
<br>> talking about a "standard-compliant non-standard library"=
; is nonsensical.
<br>
<br>I'll throw in another point here... maybe I want debugging stuff (e=
..g.
<br>asserts) in my application *but not in the libraries I use* (e.g. Qt).
<br>
<br>In fact, I will throw out a specific example: Python. Python has this
<br>"wonderful" notion of providing a different ABI for debug and=
release
<br>modes, but they also have a philosophical objection to providing debug
<br>libraries. This means that the only (sane) way to build your
<br>Python-using application with full debugging (i.e. not defining NDEBUG)
<br>*is to also build Python yourself*.
<br>
<br>This is sheer idiocy that does nothing but make developers' lives
<br>harder, and I *applaud* Qt for not making the same boneheaded mistake.
<br>If Python had done the *rational* thing and used some other symbol to
<br>decide if Python itself has debugging enabled (like Qt's QT_NO_DEBU=
G),
<br>this problem wouldn't exist.
<br>
<br>So, please, drop this silly notion that the entire world must use the
<br>exact same symbol to determine if debugging is enabled or not. Doing so
<br>is unnecessarily restrictive, at best.<br></blockquote><div><br>I disag=
ree. If I build a library without #defining NDEBUG, I expect assertions to =
be enabled, and if I build it with NDEBUG defined, I expect assertions to b=
e disabled. The reason NDEBUG is in the standard is the provide a uniform m=
echanism for controlling that, without having to know or worry about any li=
brary-specific mechanism.<br><br>That said, I would have no objection to a =
library-specific override of that default, which would only kick in if expl=
icitly specified by the user.<br><br>Wil<br><br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/ac9fbf8d-3cf9-486a-b0ca-acd0a2874925%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ac9fbf8d-3cf9-486a-b0ca-acd0a2874925=
%40isocpp.org</a>.<br />
------=_Part_448_155083028.1470146298700--
------=_Part_447_1106530365.1470146298700--
.
Author: Reza Jahanbakhshi <reza.jahanbakhshi@gmail.com>
Date: Tue, 2 Aug 2016 07:04:12 -0700 (PDT)
Raw View
------=_Part_3074_523757097.1470146652918
Content-Type: multipart/alternative;
boundary="----=_Part_3075_131504323.1470146652919"
------=_Part_3075_131504323.1470146652919
Content-Type: text/plain; charset=UTF-8
On Tuesday, August 2, 2016 at 9:25:05 PM UTC+8, Matthew Woehlke wrote:
>
> On 2016-08-01 19:33, Thiago Macieira wrote:
> > On segunda-feira, 1 de agosto de 2016 13:17:39 PDT Wil Evers wrote:
> >> Qt is not the standard. The standard only talks about the NDEBUG macro.
> If
> >> Qt ignores its intended usage, then that's a compliance issue, among a
> few
> >> others, with Qt.
> >
> > The standard does not say anything about NDEBUG except in connection to
> the
> > assert macro's behaviour ([assertions.assert], [using.headers] and in a
> note
> > in [dcl.attr.unused]). From the point of view of the standard, the
> NDEBUG
> > macro is exclusively related to NDEBUG.
> > [...]
> > What I will argue is that a library that is not the Standards Library
> is, by
> > the very definition, not part of the Standard. It needs to be written
> compliant
> > with the core language standard and using the Standard Library in a
> compliant
> > manner, but that library itself is never subject to the standard.
> Therefore,
> > talking about a "standard-compliant non-standard library" is
> nonsensical.
>
> I'll throw in another point here... maybe I want debugging stuff (e.g.
> asserts) in my application *but not in the libraries I use* (e.g. Qt).
>
> In fact, I will throw out a specific example: Python. Python has this
> "wonderful" notion of providing a different ABI for debug and release
> modes, but they also have a philosophical objection to providing debug
> libraries. This means that the only (sane) way to build your
> Python-using application with full debugging (i.e. not defining NDEBUG)
> *is to also build Python yourself*.
>
> This is sheer idiocy that does nothing but make developers' lives
> harder, and I *applaud* Qt for not making the same boneheaded mistake.
> If Python had done the *rational* thing and used some other symbol to
> decide if Python itself has debugging enabled (like Qt's QT_NO_DEBUG),
> this problem wouldn't exist.
>
> So, please, drop this silly notion that the entire world must use the
> exact same symbol to determine if debugging is enabled or not. Doing so
> is unnecessarily restrictive, at best.
>
> --
> Matthew
>
I agree with your argument about defining separate symbol give us more
flexibility. But let's not forget that we are talking about standard
library here not a third party library. Also we can define separate symbols
for enabling certain debugging feature for different components but they
can get their default values based on NDEBUG for consistency and
compatibility sake. This practice is used in boost libraries too. In this
specific case to disable assert we can define NASSERT and to enable
callstack we can define YCALLSTACK but both get their default values based
on NDEBUG definition if not defined explicitly. But again lets not forget
that macros are evil and we are trying to stay away from them as much as
possible. The whole argument about NDEBUG started when some posters claimed
that there is no notion of debug and release in standard and some others
mentioned that the fact that NDEBUG is defined in standard means there is a
notion of debug/release in it.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/170a105e-9f84-4275-a8b3-d3eb8caddb1d%40isocpp.org.
------=_Part_3075_131504323.1470146652919
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Tuesday, August 2, 2016 at 9:25:05 PM UTC+8, Ma=
tthew Woehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2016-08=
-01 19:33, Thiago Macieira wrote:
<br>> On segunda-feira, 1 de agosto de 2016 13:17:39 PDT Wil Evers wrote=
:
<br>>> Qt is not the standard. The standard only talks about the NDEB=
UG macro. If
<br>>> Qt ignores its intended usage, then that's a compliance is=
sue, among a few
<br>>> others, with Qt.
<br>>=20
<br>> The standard does not say anything about NDEBUG except in connecti=
on to the=20
<br>> assert macro's behaviour ([assertions.assert], [using.headers]=
and in a note=20
<br>> in [dcl.attr.unused]). From the point of view of the standard, the=
NDEBUG=20
<br>> macro is exclusively related to NDEBUG.
<br>> [...]
<br>> What I will argue is that a library that is not the Standards Libr=
ary is, by=20
<br>> the very definition, not part of the Standard. It needs to be writ=
ten compliant=20
<br>> with the core language standard and using the Standard Library in =
a compliant=20
<br>> manner, but that library itself is never subject to the standard. =
Therefore,=20
<br>> talking about a "standard-compliant non-standard library"=
; is nonsensical.
<br>
<br>I'll throw in another point here... maybe I want debugging stuff (e=
..g.
<br>asserts) in my application *but not in the libraries I use* (e.g. Qt).
<br>
<br>In fact, I will throw out a specific example: Python. Python has this
<br>"wonderful" notion of providing a different ABI for debug and=
release
<br>modes, but they also have a philosophical objection to providing debug
<br>libraries. This means that the only (sane) way to build your
<br>Python-using application with full debugging (i.e. not defining NDEBUG)
<br>*is to also build Python yourself*.
<br>
<br>This is sheer idiocy that does nothing but make developers' lives
<br>harder, and I *applaud* Qt for not making the same boneheaded mistake.
<br>If Python had done the *rational* thing and used some other symbol to
<br>decide if Python itself has debugging enabled (like Qt's QT_NO_DEBU=
G),
<br>this problem wouldn't exist.
<br>
<br>So, please, drop this silly notion that the entire world must use the
<br>exact same symbol to determine if debugging is enabled or not. Doing so
<br>is unnecessarily restrictive, at best.
<br>
<br>--=20
<br>Matthew
<br></blockquote><div><br></div><div>I agree with your argument about defin=
ing separate symbol give us more flexibility. But let's not forget that=
we are talking about standard library here not a third party library. Also=
we can define separate symbols for enabling certain debugging feature for =
different components but they can get their default values based on NDEBUG =
for consistency and compatibility sake. This practice is used in boost libr=
aries too. In this specific case to disable assert we can define NASSERT an=
d to enable callstack we can define YCALLSTACK but both get their default v=
alues based on NDEBUG definition if not defined explicitly. But again lets =
not forget that macros are evil and we are trying to stay away from them as=
much as possible. The whole argument about NDEBUG started when some poster=
s claimed that there is no notion of debug and release in standard and some=
others mentioned that the fact that NDEBUG is defined in standard means th=
ere is a notion of debug/release in it.</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/170a105e-9f84-4275-a8b3-d3eb8caddb1d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/170a105e-9f84-4275-a8b3-d3eb8caddb1d=
%40isocpp.org</a>.<br />
------=_Part_3075_131504323.1470146652919--
------=_Part_3074_523757097.1470146652918--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Tue, 02 Aug 2016 07:52:21 -0700
Raw View
On ter=C3=A7a-feira, 2 de agosto de 2016 00:18:15 PDT Wil Evers wrote:
> NDEBUG is used all over the place, even when you don't see it. Every dire=
ct
> or indirect call to the standard assert macro depends on the presence or
> absence of a definition for NDEBUG. Are you arguing that using assert is
> not common practice? I give up.
No, I'm arguing that there aren't many uses besides assert(), which means t=
hat=20
it's not standard practice to use that macro for other uses.
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/1545930.665XsnQ6gQ%40tjmaciei-mobl1.
.
Author: "D. B." <db0451@gmail.com>
Date: Tue, 2 Aug 2016 15:56:25 +0100
Raw View
--001a11468e08dc4b33053917ebce
Content-Type: text/plain; charset=UTF-8
Define "standard practice"? Via being a Standard-mentioned macro that has a
particular effect for debugging, it looks like many people end up using
NDEBUG for additional paranoid checks in their own debug builds (or is that
just me...?). So, it's not Standard... but depending on your definition and
the level of usage required to qualify, it might be a "standard practice"
in that sense.
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhF8EeqvVhrO3pM6UYJujnOAJvwkiiudRRZcMeg-ZS_Vnw%40mail.gmail.com.
--001a11468e08dc4b33053917ebce
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Define "standard practice"? Via being a Standard=
-mentioned macro that has a particular effect for debugging, it looks like =
many people end up using NDEBUG for additional paranoid checks in their own=
debug builds (or is that just me...?). So, it's not Standard... but de=
pending on your definition and the level of usage required to qualify, it m=
ight be a "standard practice" in that sense.<br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CACGiwhF8EeqvVhrO3pM6UYJujnOAJvwkiiud=
RRZcMeg-ZS_Vnw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhF8EeqvVhrO=
3pM6UYJujnOAJvwkiiudRRZcMeg-ZS_Vnw%40mail.gmail.com</a>.<br />
--001a11468e08dc4b33053917ebce--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Tue, 02 Aug 2016 07:58:38 -0700
Raw View
On ter=C3=A7a-feira, 2 de agosto de 2016 16:20:44 PDT Reza Jahanbakhshi wro=
te:
> NDEBUG is also used in boost libraries to check debug/release configurati=
on
> at compile-time. For example I can name test, circular_buffer, concepts,
> container, geometry, gil, hana, graph, interprocess, intrusive, python,
> range, serialization, wave and preprocessor.
I didn't include Boost in my search because then I would also include Qt an=
d I=20
could conclude that use of NDEBUG and QT_NO_DEBUG are equally common, as th=
ere=20
are 57 uses in Boost in 10993 header files, compared to 53 uses in Qt for 6=
705=20
header files.
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/33459805.iSYroNz2IM%40tjmaciei-mobl1.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Tue, 02 Aug 2016 08:01:09 -0700
Raw View
On ter=C3=A7a-feira, 2 de agosto de 2016 15:56:25 PDT D. B. wrote:
> Define "standard practice"? Via being a Standard-mentioned macro that has=
a
> particular effect for debugging, it looks like many people end up using
> NDEBUG for additional paranoid checks in their own debug builds (or is th=
at
> just me...?). So, it's not Standard... but depending on your definition a=
nd
> the level of usage required to qualify, it might be a "standard practice"
> in that sense.
I understand that this is the use being argued. And I have seen it argued l=
ike=20
that before. My point is that it's not very common to do it outside of Boos=
t,=20
so we can't call it "common pratice".
At best, I can conclude it is "Google pratice", since three projects from=
=20
Gooogle I have lying around (Google test, Google log and Google protobuf) a=
re=20
the largest users.
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/5099369.3WHQvKyhoE%40tjmaciei-mobl1.
.
Author: Tom Honermann <tom@honermann.net>
Date: Tue, 2 Aug 2016 11:05:44 -0400
Raw View
This is a multi-part message in MIME format.
--------------E5B7EF99C58136872362D915
Content-Type: text/plain; charset=UTF-8; format=flowed
On 8/2/2016 9:42 AM, Viacheslav Usov wrote:
> On Mon, Aug 1, 2016 at 7:45 PM, Tom Honermann <tom@honermann.net
> <mailto:tom@honermann.net>> wrote:
>
> > I do think that existing implementations can dispense with dynamic
> allocation, at least for non-nested exceptions.
>
> As I indicated earlier, this moves the discussion into a hypothetical
> domain. If you think it acceptable to postulate that some
> implementations dispense with /dynamic/ allocation through the use of
> /magic/ allocation, then I could equally think it acceptable to
> postulate /magic/ exceptions that need no memory allocation at all to
> capture a stack trace. I do not think either postulate is ultimately
> convincing.
All I am saying is that there *may* be ABIs that would require changes
to accommodate this feature. Thus, the price of the feature includes
potential ABI impact. Likewise, there is clearly some performance cost
to walking the stack to collect information for each frame, thus, there
would likely be some performance cost to existing code. Perhaps it
would be negligible, but it should be measured.
Rather than collecting a stack trace for every exception thrown, an
alternative approach would be to define a base exception class
(std::exception_with_backtrace) that captures the call stack in its
constructor. This would enable capturing a stack trace when desired
without imposing an additional cost on all exceptions. The downside of
this approach, of course, is that it places the onus of throwing an
exception with such support on the thrower rather than on the catcher
(who is in a better position to determine if the trace is desired).
>
> Just to stay in the real domain, your postulate is true for one major
> implementation, and mine can also be true for the same implementation.
> It is MSVC, on the AMD64 architecture at least, where the underlying
> hardware stack (as opposed to the abstract machine's stack) is not
> unwound till an exception is fully handled (i.e., a catch clause exits
> normally), and the exception object is constructed on the stack. I
> cannot reference my sources, but this can be easily confirmed with a
> debugger.
>
> Since the entire stack is present till exception handling is fully
> complete, it can be captured directly without any intermediate
> allocations.
I wasn't aware of that. I took very brief look at some disassembly and
it looks like MSVC restores the frame base pointer before executing the
catch handler (and uses a frame base pointer even if compiled with /Oy),
but doesn't restore the stack pointer. In theory, an implementation
that does this could delay capturing the stack until/unless it is
actually requested (or std::current_exception() is called).
>
> > Such implementations would necessarily dynamically allocate for
> copying an exception object to satisfy lifetime requirements for
> std::current_exception(), so I do accept that dynamic allocation is
> required in some cases.
>
> In which case an implementation can just have a statically-sized list
> that handles "most common cases", and an overflow list that handles
> everything else. Then your acceptance criterion is trivially met.
>
> > There is a distinction between dynamic allocation performed by the
> constructor of a thrown object vs the allocation for the thrown object
> itself.
>
> Does dynamic allocation solely in the constructor of a thrown object
> meet your criteria? This can, again, be trivially accomplished for a
> variable-length list of pointers.
To be clear, the only reason I brought this up was because of potential
impact to existing ABIs. The dynamic allocation isn't something I'm
actually concerned about.
Tom.
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/df5aadbc-9d69-73e5-25a5-2cbc7b08ebf2%40honermann.net.
--------------E5B7EF99C58136872362D915
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<div class=3D"moz-cite-prefix">On 8/2/2016 9:42 AM, Viacheslav Usov
wrote:<br>
</div>
<blockquote
cite=3D"mid:CAA7YVg2Pqsi+ehSQcZpuzeTcc85707cLyGgcVyJe6PhLvdOzsw@mail.gmail.=
com"
type=3D"cite">
<div dir=3D"ltr">
<div class=3D"gmail_extra">
<div class=3D"gmail_quote">On Mon, Aug 1, 2016 at 7:45 PM, Tom
Honermann <span dir=3D"ltr"><<a moz-do-not-send=3D"true"
href=3D"mailto:tom@honermann.net" target=3D"_blank">tom@hon=
ermann.net</a>></span>
wrote:<br>
<div><br>
</div>
<div>> I do think that existing implementations can
dispense with dynamic allocation, at least for non-nested
exceptions.</div>
<div><br>
</div>
<div>As I indicated earlier, this moves the discussion into
a hypothetical domain. If you think it acceptable to
postulate that some implementations dispense with <i>dynamic<=
/i>
allocation through the use of <i>magic</i>=C2=A0allocation,
then I could equally think it acceptable to postulate <i>magi=
c</i>=C2=A0exceptions
that need no memory allocation at all to capture a stack
trace. I do not think either postulate is ultimately
convincing.</div>
</div>
</div>
</div>
</blockquote>
All I am saying is that there *may* be ABIs that would require
changes to accommodate this feature.=C2=A0 Thus, the price of the featu=
re
includes potential ABI impact.=C2=A0 Likewise, there is clearly some
performance cost to walking the stack to collect information for
each frame, thus, there would likely be some performance cost to
existing code.=C2=A0 Perhaps it would be negligible, but it should be
measured.<br>
<br>
Rather than collecting a stack trace for every exception thrown, an
alternative approach would be to define a base exception class
(std::exception_with_backtrace) that captures the call stack in its
constructor.=C2=A0 This would enable capturing a stack trace when desir=
ed
without imposing an additional cost on all exceptions.=C2=A0 The downsi=
de
of this approach, of course, is that it places the onus of throwing
an exception with such support on the thrower rather than on the
catcher (who is in a better position to determine if the trace is
desired).<br>
<blockquote
cite=3D"mid:CAA7YVg2Pqsi+ehSQcZpuzeTcc85707cLyGgcVyJe6PhLvdOzsw@mail.gmail.=
com"
type=3D"cite">
<div dir=3D"ltr">
<div class=3D"gmail_extra">
<div class=3D"gmail_quote">
<div><br>
</div>
<div>Just to stay in the real domain, your postulate is true
for one major implementation, and mine can also be true
for the same implementation. It is MSVC, on the AMD64
architecture at least, where the underlying hardware stack
(as opposed to the abstract machine's stack) is not
unwound till an exception is fully handled (i.e., a catch
clause exits normally), and the exception object is
constructed on the stack. I cannot reference my sources,
but this can be easily confirmed with a debugger.</div>
<div><br>
</div>
<div>Since the entire stack is present till exception
handling is fully complete, it can be captured directly
without any intermediate allocations.</div>
</div>
</div>
</div>
</blockquote>
I wasn't aware of that.=C2=A0 I took very brief look at some disassembl=
y
and it looks like MSVC restores the frame base pointer before
executing the catch handler (and uses a frame base pointer even if
compiled with /Oy), but doesn't restore the stack pointer.=C2=A0 In
theory, an implementation that does this could delay capturing the
stack until/unless it is actually requested (or
std::current_exception() is called).<br>
<blockquote
cite=3D"mid:CAA7YVg2Pqsi+ehSQcZpuzeTcc85707cLyGgcVyJe6PhLvdOzsw@mail.gmail.=
com"
type=3D"cite">
<div dir=3D"ltr">
<div class=3D"gmail_extra">
<div class=3D"gmail_quote">
<div><br>
</div>
<div>> =C2=A0Such implementations would necessarily
dynamically allocate for copying an exception object to
satisfy lifetime requirements for
std::current_exception(), so I do accept that dynamic
allocation is required in some cases.<br>
</div>
<div><br>
</div>
<div>In which case an implementation can just have a
statically-sized list that handles "most common cases",
and an overflow list that handles everything else. Then
your acceptance criterion is trivially met.</div>
<div><br>
</div>
<div>> =C2=A0There is a distinction between dynamic allocati=
on
performed by the constructor of a thrown object vs the
allocation for the thrown object itself.</div>
<div><br>
</div>
<div>Does dynamic allocation solely in the constructor of a
thrown object meet your criteria? This can, again, be
trivially accomplished for a variable-length list of
pointers.</div>
</div>
</div>
</div>
</blockquote>
To be clear, the only reason I brought this up was because of
potential impact to existing ABIs.=C2=A0 The dynamic allocation isn't
something I'm actually concerned about.<br>
<br>
Tom.<br>
</body>
</html>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/df5aadbc-9d69-73e5-25a5-2cbc7b08ebf2%=
40honermann.net?utm_medium=3Demail&utm_source=3Dfooter">https://groups.goog=
le.com/a/isocpp.org/d/msgid/std-proposals/df5aadbc-9d69-73e5-25a5-2cbc7b08e=
bf2%40honermann.net</a>.<br />
--------------E5B7EF99C58136872362D915--
.
Author: Viacheslav Usov <via.usov@gmail.com>
Date: Tue, 2 Aug 2016 17:16:51 +0200
Raw View
--001a1141169ef66cac05391834f8
Content-Type: text/plain; charset=UTF-8
On Tue, Aug 2, 2016 at 5:05 PM, Tom Honermann <tom@honermann.net> wrote:
> Rather than collecting a stack trace for every exception thrown, an
alternative approach would be to define a base exception class
(std::exception_with_backtrace) that captures the call stack in its
constructor. This would enable capturing a stack trace when desired
without imposing an additional cost on all exceptions. The downside of
this approach, of course, is that it places the onus of throwing an
exception with such support on the thrower rather than on the catcher (who
is in a better position to determine if the trace is desired).
That would essentially make all exceptions thrown by the standard library
untraceable, and I think this is exactly the wrong thing to do.
Here is another idea: we can have something like
std::trace_current_exception, with semantics similar to that of
std::current_exception. The downside is that with this one cannot store
just an exception and get its stack trace later, the stack trace would need
to be dealt with when storing the exception.
Cheers,
V.
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg3BGRquBwf5bgwf1%2BaudvfGBNXsjimATYa4U9s7Y005Bg%40mail.gmail.com.
--001a1141169ef66cac05391834f8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Aug 2, 2016 at 5:05 PM, Tom Honermann <span dir=3D"ltr"><<a href=3D"=
mailto:tom@honermann.net" target=3D"_blank">tom@honermann.net</a>></span=
> wrote:<br><div><br></div><div>> Rather than collecting a stack trace f=
or every exception thrown, an
alternative approach would be to define a base exception class
(std::exception_with_backtrace) that captures the call stack in its
constructor.=C2=A0 This would enable capturing a stack trace when desir=
ed
without imposing an additional cost on all exceptions.=C2=A0 The downsi=
de
of this approach, of course, is that it places the onus of throwing
an exception with such support on the thrower rather than on the
catcher (who is in a better position to determine if the trace is
desired).</div><div><br></div><div>That would essentially make all exce=
ptions thrown by the standard library untraceable, and I think this is exac=
tly the wrong thing to do.</div><div><br></div><div>Here is another idea: w=
e can have something like std::trace_current_exception, with semantics simi=
lar to that of std::current_exception. The downside is that with this one c=
annot store just an exception and get its stack trace later, the stack trac=
e would need to be dealt with when storing the exception.</div><div><br></d=
iv><div>Cheers,</div><div>V.</div><div><br></div></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAA7YVg3BGRquBwf5bgwf1%2BaudvfGBNXsji=
mATYa4U9s7Y005Bg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg3BGRquBw=
f5bgwf1%2BaudvfGBNXsjimATYa4U9s7Y005Bg%40mail.gmail.com</a>.<br />
--001a1141169ef66cac05391834f8--
.
Author: Reza Jahanbakhshi <reza.jahanbakhshi@gmail.com>
Date: Tue, 2 Aug 2016 09:00:22 -0700 (PDT)
Raw View
------=_Part_6654_1640024799.1470153622240
Content-Type: multipart/alternative;
boundary="----=_Part_6655_1752675056.1470153622240"
------=_Part_6655_1752675056.1470153622240
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Tuesday, August 2, 2016 at 10:58:55 PM UTC+8, Thiago Macieira wrote:
>
> On ter=C3=A7a-feira, 2 de agosto de 2016 16:20:44 PDT Reza Jahanbakhshi w=
rote:=20
> > NDEBUG is also used in boost libraries to check debug/release=20
> configuration=20
> > at compile-time. For example I can name test, circular_buffer, concepts=
,=20
> > container, geometry, gil, hana, graph, interprocess, intrusive, python,=
=20
> > range, serialization, wave and preprocessor.=20
>
> I didn't include Boost in my search because then I would also include Qt=
=20
> and I=20
> could conclude that use of NDEBUG and QT_NO_DEBUG are equally common, as=
=20
> there=20
> are 57 uses in Boost in 10993 header files, compared to 53 uses in Qt for=
=20
> 6705=20
> header files.=20
>
> --=20
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org=20
> Software Architect - Intel Open Source Technology Center=20
>
>
I'm not sure if continuing this argument is going to be constructive=20
anymore in any way but just to clarify, the number of occurrence in the=20
header is not a fair measurement for its impact. For example=20
circular_buffer uses NDEBUG to define BOOST_CB_ENABLE_DEBUG and this one is=
=20
used 33 times allover circular_buffer headers. And in boost.concept NDEBUG=
=20
changes the definition of BOOST_CONCEPT_REQUIRES which essentially changes=
=20
the whole library. in boost.gil, based on NDEBUG, another=20
macro GIL_FORCEINLINE is defined which in turn is used 117 times allover=20
boost.gil headers. I can go on and on but my point is I think NDEBUG is=20
being used as one way to make optimization and diagnostic compile-time=20
decision whenever it was necessary in some boost libraries. Of course not=
=20
all libraries need such a decision and some uses other definitions like=20
BOOST_ASIO_ENABLE_BUFFER_DEBUGGING in boost asio.
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/ae5f8473-c9f1-44d4-b571-eeb3ed931c17%40isocpp.or=
g.
------=_Part_6655_1752675056.1470153622240
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Tuesday, August 2, 2016 at 10:58:55 PM UTC+8, T=
hiago Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On ter=C3=
=A7a-feira, 2 de agosto de 2016 16:20:44 PDT Reza Jahanbakhshi wrote:
<br>> NDEBUG is also used in boost libraries to check debug/release conf=
iguration
<br>> at compile-time. For example I can name test, circular_buffer, con=
cepts,
<br>> container, geometry, gil, hana, graph, interprocess, intrusive, py=
thon,
<br>> range, serialization, wave and preprocessor.
<br>
<br>I didn't include Boost in my search because then I would also inclu=
de Qt and I=20
<br>could conclude that use of NDEBUG and QT_NO_DEBUG are equally common, a=
s there=20
<br>are 57 uses in Boost in 10993 header files, compared to 53 uses in Qt f=
or 6705=20
<br>header files.
<br>
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.goo=
gle.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x3dD\x26sntz\x3d1\x26usg\=
x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return true;" onclick=3D"this.hr=
ef=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x=
3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return t=
rue;">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" target=3D"=
_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google.=
com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH=
GRJdo5_JYG1DowztwAHAKs80XSA';return true;" onclick=3D"this.href=3D'=
http://www.google.com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1=
\x26usg\x3dAFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return true;">kde.org</a=
>
<br>=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center
<br>
<br></blockquote><div><br></div><div>I'm not sure if continuing this ar=
gument is going to be constructive anymore in any way but just to clarify, =
the number of occurrence in the header is not a fair measurement for its im=
pact. For example circular_buffer uses NDEBUG to define=C2=A0BOOST_CB_ENABL=
E_DEBUG and this one is used 33 times allover circular_buffer headers. And =
in boost.concept NDEBUG changes the definition of BOOST_CONCEPT_REQUIRES wh=
ich essentially changes the whole library. in boost.gil, based on NDEBUG, a=
nother macro=C2=A0GIL_FORCEINLINE is defined which in turn is used 117 time=
s allover boost.gil headers. I can go on and on but my point is I think NDE=
BUG is being used as one way to make optimization and diagnostic compile-ti=
me decision=C2=A0whenever it was necessary=C2=A0in some boost libraries. Of=
course not all libraries need such a decision and some uses other definiti=
ons like BOOST_ASIO_ENABLE_BUFFER_DEBUGGING in boost asio.</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/ae5f8473-c9f1-44d4-b571-eeb3ed931c17%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ae5f8473-c9f1-44d4-b571-eeb3ed931c17=
%40isocpp.org</a>.<br />
------=_Part_6655_1752675056.1470153622240--
------=_Part_6654_1640024799.1470153622240--
.
Author: =?UTF-8?B?0JTQtdC90LjRgSDQmtC+0YLQvtCy?= <redradist@gmail.com>
Date: Tue, 2 Aug 2016 23:19:31 -0700 (PDT)
Raw View
------=_Part_4573_1969049545.1470205171317
Content-Type: multipart/alternative;
boundary="----=_Part_4574_144834417.1470205171317"
------=_Part_4574_144834417.1470205171317
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Anyway, even after all we can extend exception_ptr like in my proposal:
*class exception_ptr*
*{*
/*implementation defined*/
*public:*
char *stack_trace(); - /*implementation defined*/
*other fields: */*implementation defined*/
*}*
That stack_trace(), would be provided, but depends on implementation.
Only require will be that stack_trace() should show a sequence of function=
=20
calls.
Either it would be like:
test.so: __func(int)
two.so: __test(int)
three.so: __cal(int)
or more readable:
test.cpp: func(int), line 2
algorithm.cpp: all(...), line 25
three.so: find_if(...), line 27
Let's compiler vendor choice how better to represent stack_trace for=20
exception according to ABI of current platform.
=D0=B2=D0=BE=D1=81=D0=BA=D1=80=D0=B5=D1=81=D0=B5=D0=BD=D1=8C=D0=B5, 31 =D0=
=B8=D1=8E=D0=BB=D1=8F 2016 =D0=B3., 3:14:19 UTC+3 =D0=BF=D0=BE=D0=BB=D1=8C=
=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C =D0=94=D0=B5=D0=BD=D0=B8=
=D1=81 =D0=9A=D0=BE=D1=82=D0=BE=D0=B2=20
=D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:
>
> In *C++17* will be added a lot of new features, but no of them features=
=20
> improve quality of code and quickly fixing of the code.
> If in program exist a bug then the best that program can do is crash.=20
> Exception is a good conception for error handling, but is useless in C++=
=20
> implementation, 'cause we do not know where the problem happens. That mea=
n=20
> catching of exception is useless, because additional information is so=20
> small that better allow program simple crash.
> This is the main reason that even in debug mode exception is used not=20
> often.
>
> *PROBLEM *is no standard on it about providing to user *backtrace*.
> Operation system can get stack trace when exception was used. We can=20
> implement getting stack trace even in dummy implementation by adding to=
=20
> every function in compile time meta information with name of this functio=
n=20
> and code that will put this name in stack object that implicitly exists=
=20
> from starting the program. We can add scpecial flag *BACK_TRACE* or=20
> *BTRACE*.
>
> Sorry for straightforward speech but I tired. In we can implement=20
> *backtrace*, but are thinking about coroutine. Without strong *base *we=
=20
> cannot implement something good.
>
>
>
>
> *Thanks,Best regards.*
>
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/9a8512e3-6d6d-4aa3-b809-3239c0c22d60%40isocpp.or=
g.
------=_Part_4574_144834417.1470205171317
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Anyway, even after all we can extend=C2=A0<span style=3D"c=
olor: rgb(0, 0, 0); font-family: DejaVuSansMono, "DejaVu Sans Mono&quo=
t;, courier, monospace; font-size: 12.8px; line-height: 14.08px; white-spac=
e: nowrap;">exception_ptr like in my proposal:</span><div><span style=3D"co=
lor: rgb(0, 0, 0); font-family: DejaVuSansMono, "DejaVu Sans Mono"=
;, courier, monospace; font-size: 12.8px; line-height: 14.08px; white-space=
: nowrap;"><i>class exception_ptr</i></span></div><div><font color=3D"#0000=
00" face=3D"DejaVuSansMono, DejaVu Sans Mono, courier, monospace"><span sty=
le=3D"font-size: 12.8px; line-height: 14.08px; white-space: nowrap;"><i>{</=
i></span></font></div><div><span style=3D"color: rgb(255, 0, 0); font-famil=
y: DejaVuSansMono, "DejaVu Sans Mono", courier, monospace; font-s=
ize: 12.8px; font-style: italic; line-height: 14.08px; white-space: nowrap;=
">/*implementation defined*/</span><font color=3D"#000000" face=3D"DejaVuSa=
nsMono, DejaVu Sans Mono, courier, monospace"><span style=3D"font-size: 12.=
8px; line-height: 14.08px; white-space: nowrap;"><br></span></font></div><d=
iv><span style=3D"font-family: DejaVuSansMono, "DejaVu Sans Mono"=
, courier, monospace; font-size: 12.8px; font-style: italic; line-height: 1=
4.08px; white-space: nowrap;"><font color=3D"#000000"><b>public:</b></font>=
</span></div><div><span style=3D"font-family: DejaVuSansMono, "DejaVu =
Sans Mono", courier, monospace; font-size: 12.8px; font-style: italic;=
line-height: 14.08px; white-space: nowrap;"><font color=3D"#000000">char *=
stack_trace(); </font></span><span style=3D"color: rgb(255, 0, 0); font-fam=
ily: DejaVuSansMono, "DejaVu Sans Mono", courier, monospace; font=
-size: 12.8px; font-style: italic; line-height: 14.08px; white-space: nowra=
p;">- /*implementation defined*/</span></div><div><span style=3D"font-famil=
y: DejaVuSansMono, "DejaVu Sans Mono", courier, monospace; font-s=
ize: 12.8px; font-style: italic; line-height: 14.08px; white-space: nowrap;=
"><font color=3D"#000000"><b>other fields:=C2=A0</b></font></span><span sty=
le=3D"color: rgb(255, 0, 0); font-family: DejaVuSansMono, "DejaVu Sans=
Mono", courier, monospace; font-size: 12.8px; font-style: italic; lin=
e-height: 14.08px; white-space: nowrap;">/*implementation defined*/</span><=
/div><div><font color=3D"#000000" face=3D"DejaVuSansMono, DejaVu Sans Mono,=
courier, monospace"><span style=3D"font-size: 12.8px; line-height: 14.08px=
; white-space: nowrap;"><i>}</i><br></span></font><div><br></div><div>That=
=C2=A0<span style=3D"color: rgb(0, 0, 0); font-family: DejaVuSansMono, &quo=
t;DejaVu Sans Mono", courier, monospace; font-size: 12.8px; font-style=
: italic; line-height: 14.08px; white-space: nowrap;">stack_trace(),</span>=
<span style=3D"color: rgb(0, 0, 0); font-family: DejaVuSansMono, "Deja=
Vu Sans Mono", courier, monospace; font-size: 12.8px; line-height: 14.=
08px; white-space: nowrap;"> would be provided, but depends on=C2=A0</span>=
<font color=3D"#000000" face=3D"DejaVuSansMono, DejaVu Sans Mono, courier, =
monospace"><span style=3D"font-size: 12.8px; line-height: 14.08px; white-sp=
ace: nowrap;">implementation.</span></font></div><div><font color=3D"#00000=
0" face=3D"DejaVuSansMono, DejaVu Sans Mono, courier, monospace"><span styl=
e=3D"font-size: 12.8px; line-height: 14.08px; white-space: nowrap;">Only=C2=
=A0require=C2=A0will be that stack_trace() should show=C2=A0a sequence of f=
unction calls.</span></font></div><div><font color=3D"#000000" face=3D"Deja=
VuSansMono, DejaVu Sans Mono, courier, monospace"><span style=3D"font-size:=
12.8px; line-height: 14.08px; white-space: nowrap;">Either it would be lik=
e:</span></font></div><div><font color=3D"#000000" face=3D"DejaVuSansMono, =
DejaVu Sans Mono, courier, monospace"><span style=3D"font-size: 12.8px; lin=
e-height: 14.08px; white-space: nowrap;"><br></span></font></div><div><font=
color=3D"#000000" face=3D"DejaVuSansMono, DejaVu Sans Mono, courier, monos=
pace"><span style=3D"font-size: 12.8px; line-height: 14.08px; white-space: =
nowrap;">test.so: __func(int)</span></font></div><div><span style=3D"color:=
rgb(0, 0, 0); font-family: DejaVuSansMono, "DejaVu Sans Mono", c=
ourier, monospace; font-size: 12.8px; line-height: 14.08px; white-space: no=
wrap;">two.so: __test(int)</span><font color=3D"#000000" face=3D"DejaVuSans=
Mono, DejaVu Sans Mono, courier, monospace"><span style=3D"font-size: 12.8p=
x; line-height: 14.08px; white-space: nowrap;"><br></span></font></div><div=
><span style=3D"color: rgb(0, 0, 0); font-family: DejaVuSansMono, "Dej=
aVu Sans Mono", courier, monospace; font-size: 12.8px; line-height: 14=
..08px; white-space: nowrap;">three.so: __cal(int)</span><span style=3D"colo=
r: rgb(0, 0, 0); font-family: DejaVuSansMono, "DejaVu Sans Mono",=
courier, monospace; font-size: 12.8px; line-height: 14.08px; white-space: =
nowrap;"><br></span></div><div><span style=3D"color: rgb(0, 0, 0); font-fam=
ily: DejaVuSansMono, "DejaVu Sans Mono", courier, monospace; font=
-size: 12.8px; line-height: 14.08px; white-space: nowrap;"><br></span></div=
><div><span style=3D"color: rgb(0, 0, 0); font-family: DejaVuSansMono, &quo=
t;DejaVu Sans Mono", courier, monospace; font-size: 12.8px; line-heigh=
t: 14.08px; white-space: nowrap;">or more readable:</span></div><div><span =
style=3D"color: rgb(0, 0, 0); font-family: DejaVuSansMono, "DejaVu San=
s Mono", courier, monospace; font-size: 12.8px; line-height: 14.08px; =
white-space: nowrap;"><br></span></div><div><div><font color=3D"#000000" fa=
ce=3D"DejaVuSansMono, DejaVu Sans Mono, courier, monospace"><span style=3D"=
font-size: 12.8px; line-height: 14.08px; white-space: nowrap;">test.cpp: fu=
nc(int), line 2</span></font></div><div><span style=3D"color: rgb(0, 0, 0);=
font-family: DejaVuSansMono, "DejaVu Sans Mono", courier, monosp=
ace; font-size: 12.8px; line-height: 14.08px; white-space: nowrap;">algorit=
hm.cpp: all(...), line 25</span><font color=3D"#000000" face=3D"DejaVuSansM=
ono, DejaVu Sans Mono, courier, monospace"><span style=3D"font-size: 12.8px=
; line-height: 14.08px; white-space: nowrap;"><br></span></font></div><div>=
<span style=3D"color: rgb(0, 0, 0); font-family: DejaVuSansMono, "Deja=
Vu Sans Mono", courier, monospace; font-size: 12.8px; line-height: 14.=
08px; white-space: nowrap;">three.so: find_if(...), line 27</span></div></d=
iv><div><br></div><div>Let's compiler vendor choice how better to repre=
sent stack_trace for exception according to ABI of current platform.</div><=
div><br>=D0=B2=D0=BE=D1=81=D0=BA=D1=80=D0=B5=D1=81=D0=B5=D0=BD=D1=8C=D0=B5,=
31 =D0=B8=D1=8E=D0=BB=D1=8F 2016 =D0=B3., 3:14:19 UTC+3 =D0=BF=D0=BE=D0=BB=
=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C =D0=94=D0=B5=D0=BD=
=D0=B8=D1=81 =D0=9A=D0=BE=D1=82=D0=BE=D0=B2 =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=
=D0=B0=D0=BB:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
In <b>C++17</b> will be added a lot of new features, but no of them feature=
s improve quality of code and quickly fixing of the code.<br>If in program =
exist a bug then the best that program can do is crash. Exception is a good=
conception for error handling, but is useless in C++ implementation, '=
cause we do not know where the problem happens. That mean catching of excep=
tion is useless, because additional information is so small that better all=
ow program simple crash.<br>This is the main reason that even in debug mode=
exception is used not often.<br><br><b>PROBLEM </b>is no standard on it ab=
out providing to user <b>backtrace</b>.<br>Operation system can get stack t=
race when exception was used. We can implement getting stack trace even in =
dummy implementation by adding to every function in compile time meta infor=
mation with name of this function and code that will put this name in stack=
object that implicitly exists from starting the program. We can add scpeci=
al flag <b>BACK_TRACE</b> or <b>BTRACE</b>.<br><br>Sorry for straightforwar=
d speech but I tired. In we can implement <b>backtrace</b>, but are thinkin=
g about coroutine. Without strong <b>base </b>we cannot implement something=
good.<br><br><b>Thanks,<br>Best regards.<br><br></b></div></blockquote></d=
iv></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/9a8512e3-6d6d-4aa3-b809-3239c0c22d60%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9a8512e3-6d6d-4aa3-b809-3239c0c22d60=
%40isocpp.org</a>.<br />
------=_Part_4574_144834417.1470205171317--
------=_Part_4573_1969049545.1470205171317--
.
Author: gmisocpp@gmail.com
Date: Wed, 3 Aug 2016 01:22:05 -0700 (PDT)
Raw View
------=_Part_466_477221252.1470212525922
Content-Type: multipart/alternative;
boundary="----=_Part_467_51412044.1470212525923"
------=_Part_467_51412044.1470212525923
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
I'm not completely confident that I'm sure I know what you want to achieve=
=20
but it might help me if you can confirm if my post earlier reasonably=20
describe what you want at a minimum?
I'd ask you/the experts Is it necessary or good to define this interface to=
=20
the back trace in terms of exceptions or debug mode? Sorry if it is and I'm=
=20
missing something obvious.
I can imagine a world without exceptions or where they are turned off but=
=20
you might still want to dump the call stack on an error situation that=20
isn't even in an exception state. So I'm wondering if having to get an=20
exception pointer to get at that stack trace would seem to expose more=20
implementation details than is needed or possibly even available.
It seems to me things like the exceptions and debug mode don't need to be=
=20
exposed as or aren't tied to the facility that you want. Please anyone=20
enlighten me here.
On Wednesday, August 3, 2016 at 6:19:31 PM UTC+12, =D0=94=D0=B5=D0=BD=D0=B8=
=D1=81 =D0=9A=D0=BE=D1=82=D0=BE=D0=B2 wrote:
> Anyway, even after all we can extend exception_ptr like in my proposal:
> *class exception_ptr*
> *{*
> /*implementation defined*/
> *public:*
> char *stack_trace(); - /*implementation defined*/
> *other fields: */*implementation defined*/
> *}*
>
> That stack_trace(), would be provided, but depends on implementation.
> Only require will be that stack_trace() should show a sequence of functio=
n=20
> calls.
> Either it would be like:
>
> test.so: __func(int)
> two.so: __test(int)
> three.so: __cal(int)
>
> or more readable:
>
> test.cpp: func(int), line 2
> algorithm.cpp: all(...), line 25
> three.so: find_if(...), line 27
>
> Let's compiler vendor choice how better to represent stack_trace for=20
> exception according to ABI of current platform.
>
> =D0=B2=D0=BE=D1=81=D0=BA=D1=80=D0=B5=D1=81=D0=B5=D0=BD=D1=8C=D0=B5, 31 =
=D0=B8=D1=8E=D0=BB=D1=8F 2016 =D0=B3., 3:14:19 UTC+3 =D0=BF=D0=BE=D0=BB=D1=
=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C =D0=94=D0=B5=D0=BD=D0=
=B8=D1=81 =D0=9A=D0=BE=D1=82=D0=BE=D0=B2=20
> =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:
>>
>> In *C++17* will be added a lot of new features, but no of them features=
=20
>> improve quality of code and quickly fixing of the code.
>> If in program exist a bug then the best that program can do is crash.=20
>> Exception is a good conception for error handling, but is useless in C++=
=20
>> implementation, 'cause we do not know where the problem happens. That me=
an=20
>> catching of exception is useless, because additional information is so=
=20
>> small that better allow program simple crash.
>> This is the main reason that even in debug mode exception is used not=20
>> often.
>>
>> *PROBLEM *is no standard on it about providing to user *backtrace*.
>> Operation system can get stack trace when exception was used. We can=20
>> implement getting stack trace even in dummy implementation by adding to=
=20
>> every function in compile time meta information with name of this functi=
on=20
>> and code that will put this name in stack object that implicitly exists=
=20
>> from starting the program. We can add scpecial flag *BACK_TRACE* or=20
>> *BTRACE*.
>>
>> Sorry for straightforward speech but I tired. In we can implement=20
>> *backtrace*, but are thinking about coroutine. Without strong *base *we=
=20
>> cannot implement something good.
>>
>>
>>
>>
>> *Thanks,Best regards.*
>>
>
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/2c61165a-535e-4d3d-8130-86b76a80d48b%40isocpp.or=
g.
------=_Part_467_51412044.1470212525923
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>I'm not completely confident that I'm sure I =
know what you want to achieve but it might help me if you can confirm if my=
post earlier reasonably describe what you want at a minimum?</div><div><br=
></div><div>I'd ask you/the experts Is it necessary or good to define t=
his interface to the back trace in terms of exceptions or debug mode? Sorry=
if it is and I'm missing=C2=A0something obvious.</div><div><br></div><=
div>I can imagine a world without exceptions or where they are turned off b=
ut you might still want to dump the call stack on an error situation that i=
sn't even in an exception state.=C2=A0So I'm wondering if having to=
get an exception pointer to get at that=C2=A0stack trace=C2=A0would seem t=
o expose more implementation details=C2=A0than is needed or possibly even a=
vailable.</div><div><br></div><div>It seems to me things like the exception=
s and debug mode don't need to=C2=A0be exposed=C2=A0as or=C2=A0aren'=
;t tied to the facility that you want. Please anyone enlighten me here.</di=
v><div><br>On Wednesday, August 3, 2016 at 6:19:31 PM UTC+12, =D0=94=D0=B5=
=D0=BD=D0=B8=D1=81 =D0=9A=D0=BE=D1=82=D0=BE=D0=B2 wrote:</div><blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex;=
border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left=
-style: solid;"><div dir=3D"ltr">Anyway, even after all we can extend=C2=A0=
<span style=3D"color: rgb(0, 0, 0); line-height: 14.08px; font-family: Deja=
VuSansMono,"DejaVu Sans Mono",courier,monospace; font-size: 12.8p=
x; white-space: nowrap;">exception_ptr like in my proposal:</span><div><spa=
n style=3D"color: rgb(0, 0, 0); line-height: 14.08px; font-family: DejaVuSa=
nsMono,"DejaVu Sans Mono",courier,monospace; font-size: 12.8px; w=
hite-space: nowrap;"><i>class exception_ptr</i></span></div><div><font colo=
r=3D"#000000" face=3D"DejaVuSansMono, DejaVu Sans Mono, courier, monospace"=
><span style=3D"line-height: 14.08px; font-size: 12.8px; white-space: nowra=
p;"><i>{</i></span></font></div><div><span style=3D"color: rgb(255, 0, 0); =
line-height: 14.08px; font-family: DejaVuSansMono,"DejaVu Sans Mono&qu=
ot;,courier,monospace; font-size: 12.8px; font-style: italic; white-space: =
nowrap;">/*implementation defined*/</span><font color=3D"#000000" face=3D"D=
ejaVuSansMono, DejaVu Sans Mono, courier, monospace"><span style=3D"line-he=
ight: 14.08px; font-size: 12.8px; white-space: nowrap;"><br></span></font><=
/div><div><span style=3D"line-height: 14.08px; font-family: DejaVuSansMono,=
"DejaVu Sans Mono",courier,monospace; font-size: 12.8px; font-sty=
le: italic; white-space: nowrap;"><font color=3D"#000000"><b>public:</b></f=
ont></span></div><div><span style=3D"line-height: 14.08px; font-family: Dej=
aVuSansMono,"DejaVu Sans Mono",courier,monospace; font-size: 12.8=
px; font-style: italic; white-space: nowrap;"><font color=3D"#000000">char =
*stack_trace(); </font></span><span style=3D"color: rgb(255, 0, 0); line-he=
ight: 14.08px; font-family: DejaVuSansMono,"DejaVu Sans Mono",cou=
rier,monospace; font-size: 12.8px; font-style: italic; white-space: nowrap;=
">- /*implementation defined*/</span></div><div><span style=3D"line-height:=
14.08px; font-family: DejaVuSansMono,"DejaVu Sans Mono",courier,=
monospace; font-size: 12.8px; font-style: italic; white-space: nowrap;"><fo=
nt color=3D"#000000"><b>other fields:=C2=A0</b></font></span><span style=3D=
"color: rgb(255, 0, 0); line-height: 14.08px; font-family: DejaVuSansMono,&=
quot;DejaVu Sans Mono",courier,monospace; font-size: 12.8px; font-styl=
e: italic; white-space: nowrap;">/*implementation defined*/</span></div><di=
v><font color=3D"#000000" face=3D"DejaVuSansMono, DejaVu Sans Mono, courier=
, monospace"><span style=3D"line-height: 14.08px; font-size: 12.8px; white-=
space: nowrap;"><i>}</i><br></span></font><div><br></div><div>That=C2=A0<sp=
an style=3D"color: rgb(0, 0, 0); line-height: 14.08px; font-family: DejaVuS=
ansMono,"DejaVu Sans Mono",courier,monospace; font-size: 12.8px; =
font-style: italic; white-space: nowrap;">stack_trace(),</span><span style=
=3D"color: rgb(0, 0, 0); line-height: 14.08px; font-family: DejaVuSansMono,=
"DejaVu Sans Mono",courier,monospace; font-size: 12.8px; white-sp=
ace: nowrap;"> would be provided, but depends on=C2=A0</span><font color=3D=
"#000000" face=3D"DejaVuSansMono, DejaVu Sans Mono, courier, monospace"><sp=
an style=3D"line-height: 14.08px; font-size: 12.8px; white-space: nowrap;">=
implementation.</span></font></div><div><font color=3D"#000000" face=3D"Dej=
aVuSansMono, DejaVu Sans Mono, courier, monospace"><span style=3D"line-heig=
ht: 14.08px; font-size: 12.8px; white-space: nowrap;">Only=C2=A0require=C2=
=A0will be that stack_trace() should show=C2=A0a sequence of function calls=
..</span></font></div><div><font color=3D"#000000" face=3D"DejaVuSansMono, D=
ejaVu Sans Mono, courier, monospace"><span style=3D"line-height: 14.08px; f=
ont-size: 12.8px; white-space: nowrap;">Either it would be like:</span></fo=
nt></div><div><font color=3D"#000000" face=3D"DejaVuSansMono, DejaVu Sans M=
ono, courier, monospace"><span style=3D"line-height: 14.08px; font-size: 12=
..8px; white-space: nowrap;"><br></span></font></div><div><font color=3D"#00=
0000" face=3D"DejaVuSansMono, DejaVu Sans Mono, courier, monospace"><span s=
tyle=3D"line-height: 14.08px; font-size: 12.8px; white-space: nowrap;">test=
..so: __func(int)</span></font></div><div><span style=3D"color: rgb(0, 0, 0)=
; line-height: 14.08px; font-family: DejaVuSansMono,"DejaVu Sans Mono&=
quot;,courier,monospace; font-size: 12.8px; white-space: nowrap;">two.so: _=
_test(int)</span><font color=3D"#000000" face=3D"DejaVuSansMono, DejaVu San=
s Mono, courier, monospace"><span style=3D"line-height: 14.08px; font-size:=
12.8px; white-space: nowrap;"><br></span></font></div><div><span style=3D"=
color: rgb(0, 0, 0); line-height: 14.08px; font-family: DejaVuSansMono,&quo=
t;DejaVu Sans Mono",courier,monospace; font-size: 12.8px; white-space:=
nowrap;">three.so: __cal(int)</span><span style=3D"color: rgb(0, 0, 0); li=
ne-height: 14.08px; font-family: DejaVuSansMono,"DejaVu Sans Mono"=
;,courier,monospace; font-size: 12.8px; white-space: nowrap;"><br></span></=
div><div><span style=3D"color: rgb(0, 0, 0); line-height: 14.08px; font-fam=
ily: DejaVuSansMono,"DejaVu Sans Mono",courier,monospace; font-si=
ze: 12.8px; white-space: nowrap;"><br></span></div><div><span style=3D"colo=
r: rgb(0, 0, 0); line-height: 14.08px; font-family: DejaVuSansMono,"De=
jaVu Sans Mono",courier,monospace; font-size: 12.8px; white-space: now=
rap;">or more readable:</span></div><div><span style=3D"color: rgb(0, 0, 0)=
; line-height: 14.08px; font-family: DejaVuSansMono,"DejaVu Sans Mono&=
quot;,courier,monospace; font-size: 12.8px; white-space: nowrap;"><br></spa=
n></div><div><div><font color=3D"#000000" face=3D"DejaVuSansMono, DejaVu Sa=
ns Mono, courier, monospace"><span style=3D"line-height: 14.08px; font-size=
: 12.8px; white-space: nowrap;">test.cpp: func(int), line 2</span></font></=
div><div><span style=3D"color: rgb(0, 0, 0); line-height: 14.08px; font-fam=
ily: DejaVuSansMono,"DejaVu Sans Mono",courier,monospace; font-si=
ze: 12.8px; white-space: nowrap;">algorithm.cpp: all(...), line 25</span><f=
ont color=3D"#000000" face=3D"DejaVuSansMono, DejaVu Sans Mono, courier, mo=
nospace"><span style=3D"line-height: 14.08px; font-size: 12.8px; white-spac=
e: nowrap;"><br></span></font></div><div><span style=3D"color: rgb(0, 0, 0)=
; line-height: 14.08px; font-family: DejaVuSansMono,"DejaVu Sans Mono&=
quot;,courier,monospace; font-size: 12.8px; white-space: nowrap;">three.so:=
find_if(...), line 27</span></div></div><div><br></div><div>Let's comp=
iler vendor choice how better to represent stack_trace for exception accord=
ing to ABI of current platform.</div><div><br>=D0=B2=D0=BE=D1=81=D0=BA=D1=
=80=D0=B5=D1=81=D0=B5=D0=BD=D1=8C=D0=B5, 31 =D0=B8=D1=8E=D0=BB=D1=8F 2016 =
=D0=B3., 3:14:19 UTC+3 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=
=82=D0=B5=D0=BB=D1=8C =D0=94=D0=B5=D0=BD=D0=B8=D1=81 =D0=9A=D0=BE=D1=82=D0=
=BE=D0=B2 =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:<blockquote class=3D"g=
mail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-l=
eft-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: s=
olid;"><div dir=3D"ltr">In <b>C++17</b> will be added a lot of new features=
, but no of them features improve quality of code and quickly fixing of the=
code.<br>If in program exist a bug then the best that program can do is cr=
ash. Exception is a good conception for error handling, but is useless in C=
++ implementation, 'cause we do not know where the problem happens. Tha=
t mean catching of exception is useless, because additional information is =
so small that better allow program simple crash.<br>This is the main reason=
that even in debug mode exception is used not often.<br><br><b>PROBLEM </b=
>is no standard on it about providing to user <b>backtrace</b>.<br>Operatio=
n system can get stack trace when exception was used. We can implement gett=
ing stack trace even in dummy implementation by adding to every function in=
compile time meta information with name of this function and code that wil=
l put this name in stack object that implicitly exists from starting the pr=
ogram. We can add scpecial flag <b>BACK_TRACE</b> or <b>BTRACE</b>.<br><br>=
Sorry for straightforward speech but I tired. In we can implement <b>backtr=
ace</b>, but are thinking about coroutine. Without strong <b>base </b>we ca=
nnot implement something good.<br><br><b>Thanks,<br>Best regards.<br><br></=
b></div></blockquote></div></div></div></blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/2c61165a-535e-4d3d-8130-86b76a80d48b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2c61165a-535e-4d3d-8130-86b76a80d48b=
%40isocpp.org</a>.<br />
------=_Part_467_51412044.1470212525923--
------=_Part_466_477221252.1470212525922--
.
Author: Viacheslav Usov <via.usov@gmail.com>
Date: Wed, 3 Aug 2016 10:38:25 +0200
Raw View
--001a11410242dab2d1053926c19d
Content-Type: text/plain; charset=UTF-8
On Wed, Aug 3, 2016 at 10:22 AM, <gmisocpp@gmail.com> wrote:
> I can imagine a world without exceptions or where they are turned off but
you might still want to dump the call stack on an error situation that
isn't even in an exception state.
This has already been discussed in this and the previous thread(s). My
personal understanding is that we need a couple of classes or functions,
not bound with exceptions or exception pointers.
1. std::current_stack_trace. This gets the stack trace at its invocation
point.
2. std::exception_stack_trace. This gets the stack trace at the throw point
of the currently handled exception (semantics similar to
std::current_exception).
As discussed earlier, both return information in an implementation-defined
format, which is not necessarily human-readable without an extra
translation step; this covers the case when symbolic information is not
available at runtime.
Cheers,
V.
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg3qUWwgN2D5Fv_myTMWZD7g_u43bOK7xkWHqSAb0ZjeXA%40mail.gmail.com.
--001a11410242dab2d1053926c19d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Aug 3, 2016 at 10:22 AM, <span dir=3D"ltr"><<a href=3D"mailto:gmiso=
cpp@gmail.com" target=3D"_blank">gmisocpp@gmail.com</a>></span> wrote:<b=
r><div><br></div><div>> I can imagine a world without exceptions or wher=
e they are turned off but you might still want to dump the call stack on an=
error situation that isn't even in an exception state.</div><div><br><=
/div><div>This has already been discussed in this and the previous thread(s=
). My personal understanding is that we need a couple of classes or functio=
ns, not bound with exceptions or exception pointers.</div><div><br></div><d=
iv>1. std::current_stack_trace. This gets the stack trace at its invocation=
point.</div><div>2. std::exception_stack_trace. This gets the stack trace =
at the throw point of the currently handled exception (semantics similar to=
std::current_exception).</div><div><br></div><div>As discussed earlier, bo=
th return information in an implementation-defined format, which is not nec=
essarily human-readable without an extra translation step; this covers the =
case when symbolic information is not available at runtime.</div><div><br><=
/div><div>Cheers,</div><div>V.</div></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAA7YVg3qUWwgN2D5Fv_myTMWZD7g_u43bOK7=
xkWHqSAb0ZjeXA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg3qUWwgN2D5=
Fv_myTMWZD7g_u43bOK7xkWHqSAb0ZjeXA%40mail.gmail.com</a>.<br />
--001a11410242dab2d1053926c19d--
.
Author: gmisocpp@gmail.com
Date: Wed, 3 Aug 2016 02:26:10 -0700 (PDT)
Raw View
------=_Part_2640_919400191.1470216370261
Content-Type: multipart/alternative;
boundary="----=_Part_2641_40242161.1470216370262"
------=_Part_2641_40242161.1470216370262
Content-Type: text/plain; charset=UTF-8
On Wednesday, August 3, 2016 at 8:38:30 PM UTC+12, Viacheslav Usov wrote:
>
> On Wed, Aug 3, 2016 at 10:22 AM, <gmis...@gmail.com <javascript:>> wrote:
>
> > I can imagine a world without exceptions or where they are turned off
> but you might still want to dump the call stack on an error situation that
> isn't even in an exception state.
>
> This has already been discussed in this and the previous thread(s). My
> personal understanding is that we need a couple of classes or functions,
> not bound with exceptions or exception pointers.
>
> 1. std::current_stack_trace. This gets the stack trace at its invocation
> point.
> 2. std::exception_stack_trace. This gets the stack trace at the throw
> point of the currently handled exception (semantics similar to
> std::current_exception).
>
> As discussed earlier, both return information in an implementation-defined
> format, which is not necessarily human-readable without an extra
> translation step; this covers the case when symbolic information is not
> available at runtime.
>
> Cheers,
>
> V.
>
Thanks for that.
Would something like this suffice do you think (or the OP)?
enum_back_trace(back_trace_point::include_exception_point // otherwise is
from current point if no exception active
[](const std::trace_point& tp
(
std::cout << tp.location();
));
And if compiled without back trace enabled just does nothing.
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4e3e284a-6e71-4993-80fd-3057881c11b2%40isocpp.org.
------=_Part_2641_40242161.1470216370262
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Wednesday, August 3, 2016 at 8:38:30 PM UTC+12,=
Viacheslav Usov wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204);=
border-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><div><=
div class=3D"gmail_quote">On Wed, Aug 3, 2016 at 10:22 AM, <span dir=3D"lt=
r"><<a onmousedown=3D"this.href=3D'javascript:';return true;" on=
click=3D"this.href=3D'javascript:';return true;" href=3D"javascript=
:" target=3D"_blank" rel=3D"nofollow" gdf-obfuscated-mailto=3D"Dq6xlMs2BwAJ=
">gmis...@gmail.com</a>></span> wrote:<br><div><br></div><div>> I can=
imagine a world without exceptions or where they are turned off but you mi=
ght still want to dump the call stack on an error situation that isn't =
even in an exception state.</div><div><br></div><div>This has already been =
discussed in this and the previous thread(s). My personal understanding is =
that we need a couple of classes or functions, not bound with exceptions or=
exception pointers.</div><div><br></div><div>1. std::current_stack_trace. =
This gets the stack trace at its invocation point.</div><div>2. std::except=
ion_stack_trace. This gets the stack trace at the throw point of the curren=
tly handled exception (semantics similar to std::current_exception).</div><=
div><br></div><div>As discussed earlier, both return information in an impl=
ementation-defined format, which is not necessarily human-readable without =
an extra translation step; this covers the case when symbolic information i=
s not available at runtime.</div><div><br></div><div>Cheers,</div><div></di=
v></div></div></div></blockquote><div>=C2=A0</div><blockquote class=3D"gmai=
l_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left=
-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: soli=
d;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>V.</div></div></d=
iv></div></blockquote><div><br></div><div>Thanks for that.</div><div><br></=
div><div>Would something like this suffice do you think (or the OP)?</div><=
div><br></div><div>enum_back_trace(back_trace_point::include_exception_poin=
t // otherwise is from current point if no exception active</div><div>[](co=
nst std::trace_point& tp</div><div>(</div><div>std::cout << tp.lo=
cation();</div><div>));</div><div><br></div><div>And if compiled without ba=
ck trace enabled just does nothing.</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/4e3e284a-6e71-4993-80fd-3057881c11b2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/4e3e284a-6e71-4993-80fd-3057881c11b2=
%40isocpp.org</a>.<br />
------=_Part_2641_40242161.1470216370262--
------=_Part_2640_919400191.1470216370261--
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Wed, 3 Aug 2016 08:48:05 -0400
Raw View
On 2016-08-03 04:22, gmisocpp@gmail.com wrote:
> I can imagine a world without exceptions or where they are turned off but
> you might still want to dump the call stack on an error situation that
> isn't even in an exception state.
I can imagine a world where you might want to dump a stack trace as part
of routine logging :-). Pretty sure I've done that, in fact.
(Another thing I *know* I've done at one point is implement "poor man's
valgrind", i.e. I collect my own stack traces on memory allocations and
*possibly* use them to help track down errors such as double-frees or
leaks. Most of the collected traces are never used in any meaningful
way. So, yes, there are most definitely reasons to want to collect a
stack trace - and in particular, one which has not had address to symbol
resolution performed yet - outside of exceptions.)
--
Matthew
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/57A1E805.2060905%40gmail.com.
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Mon, 1 Aug 2016 10:19:23 -0400
Raw View
On 2016-07-30 20:14, redradist@gmail.com wrote:
> In *C++17* will be added a lot of new features, but no of them features
> improve quality of code and quickly fixing of the code.
> If in program exist a bug then the best that program can do is crash.
> Exception is a good conception for error handling, but is useless in C++
> implementation, 'cause we do not know where the problem happens. That mean
> catching of exception is useless, because additional information is so
> small that better allow program simple crash.
> This is the main reason that even in debug mode exception is used not often.
>
> *PROBLEM *is no standard on it about providing to user *backtrace*.
> Operation system can get stack trace when exception was used. We can
> implement getting stack trace even in dummy implementation by adding to
> every function in compile time meta information with name of this function
> and code that will put this name in stack object that implicitly exists
> from starting the program. We can add scpecial flag *BACK_TRACE* or *BTRACE*
> .
Didn't we have this conversation already?
https://groups.google.com/a/isocpp.org/forum/#!topic/std-discussion/A17G1ram9ns
Yup, there it is...
--
Matthew
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/nnnlpb%24ab%242%40blaine.gmane.org.
.
Author: loic.actarus.joly@numericable.fr
Date: Mon, 1 Aug 2016 07:54:36 +0200 (CEST)
Raw View
------=_NextPart_001_579ee41c_6066_2508cfc8
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
---- Message d'origine ----
De : "Thiago Macieira" <thiago@macieira.org>
On domingo, 31 de julho de 2016 20:03:03 PDT =D0=94=D0=B5=D0=BD=D0=B8=D1=81=
=D0=9A=D0=BE=D1=82=D0=BE=D0=B2 wrote:
> > > What is "Debug Mode"? I ask this question because the C++ standard do=
es=20
> > > not mention any such thing.
> > If NDEBUG is not defined that is mean we in debug mode.
>=20
> What's NDEBUG? I never set that in my programs, since I almost never need
> them. I'm being serious, I never set them. Qt doesn't react to NDEBUG and
> since all my programs are written with Qt...
NDEBUG is defined in the C standard and is referenced in the C++ standard (=
17.6.2.2). It
modifies the meaning of the <cassert> header.
You may not use it, but it exists nevertheless. Just like my never having u=
sed=20
gslice_array does not mean it does not exist.
=C2=A0
[...]
> This is useful, but the feature already exists.
Which is a very good reason for standardization. In fact, standardizing som=
ething that=20
does not already exist in some way would be very dangerous...
> We don't need what you're
> suggestion because it cannot be standardised and it will just be a poor
> comparison to the tools that already exist.
I agree that anything that could be standardized would probably be very poo=
r compared=20
to existing vendor specific tools. It would probably just boil down to some=
thing like=20
"returns an unspecified string". But I still think it might be worthwile:
- Getting it in the code instead of as part of external tools can be useful=
to debug=20
=C2=A0 on customer site when the customer cannot install any software
- Getting it in the standard allows a standard way of generating it, even i=
f understanding
=C2=A0 it will probably be limited to human parsing, since the content woul=
d not be normalized.
=C2=A0 Right now, if I have to write cross platform code with some basic er=
ror reporting, there
=C2=A0 is nothing I can do except did into the documentation of 20 differen=
t toolchains
- Getting it in the standard would not prevent other tools from existing an=
d providing=20
=C2=A0 much more features
- It is easy to implement, since a compiler could just return an empty stri=
ng, everything
=C2=A0 else being a question of QOI.
---=20
Lo=C3=AFc
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/ea-mime-579ee41c-6066-3298ffff%40webmail.numeric=
able.fr.
------=_NextPart_001_579ee41c_6066_2508cfc8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transational//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3DUTF-8">
</HEAD>
<BODY><br>---- Message d'origine ----<br>De : "Thiago Macieira" <thiago@=
macieira.org><br><br>On domingo, 31 de julho de 2016 20:03:03 PDT =D0=94=
=D0=B5=D0=BD=D0=B8=D1=81 =D0=9A=D0=BE=D1=82=D0=BE=D0=B2 wrote:<br>> >=
> What is "Debug Mode"? I ask this question because the C++ standard do=
es <br>> > > not mention any such thing.<br>> > If NDEBUG is=
not defined that is mean we in debug mode.<br>> <br>> What's NDEBUG?=
I never set that in my programs, since I almost never need<br>> them. I=
'm being serious, I never set them. Qt doesn't react to NDEBUG and<br>> =
since all my programs are written with Qt...<br><br>NDEBUG is defined in th=
e C standard and is referenced in the C++ standard (17.6.2.2). It<br>modifi=
es the meaning of the <cassert> header.<br>You may not use it, but it=
exists nevertheless. Just like my never having used <br>gslice_array does =
not mean it does not exist.<br> <br>[...]<br>> This is useful, but =
the feature already exists.<br><br>Which is a very good reason for standard=
ization. In fact, standardizing something that <br>does not already exist i=
n some way would be very dangerous...<br><br><br>> We don't need what yo=
u're<br>> suggestion because it cannot be standardised and it will just =
be a poor<br>> comparison to the tools that already exist.<br><br>I agre=
e that anything that could be standardized would probably be very poor comp=
ared <br>to existing vendor specific tools. It would probably just boil dow=
n to something like <br>"returns an unspecified string". But I still think =
it might be worthwile:<br>- Getting it in the code instead of as part of ex=
ternal tools can be useful to debug <br> on customer site when the cu=
stomer cannot install any software<br>- Getting it in the standard allows a=
standard way of generating it, even if understanding<br> it will pro=
bably be limited to human parsing, since the content would not be normalize=
d.<br> Right now, if I have to write cross platform code with some ba=
sic error reporting, there<br> is nothing I can do except did into th=
e documentation of 20 different toolchains<br>- Getting it in the standard =
would not prevent other tools from existing and providing <br> much m=
ore features<br>- It is easy to implement, since a compiler could just retu=
rn an empty string, everything<br> else being a question of QOI.<br><=
br>--- <br>Lo=C3=AFc<br><br></BODY></HTML>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/ea-mime-579ee41c-6066-3298ffff%40webm=
ail.numericable.fr?utm_medium=3Demail&utm_source=3Dfooter">https://groups.g=
oogle.com/a/isocpp.org/d/msgid/std-proposals/ea-mime-579ee41c-6066-3298ffff=
%40webmail.numericable.fr</a>.<br />
------=_NextPart_001_579ee41c_6066_2508cfc8--
.
Author: =?UTF-8?B?0JTQtdC90LjRgSDQmtC+0YLQvtCy?= <redradist@gmail.com>
Date: Fri, 5 Aug 2016 14:44:32 -0700 (PDT)
Raw View
------=_Part_2505_930160245.1470433472167
Content-Type: multipart/alternative;
boundary="----=_Part_2506_230345756.1470433472167"
------=_Part_2506_230345756.1470433472167
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
What is the result of our TOPIC ?
Result is *ZERO *!!!!! How many *human*hours* has been spent, but nothing !
Can somebody from *=D1=81ommittee *help us ?
Will be it consider on standartization ?
We have different opinions. Some guys think it is usefull, another is not.
*We need a look from outside !!!*
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/3c73071d-76bc-4cc0-8d9b-155999d7ade2%40isocpp.or=
g.
------=_Part_2506_230345756.1470433472167
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">What is the result of our TOPIC ?<br><br>Result is <b>ZERO=
</b>!!!!! How many <b>human*hours</b> has been spent, but nothing !<br>Can=
somebody from <b>=D1=81ommittee </b>help us ?<br>Will be it consider on st=
andartization ?<br><br>We have different opinions. Some guys think it is us=
efull, another is not.<br><b>We need a look from outside !!!</b><br><b><br>=
</b></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/3c73071d-76bc-4cc0-8d9b-155999d7ade2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/3c73071d-76bc-4cc0-8d9b-155999d7ade2=
%40isocpp.org</a>.<br />
------=_Part_2506_230345756.1470433472167--
------=_Part_2505_930160245.1470433472167--
.
Author: Patrice Roy <patricer@gmail.com>
Date: Fri, 5 Aug 2016 17:53:05 -0400
Raw View
--001a11441094768ab905395a17b6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
This list is for discussion, but nothing stopping you from preparing a
proposal and coming to present it at a committee meeting, regardless of
what's being discussed here. Take that feedback into account, it can only
help you prepare yourself better. If you see a lot of resistance, try to
see if you think you can convince people, including committee members
(you'll have an advance perspective on what objections you might expect
there).
As has been pointed out previously, this is not the first time this has
been discussed, so you might want to inspire yourself from prior exchanges
to prepare yourself, should you wish to go forward.
Not all feedback has been negative. You can build something from all this
should you be inclined to.
Cheers!
2016-08-05 17:44 GMT-04:00 =D0=94=D0=B5=D0=BD=D0=B8=D1=81 =D0=9A=D0=BE=D1=
=82=D0=BE=D0=B2 <redradist@gmail.com>:
> What is the result of our TOPIC ?
>
> Result is *ZERO *!!!!! How many *human*hours* has been spent, but nothing
> !
> Can somebody from *=D1=81ommittee *help us ?
> Will be it consider on standartization ?
>
> We have different opinions. Some guys think it is usefull, another is not=
..
> *We need a look from outside !!!*
>
> --
> 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.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/3c73071d-76bc-4cc0-
> 8d9b-155999d7ade2%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/3c73071d-76=
bc-4cc0-8d9b-155999d7ade2%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAKiZDp0V8a%2B3wf_BJJQrJ20vhHcOxDeXemXpSzNmnrYY5=
fjfDQ%40mail.gmail.com.
--001a11441094768ab905395a17b6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>This list is for discussion, but nothing stopping you=
from preparing a proposal and coming to present it at a committee meeting,=
regardless of what's being discussed here. Take that feedback into acc=
ount, it can only help you prepare yourself better. If you see a lot of res=
istance, try to see if you think you can convince people, including committ=
ee members (you'll have an advance perspective on what objections you m=
ight expect there).<br><br></div><div>As has been pointed out previously, t=
his is not the first time this has been discussed, so you might want to ins=
pire yourself from prior exchanges to prepare yourself, should you wish to =
go forward.<br><br></div><div>Not all feedback has been negative. You can b=
uild something from all this should you be inclined to.<br></div><div><br><=
/div>Cheers!<br></div><div class=3D"gmail_extra"><br><div class=3D"gmail_qu=
ote">2016-08-05 17:44 GMT-04:00 =D0=94=D0=B5=D0=BD=D0=B8=D1=81 =D0=9A=D0=BE=
=D1=82=D0=BE=D0=B2 <span dir=3D"ltr"><<a href=3D"mailto:redradist@gmail.=
com" target=3D"_blank">redradist@gmail.com</a>></span>:<br><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex"><div dir=3D"ltr">What is the result of our TOPIC ?<br><br=
>Result is <b>ZERO </b>!!!!! How many <b>human*hours</b> has been spent, bu=
t nothing !<br>Can somebody from <b>=D1=81ommittee </b>help us ?<br>Will be=
it consider on standartization ?<br><br>We have different opinions. Some g=
uys think it is usefull, another is not.<br><b>We need a look from outside =
!!!</b><br><b><br></b></div><span class=3D"">
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/3c73071d-76bc-4cc0-8d9b-155999d7ade2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/3c73=
071d-76bc-4cc0-<wbr>8d9b-155999d7ade2%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAKiZDp0V8a%2B3wf_BJJQrJ20vhHcOxDeXem=
XpSzNmnrYY5fjfDQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKiZDp0V8a%2B3=
wf_BJJQrJ20vhHcOxDeXemXpSzNmnrYY5fjfDQ%40mail.gmail.com</a>.<br />
--001a11441094768ab905395a17b6--
.
Author: =?UTF-8?B?0JTQtdC90LjRgSDQmtC+0YLQvtCy?= <redradist@gmail.com>
Date: Sat, 6 Aug 2016 06:05:06 -0700 (PDT)
Raw View
------=_Part_164_1587156015.1470488706530
Content-Type: multipart/alternative;
boundary="----=_Part_165_180777201.1470488706530"
------=_Part_165_180777201.1470488706530
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Okay,
Where could I submit my reworked proposal ?
Could you privde me with link ?
=D1=81=D1=83=D0=B1=D0=B1=D0=BE=D1=82=D0=B0, 6 =D0=B0=D0=B2=D0=B3=D1=83=D1=
=81=D1=82=D0=B0 2016 =D0=B3., 0:53:08 UTC+3 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=
=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Patrice Roy =D0=BD=D0=B0=D0=BF=
=D0=B8=D1=81=D0=B0=D0=BB:
>
> This list is for discussion, but nothing stopping you from preparing a=20
> proposal and coming to present it at a committee meeting, regardless of=
=20
> what's being discussed here. Take that feedback into account, it can only=
=20
> help you prepare yourself better. If you see a lot of resistance, try to=
=20
> see if you think you can convince people, including committee members=20
> (you'll have an advance perspective on what objections you might expect=
=20
> there).
>
> As has been pointed out previously, this is not the first time this has=
=20
> been discussed, so you might want to inspire yourself from prior exchange=
s=20
> to prepare yourself, should you wish to go forward.
>
> Not all feedback has been negative. You can build something from all this=
=20
> should you be inclined to.
>
> Cheers!
>
> 2016-08-05 17:44 GMT-04:00 =D0=94=D0=B5=D0=BD=D0=B8=D1=81 =D0=9A=D0=BE=D1=
=82=D0=BE=D0=B2 <redr...@gmail.com <javascript:>>:
>
>> What is the result of our TOPIC ?
>>
>> Result is *ZERO *!!!!! How many *human*hours* has been spent, but=20
>> nothing !
>> Can somebody from *=D1=81ommittee *help us ?
>> Will be it consider on standartization ?
>>
>> We have different opinions. Some guys think it is usefull, another is no=
t.
>> *We need a look from outside !!!*
>>
>> --=20
>> You received this message because you are subscribed to the Google Group=
s=20
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n=20
>> email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> To view this discussion on the web visit=20
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/3c73071d-76=
bc-4cc0-8d9b-155999d7ade2%40isocpp.org=20
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/3c73071d-7=
6bc-4cc0-8d9b-155999d7ade2%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoo=
ter>
>> .
>>
>
>
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/b5548c7a-933e-4a92-a2d4-77a1cca213c1%40isocpp.or=
g.
------=_Part_165_180777201.1470488706530
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Okay,<br><br>Where could I submit my reworked proposal ?<b=
r>Could you privde me with link ?<br><br>=D1=81=D1=83=D0=B1=D0=B1=D0=BE=D1=
=82=D0=B0, 6 =D0=B0=D0=B2=D0=B3=D1=83=D1=81=D1=82=D0=B0 2016 =D0=B3., 0:53:=
08 UTC+3 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=
=D1=8C Patrice Roy =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:<blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px=
#ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>This list is for disc=
ussion, but nothing stopping you from preparing a proposal and coming to pr=
esent it at a committee meeting, regardless of what's being discussed h=
ere. Take that feedback into account, it can only help you prepare yourself=
better. If you see a lot of resistance, try to see if you think you can co=
nvince people, including committee members (you'll have an advance pers=
pective on what objections you might expect there).<br><br></div><div>As ha=
s been pointed out previously, this is not the first time this has been dis=
cussed, so you might want to inspire yourself from prior exchanges to prepa=
re yourself, should you wish to go forward.<br><br></div><div>Not all feedb=
ack has been negative. You can build something from all this should you be =
inclined to.<br></div><div><br></div>Cheers!<br></div><div><br><div class=
=3D"gmail_quote">2016-08-05 17:44 GMT-04:00 =D0=94=D0=B5=D0=BD=D0=B8=D1=81 =
=D0=9A=D0=BE=D1=82=D0=BE=D0=B2 <span dir=3D"ltr"><<a href=3D"javascript:=
" target=3D"_blank" gdf-obfuscated-mailto=3D"XpjNslH_BwAJ" rel=3D"nofollow"=
onmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"=
this.href=3D'javascript:';return true;">redr...@gmail.com</a>></=
span>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">What is the resul=
t of our TOPIC ?<br><br>Result is <b>ZERO </b>!!!!! How many <b>human*hours=
</b> has been spent, but nothing !<br>Can somebody from <b>=D1=81ommittee <=
/b>help us ?<br>Will be it consider on standartization ?<br><br>We have dif=
ferent opinions. Some guys think it is usefull, another is not.<br><b>We ne=
ed a look from outside !!!</b><br><b><br></b></div><span>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
XpjNslH_BwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:&=
#39;;return true;" onclick=3D"this.href=3D'javascript:';return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"XpjNslH_BwAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'=
;javascript:';return true;">std-pr...@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/3c73071d-76bc-4cc0-8d9b-155999d7ade2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank" =
rel=3D"nofollow" onmousedown=3D"this.href=3D'https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/3c73071d-76bc-4cc0-8d9b-155999d7ade2%40i=
socpp.org?utm_medium\x3demail\x26utm_source\x3dfooter';return true;" on=
click=3D"this.href=3D'https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/3c73071d-76bc-4cc0-8d9b-155999d7ade2%40isocpp.org?utm_medium\x3=
demail\x26utm_source\x3dfooter';return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/3c73071d-76bc-4cc0-<wbr>8d9b-=
155999d7ade2%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></div>
</blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/b5548c7a-933e-4a92-a2d4-77a1cca213c1%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b5548c7a-933e-4a92-a2d4-77a1cca213c1=
%40isocpp.org</a>.<br />
------=_Part_165_180777201.1470488706530--
------=_Part_164_1587156015.1470488706530--
.
Author: Patrice Roy <patricer@gmail.com>
Date: Sat, 6 Aug 2016 09:19:04 -0400
Raw View
--001a114ba1ce05cc3b0539670771
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
I'd say https://isocpp.org/std/submit-a-proposal is a starting point :)
Good luck!
2016-08-06 9:05 GMT-04:00 =D0=94=D0=B5=D0=BD=D0=B8=D1=81 =D0=9A=D0=BE=D1=82=
=D0=BE=D0=B2 <redradist@gmail.com>:
> Okay,
>
> Where could I submit my reworked proposal ?
> Could you privde me with link ?
>
> =D1=81=D1=83=D0=B1=D0=B1=D0=BE=D1=82=D0=B0, 6 =D0=B0=D0=B2=D0=B3=D1=83=D1=
=81=D1=82=D0=B0 2016 =D0=B3., 0:53:08 UTC+3 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=
=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Patrice Roy =D0=BD=D0=B0=D0=BF=
=D0=B8=D1=81=D0=B0=D0=BB:
>>
>> This list is for discussion, but nothing stopping you from preparing a
>> proposal and coming to present it at a committee meeting, regardless of
>> what's being discussed here. Take that feedback into account, it can onl=
y
>> help you prepare yourself better. If you see a lot of resistance, try to
>> see if you think you can convince people, including committee members
>> (you'll have an advance perspective on what objections you might expect
>> there).
>>
>> As has been pointed out previously, this is not the first time this has
>> been discussed, so you might want to inspire yourself from prior exchang=
es
>> to prepare yourself, should you wish to go forward.
>>
>> Not all feedback has been negative. You can build something from all thi=
s
>> should you be inclined to.
>>
>> Cheers!
>>
>> 2016-08-05 17:44 GMT-04:00 =D0=94=D0=B5=D0=BD=D0=B8=D1=81 =D0=9A=D0=BE=
=D1=82=D0=BE=D0=B2 <redr...@gmail.com>:
>>
>>> What is the result of our TOPIC ?
>>>
>>> Result is *ZERO *!!!!! How many *human*hours* has been spent, but
>>> nothing !
>>> Can somebody from *=D1=81ommittee *help us ?
>>> Will be it consider on standartization ?
>>>
>>> We have different opinions. Some guys think it is usefull, another is
>>> not.
>>> *We need a look from outside !!!*
>>>
>>> --
>>> 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-proposal...@isocpp.org.
>>> To post to this group, send email to std-pr...@isocpp.org.
>>> To view this discussion on the web visit https://groups.google.com/a/is
>>> ocpp.org/d/msgid/std-proposals/3c73071d-76bc-4cc0-8d9b-
>>> 155999d7ade2%40isocpp.org
>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/3c73071d-=
76bc-4cc0-8d9b-155999d7ade2%40isocpp.org?utm_medium=3Demail&utm_source=3Dfo=
oter>
>>> .
>>>
>>
>> --
> 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.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/b5548c7a-933e-4a92-
> a2d4-77a1cca213c1%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b5548c7a-93=
3e-4a92-a2d4-77a1cca213c1%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAKiZDp3VuW_zi5CecXpth-sp81z25bArWyrJYzaMGfeR8JG=
0LQ%40mail.gmail.com.
--001a114ba1ce05cc3b0539670771
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>I'd say <a href=3D"https://isocpp.org/std/submit-=
a-proposal">https://isocpp.org/std/submit-a-proposal</a> is a starting poin=
t :)<br><br></div>Good luck!<br></div><div class=3D"gmail_extra"><br><div c=
lass=3D"gmail_quote">2016-08-06 9:05 GMT-04:00 =D0=94=D0=B5=D0=BD=D0=B8=D1=
=81 =D0=9A=D0=BE=D1=82=D0=BE=D0=B2 <span dir=3D"ltr"><<a href=3D"mailto:=
redradist@gmail.com" target=3D"_blank">redradist@gmail.com</a>></span>:<=
br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Okay,<br><br>Where could=
I submit my reworked proposal ?<br>Could you privde me with link ?<br><br>=
=D1=81=D1=83=D0=B1=D0=B1=D0=BE=D1=82=D0=B0, 6 =D0=B0=D0=B2=D0=B3=D1=83=D1=
=81=D1=82=D0=B0 2016 =D0=B3., 0:53:08 UTC+3 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=
=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Patrice Roy =D0=BD=D0=B0=D0=BF=
=D0=B8=D1=81=D0=B0=D0=BB:<blockquote class=3D"gmail_quote" style=3D"margin:=
0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><span clas=
s=3D""><div dir=3D"ltr"><div>This list is for discussion, but nothing stopp=
ing you from preparing a proposal and coming to present it at a committee m=
eeting, regardless of what's being discussed here. Take that feedback i=
nto account, it can only help you prepare yourself better. If you see a lot=
of resistance, try to see if you think you can convince people, including =
committee members (you'll have an advance perspective on what objection=
s you might expect there).<br><br></div><div>As has been pointed out previo=
usly, this is not the first time this has been discussed, so you might want=
to inspire yourself from prior exchanges to prepare yourself, should you w=
ish to go forward.<br><br></div><div>Not all feedback has been negative. Yo=
u can build something from all this should you be inclined to.<br></div><di=
v><br></div>Cheers!<br></div></span><div><br><div class=3D"gmail_quote"><sp=
an class=3D"">2016-08-05 17:44 GMT-04:00 =D0=94=D0=B5=D0=BD=D0=B8=D1=81 =D0=
=9A=D0=BE=D1=82=D0=BE=D0=B2 <span dir=3D"ltr"><<a rel=3D"nofollow">redr.=
...@gmail.com</a>></span>:<br></span><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span=
class=3D""><div dir=3D"ltr">What is the result of our TOPIC ?<br><br>Resul=
t is <b>ZERO </b>!!!!! How many <b>human*hours</b> has been spent, but noth=
ing !<br>Can somebody from <b>=D1=81ommittee </b>help us ?<br>Will be it co=
nsider on standartization ?<br><br>We have different opinions. Some guys th=
ink it is usefull, another is not.<br><b>We need a look from outside !!!</b=
><br><b><br></b></div></span><span><span class=3D"">
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br></span>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</a>.<br></span><span class=3D"">
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/3c73071d-76bc-4cc0-8d9b-155999d7ade2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" rel=3D"nofollow" t=
arget=3D"_blank">https://groups.google.com/a/is<wbr>ocpp.org/d/msgid/std-pr=
oposals<wbr>/3c73071d-76bc-4cc0-8d9b-<wbr>155999d7ade2%40isocpp.org</a>.<br=
>
</span></blockquote></div><br></div>
</blockquote></div><span class=3D"">
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/b5548c7a-933e-4a92-a2d4-77a1cca213c1%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/b554=
8c7a-933e-4a92-<wbr>a2d4-77a1cca213c1%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAKiZDp3VuW_zi5CecXpth-sp81z25bArWyrJ=
YzaMGfeR8JG0LQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKiZDp3VuW_zi5Ce=
cXpth-sp81z25bArWyrJYzaMGfeR8JG0LQ%40mail.gmail.com</a>.<br />
--001a114ba1ce05cc3b0539670771--
.
Author: =?UTF-8?B?0JTQtdC90LjRgSDQmtC+0YLQvtCy?= <redradist@gmail.com>
Date: Sun, 7 Aug 2016 02:43:06 -0700 (PDT)
Raw View
------=_Part_1054_1382837403.1470562987050
Content-Type: multipart/alternative;
boundary="----=_Part_1055_915509269.1470562987050"
------=_Part_1055_915509269.1470562987050
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
In this topic some one has mentioned that we need dinamic structure to keep=
=20
stacktrace information.
I have another idea.
What if compiler would support stacktrace first of all put on stack of=20
current thread an address of function that would be invoked and then put=20
all information for function parameters and so on. Like on picture below:
In this case we no need any other dynamic structure data. We have already=
=20
the main dynamic structure of our program *A STACK OF CURRENT THREAD !!!!!!=
*
Invoked function that does not support stacktrace would never know about=20
this additional information, only our program that would be compiled with=
=20
stacktrace support would know about this information !
*What do you think about it ? *
=D0=B2=D0=BE=D1=81=D0=BA=D1=80=D0=B5=D1=81=D0=B5=D0=BD=D1=8C=D0=B5, 31 =D0=
=B8=D1=8E=D0=BB=D1=8F 2016 =D0=B3., 3:14:19 UTC+3 =D0=BF=D0=BE=D0=BB=D1=8C=
=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C =D0=94=D0=B5=D0=BD=D0=B8=
=D1=81 =D0=9A=D0=BE=D1=82=D0=BE=D0=B2=20
=D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:
>
> In *C++17* will be added a lot of new features, but no of them features=
=20
> improve quality of code and quickly fixing of the code.
> If in program exist a bug then the best that program can do is crash.=20
> Exception is a good conception for error handling, but is useless in C++=
=20
> implementation, 'cause we do not know where the problem happens. That mea=
n=20
> catching of exception is useless, because additional information is so=20
> small that better allow program simple crash.
> This is the main reason that even in debug mode exception is used not=20
> often.
>
> *PROBLEM *is no standard on it about providing to user *backtrace*.
> Operation system can get stack trace when exception was used. We can=20
> implement getting stack trace even in dummy implementation by adding to=
=20
> every function in compile time meta information with name of this functio=
n=20
> and code that will put this name in stack object that implicitly exists=
=20
> from starting the program. We can add scpecial flag *BACK_TRACE* or=20
> *BTRACE*.
>
> Sorry for straightforward speech but I tired. In we can implement=20
> *backtrace*, but are thinking about coroutine. Without strong *base *we=
=20
> cannot implement something good.
>
>
>
>
> *Thanks,Best regards.*
>
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/770cb07a-f2c7-4928-8edb-f24e28f61a82%40isocpp.or=
g.
------=_Part_1055_915509269.1470562987050
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
In this topic some one has mentioned that we need dinamic structure to keep=
stacktrace information.<br>I have another idea.<br><br>What if compiler wo=
uld support stacktrace first of all put on stack of current thread an addre=
ss of function that would be invoked and then put all information for funct=
ion parameters and so on. Like on picture below:<br><br><img style=3D"" src=
=3D"cid:autoGeneratedInlineImage1" alt=3D""><br><br>In this case we no need=
any other dynamic structure data. We have already the main dynamic structu=
re of our program <b>A STACK OF CURRENT THREAD !!!!!!</b><br><br>Invoked fu=
nction that does not support stacktrace would never know about this additio=
nal information, only our program that would be compiled with stacktrace su=
pport would know about this information !<br><br><b>What do you think about=
it ? </b><br><br>=D0=B2=D0=BE=D1=81=D0=BA=D1=80=D0=B5=D1=81=D0=B5=D0=BD=D1=
=8C=D0=B5, 31 =D0=B8=D1=8E=D0=BB=D1=8F 2016 =D0=B3., 3:14:19 UTC+3 =D0=BF=
=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C =D0=94=
=D0=B5=D0=BD=D0=B8=D1=81 =D0=9A=D0=BE=D1=82=D0=BE=D0=B2 =D0=BD=D0=B0=D0=BF=
=D0=B8=D1=81=D0=B0=D0=BB:<blockquote class=3D"gmail_quote" style=3D"margin:=
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div =
dir=3D"ltr">In <b>C++17</b> will be added a lot of new features, but no of =
them features improve quality of code and quickly fixing of the code.<br>If=
in program exist a bug then the best that program can do is crash. Excepti=
on is a good conception for error handling, but is useless in C++ implement=
ation, 'cause we do not know where the problem happens. That mean catch=
ing of exception is useless, because additional information is so small tha=
t better allow program simple crash.<br>This is the main reason that even i=
n debug mode exception is used not often.<br><br><b>PROBLEM </b>is no stand=
ard on it about providing to user <b>backtrace</b>.<br>Operation system can=
get stack trace when exception was used. We can implement getting stack tr=
ace even in dummy implementation by adding to every function in compile tim=
e meta information with name of this function and code that will put this n=
ame in stack object that implicitly exists from starting the program. We ca=
n add scpecial flag <b>BACK_TRACE</b> or <b>BTRACE</b>.<br><br>Sorry for st=
raightforward speech but I tired. In we can implement <b>backtrace</b>, but=
are thinking about coroutine. Without strong <b>base </b>we cannot impleme=
nt something good.<br><br><b>Thanks,<br>Best regards.<br><br></b></div></bl=
ockquote>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/770cb07a-f2c7-4928-8edb-f24e28f61a82%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/770cb07a-f2c7-4928-8edb-f24e28f61a82=
%40isocpp.org</a>.<br />
------=_Part_1055_915509269.1470562987050--
------=_Part_1054_1382837403.1470562987050
Content-Type: image/png; name="Auto Generated Inline Image 1"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Auto Generated Inline Image 1"
X-Attachment-Id: autoGeneratedInlineImage1
Content-ID: <autoGeneratedInlineImage1>
iVBORw0KGgoAAAANSUhEUgAAAoQAAAK+CAIAAAC0NJjTAAA2cklEQVR42u3da2KqOhRA4Y6rA3I8
jsbJOJh7e7RVkuw88AXot34VG0gIcS/zAL7+AwAAi/KlCgAAIGMAAMgYAACQMQAAZAwAAMgYAAAy
BgAAZAwAABk3kgKrwVcXABkDZAwAZAwyBgAyBsgYAMgYZAwAny1jdYeXtlTNDwAZi4YgYwAgY5Cx
5geAjEVDkDEAkDHIWPMDQMaiIcgYAMgYZKz5ASDjFUTDwy4rze4QJTvu94cnZPy9Pz7zjKqHT07n
aSW5leP+u3ohyBgA3kvG55gfkojgOW54jgLTcwrLXJwOGQMAGS8UDf+0lcX8v37l5OMtyfhc/GZZ
yZiMAZDxSqLhOeCHCsqFtjkZt49KxmQMgIzXL+Oo/1xOwpaD3IE9pjPSWV65An+P1ytROsc9zbIo
UFCe8HQuJZn8NynG6fOfo13yrlZDJNCRipqc1c8/yRgAPkTGV0cMjOnmQq3ONk8dFiSa/juR8ZCJ
K7n+lf9OGe9237XCnmW82+X/KRa/9X8gjPyq+S0KGQPA+8u4a8ssXT6um6X9FdPlw3xKutDtRMbR
8aqlDTQ2+ejmYeqg7MW5hGccuPfy0UBFFVP3F8OTMQB8gowbfbcbVlOn497BKHj20Z82h0xcHVbP
P75dxslO6bR5mHclp9PHA4MNyRhDephc6WQMAO8u46qXhxdwJbslI7hNKSZjvP3lU7UDZoV70AKu
NE1UAY37wmoFiCoqXP1tzhgAPlfGmTSyUdqgs9zQ0LiMv7/HF25VZVz0t58u43i+uPgl06uosLxk
DACfIeO2tKJR2mCSNdDOTBmfUgyt3lpnz7gjzH5F6RkDwAfLuDkvmfU2czc0enOtOePsONOjDMyS
PnvOeK6MRx4vMlBR5owB4INlXF+1Wy4dDmVc3qbUXk0drzROh5ebAnryaurZMo6eVZad5FBF5Wc+
dssZGQPAW8i4vQapcrPs9Fak3o7R4Rva7Ou4km+5DHr4duXsoR/zZFyth/xny9xpZfcZA8AHybii
zOrE7Fc+yJzuE424JsmCFVDB/USdlVz1J3CNyrg4nZtlHFREXKBuRU2ugidwAcDnyRif11I1PwBk
LBqCjAGAjEHGmh8AMhYNQcYAQMYgY80PABmLhiBjACBjkLHmB4CMRUOQMQCQMcgYAMhYNAQZAwAZ
g4wBgIwBMgYAMgYZAwAZA2QMAGQMMgYAMgbIGADIGGQMAGQMkDEAkDHIGADIGCBjACBjkDEAkDFA
xgBAxiBjACBjgIwBgIxBxgBAxgAZAwAZg4wBgIwBMgYAMgYZAwAZA2QMAGQMMgYAMgbIGADIGGQM
AGQMkDEAkDHIGADIGCBjACBjkDEAkDFAxgBAxiBjACBjgIwBgIxBxgBAxgAZAwAZg4wBgIwBzQ8A
yBhkDABkDGh+AIQ40RBkDABkDGh+AMhYNAQZAwAZA5ofADIWDUHGAEDGgOYHgIxFQ5AxAJAxoPkB
IGPREGQMAGQMaH4AyFg0BBkDABkDmh8AMhYNQcYAQMaA5geAjEVDkDEAkDGg+QEgY9EQZAwAZAxo
fgDIWDQEGQMAGYOMNT8AZCwagowBgIxBxpofADIWDUHGAEDGIGPNDwAZi4YgYwAgY5Cx5geAjEVD
kDEAkDHIGADIWDQEGQMAGYOMAeDDZQwsiK8uADIGyBgAyBhkDABkDJAxAJAxyPgzOe6//1XC7jAn
+WjqdXLYXa799/54e5onXIv9ISvCSzJP8n1ctunpvPk36PyVeMTX4xHHsJoaG/nZqPnlLh4Ov5uX
8eWEv+q/QUbSPDOkv1LGRb6PyfYdfrSRMbARGb9BAz5H3u/v4fi7+SB77vK2T2AkzfNlvFC+ZEzG
wDZk/EYD3X+BdzwAv4eMO6f6ugFiMiZjMgYZz25+7zblfI27jb7gZPb05/9ppDht/Wxc0kyCeHes
d3LgOPx3EzS6tVG+aYniQoVpAj+l9fCXINm7PPq0aNPDZZn+/iu0Yv3sxovRzveS7eS/Zd0X9TTJ
Jz6dnnDOHyWJ81StTO9pM7XrMpZvT8b9SY/WV4yMQcZ9DW+96U6jfWzjIgp973aljHe7PJKlITGI
Q2V4a6p8MLjGO6WlfZ6M28UNynb595iMO2c3VoxRGZ+v85xrc00zIOPSOH87Ffn8pull+sA2E/wg
aB23JePuF6H7FSNjkPHbOjjuiZzDRhiHLnHhElpyvaUB7zdZEHJSeZWuapQm6DhVwmqgjclHtwxT
D8u40GteUdl2zTxBriNn1y3G8DB1cJBWS/nbKRfjeL5XJ12PcTrob4qBTO9pM9XrMpBvXcb9L0L/
K0bG+HQZv/2NW0WgKsJOFMrCWJJFu4rueqE1GLibNXNZibz5x0+UcZIiGWqoDsG27JXkOnR2vWLM
kPG8g4ycTrhHYvjv/X4XjP2PZvqYNtMXeJ6mKuP+F2HgK0bGIOP3lvHAqF8YgoM54+YUWeXo2fBd
JWLNmvyrxe6sjM+TcSPBQKYdGQ+dXbecwzIeP0hyuefIuJwl2R2me7XqLM70cW1maEy7J+OBL8LA
V4yMQcZvLePK7OLXV69n0pdx69C96bTkSN0Ec2ScRux3k3F9yddTZDw8fztwB9kpyd9CwEl3Oe04
j2X6sDYz62drTcYDX4SBrxgZ49Nl3Fby1mugMqKXjpDd1TMejyXdxaaDj+DQM36RjKeSyeZ858n4
YuOLi68Ozl08lOnD2kz8i7CSb7tn3B8c0DMGGX/saurqHGBi4+E54+gGmxuCSTcythM8e864uyCt
IbB6VWYB/gFzxs+WcaM3N1fGvzbeT8UbfDSc6UPazOyTbc8Z9+fNzRmDjD/1PuNWkEj6zPlq0Et/
oynjS2+iaq8w3kxz7iZodbEfv5o6j/pFPXQtWKyaLc7wYaupXyLjytjwXBmf1219f5dLFcIsmpne
1WZq12XkZLurqfv3FTS+YmQMMp6h5G2dfnu5aBJ+hu4z7jzdYnjC+CsMybNuGo33KlcGz30CV68e
bpxnrWRRmwHunt3tMo4e+jEyTF29ws0nhgS5BxXVXUAQLnKY22Y612Ug3/n3GTfvuHefMcj49uNs
6/Q7t27Es3+NJ3A1+9iDz6N60Irqcq/4EU03PA4zs8u8OeOoaEXJrjk0lhMPPYFrjoyLfEcOElyZ
YsQ1P51m5o2+46xMb2sz7evSy7c3T9z9IjS/YmQMMgaAbYY40RBkDABblTGwwmdUNdqtbzsAMgYW
kLH+NAAyBtYlYz4GQMYAGQMAGeOD54z5GMAbyljd4aUt9Y7mx8cAyBhYnYw1YABkDLxUxjrHAMh4
K8SvwBx6NNvxcDguXvYZr9v+QBnzMQAy3oyMw/dudR44ugYRkjEfAyDjt5Xx+YHhbRuT8ZZlzMcA
yHhzMp4OZZ8+DV4Lk70D5bT574/zu7dPO54/PySv/WgX5tpFT0fTJ+8guWQUFSAs/OfJmI8BkPEG
ZXx6kVby6rnpxvWd6tNXVtdkXLw3NHnPdW7H9EiXreS3QWrotowrhf88Gf9nsBoAGa9cxq03SucD
1n/bwzLOOtjpZuHG8LDH4zFM05VxrfAfKWM+BkDGG+kZn3xZDBRHa61HZVwbPa51VOO+96W/ngxU
9zKqFv5TZczHAMh4CzL+Lxujrg/tPkvGpwLktj97uOwxD8h44wu8yBgAGX+kjDMd/9uIhPY8GZ9t
/G+d16QMeRd5fJh62zZ+RvPjYwBkvAEZpwuv0pHrq96m869T6U2Wad0o478B6Uv3vDx8fvxKAaqF
/2gZ8zEAMt6CjMOFz8WUa6LM4/SGpb+e7K0yzobK/0vmi392qS0iKwpQLzwZ8zEAMgYWbn5kDICM
geWbHx8DIGNg+ebHxwDIGCBjAGR8U7QCluIFvudjAHrGwALNj48BkDFAxgDImIzx2TLmYwBkvCzr
fpnC8XC4ryTXp4Vs87GYr2x+ZAyAjJeUceap8E3D6yjazQdYyzltSMZ8DICMlzXeOt77e6+M07PY
3ruMF2h+ZAyAjFcp43QYe9LP3O1//3NKWE12fv9S9iLky0Ok09749ONjuleYJixJ9cw2aeNlZczH
AMh4MRlPXtOQCOw61Ju81qmXLHrfUpIsHUO+FigpWiNNxbG5fMlYgwdAxiuWccFFesdjKO5sBnY0
Wbl5eetwZM2pjFtpKoqNdtncKq7FZczHAMh4mZ5xZLV0BLo6tt1MVtmsrufO11910ugZ6xwDIOO3
lPFZsNOR5VDGY8kaMg5LkMm4l6b3LzLW5gGQ8RZl/OOvXGeRZQeT1TZr48f5MHUvTbtrbDX1KzI9
/SybPRkwGVRZ40TCcb8/3HuKt7Dmapku1mgs3LjpeOuqkKWuPhmTcd74o/VXpYxHklU3T/tc/nM9
2tSflTSjxXef8WvyvSFWpVMQa7tGpSReFI7XXS0LyHiJClns6pMxGXd+i0ZLq8aTtTan37Rrmt/D
BndZFUPi3fJv0MSfIePzJVrr5XmEaO7oFq+21b5exktUyGJXn4w/UcYg4xXIeLV9jWVlvN4u2EIy
fnGFkDEZA+8h47/tZIwxvSX9Kx58TBbn5/Hwb9bhkuiSxb+ExXBI/KCZuAj5vXjFo2xCKTRL266E
mgIeVC0Dg0b15RjVYnRl3B9UnuT/8++m9sIKCa5DepDBaq/Vw1JXn4zJGGT8JBlX30RSsU54I1v5
wLbdblc+2m3y4e9O+dGupavkUyteJRz3S9uuhGEZ31YtYzlkaXs105ZxfL6lyqfH3e2eI+N2tbfq
YamrT8ZkDDJ+noyLEJeF7iC8tT4K0lzDYhGMk3V/X8kK/Two/u6TC7u+hGektAOV0K/JW6ul4bZk
cWS5VqNZM3UZpws9phlk+V2TXK7UnAoZlnG12rv1sNzVJ+OBqAQsyFK/A+6UcbDYryrj9BmqWZxN
VRBF4rJPUt4Q31+zOyzjodIOVEK3Jm+ulv4pDu4YZRXIuDK1O3nG7tjFe5SM69U+UA+LXX0y1jOG
nvHje8atiFkkqa3TSXarz1KWfeUilMZRMBlvHA7HQ6UdqIRuTd5cLf1r1COsmZqMqwPc153DizB/
AdfwnPGMy9Ks3VdefTImY5DxqmWczOZGMq4tMgpl3J8avS8c1xf9PFjGjWq5TcbdmqnJuDJDOh2G
DvN/Qxnfc/XJmIxBxtvuGc+Q8dQbmZ8/vGc8UDPtnnGzCHrGZEzGwz+BV7PS73g4PKAk2eM6yXjN
Mp4xOXqfjBsdtGfMGt4p45urpfaVn2up6A2o1TnjWdPyk6PPlnFrnViv2rv1sODVJ+NPlXHWmtby
6MiBF0rd4gcyXrWMZywbfoCMg+VdT1pNfaeMb66Wxg/wfLi+vvKprJnuauquJqPpghsqpLwVaVTG
3XpY8OqTMRlPWtzyTeUBMh56+gEZr0rG/9UmHpu3nNw5TF29T3QyclSbA+yW9iEyvrVahsfD+neH
l89RmXOfcXFD9Ph9xnGF9A4yUO2delju6pMxGZcyTpvrZKHIbj/9XVlN9r0/pA06fhrSdP/8gNk7
KIpbA9OSZOfx+3AfMn5Npo+RcRnkBmYYb1jAlUfSa/sMH+vQGN4eegbTvTK+qVr6P1RrX51mzfTm
iQ+7r6/2I7jSQHBbhRyj2DJDxv16WOjqkzEZX1vPtemlnYSJKSuvJ8yTRe9zSgfDk3Hx9GVO6YBQ
nKbXrMl4I91xAGT80TKuDigdj8fQatms8miycvPyPuO8+5K/9KmVpvcTk4zJGAAZb65nHI4PJWPG
1bHtZrLKZnU99yT9SBoyfkaOZAyAjBeXcbquMunylosYeskaMg5LkMm4l4aMdYsBkPE7yji7Qfef
cyPLDiarbV7SN4o2koaMdYsBkPF7yjhcf1XKeCRZdfO0T3Jf3vUhtsk9gWUaMtYtBkDGby7jZCL4
J1W0tGo8WWtzOimcv8otusuqGBInY91iAGQMvJmMVT4AMgZe2vx0iwGQMbAuGat5AKuWMbAgusUA
yFiQwnv2jDVyAGQMLNn8dIsBkDGwZPNjYgBkDJAxADImY3ywjJkYABmvhOr7kNZRusPhrpJM3yS1
yXd5v1LG4gIAMl5Sxpl7R94RvFDR5pv47zxqb5r4WBnrFgMg41XLOH1Dw2ZlnOl3m0+oflLzY2IA
ZLwpGafD2JPXC+/2v/85Jawm+94frv/6e31xOXA83T8/YPZCqGTXsiTP6meTMQCQ8QtlPBneTbrI
1+Hrsxav7msmi16umCRLx8XTNyumr3WK0wz14g1TMzEAMl61jAsu0jseQ3Fns8qjycrNU7J8UDx6
A2MrTd/F6cuQP1rGTAyAjLfRM446lekIdHVsu5msslldzz1JP5Km/XNjk2upyRgAGZPxn2CnI8uh
jMeSNWQcliCTcS9N/QQ22Sd+RvNjYgBkvEEZ/6gsd25k2cFktc3adG4+TN1LE/eJN9olfnzzY2IA
ZLxZGYfrr0oZjySrbqZTutejTSeKK2kaxd/m8mkyBkDGZBzp+DpFGy2tGk/W2pxOCl/T/B42uMuq
GBKPu8W1lWkfJ2MmBkDGwJIy/opQtwDIGFhSxioWABkDr2t+TAyAjIElZWyAGgAZA6uTsSoF8A4y
BhaEiQGQsXCGLfWMyRgAGQNLypiJAZAxsKSMmRgAGQNkDABkDDLWaAGQMbCgjKc7qkMAZAwsI2MA
IGOAjAGAjEHGAEDGABkDABmDjAGAjAEyBgAyBhkDABkDZAwAZAwyBgAyBsgYAMgYZAwAZAyQMQCQ
McgYAMgYIGMAIGOQMQCQMaD5AQAZg4wBgIwBzQ+AECcagowBgIwBzQ8AGYuGIGMAIGNA8wNAxqIh
yBgAyBjQ/ACQsWgIMgYAMgY0PwBkLBqCjAGAjAHNDwAZi4YgYwAgY0DzA0DGoiHIGADIGND8AJCx
aAgyBoA1yxhYEF9dAGQMkDEAkDHIGADIGCBjACBjkDEAfLaM1R1e2lI1v4Dj/vtfbewOc5KPpl4n
h92lEXzvj7enecK12B+yIrwk8yTfx2Wbns6bf4POX4lHfD3uOAYZg4y37uLh8Lt5GV9O+Kv+G2Qk
zTND+itlXOT7mGzf4UcbGQMbkfEbtORz5P3+Ho6/mw+y5y5v+wRG0jxfxgvlS8ZkDGxDxm80/fwX
eMcD8HvIuHOqrxsgJmMyJmOQ8QM0vO1mfI27jb7gZPb05/9ppDht/Wxc0kyCeHesd3LgOPx3EzS6
tVG+aYniQoVpAj+l9fCXINm7PPq0aNPDZZn+/iu0Yv3sxovRzveS7eS/Zd0X9TTJJz6dnnDOHyWJ
81StTO9pM7XrMpZvT8b9SY/WV4yMQcZ9DW+9DU+jfWzjIgp973aljHe7PJKlITGIQ2V4a6p8MLjG
O6WlfZ6M28UNynb595iMO2c3VoxRGZ+v85xrc00zIOPSOH87Ffn8pull+sA2E/wgaB23JePuF6H7
FSNjkPHbOjjuiZzDRhiHLnHhElpyvaUB7zdZEHJSeZWuapQm6DhVwmqgjclHtwxTD8u40GteUdl2
zTxBriNn1y3G8DB1cJBWS/nbKRfjeL5XJ12PcTrob4qBTO9pM9XrMpBvXcb9L0L/K0bG+HQZv/3t
1EWgKsJOFMrCWJJFu4rueqE1GLibNXNZibz5x0+UcZIiGWqoDsG27JXkOnR2vWLMkPG8g4ycTrhH
Yvjv/X4XjP2PZvqYNtMXeJ6mKuP+F2HgK0bGIOP3lvHAqF8YgoM54+YUWeXo2fBdJWLNmvyrxe6s
jM+TcSPBQKYdGQ+dXbecwzIeP0hyuefIuJwl2R2me7XqLM70cW1maEy7J+OBL8LAV4yMQcZvLePK
7OLXV69n0pdx69C96bTkSN0Ec2ScRux3k3F9yddTZDw8fztwB9kpyd9CwEl3Oe04j2X6sDYz62dr
TcYDX4SBrxgZ49Nl3Fby1quiMqKXjpDd1TMejyXdxaaDj+DQM36RjKeSyeZ858n4YuOLi68Ozl08
lOnD2kz8i7CSb7tn3B8c0DMGGd++78bbcHUOMLHx8JxxdIPNDcGkGxnbCZ49Z9xdkNYQWL0qswD/
gDnjZ8u40ZubK+NfG++n4g0+Gs70IW1m9sm254z78+bmjEHG9x5hq824FSSSPnO+GvTS32jK+NKb
qNorjDfTnLsJWl3sx6+mzqN+UQ9dCxarZoszfNhq6pfIuDI2PFfG53Vb39/lUoUwi2amd7WZ2nUZ
Odnuaur+fQWNrxgZg4xnKHlb9dBeLpqEn6H7jDtPtxieMP4KQ/Ksm0bjvcqVwXOfwNWrhxvnWStZ
1GaAu2d3u4yjh36MDFNXr3DziSFB7kFFdRcQhIsc5raZznUZyHf+fcbNO+7dZwwyvv2A26qHzq0b
8exf4wlczT724POoHrSiutwrfkTTDY/DzOwyb844KlpRsmsOjeXEQ0/gmiPjIt+RgwRXphhxzU+n
mXmj7zgr09vaTPu69PLtzRN3vwjNrxgZg4zfRL0APiXE3TO+B6ztaRgAQMYAGQMAGYOMjUsDIGNg
cRnrRgMgY2BdMuZjAG8rY3WHl7ZUMgZAxmSMDcmYjwGQMbC8jPkYABlvkfhlW0MPgTkeDsfFyz7r
vdwfKmM+BkDGG5Bx+IaPzqPN1iBCMtY5BkDGbyvj86NJ2zYm4xXLmI8BkPH7yXg6lH36NHgAffa0
9dPmvz/Ob/k87Xj+/JA8YLxdmGsXPR1Nnzzt/JJRVICw8J8hYz4GQMYbl/H5XdmHXIhJ6ul+LRkX
byhL3qiZ2zE90mUr+W2QGrot40rhP1XGfAyAjNcr49a7K/MB67/tYRlnHex0s3BjeNjj8Rim6cq4
VvjPkDEfAyDjbfaMT75svqE8Gppuybg2elzrqMZ970t/PRmo7mVULfzHyPg/g9UAyHh7Mv4vG6Ou
D+0+S8anAuS2P3u47DEPyHjjC7we0vz4GAAZb03GmY7/bURCe56Mzzb+t85rUoa8izw+TL1tGz+q
+fExADLemIzThVfpyPVVb9P516n0Jsu0bpTx34D0pXteHj4/fqUA1cKTMRkDIOOVyzhc+FxMuSbK
PE5vWPrryd4q42yo/L9kvvhnl9oisqIA9cJ/moz5GAAZA8vLmI8BkDGwRhlr0gDIGHh18yNjAGQM
LCxjPgbwDjIGFuRJjudjAHrGwKubHxkDIGNg+ebHxwDIGFi++fExADJeCet+mcLxcLivJNenhWzz
sZhkDICMP0XGmafCNw2vo2g3H2At57QqGfMxADJer4zX8t7fe2WcnsX23mX8ouZHxgDIePUyToex
J/3M3f73P6eE1WTn9y9lL0K+PEQ67Y1PPz6me4VpwpJUz2yTNn69jPkYABmvQsaT1zQkArsO9Sav
deoli963lCRLx5CvBUqK1khTcWwuXzLWOQZAxiuWccFFesdjKO5sBnY0Wbl5eetwZM2pjFtpKoqN
dtncKq5FZMzHAMh4+Z5xZLV0BLo6tt1MVtmsrufO11910ugZ6xwDIOO3lPFZsNOR5VDGY8kaMg5L
kMm4l6b3LzLWOQZAxluU8Y+/cp1Flh1MVtusjR/nw9S9NO2usdXUOscAyHirMg7XX5UyHklW3Tzt
c/nP9WhTf1bSjBbffcaaOgAy3qiMk4ngn1TR0qrxZK3N6aTwNc3vYYO7rIoh8W75N2hiMgZAxiIU
PkvGd2R3+s0ze6l6+hNuhb9T94d7T/EW1lwt01sJG7cV3nS8dVXIUlefjMkYZPxSGacL5Nc2blFK
4kXheN3VsoCMl6iQxa4+GZMxyPjVMj53d9Y6efAI0dzRLV7tnMrrZbxEhSx29cmYjEHGi8h4tX2N
ZWW83i7YQjJ+cYWQ8SZkDCzIVmT8t52MMaYPTP2KBx+TR8fk8fBvTfwl0SWLfwmLxXrxY9DjIuRP
iisetB5KoVnadiXUFPCgaun0NOvpWjXTl3F/UHmS/8+/m9oLKyS4DulBBqu9Vg9LXX0y1jOGnvGT
ZFx9T3bFOuFj1srXiex2u/LFI5MPf3fKj3YtXSWfWvEq4bhf2nYlDMv4tmoZyyFL26uZtozj8y1V
Pj3ubvccGbervVUPS119MiZjkHE1x7tlXIS4LHQH4a31UZDmGhaLYJzclf6VPD8mD4q/++TCri/h
GSntQCX0a/LWamm4Lbl1v7yTsFkzdRmntyFOM8jyuya5XKk5FTIs42q1d+thuatPxmQMMn5Czzi4
Fb0q4/QNX1mcTVUQReKyT1I+rrW/ZndYxkOlHaiEbk3eXC39UxzcMcoqkHFlanfyBrixi/coGder
faAeFrv6ZPzRMq6+gmEdpTscHlCS7HGdZPwaGbciZpGktk4n2a0+S1n2lYtQGkfBpP0Ph+Oh0g5U
Qrcmb66W/jWaFRl6Mq4OcF93Di/C/AVcw3PGMy5Ls3ZfefXJ+ONlnLWrtTw6cuCFUreIgoy3J+Nk
NjeScW2RUSjj/tTofeG4vujnwTJuVMtt34NuzdRkXJkhnQ5Dh/m/oYzvufpkTMbR2xCXbzMPkPHQ
+lIy3n7PeIaMp97I/PzhPeOBmmn3jJtF0DMmYzK+S8bpb+XJT/HdfrogoZrse3+4/it7fXG+IHT6
8THdK0wTliQ7j9/bJ8h45TKeMTl6n4wbHbRnzBreKeObq6VmmLmWymqmPWc8a1p+cvTZMm6tE+tV
e7ceFrz6ZEzGabOaLLpIusjX4esosFaTRe9zSgfDk3Hx9GVO6VrEOE2vfZPxBmQ8Y9nwA2QcLO96
0mrqO2V8c7U0xqDz4fr6yqeyZrqrqbuajKYLbqiQ8lakURl362HBq0/GHy/j6u1yx+MxtFo2qzya
rNy8vM84b/j5S59aaXrNm4yfntcDZPxfbeKxecvJncPU1ftEy4GZorzd0j5ExrdWy/CXvX93ePkc
lTn3GdfGvwbuM44rpHeQgWrv1MNyV5+M9YzbpkraXf0twt1klc3qeu5J+pE0ZLx1GZdBbmCG8YYF
XHkkvbbC8LEOjeHtoWcw3Svjm6pl7NscTew0a6Y3T3zYfX21H8GVTlPdViHHaOZrhoz79bDQ1Sdj
Mq6aKh25Srq85c/EXrKGjMMSZDLupSHjbQ2JAwAZj5kqu0H3n3Mjyw4mq21e0jeKNpKGjB+XERkD
IOM1yThcf1XKeCRZdfO0T7Ly4fqYgGTVRZmGjHWLAZDxm8s4mRb5SRUtrRpP1tqcTgrnD8uN7rIq
hsTJWLcYABkDbyNj1Q6AjIGXNj/dYgBkDKxLxuocwAZkDCyIbjEAMhaq8G49Y80bABkDSzY/3WIA
ZAysS8ZqGwAZAy9tfrrFAMgYWLL5MTEAMl4V1fchraN0h8NdJZm+V2WTb0shYwBk/Ckyjl5QtgJ1
3fsYy5OJpy9W2+AzMZ/R/JgYABlvQMbpGxo2K+NMv9t8QvULZCwcACDj1cs4HcaevF54t//9zylh
Ndn3/hC9CTwfOJ7unx8weyFUsmtZkmf1s99ExrrFAMh4GzKeDO8mXeTr8PVZi1f3NZNFL1dMkqXj
4umbFdPXOsVphnrxhqmZGAAZr1rGBRfpHY+huLNZ5dFk5eYpWT4oHr2BsZWm7+L0ZchkTMYAyHj1
PeOoU5mOQFfHtpvJKpvV9dyT9CNp2j83NrmW+qHNj4kBkPFGZXwW7HRkOZTxWLKGjMMSZDLupamf
wCb7xI9tfkwMgIw3K+MfleXOjSw7mKy2WZvOzYepe2niPvFGu8RkDICMyfi/QoHT9VeljEeSVTfT
Kd3r0aYTxZU0jeJvc/n0M5ofEwMg4y3LOJkI/kkVLa0aT9banE4KX9P8Hja4y6oYEo+7xbWVaR8k
YyYGQMYAGQMAGeODZczEAMgYWFLGXxGqFAAZA0vKWH0CIGPgdTJmYgDvLGNgQe5ptL72APSMgdf1
jJkYABkDS8qYiQGQMUDGAEDG+GAZMzEAMgaWlDETAyBjgIwBgIxBxtoqADIGFpTxNL2qA0DGwDIy
BgAyBsgYAMgYZAwAZAyQMQCQMcgYAMgYIGMAIGOQMQCQMUDGAEDGIGMAIGOAjAGAjEHGAEDGABkD
ABmDjAGAjAEyBgAyBhkDABkDZAwAZAwyBgAyBsgYAMgYZAwAZAyQMQCQMcgYAMgY0PwAgIxBxgCw
WRkDC+KrC4CMATIGADIGGQMAGQNkDABkDDIGgM+WsbrDS1uq5lfluP/+Vye7w5zko6nXyWF3aQrf
++PtaZ5wLfaHrAgvyTzJ93HZpqfz5t+g81fiEV+Pm45BxiDj93DxcPjdvIwvJ/xV/w0ykuaZIf2V
Mi7yfUy27/CjjYyBjcj4DdrzOfJ+fw/H380H2XOXt30CI2meL+OF8iVjMga2IeM3moT+C7zjAfg9
ZNw51dcNEJMxGZMxyPgBGt52Y77G3UZfcDJ7+vP/NFKctn42LmkmQbw71js5cBz+uwka3doo37RE
caHCNIGf0nr4S5DsXR59WrTp4bJMf/8VWrF+duPFaOd7yXby37Lui3qa5BOfTk8454+SxHmqVqb3
tJnadRnLtyfj/qRH6ytGxiDjvoa33pKn0T62cRGFvne7Usa7XR7J0pAYxKEyvDVVPhhc453S0j5P
xu3iBmW7/HtMxp2zGyvGqIzP13nOtbmmGZBxaZy/nYp8ftP0Mn1gmwl+ELSO25Jx94vQ/YqRMcj4
bR0c90TOYSOMQ5e4cAktud7SgPebLAg5qbxKVzVKE3ScKmE10Mbko1uGqYdlXOg1r6hsu2aeINeR
s+sWY3iYOjhIq6X87ZSLcTzfq5Ouxzgd9DfFQKb3tJnqdRnIty7j/heh/xUjY3y6jN/+puoiUBVh
JwplYSzJol1Fd73QGgzczZq5rETe/OMnyjhJkQw1VIdgW/ZKch06u14xZsh43kFGTifcIzH8936/
C8b+RzN9TJvpCzxPU5Vx/4sw8BUjY5Dxe8t4YNQvDMHBnHFziqxy9Gz4rhKxZk3+1WJ3VsbnybiR
YCDTjoyHzq5bzmEZjx8kudxzZFzOkuwO071adRZn+rg2MzSm3ZPxwBdh4CtGxiDjt5ZxZXbx66vX
M+nLuHXo3nRacqRugjkyTiP2u8m4vuTrKTIenr8duIPslORvIeCku5x2nMcyfVibmfWztSbjgS/C
wFeMjPHpMm4reesVUhnRS0fI7uoZj8eS7mLTwUdw6Bm/SMZTyWRzvvNkfLHxxcVXB+cuHsr0YW0m
/kVYybfdM+4PDugZg4xvP8LGW3J1DjCx8fCccXSDzQ33WnYjYzvBs+eMuwvSGgKrV2UW4B8wZ/xs
GTd6c3Nl/Gvj/VS8wUfDmT6kzcw+2faccX/e3JwxyPgxSn4jF+d95nw16KW/0ZTxpTdRtVcYb6Y5
dxO0utiPX02dR/2iHroWLFbNFmf4sNXUL5FxZWx4rozP67a+v8ulCmEWzUzvajO16zJyst3V1P37
ChpfMTIGGc9Q8rZqo71cNAk/Q/cZd55uMTxh/BWG5Fk3jcZ7lSuD5z6Bq1cPN86zVrKozQB3z+52
GUcP/RgZpq5e4eYTQ4Lcg4rqLiAIFznMbTOd6zKQ7/z7jJt33LvPGGR8+2G3VRudWzfi2b/GE7ia
fezB51E9aEV1uVf8iKYbHoeZ2WXenHFUtKJk1xway4mHnsA1R8ZFviMHCa5MMeKan04z80bfcVam
t7WZ9nXp5dubJ+5+EZpfMTIGGb+JegG8f4i7Z2QPWNtzMACAjAEyBgAyBhkblwZAxsBKZKwzDYCM
gXXJmI8BvKGM1R1e2lLJGAAZkzE2J2M+BkDGwPIy5mMAZLwt4tdsDT3+5Xg4HBcv+6w3cn+0jPkY
ABmvWsbhuz06DzVbgwjJWOcYABm/rYzPDyVt25iMVy9jPgZAxu8k4+lQ9unT4NHz2XPWT5v//ji/
3/O04/nzQ/Jo8XZhrl30dDR98pzzS0ZRAcLCf5KM+RgAGW9Wxue3ZB9yISapp/u1ZFy8myx5l2Zu
x/RIl63kt0Fq6LaMK4X/bBnzMQAyXqOMW2+tzAes/7aHZZx1sNPNwo3hYY/HY5imK+Na4T9JxnwM
gIy31jM++bL5bvJoaLol49roca2jGve9L/31ZKC6l1G18B8m4/8MVgMg4y3J+L9sjLo+tPssGZ8K
kNv+7OGyxzwg440v8Hpg8+NjAGS8HRlnOv63EQnteTI+2/jfOq9JGfIu8vgw9bZt/Njmx8cAyHgz
Mk4XXqUj11e9Tedfp9KbLNO6UcZ/A9KX7nl5+Pz4lQJUC0/GZAyAjFcu43DhczHlmijzOL1h6a8n
e6uMs6Hy/5L54p9daovIigLUC/+ZMuZjAGQMLC9jPgZAxsAaZaxhAyBj4NXNj4wBkDGwfPPjYwAb
ljGwIE81PR8D0DMGXt38yBgAGQPLNz8+BkDGwPLNj48BkPHirPtlCsfD4b6SXJ8Wss3HYpIxADL+
FBlnngrfNLyOot18gLWc0wplzMcAyHidxlvHe3/vlXF6Ftt7l/FLmx8ZAyDjFcs4Hcae9DN3+9//
nBJWk53fv5S9CPnyEOm0Nz79+JjuFaYJS1I9s03aeCkZ8zEAMl5YxpPXNCQCuw71Jq916iWL3reU
JEvHkK8FSorWSFNxbC5fMtY5BkDGK5ZxwUV6x2Mo7mwGdjRZuXl563BkzamMW2kqio122dwqrgVl
zMcAyHjJnnFktXQEujq23UxW2ayu587XX3XS6BnrHAMg47eU8Vmw05HlUMZjyRoyDkuQybiXpvcv
MtY5BkDGW5Txj79ynUWWHUxW26yNH+fD1L007a6x1dQaPAAy3qqMw/VXpYxHklU3T/tc/nM92tSf
lTSjxXef8WtyPI2RzJ6Zn8xwrHFW/7jfH+49xVtYc7VMV042VlHedLx1VchSV5+MybjV/KOlVePJ
WpvTSeFrmt/DBndZFUPi3fJv0MSfIeN0PcDaLlMpiReF43VXywIyXqJCFrv6ZPyJMgYZPzDTG2LV
+ffSWn8rPUI0d3SLV/sT8vUyXqJCFrv6ZEzGIONFZLzavsayMl5vF2whGb+4QsiYjIH3kPHfdjLG
mD4f5isefEzulMvj4d8SgEuiSxb/EhZzE/FT3+Ii5DfGF8+VC6XQLG27EmoKeFC1dHqa9XStmunL
uD+oPMn/599N7YUVElyH9CCD1V6rh6WuPhmTMcj4STKuvhasYp3wrvLy6am73a58zurkw9+d8qNd
S1fJp1a8Sjjul7ZdCcMyvq1axnLI0vZqpi3j+HxLlU+Pu9s9R8btam/Vw1JXn4xHAxOwIJuVcRHi
stAdhLfWR0Gaa1gsgnGyCP8ruV0uD4q/++TCri/hGSntQCX0a/LWamm4LblToVw42ayZuozTVZfT
DLL8rkkuV2pOhQzLuFrt3XpY7uqTsZ4x9IyfIONg5X1VxukDzbM4m6ogisRln6R8Ok1/ze6wjIdK
O1AJ3Zq8uVr6pzi4Y5RVIOPK1O7kgfdjF+9RMq5X+0A9LHb1yZiMQcZFvnfLuBUxiyS1dTrJbvVZ
yrKvXITSOAom443D4XiotAOV0K3Jm6ulf416hDVTk3F1gPu6c3gR5i/gGp4znnFZmrX7yqtPxmQM
Mn7KAq5HyTiZzY1kXFtkFMq4PzV6XziuL/p5sIwb1XKbjLs1U5NxZYZ0Ogwd5v+GMr7n6pPxJ8q4
+gqGdZTucHhASbLHdZLxdmXc7RnPkPHUG5mfP7xnPFAz7Z5xswh6xmRMxrXmljWntTw6cuCFUrf4
gYxXLeMZk6P3ybjRQXvGrOGdMr65WmqGmWup6HXk1TnjWdPyk6PPlnFrnViv2rv1sODVJ2MynrS4
5ZvKA2Q8dMMlGa9JxjOWDT9AxsHyrietpr5TxjdXS2M0LB+ur698Kmumu5q6q8louuCGCilvRRqV
cbceFrz6ZEzGpYzTYezJ3NRuP23K1WTf+8P1X9nri/M7JKcfH9O9wjRhSbLz+H2eABlvRsb/1SYe
m7ec3DlMXb1PtGyHRXm7pX2IjG+tlqaOWwVu18z8+4xrX/eB+4zjCukdZKDaO/Ww3NUnYzK+tp5r
7yGNSxNTVl5PmCeL3ueUDoYn4+Lpy5zS36Bxml6zJuOtybgMcgMzjDcs4Moj6fXHYvhYh8bw9tAz
mO6V8U3V0h81qv2ObdZMb574sPv6aj+CK/1VfluFHKMf+jNk3K+Hha4+GX+qjKu/YY/HY2i1bFZ5
NFm5eXmfcR4x85c+tdL0WjUZr17/AMiYjHumSn731d8i3E1W2ayu556kH0lDxmQMgIzfUsbpUo6k
y1vOm/SSNWQcliCTcS8NGZMxADJ+RxlnN+j+c25k2cFktc1L+kbRRtKQ8aOzI2MAZLwOGYfrr0oZ
jySrbp72SW4FuD43L7kNoUxDxrrFAMj4zWWcTAT/pIqWVo0na21OJ4Xzt8dEd1kVQ+JkrFsMgIyB
N5OxygdAxsBLm59uMQAyBtYlYzUPYNUyBhZEtxgAGQtSeM+esUYOgIyBJZufbjEAMgbWJWN1DoCM
gZc2P91iAGQMLNn8mBgAGa+E6vuQ1lG6w+GukkzfJLXJ14eSMQAy/hQZR2/sXoG67n2M5cnE0zeN
b/CZmM9rfkwMgIxXLeP0DQ2blXGm320+ofplMhYUAJDximWcDmNPXi+82//+55Swmux7f7j+6+/1
xeXA8XT//IDZC6GSXcuSPKuf/VYy1i0GQMZrl/FkeDfpIl+Hr89avLqvmSx6uWKSLB0XT9+smL7W
KU4z1Is3TM3EAMh41TIuuEjveAzFnc0qjyYrN0/J8kHx6A2MrTR9F6cvQyZjMgZAxqvvGUedynQE
ujq23UxW2ayu556kH0nT/rmxybXUT2h+TAyAjDcn47NgpyPLoYzHkjVkHJYgk3EvTf0ENtknfkbz
Y2IAZLxBGf+oLHduZNnBZLXN2nRuPkzdSxP3iTfaJSZjAGRMxv8VCpyuvyplPJKsuplO6V6PNp0o
rqRpFH+by6ef1/yYGAAZb1PGyUTwT6poadV4stbmdFL4mub3sMFdVsWQeNwtrq1M+zgZMzEAMgbI
GADIGB8sYyYGQMbAkjL+ilCxAMgYWFLGahUAGQOvkzETA3hPGQMLcqeJyRiAnjHw0p4xEwMgY2BJ
GTMxADIGyBgAyBgfLGMmBkDGwJIyZmIAZAyQMQCQMchYiwVAxsCCMp7upQIBkDGwjIwBgIwBMgYA
MgYZAwAZA2QMAGQMMgYAMgbIGADIGGQMAGQMkDEAkDHIGADIGCBjACBjkDEAkDFAxgBAxiBjACBj
gIwBgIxBxgBAxgAZAwAZg4wBgIwBzQ8AyBhkDABkDGh+AMhYNAQZAwAZA5ofADIWDUHGAEDGgOYH
gIxFQ5AxAJAxoPkBIGPREGQMAGQMaH4AyFg0BBkDABkDmh8AMhYNQcYAQMaA5geAjEVDkDEAkDGg
+QEgY9EQZAwAZAxofgDIWDQEGQMAGQOaHwAyFg1BxgBAxiBjzQ8AGYuGIGMAIGOQseYHgIxFQ5Ax
AJAxyFjzA0DGoiHIGADIGGSsQgCQsWgIMgYAMgYZAwAZqzuQMQCQMcgYAMgYIGMAIGOQMQCQMUDG
AEDGIGMAIGOAjAGAjEHGAEDGABkDABmDjAGAjAEyBgAyBhkDABkDZAwAZAwyBgAyBsgYAMgYZAwA
ZAyQMQCQMcgYAMgYIGMAIGOQMQCQMUDGAEDGIGMAIGOAjAGAjEHGAEDGABkDABmDjAGAjAEyBgAy
BhkDABkDZAwAZAwyBgAyBsgYAMgYZAwAZAyQMQCQMcgYAMgY0PwAgIxBxgBAxoDmB4CMRUOQMQCQ
MaD5ASBj0RBkDABkDGh+AMhYNAQZAwAZA5ofADIWDUHGAEDGgOYHgIxFQ5AxAJAxoPkBIGPREGQM
AGQMaH4AyFg0BBkDABkDmh8AMhYNQcYAQMaA5geAjEVDkDEAkDGg+QEgY9EQZAwAZAwy1vwAkLFo
CDIGADIGGWt+AMhYNAQZAwAZg4w1PwBkLBqCjAGAjEHGAEDGoiHIGADIGGQMAGQMkDEAkDHIGADI
GCBjACBjkDEAkDFAxgBAxiBjACBjgIwBgIxBxgBAxgAZAwAZg4wBgIwBMgYAMgYZAwAZA2QMAGQM
MgYAMgbIGADIGGQMAGQMkDEAkDHIGADIGCBjACBjkDEAkDFAxgBAxiBjACBjgIwBgIxBxgBAxgAZ
AwAZg4wBgIwBMgYAMgYZAwAZA2QMAGQMMgYAMgbIGADIGGQMAGQMkDEAkDHIGADIGND8AICMQcYA
QMaA5geAjEVDkDEAkDGg+QEgY9EQZAwAZAxofgDIWDQEGQPAx8j46z5cNjJWIQDIeHY0/HoJLicZ
AwAZLyBghiZjACDj9WqYm8kYAD5Oxl/bRCMgYwB4Bxm/WIHcTMYqBAAZX6PhqiRHzGQMAJ8l463I
jJvJGAA+UcYbiuncTMYA8G4y3nqI52YyBoANy/gtIz4xkzEAbEPGnyMAel5P/ascAGT8iTHROu1V
1bOKAkDGoqHbqBauSV9dAGQsGj7dze9ayWoGAO6SMRZ38+ZU5KcJAJDxp7h5QWn52QEAZEzPb4jm
AYCMQc/UCwBkjPc1tGsKAGRM0tQLAGSMN7K1egYAMgYAgIwBAAAZAwBAxgAAgIwBACBjAABAxgAA
kDEAACBjAADIGAAAkDEAAGQMAADIGAAAMgYAAGQMAAAZAwAAMgYAgIwBAAAZAwBAxgAAgIwBACBj
AABAxgAArJX/AWw3JwTsJPRhAAAAAElFTkSuQmCC
------=_Part_1054_1382837403.1470562987050--
.
Author: =?UTF-8?B?0JTQtdC90LjRgSDQmtC+0YLQvtCy?= <redradist@gmail.com>
Date: Sun, 7 Aug 2016 02:55:40 -0700 (PDT)
Raw View
------=_Part_104_1415642680.1470563740737
Content-Type: multipart/alternative;
boundary="----=_Part_105_404431638.1470563740737"
------=_Part_105_404431638.1470563740737
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
After this we can collect all this information for Debug purpous.
If programm support Debug information that's GREATE !!! We would have:
*sort() function in test.so*
Another we would print some strange name of function in module like this:
*__func213 in test.so*
But it is not problem =3D)
=D0=B2=D0=BE=D1=81=D0=BA=D1=80=D0=B5=D1=81=D0=B5=D0=BD=D1=8C=D0=B5, 7 =D0=
=B0=D0=B2=D0=B3=D1=83=D1=81=D1=82=D0=B0 2016 =D0=B3., 12:43:07 UTC+3 =D0=BF=
=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C =D0=94=
=D0=B5=D0=BD=D0=B8=D1=81 =D0=9A=D0=BE=D1=82=D0=BE=D0=B2=20
=D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:
>
> In this topic some one has mentioned that we need dinamic structure to=20
> keep stacktrace information.
> I have another idea.
>
> What if compiler would support stacktrace first of all put on stack of=20
> current thread an address of function that would be invoked and then put=
=20
> all information for function parameters and so on. Like on picture below:
>
>
>
> In this case we no need any other dynamic structure data. We have already=
=20
> the main dynamic structure of our program *A STACK OF CURRENT THREAD=20
> !!!!!!*
>
> Invoked function that does not support stacktrace would never know about=
=20
> this additional information, only our program that would be compiled with=
=20
> stacktrace support would know about this information !
>
> *What do you think about it ? *
>
> =D0=B2=D0=BE=D1=81=D0=BA=D1=80=D0=B5=D1=81=D0=B5=D0=BD=D1=8C=D0=B5, 31 =
=D0=B8=D1=8E=D0=BB=D1=8F 2016 =D0=B3., 3:14:19 UTC+3 =D0=BF=D0=BE=D0=BB=D1=
=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C =D0=94=D0=B5=D0=BD=D0=
=B8=D1=81 =D0=9A=D0=BE=D1=82=D0=BE=D0=B2=20
> =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:
>>
>> In *C++17* will be added a lot of new features, but no of them features=
=20
>> improve quality of code and quickly fixing of the code.
>> If in program exist a bug then the best that program can do is crash.=20
>> Exception is a good conception for error handling, but is useless in C++=
=20
>> implementation, 'cause we do not know where the problem happens. That me=
an=20
>> catching of exception is useless, because additional information is so=
=20
>> small that better allow program simple crash.
>> This is the main reason that even in debug mode exception is used not=20
>> often.
>>
>> *PROBLEM *is no standard on it about providing to user *backtrace*.
>> Operation system can get stack trace when exception was used. We can=20
>> implement getting stack trace even in dummy implementation by adding to=
=20
>> every function in compile time meta information with name of this functi=
on=20
>> and code that will put this name in stack object that implicitly exists=
=20
>> from starting the program. We can add scpecial flag *BACK_TRACE* or=20
>> *BTRACE*.
>>
>> Sorry for straightforward speech but I tired. In we can implement=20
>> *backtrace*, but are thinking about coroutine. Without strong *base *we=
=20
>> cannot implement something good.
>>
>>
>>
>>
>> *Thanks,Best regards.*
>>
>
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/28dc51d2-87af-4853-a51b-7ab53f92cc37%40isocpp.or=
g.
------=_Part_105_404431638.1470563740737
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">After this we can collect all this information for Debug p=
urpous.<br>If programm support Debug information that's GREATE !!! We w=
ould have:<br><b>sort() function in test.so</b><br><br>=C2=A0Another we wou=
ld print some strange name of function in module like this:<br><b>__func213=
in test.so</b><br><br>But it is not problem =3D)<br>=D0=B2=D0=BE=D1=81=D0=
=BA=D1=80=D0=B5=D1=81=D0=B5=D0=BD=D1=8C=D0=B5, 7 =D0=B0=D0=B2=D0=B3=D1=83=
=D1=81=D1=82=D0=B0 2016 =D0=B3., 12:43:07 UTC+3 =D0=BF=D0=BE=D0=BB=D1=8C=D0=
=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C =D0=94=D0=B5=D0=BD=D0=B8=D1=
=81 =D0=9A=D0=BE=D1=82=D0=BE=D0=B2 =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=
=BB:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;">In this topic some one has=
mentioned that we need dinamic structure to keep stacktrace information.<b=
r>I have another idea.<br><br>What if compiler would support stacktrace fir=
st of all put on stack of current thread an address of function that would =
be invoked and then put all information for function parameters and so on. =
Like on picture below:<br><br><img src=3D"https://groups.google.com/a/isocp=
p.org/group/std-proposals/attach/874a4a2657a5d/Auto%20Generated%20Inline%20=
Image%201?part=3D0.1&authuser=3D0" alt=3D""><br><br>In this case we no =
need any other dynamic structure data. We have already the main dynamic str=
ucture of our program <b>A STACK OF CURRENT THREAD !!!!!!</b><br><br>Invoke=
d function that does not support stacktrace would never know about this add=
itional information, only our program that would be compiled with stacktrac=
e support would know about this information !<br><br><b>What do you think a=
bout it ? </b><br><br>=D0=B2=D0=BE=D1=81=D0=BA=D1=80=D0=B5=D1=81=D0=B5=D0=
=BD=D1=8C=D0=B5, 31 =D0=B8=D1=8E=D0=BB=D1=8F 2016 =D0=B3., 3:14:19 UTC+3 =
=D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C =
=D0=94=D0=B5=D0=BD=D0=B8=D1=81 =D0=9A=D0=BE=D1=82=D0=BE=D0=B2 =D0=BD=D0=B0=
=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:<blockquote class=3D"gmail_quote" style=3D"m=
argin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
dir=3D"ltr">In <b>C++17</b> will be added a lot of new features, but no of=
them features improve quality of code and quickly fixing of the code.<br>I=
f in program exist a bug then the best that program can do is crash. Except=
ion is a good conception for error handling, but is useless in C++ implemen=
tation, 'cause we do not know where the problem happens. That mean catc=
hing of exception is useless, because additional information is so small th=
at better allow program simple crash.<br>This is the main reason that even =
in debug mode exception is used not often.<br><br><b>PROBLEM </b>is no stan=
dard on it about providing to user <b>backtrace</b>.<br>Operation system ca=
n get stack trace when exception was used. We can implement getting stack t=
race even in dummy implementation by adding to every function in compile ti=
me meta information with name of this function and code that will put this =
name in stack object that implicitly exists from starting the program. We c=
an add scpecial flag <b>BACK_TRACE</b> or <b>BTRACE</b>.<br><br>Sorry for s=
traightforward speech but I tired. In we can implement <b>backtrace</b>, bu=
t are thinking about coroutine. Without strong <b>base </b>we cannot implem=
ent something good.<br><br><b>Thanks,<br>Best regards.<br><br></b></div></b=
lockquote></blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/28dc51d2-87af-4853-a51b-7ab53f92cc37%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/28dc51d2-87af-4853-a51b-7ab53f92cc37=
%40isocpp.org</a>.<br />
------=_Part_105_404431638.1470563740737--
------=_Part_104_1415642680.1470563740737--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Sun, 07 Aug 2016 09:21:42 -0700
Raw View
On domingo, 7 de agosto de 2016 02:43:06 PDT =D0=94=D0=B5=D0=BD=D0=B8=D1=81=
=D0=9A=D0=BE=D1=82=D0=BE=D0=B2 wrote:
> What if compiler would support stacktrace first of all put on stack of=20
> current thread an address of function that would be invoked and then put=
=20
> all information for function parameters and so on. Like on picture below:
>=20
>=20
>=20
> In this case we no need any other dynamic structure data. We have already=
=20
> the main dynamic structure of our program *A STACK OF CURRENT THREAD !!!!=
!!*
First of all, that's still dynamic. The information is kept on the stack,=
=20
instead of allocating heap memory, but it's still dynamic. This means the=
=20
application now needs a larger stack by the same amount as it would have=20
needed before in the heap (probably more). So you've only shifted the OOM=
=20
problem elsewhere, and to an even more difficult place to fix since it ther=
e's no=20
exception thrown when a stack overflow happens.
Second, there's a big problem in the design of your solution: you can't use=
=20
the stack to pass information along when the stack unwinds. That informatio=
n=20
was lost by the time the exception handler got called.
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/1919410.RBSa41uZPv%40tjmaciei-mobl1.
.
Author: =?UTF-8?B?0JTQtdC90LjRgSDQmtC+0YLQvtCy?= <redradist@gmail.com>
Date: Sun, 7 Aug 2016 12:01:03 -0700 (PDT)
Raw View
------=_Part_1437_548995536.1470596463374
Content-Type: multipart/alternative;
boundary="----=_Part_1438_587641310.1470596463374"
------=_Part_1438_587641310.1470596463374
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Thiago Macieira wrote:
> First of all, that's still dynamic. The information is kept on the stack,=
=20
> instead of allocating heap memory, but it's still dynamic. This means the=
=20
> application now needs a larger stack by the same amount as it would have=
=20
> needed before in the heap (probably more).
*No, it is a good place to put this information !!!*
Because this would be proportional invokes of functions. It is similary=20
pushing parameters on stack for function.
And if user will compile with stack support information - then it is deal=
=20
of user !!!
> Second, there's a big problem in the design of your solution: you can't=
=20
use=20
> the stack to pass information along when the stack unwinds. That=20
information=20
> was lost by the time the exception handler got called.=20
It is not true. Stack unwinding shown below:
When program detect exception, then in stack unwinding operation it should=
=20
copy address of invoked function like shown on picture.
If nobody caught exception or it would be caught in main function we would=
=20
be able to understand the problem in program.
=D0=B2=D0=BE=D1=81=D0=BA=D1=80=D0=B5=D1=81=D0=B5=D0=BD=D1=8C=D0=B5, 7 =D0=
=B0=D0=B2=D0=B3=D1=83=D1=81=D1=82=D0=B0 2016 =D0=B3., 19:21:47 UTC+3 =D0=BF=
=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Thiago M=
acieira=20
=D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:
>
> On domingo, 7 de agosto de 2016 02:43:06 PDT =D0=94=D0=B5=D0=BD=D0=B8=D1=
=81 =D0=9A=D0=BE=D1=82=D0=BE=D0=B2 wrote:=20
> > What if compiler would support stacktrace first of all put on stack of=
=20
> > current thread an address of function that would be invoked and then pu=
t=20
> > all information for function parameters and so on. Like on picture=20
> below:=20
> >=20
> >=20
> >=20
> > In this case we no need any other dynamic structure data. We have=20
> already=20
> > the main dynamic structure of our program *A STACK OF CURRENT THREAD=20
> !!!!!!*=20
>
> First of all, that's still dynamic. The information is kept on the stack,=
=20
> instead of allocating heap memory, but it's still dynamic. This means the=
=20
> application now needs a larger stack by the same amount as it would have=
=20
> needed before in the heap (probably more). So you've only shifted the OOM=
=20
> problem elsewhere, and to an even more difficult place to fix since it=20
> there's no=20
> exception thrown when a stack overflow happens.=20
>
> Second, there's a big problem in the design of your solution: you can't=
=20
> use=20
> the stack to pass information along when the stack unwinds. That=20
> information=20
> was lost by the time the exception handler got called.=20
>
> --=20
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org=20
> Software Architect - Intel Open Source Technology Center=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/5272e13e-248e-4642-873c-33fe0ff291ee%40isocpp.or=
g.
------=_Part_1438_587641310.1470596463374
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><span class=3D"_username"><span style=3D"color: rgb(34, 34=
, 34);" class=3D"IVILX2C-D-a">Thiago Macieira wrote:</span></span><br>> =
First of all, that's still dynamic. The information is kept on the stac=
k,=20
<br>> instead of allocating heap memory, but it's still dynamic. Thi=
s means the=20
<br>> application now needs a larger stack by the same amount as it woul=
d have=20
<br>> needed before in the heap (probably more).<br><br><b>No, it is a g=
ood place to put this information !!!</b><br>Because this would be proporti=
onal invokes of functions. It is similary pushing parameters on stack for f=
unction.<br>And if user will compile with stack support information - then =
it is deal of user !!!<br><br><br>> Second, there's a big problem in=
the design of your solution: you can't use=20
<br>> the stack to pass information along when the stack unwinds. That i=
nformation=20
<br>> was lost by the time the exception handler got called.
<br><br>It is not true. Stack unwinding shown below:<br><br><br><img style=
=3D"" src=3D"cid:autoGeneratedInlineImage1" alt=3D""><br><br>When program d=
etect exception, then in stack unwinding operation it should copy address o=
f invoked function like shown on picture.<br>If nobody caught exception or =
it would be caught in main function we would be able to understand the prob=
lem in program.<span id=3D"result_box" class=3D"short_text" lang=3D"en"><sp=
an class=3D""></span></span><br><br>=D0=B2=D0=BE=D1=81=D0=BA=D1=80=D0=B5=D1=
=81=D0=B5=D0=BD=D1=8C=D0=B5, 7 =D0=B0=D0=B2=D0=B3=D1=83=D1=81=D1=82=D0=B0 2=
016 =D0=B3., 19:21:47 UTC+3 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=
=B0=D1=82=D0=B5=D0=BB=D1=8C Thiago Macieira =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=
=D0=B0=D0=BB:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On domingo, 7 de =
agosto de 2016 02:43:06 PDT =D0=94=D0=B5=D0=BD=D0=B8=D1=81 =D0=9A=D0=BE=D1=
=82=D0=BE=D0=B2 wrote:
<br>> What if compiler would support stacktrace first of all put on stac=
k of=20
<br>> current thread an address of function that would be invoked and th=
en put=20
<br>> all information for function parameters and so on. Like on picture=
below:
<br>>=20
<br>>=20
<br>>=20
<br>> In this case we no need any other dynamic structure data. We have =
already=20
<br>> the main dynamic structure of our program *A STACK OF CURRENT THRE=
AD !!!!!!*
<br>
<br>First of all, that's still dynamic. The information is kept on the =
stack,=20
<br>instead of allocating heap memory, but it's still dynamic. This mea=
ns the=20
<br>application now needs a larger stack by the same amount as it would hav=
e=20
<br>needed before in the heap (probably more). So you've only shifted t=
he OOM=20
<br>problem elsewhere, and to an even more difficult place to fix since it =
there's no=20
<br>exception thrown when a stack overflow happens.
<br>
<br>Second, there's a big problem in the design of your solution: you c=
an't use=20
<br>the stack to pass information along when the stack unwinds. That inform=
ation=20
<br>was lost by the time the exception handler got called.
<br>
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.goo=
gle.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x3dD\x26sntz\x3d1\x26usg\=
x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return true;" onclick=3D"this.hr=
ef=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x=
3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return t=
rue;">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" target=3D"=
_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google.=
com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH=
GRJdo5_JYG1DowztwAHAKs80XSA';return true;" onclick=3D"this.href=3D'=
http://www.google.com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1=
\x26usg\x3dAFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return true;">kde.org</a=
>
<br>=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center
<br>
<br></blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/5272e13e-248e-4642-873c-33fe0ff291ee%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5272e13e-248e-4642-873c-33fe0ff291ee=
%40isocpp.org</a>.<br />
------=_Part_1438_587641310.1470596463374--
------=_Part_1437_548995536.1470596463374
Content-Type: image/png; name="Auto Generated Inline Image 1"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Auto Generated Inline Image 1"
X-Attachment-Id: autoGeneratedInlineImage1
Content-ID: <autoGeneratedInlineImage1>
iVBORw0KGgoAAAANSUhEUgAAAkAAAALtCAIAAABPekxRAAA2xklEQVR42u3da2KiMBRA4a7LBbke
V+NmXEynU62ScBOCTwLf+TW2AYJzuad5kHx9AwDQIV++AgAAgQEAQGAAABAYAIDAAAAgMAAACAwA
QGAAABAY/nPcf6Xsj1Gx0+FwfMGFd4dTa/nTYVes3dxzvbSik1V/aW0BENgWOOfVkMQTNXUQGIEB
ILAP6StTwl+LbPDjjQvsWV/1s79AAAS2aX+FSf/ssFu+JTACA0BgXQgsaqddGJQfd0AGGXo4wpZd
K5fO5XzFGrUL7O9TUsO/A4PTBF/FsNSMk0f3/fO7ahfi3BP+P5ARAQJjsK+pPBgLrDh6NrRAUGj4
6ySNT9lrvsCKdRud56+eI5leysw5eXjfu/1+SmCPnRAAgW1WYcVWUkEd55yblr3k4esP8yG2kaIG
aTw63xMEVqhLdqLbt5DV7a/ErJOPhxavgpoQ2AMnBEBgLPbILMS0I67YLTfqOmuy1x0CS86YDOv9
nikpvTscJpTVevKoZ/byFVcF9tAJARAYl+1Ch00ILDnsL9NOT6tIus4aJmDMHwMrHjwscGlslQe9
5p08nwATVX3+CfOvxxgYQGCoGSnr0woaZZWhm3aB7Xa7r/bpJE8R2KCL8PcX//91a5alDbQX+IbA
AALDA9QFk7YjCmNgWUMt7etqFNjNGNMKK59y+kXh/Bb+DHb1181bub+0wAAQ2BJbWaV1o3a1Flgl
p9bGwCr9eE2DOsWJ//kvGgR2MdhhKKvgR/N9c+cY2GMnBEBgG2yDFZsLw5wZCmzcSKnPQmyaytA2
pT+YGlLp8ys0WX7nbux2I/EV5lfOHGCLZjneJzCzEAECQ1kIU4shDsoNp71PHRidvqKZOQqrvn/W
JrDgNbjCm3FzB9jueQ9s3gkJDCAwhNmx2En3NW5njJeHCN8Om/ZC3LJrqnC8asWUwKJ+uLhrbq5v
skq2rsRRP2E67GgMDCAwoEusZw8QGNBJCzkfvtMAAwgM6MNgBsAAAgP6IxtxJC+AwAAAIDAAAAgM
AEBgAAAQGAAABAYAIDAAAAgMAAACAwAQGAAABAYAAIEBAEBgAAACAwCAwAAAIDAAAIEBAEBgAAAQ
GACAwAAAIDAAAAgMAAACAwAQGAAABAYAAIEBAAgMAAACW9L9A4tBPgIIjMBAYACBERhAYACBERhA
YACBERgIDCAwApNBIPwAApNBAOEHEJgMAuEHgMBkEAg/gMBkEED4AQQmg0D4CT+AwGQQCD+AwGSQ
93LcZ7XZH6Nip8Ph+IIL7w6nV95R8fTJ7bysJvdyOuyK/xEEBhAYgf3lyZAkeb4mn75GG+k9hXUe
3Q6BASCwrjLIX6rP8uRf+2Xw454Edq5+ta4ERmAAgXWdQc5JMkzbuQS6E1j9rARGYACBrVVgUTtt
PKg07oAMMu5whC27Vq6Ny/mmapSO2Q0vOapQUJ/wdq41Gfw2qcbvz3/Odr128WuIpNPyRQ3u6ueX
BAYQGIE1qamhvy2XUHH0bJj3g0LDXycCa7JX4ap/9X9QYPv9rlTZs8D2+/w3owkw01Jt+UvgUhUC
AwiMwGYIITRI3OeWlb0k8+sP8yG2kaIGAovOV6xtkPoHP7q7CzGo++hewjsOfHX9UcMXNRqKvFqR
wAACI7C5FrtvFmLaJxn0UGY/+lNNk72KXZ75j+8XWHJQOgwYXrtwpd8fNzRqk7ZseppcgwQGEBiB
zXJZ8ySO5LCkd60qkqT/bXoKRemEWeWeNIkjLRN9AZV3EEoViL6ocNakMTCAwAjsIZFlPWhBo6yS
utsFttu1T94oCmzUrnu5wOLxr5H9p76osL4EBhAYgc33wTA7F/P3MHlnqXqmwH5LNM3gWGYLbEIy
01+UFhhAYAR2XyurtG7UrtYCq7QaamNg2XmGZ2kY9Xn1GNhcgbW8Mt3wRRkDAwiMwO5rgxX//B/N
Is8FNp4SX5+FGM/QS7v+qkn7xbMQZwssWrMku8mmLyq/87bXGwgMILANC6w+D6HwMtNw2vvUgdHp
K6qZVljhuuPpg82vk2UvMs8TWPF7yFU/d5jMe2AAgRHYfRYrDjR95R2A6TFRb1hSLJgFEcxdn5jN
UV6Jo1Vgo9u5W2DBFxFXaPKLGvwvWIkDIDACA4QfQGAyCIQfAAKTQSD8AAKTQQDhBxCYDALhB4DA
ZBAIP4DAZBBA+AEEJoOAwIQfQGAyCIQfQGAyCCD8AAKTQQDhBxCYDALhB4DAZBAIP4DAZBBA+AEE
JoNA+AEgMBkEwg8gMBkEEH4AgckggPADCEwGgfADCEwGAYQfQGAyCCD8AAKTQSD8ABCYDALhBxCY
DAIIP4DAZBAIPwAEJoNA+AEEJoMAwg8gMBkEEH4AgckgEH4AgckgMgiEH0BgMggg/AACk0Eg/AAQ
mAwC4QcQmAwCCD+AwGQQCD8ABCaDQPgBBCaDAMIPIDAZBBB+AIHJIBB+AIHJIDIIhB9AYDIIIPwA
ApNBIPwAEJgMAuEHEJgMAgg/gMBkEAg/4QcQmAwC4QcQmAwCCD+AwGQQQPgBBCaDQPgBBCaDyCAQ
fgCBySCA8AMITAaB8ANAYDIIhB9AYDIIIPwAApNBIPyEH0BgMgiEH0BgMggg/AACk0EA4QcQmAwC
4QeAwGQQCD+AwGQQQPgBBCaDQPgBIDAZBMIPIDAZBBB+AIHJIBB+wg8gMBkEwg8gMBkEEH4Agckg
gPADCEwGgfADQGAyCIQfQGAyCCD8AAKTQSD8ABCYDALhBxCYDAIIP4DAZBB4/IQfQGAyCIQfQGCb
ziDAB5GPAAIjMBAYQGAEBhAYQGAEBhAYQGAEBgJbE6fD7v+XsD/OKd5aepkc99f/+93hdH+ZF/xf
HI5ZFd53cQK7W2D+ooHw+6i/mjNl9wK73vBX2dstZV5Trz2BySDAW8JvBQF8TpK7XXOq7F5g56ZV
/QZayrxeYEt+gmQQAkOn4beiTsi/P/Lb/9hfh8AmbvUTbR8CIzDgpeG3tiG0W6KutDkGo0E/v0/z
7O+nnw/XMoOsP9kPNzhx7IvJApXmU3TdtEZxpcIygdDS7+GvQHL0+OzDqg1Pl1308qtQo+W7a68G
gREYthV+q5wAMsyQscFG6Xy3348Ftt/nWTlNs0EqHZ24rr9GicUHpbV9ncDq1Q3qdv11m8Am7q6t
GgRGYNhM+K154uI5H16T2zn5JbnuL2NeU+Q1QeZKSFPkpVjQ+EkT/ji/V2qTFajoK8j5gx/d04XY
LLCRkvIvKvs8qmp5EkfL3U1Wg8AIDJsIv9W/JDASwsgZkTIyEYVWKSji98eXAwNbRp1ts5oOBcPl
P36hwJISSZM2qFv+owmBNd3dVDUI7AXpg8BAYG8XWKE/apTq89wXjIFlRYpnrvQxFnQ3qxesZKas
jq8TWKVAw0UnBNZ0d5P1JLDn24vAQGDvFlhhtOTrq56VWwRWO/WwbFQuOdNkgTkCS7vZ1iaw8rQP
Anu1vQgMCxTYuiO20EOXdhA+1AJrT5mTsxUbXyvWAiMwAgOBrT90iwMjicGax8Ciydx35MzJLF8v
8OoxsMlJKRVzlL/K60mfNgZGYO+1F4Fh+QKrxPCK/JW3zfLphNe2UFVg176/YsYP118cXnmyQK0p
9/xZiPmcwdH3MGmO0XTA0R0+bRYigb3XXgSGXgRWCua+br8+Hz3RRNN7YBNv7DYPgAUzSOa+0hQf
NZ6WN3cljqnvocEc0dyWwiVKI1qTd0dgH7AXgaEvgY3P09ftT7xPFc/vrqzEUW3LNa5L8aSZiOOj
Rpe9dympTDDzxsCiqo1qdrvC+Vf3r8RBYG+0F4GhU4EBG32CtmwvGQQEBhBYl/b6tqElbGgJEFiP
9iIwEBhAYD0JbFJvAIEBBLZoexEYCAwgsP46DwkMBAYQWK/2+jYNDEuKUl8IQGAzFtqRQUBgAIH1
Zy8ZBAQGEFiX9tpABon39GtaCud0PJ4+XvdZO+ESWLdReritMNSywtIdp13zt7fLFid+bL2m16z5
RGB3CmzbGSSSwG+ATsTnEuRBYNuQV5YunyOwrrIwgRHYPfbaqMDOOaIeoARGYARGYAS2ZHsR2CBg
B4tKB8tdZ3v//H78/4/94bq90Pnnx2TF8Hplbk3BtKdzsIPG9UJRBcLKExiBERiB9W4vAisK7DdD
JNtQDD/c9vEbbsFaEthoY7xk39b8IUjPdP2U+DS1Wl1ghcoTWFepN/vD5Sqw8b5U5UNrG15FQREk
6WCn4emdtOI9Uh7Zd6Vc29J1pwSWHh2JaXD90T41BLZce31vdRJHup1fvvfq/8/NAsue7vRjuO/4
6LSn0yksMymwUuUJrH+BnbdpjF0QB/VXafPL0CKjLF3cZ/hSZuqi33fOmAoOCiRaO29NYPHOk8EG
1YPzpjtkEthy7bW5FthvsFb3d426DWsCK/XslRpEcRtv9Kg1CaxYeQLrvgtxnKCz7eqz/+jLQblM
Klk47D9IzzHsqmi46LjI6TCxZef1sum+nKP9oKvXLQvsUjDwVXa9W5HrY0hgy7fXFrsQk/7Dcrfb
qwT2W4HckOlD2twCW8EkDwIrCWwctPWUGu/eXDsk/Wvu/yV2h8P+q7q5cfWikWuabj5ocdXPEvTW
RwIr3MAgBUQXyxRHYG8VmAwyIbBMYefn9vRGgZ0N9n+ux6AOeVOsvQuxb4MRWNMkjpqNknb4HIEl
F7o8FMOjav6KL5r11zWE5twJK+F1SwIrdj5m3bX5t2QMrBd7fW/4PbCkaz/7O/QvtCPLDf5mu1Ng
o46N8enz8xcqUKw8ga1bYM3jUfUsfPtT7jp+e4uotu72XFTRmFOlEi0Cm7xuSWDx+FdSq/D6BNaL
vb63Oo0+6oIIBwCCP+b2x78W070Cy7ox00ft55DSRJJRBcqVJ7AVC2yYmAtzYBuz8F8gDuYf/Xkr
91fTRUvWKVZjWmAN1623wKYboVpgn7cXgUEX4jYEVmk1zBXYxWCHoayCHzVfdLaiymNQM262PgY2
PQ5oDKxXe8kgILAuBVbot5srsHO3824XdD1El6heNEz8UxM7RrMAs7O03OzkLMTaNMS8P//adCSw
5dtLBgGBLUJg0YvMJcnVxnaCafFN09ijAbYkhbdctFCmZUZh8YiG685/Dyx6/817YJ8RmAwCAluJ
wkoTC4rvimVvLhZed57uRKu1UWZd9I6ZiPlBs687Ne6VHR98G8kIszGwbuxVatIBH4HRgXUK7EVP
uwwCLTCAwN5qLwIDgQEEtl17ySAgMIDAurTX90ZXo1/MC7+n4/GxmkQTqAkMILAN2Ot7kytxhDt1
LaNqd59gKfck/AACKwpMBnmGJZaxb9ajAkvvor+9wAgMWK/A3jPJeOsCS7sYB+2Z82I6yWKnUbHz
uvKjN1Rqb0vmJ4yWZBxuV5TWpHhnXRqMwIAVCuxtr8hsezuVJOnfuuGi1/mLxaJ15JNiaf9eYUfL
SpmCl/rfjpnAgBUK7J3veG5yEsdVFKdTKLtsRKm12PjjddeuyDT5lpalMgUtRYd0N5ODwIBVCezN
KxRsczuVkQnS3sFiv2O1WGXf5HAeZD4HY6KMFhiA/gQmg7xMYOla16UdkBuLVQQW1iAT2FSZqV8R
GEBgW7LX1gU23Bjye9AJlx3UWKz0sdS3l3chTpWpN8HMQgQIbFP2IrB4DsZYYC3Fih/TzW1vZxs6
p1CmtfreAwMIbEn2IrCXCywZ2PopFU2vaC9W+zgc5BptHRjM6B91V07Wv0N7ERiwBoF9cGsJGQQE
BhDYMwUmg4DAACxdYJ/d1k8GAYEBBNafvWQQEBhAYM+x18cFBnwQ+QjoWGD+BIYWGIClC2whf37K
ICAwgMD6s5cMAgIDCOwhexHYyyguk7uM2h2PT6hJttQVgQEEtoHm1/cmV+JYyrJLj+7IfNPXF4EB
BLY1e33bkblvgV1XkiIwgMA2Zi8Cy7oYB0vj7g+X3ww2Xw6K7Q7H26+y7b8Gjhwen58wWyc43XJz
VJPsPn5+9qSWnPADCGyGvQjsIwL7bbacZZA0xW5di2eVFLYqyYtF69QnxdI+y3SR+nS137jMVGuR
wAAC22Dz63ujkziuojidQhNko2StxcYfr/uBRVsn5/uBlcpM9XYSGEBgG7TX9+a3U7m2yJL+vGK/
Y7VYZUfmcB5ktiPzVBkCA/ABgS15yZxtC+wspdHmW/lBbcUqAgtrkAlsqgyBAXi3wBa+5tvWd2TO
PVXYkbmlWOnjcEPnUtVayhAYgI8LTAZZkMDCORhjgbUUK378Peb6m9vZhgNfhTIEBuBTAlv+etsb
HwMbDGz9lIqmV7QXq30cDnLdylxOG8zoH3VXEhiAdwqsi90iZBAIP4DACAwQfkD/Autlsz4ZBMIP
ILD+7PVtR2bYkRkgsHUITEBA+AHbFVhff1fKIBB+AIH1Zy8ZBMIPIDACA4Qf0K3AehyUlkEg/AAC
I7AFUlznfRm1Ox6fsyPz1xK2mBZ+QK8C63RO8AaXkmrZY+tDVZtvr7/7KK0GLPwAAlunvb43uhZi
vn1klwLLlNXniogEBhCYDHKvwNIuxsH2XPvD5Te/BYvFdofj7VfZ/pUDRw6Pz0+YLXSf7hk9qsmr
2nPCD9ikwLpeUGCDAht0vSVNsVvX4lklN19Ui0UbrSTF0j7LdJeVdLn6uExTa1EXIkBgBLZCgY24
iuJ0CmWXjZK1Fht/vG5oOVRQtBtLrcy0v9LNxAgMILAN2Ot78/uBXVtkSX9esd+xWqzwsTgPclC+
pUxd0V3OQSQwYFECk0G6EthZSqPdI/OD2opVBBbWIBPYVJnyDfS6myWBAZ8U2AqW0960wH7Sf+6p
yEyNxUofS8NTeRfiVJm47dVp04vAgIUJTAbpT2DhHIyxwFqKFT+mQ1S3sw0HvgplKtXvc9ohgQGL
ENg6djPa+BjYYGDrp1Q0vaK9WO3jcJDrVuZy2mBG/6i7Mm5+lWanCD+AwDbw7MkgEH7AtgS2ms1k
ZRAIP2DTApNBAOEHdCCw1TS/ZBAIP2DTApNBAOEHdCCwNTW/wtsBPoV8BLxVYP4EBoQf0IHA1vc3
owwC4QdsUWAyCCD8AAKTQUBgAF4jsFWOOcsgEH7A5gQmgwDCDyAwGQQEJvyA1whsrU+aDALhBxCY
DAIIP2BhAlvxkgEyCIQfsCGBySCA8AMITAYBgQk/gMBkEAg/gMBKzxiBAcIP6FJgMggg/AACk0FA
YMIPeI3AVr/nngwC4QdsQmAyCCD8AAKTQUBgwg8gMBkEwg8gMAIDhB/Qt8BWP4NDBoHwAzYhMBkE
EH4AgckggPADCEwGgfADCIzAAOEHEJgMAgg/gMBkEAg/AC0C28ijJYNA+AEEJoMAwg8gMBkEBAaA
wGQQCD+AwGQQQPgBBCaDgMCEH0BgMgiEH0BgBAYIP4DAZBBA+AEEJoNA+AEgMBkEwg8gsLVkEOCD
yEcAgREYCAwgMAIDCAwgMAIDCAwgMAIDga2S02H3/9vYH+cUby29TI77axDsDqf7y7zg/+JwzKrw
vosT2FyBSR4QfsvwV3Om7F5g1xv+Knu7pcxr6rUnMBkEEH4zGiO73a45VXYvsHPTqn4DLWVeL7AF
PkEEJoNgNeHXfyT//ZHf/sf+OgQ2caufaPsQGIEBbwi/9Qyn3RJ1pc0xGA36+X2aZ38//Xy4lhlk
/cl+uMGJY19MFqg0n6LrpjWKKxWWCYSWfg9/BZKjx2cfVm14uuyil1+FGi3fXXs1CIzAsMXwW9lk
kGGGjA02Sue7/X4ssP0+z8ppmg1S6ejEdf01Siw+KK3t6wRWr25Qt+uv2wQ2cXdt1SAwAsP2wm+F
UxnP+fCa3M7JL8l1fxnzmiKvCTJXQpoiL8WCxk+a8Mf5vVKbrEBFX0HOH/zoni7EZoGNlJR/Udnn
UVXLkzha7m6yGgRGYNhQ+K14Cv5ICCNnRMrIRBRapaCI3x9fDgxsGXW2zWo6FAyX//iFAktKJE3a
oG75jyYE1nR3U9UgsOelDwLDkgW29tfdCv1Ro1Sf575gDCwrUjxzpY+xoLtZvWAlM2V1fJ3AKgUa
LjohsKa7m6znqwS2eod5kxQEtiCBFUZLvr7qWblFYLVTD8tG5ZIzTRaYI7C0m21tAitP+yCwF9mL
wEBgnxJYoYcu7SB8qAXWnjInZys2vlasBUZgb7QXgWHJAlv1317FgZHEYM1jYNFk7jty5mSWrxd4
9RjY5KSUijnKX+X1pE8bAyOwt9iLwLB8ga3TZDXDJG2zfDrhtS1UFdi176+Y8cP1F4dXnixQa8o9
fxZiPmdw9D1MmmM0HXB0h0+bhUhgb7EXgaEjgVVCurvvoT4fPdFE03tgE2/sNg+ABTNI5r7SFB81
npY3dyWOqe+hwRzR3JbCJUojWpN3R2DvsxeBoTuBlWK7r+9h4n2qeH53ZSWOaluucV2KJ81EHB81
uuy9S0llgpk3BhZVbVSz2xXOv7p/JQ4Ce4G9vr0HhlUIbHxC3y028QS9+QFblL0IDF0LTNyCwFYu
sHpXoU0UYUNLgMD6sxeBgcAAAuvSXgQGAgMIrEt7ERgIDCCwLu1FYCAwYLUC69Fhs1KDDILlxKov
BNi0wOb+YSuDgMAAAuvPXjIICAwgsC7ttYEMEm/l17QCzul4PH287rM2wCWw/sP1cFthqGWFpTtO
u+Zv77ZG0zPWa3rqmk9LEdgyH7O7h8S3ILBwA8CJsFyCPAhsY/LK0uVzBNZDFiawFwps+Y/ZIxO6
tiiwc2qoxyWBERiBERiBfURgMsgcgQ27GX9/GqxynW358/vx/z/2h+uuQuefH5OFwuuVuTUF057O
wcYZ1wtFFQgrT2AERmAE1stj9mAP5xYF9psYkt0nhh9u2/cNd14tCWy0H16yXWse++mZrp8Sn6ZW
qwusUHkC6zP1Zn/BXAU23peqfOhXZcOrKDqCJB3sNDy9k1a8R8q8Uef0oHJtS9edElh6dCSmwfVH
+9QQ2OLs9b3VSRzpLn75lqv/PzcLLHuo04/hduOj055Op7DMpMBKlSewFQnsvE1j7II4ur9Km1+G
Fhll6eI+w5cyUxf9vnPqVHBQINHaeWsCi3eeDDaoHpw33SGzY4Et80l7yloG22qB/cZodVvXqNuw
JrBSz16pQRS38UZPWJPAipUnsPV0IY4TdLZdffY/fjkol0klC4cdCek5hn0WDRcdFzkdJrbsvF42
3ZdztB909bplgV0KBr7Krncrcn0eCWyx9tpiF2LSf1judnuVwH4rkBsyfTabW2ArmORBYJMCG0dv
PaXGuzfXDkn/rPt/id3hsP+qbm5cvWjkmqabD1pc9bME3faRwAo3MMgF0cUyxRHY4uz1vckxsGP+
bJY6218jsLPB/s/1GNQhb4q1dyH2bTACmxJY+270SYN8jsCSC12ejuFRNX/FF8366xpidO6ElfC6
JYEVOx+z7tr8W1rNGNj3kt4Ge+4qqJt9Dyzp0c/+/PyL6Mhygz/V7hTYqD9jfPr8/IUKFCtPYBsR
WPN4VD0L3/6muw7k3kKrrd89F1U05lSpRIvAJq9bElg8/pXUKrz+mgS2kIft6Wt4b3MafdTzEPb7
B3/D7Y9/LaZ7BZZ1Y6ZP2M8hpYkkowqUK09gWxDYMDEXJsM2ZuG/iBxMRPrzVu6vpouWrFOsxrTA
Gq5bb4FNN0LX3AJbwsP2ih0oZBAQWJ8Cq7Qa5grsYrDDUFbBj5ovOltR5TGoGTdbHwObHgdc8xjY
xx+2F+2fJIOAwDoWWKHfbq7Azv3Pu13QBxFdonrRMPFPTewYzQLMztJys5OzEGvTEPOO/WvTca0C
e+fz9rrd/2QQENiCBBa9yFySXG1sJ5gW3zSNPRpgS1J4y0ULZVpmFBaPaLju/PfAovff1vke2Aef
t5fuXSuDgMAWp7DSxILiu2LZK4yF152nO9FqbZRZF71jJmJ+0OzrTo17ZccH30Yy1Ly2MbCPPG+v
3nndNvZYDowOvE9gr37k3vCQyyDQAgM2IbA3P3Jv8KUMAgIDCKw/e8kgIDBguwJ7j1de92xvcjX6
xbzwezoeH6tJNG+awAAC+9xT987x7Q2uxBHu1LWMqt19gqXck/ADNi2wN8/O2uRSUsvYN+tRgaV3
0d9eYAQGrEtg759bvHWBpV2Mg/bMeQ2dZI3TqNh5XfnRiym1lyTzE0ZLMg53KUprUryzLg1GYMC7
BfaiB+8jb8ZsezuVJOnfuuGit/iLxaJ15JNiaf9eYUfLSpmCl/rfjpnAgDULTAZ5isCK68ecTqdQ
dtmIUmux8cfrrl2RafItLUtlClqKDuluJgeBAWsQ2KdWJdjmdiojE6S9g8V+x2qxyr7J4TzIfA7G
RBktMAAvEdhzN+X64DLBGxNYusR1aQfkxmIVgYU1yAQ2VWbqVwQGENjbn73PLgq3aYENN4b8HnTC
ZQc1Fit9LPXt5V2IU2XqTTCzEAECe/Oz9/ElTbcusHAOxlhgLcWKH9M9bW9nGzqnUKa1+t4DAwjs
Mfd86iQyyJ0CSwa2fkpF0yvai9U+Dge5RjsGBjP6R92Vk/Xv0F4EBnxMYI8/fkvYTkIGAYEBBLbo
nVlkEBAYQGBPeAKXs5ufDAICAwjsIYHJICAwXwjwSYG1PISL2kndNvZYDvIR8FaBzf0rcmkPrQwC
4QcQGIEBwg/oWWCV53CBfSYyCIQfsF2BNT6Hy+zx3+Rq9ItZtP10PD6hJtlSVwQGEBiBrUVgWXZf
yrJLj+7IfNPXF4EBBPas53D8KC52wtXWd2TuW2DXlaQIDCCwlz2Ki31Qty6wtItxsDTu/nD5zWDz
5aDY7nC8/Srb/mvgyOHx+QmzdYLTLTdHNcnu4+dnT2rJCT+AwIJHccnvu2xQYL/NlrMMkqbYrWvx
rJLCViV5sWid+qRY2meZLlKfrvYbl5lqLRIYQGAvehoX/rbmJidxXEVxOoUmyEbJWouNP173A4u2
Ts73AyuVmertJDCAwAhsg9upXFtkSX9esd+xWqyyI3M4DzLbkXmqDIEBeJ/AulgsZ9sCO0tptPlW
flBbsYrAwhpkApsqQ2AAXiiwFofJIAsSWPYCVWkf5MZipY/DDZ1LVWspQ2AAPigwGWRxAgvnYIwF
1lKs+PH3mOtvbmcbDnwVyhAYgCUITAZZnMCSga2fUtH0ivZitY/DQa5bmctpgxn9o+5KAgPwaoFV
HCaDAMIPIDAZBAQGENjrH8slP5kyCIQfQGBrEBhgR2aAwLTAAOEHEJgMAgID8GqBmcQBCD+AwGQQ
EBgAApNBIPwAArtDYJaS+gTFdd6XUbvj8Tk7Mn8tYYtp4Qf0LTBrIS5QYJmvWvbY+lDV5tvr7z5K
qwETGEBgzxGY1eiXYYl8+8guBZYpq88VEQkMWK7Alv+Ibl1gaRfjYHuu/eHym9+CxWK7w/H2q2z/
yoEjh8fnJ8wWuk/3jB7V5FXtOeEHEBiBLV5gg663pCl261o8q+Tmi2qxaKOVpFjaZ5nuspIuVx+X
aWot6kIECOzlAlvaU7rJSRxXUZxOoeyyUbLWYuOP1w0thwqKdmOplZn2V7qZGIEBBPbw03h9IAls
US2wqPGS9g4W+x2rxQofi/MgB+VbytQV3eUcRAIDFiuwSbHJIJ8W2FlKo90j84PailUEFtYgE9hU
mfIN9LqbJYEBHQhsyQ/qpgX2k/5zT0VmaixW+lgansq7EKfKxG2vTpteBAYQmAzyoMDCORhjgbUU
K35Mh6huZxsOfBXKVKrf57RDAgO6F9hyntWNj4ENBrZ+SkXTK9qL1T4OB7luZS6nDWb0j7or4+ZX
aXYKgQEE9tSnkcAA4QesQWALeVxlEAg/gMCmn0YCA4QfsAaBLeGJlUEg/AACa3oaCQwQfgCBPb/O
wAeRj4CeBPbxh1YGgfADCKz1aSQwQPgBaxDYZ59bGQTCDyCwLhthMgiEH0BgXTbCZBAQGEBg8x5I
AgOEH0BgMggIDCCwDwnsU0+vDAICAwhs9gNJYCAw4QcsRWDdNcJkEBAYQGBdNsJkEBAYQGBPENj7
n2EZBAQGENidzySBgcCEH7BEgS28F1EGAYEBBHbnY/nZXkQZBAQGENj9jyWBgcCEH7BEgS25ESaD
gMAAAuuyESaDgMAAAnumwN72MMsgIDCAwB4VEoGBwAB8XmC9NMJkEBAYQGBPeDgJDAQGYHECW2Yv
ogwCAgMI7AnP5/t7EWUQEBhAYM95PgkMBAZgcQJbYCNMBgGBAQTWZSNMBgGBAQTWZSNMBgGBAQTW
ZSNMBgGBAQT2QoG97tmWQUBgAIE92UYEBgID8GGBLbkR9gUsBvkI6EBgy5nKIWmCwAACe3kjjMBA
YAA+L7CFNMIkTRAYQGBdNsIkTRDY8jgddv+/kP1xTvHW0svkuL/Gwe5wur/MC/4vDsesCu+7+JIF
toRGmAyCTz5+wq/mr+ZM2b3Arjf8VfZ2S5nX1GtPYA/YiMBAYJvinCR3u+ZU2b3Azk2r+g20lHm9
wJb2BC3/iX1pI0wGwfoE1nk8//2R3/7H/joENnGrn2j7ENjCG2EEhtUIbCWDardEXWlzDEaDfn6f
5tnfTz8frmUGWX+yH25w4tgXkwUqzafoummN4kqFZQKhpd/DX4Hk6PHZh1Ubni676OVXoUbLd9de
jT4EtrRGGIFhBQJb05SQYYaMDTZK57v9fiyw/T7PymmaDVLp6MR1/TVKLD4ore3rBFavblC366/b
BDZxd23V6Flgn22EERi6FtjaJjSe8+E1uZ2TX5Lr/jLmNUVeE2SuhDRFXooFjZ804Y/ze6U2WYGK
voKcP/jRPV2IzQIbKSn/orLPo6qWJ3G03N1kNToT2KIaYQSGHgW21on4IyGMnBEpIxNRaJWCIn5/
fDkwsGXU2Tar6VAwXP7jFwosKZE0aYO65T+aEFjT3U1Vo3+BfaoR5kUcdCewVb/0VuiPGqX6PPcF
Y2BZkeKZK32MBd3N6gUrmSmr4+sEVinQcNEJgTXd3WQ9+xPY96dfavYmKQhscQIrjJZ8fdWzcovA
aqcelo3KJWeaLDBHYGk329oEVp72sT6BvfOlZkshgMAWKLBCD13aQfhQC6w9ZU7OVmx8rVgLbKUC
+1QjzFo+6Fpg6+1CKA6MJAZrHgOLJnPfkTMns3y9wKvHwCYnpVTMUf4qryd92hjYBgT2hkaYxeiw
DoGt0GQ1wyRts3w64bUtVBXYte+vmPHD9ReHV54sUGvKPX8WYj5ncPQ9TJpjNB1wdIdPm4W4RoG9
uRFmNVWsT2CV2O7rq6jPR0800fQe2MQbu80DYMEMkrmvNMVHjaflzV2JY+p7aDBHNLelcInSiNbk
3W1IYC9qhFV0RWBYgcCe0j/xWSbep4rnd1dW4qi25RrXpXjSTMTxUaPL3ruUVCaYeWNgUdVGNbtd
4fyr+1fiWKPAniKkR/pYCAyrEdj4tL5hrPwJWoHAKodMdhUSGHoXmOgFga2wEdYy0GUTRdjQEiCw
ZTXCGhOEpAkCAwhsKY2wWdlB0gSBAQT27vGAllmFdw+SAQQGENirGmFPyQuSJggMILBFNMIetKCA
wJIDHkA3AnuwESaDgMAAAuuvESaDgMAAAltuI+zxsYS1Z5B4H7+m5W9Ox+Pp43Wftfstga0iYg+3
FYZaVli647Rr/vZuazQ9Y72m5635tBWBtT/VTxkJ34LAwt3/JmJyCfIgsO3JK0uXzxHY4rMwga1Z
YHe8gCyD1CXwPy/Ug5LACIzACIzAXuGwJ05HJrC0m/H3p8ES19l+P78f//9jf7huKXT++TFZJbxe
mVtTMO3pHOyacb1QVIGw8gRGYARGYIsV2HNfqdmiwH6zQrL1xPDDbe++4barJYGNNsNL9mrNAz89
0/VT4tPUanWBFSpPYN2m3uyPmKvAxvtSlQ/9qmx4FQVIkKSDnYand9KK90iZN/CcHlSubem6UwJL
j47ENLj+aJ8aAnvUYRVXEVhDWhgFbt6Z+Pe5WWDZE51+DPcaH532dDqFZSYFVqo8ga1LYOdtGmMX
xAH+Vdr8MrTIKEsX9xm+lJm66Peds6eCgwKJ1s5bE1i882SwQfXgvOkOmQT2qMNmtcxkkKjNU9/T
Neo2rAms1LNXahDFbbzR49UksGLlCWxVXYjjBJ1tV5/9p18OymVSycJhX0J6jmG3RcNFx0VOh4kt
O6+XTfflHO0HXb1uWWCXgoGvsuvdilwfSQJ7kcAeTweb60JM+g/L3W6vEthvBXJDpg9mcwtsBZM8
CKxFYOMArqfUePfm2iHpX3b/L7E7HPZf1c2NqxeNXNN080GLq36WoOc+EljhBgbpILpYpjgCe6bD
GnsdCSwL22P+YJZ62l8jsLPB/s/1GNQhb4q1dyH2bTACaxBY+270SZt8jsCSC10ekOFRNX/FF836
6xrCdO6ElfC6JYEVOx+z7tr8WzIG9iKBNRYe/4rAgu787G/Pv3COLDf4O+1OgY06M8anz89fqECx
8gS2HYE1j0fVs/Dtz7rrWO4tutq63nNRRWNOlUq0CGzyuiWBxeNfSa3C6xPYKwQ2NyO0z8jfhMDi
boew0z/4A25//Gsx3SuwrBszfbx+DilNJBlVoFx5AtuIwIaJuTAftjEL/wXlYC7Sn7dyfzVdtGSd
YjWmBdZw3XoLbLoRqgX2seZXpRG2YYGBwFYssEqrYa7ALgY7DGUV/Kj5orMVVR6DmnGz9TGw6XFA
Y2Avt9cdjbD2uYtSKgisM4EV+u3mCuzcBb3bBd0Q0SWqFw0T/9TEjtEswOwsLTc7OQuxNg0x79u/
Nh0J7Ln2emIjTAYBgS1LYNGLzCXJ1cZ2gmnxTdPYowG2JIW3XLRQpmVGYfGIhuvOfw8sev/Ne2Cv
tdfjjTAZBAS2aIWVJhYU3xXL3mIsvO483YlWa6PMuugdMxHzg2Zfd2rcKzs++DaS0WZjYM+x19yn
vd1/trHHciAwoGOBPXGtjcZGmAwCLTCAwF5rr7kOa/yDVwYBgQEE9nJ7vaIRJoOAwAACe7LA7ig5
d3zre6Or0S/mhd/T8fhYTaJJ0wQGENgi7VV57J8yR2OVAstye7hT1zKqdvcJlnJPBAZsS2CPr8Bb
eVuZwCJLLGPfrEcFlt5Ff3uBERiwSYF9v2z6++YElnYxDtoz5wV0kgVOo2LndeVHb6XU3pDMTxgt
yTjcoiitSfHOujQYgQEdC+xuhdzd3vqeuUXL+gQ2WEo3Sfq3brjoFf5isWgd+aRY2r9X2NGyUqbg
pf63YyYwoGOBPeiPp/QZbnISx1UUp1Mou2xEqbXY+ON1167INPmWlqUyBS1Fh3Q3k4PAgI0K7PtJ
Ezc2uJ3KyARp72Cx37FarLJvcjgPMp+DMVFGCwzAcgX2RAUSWJvA0vWtSzsgNxarCCysQSawqTJT
vyIwgMD6aX7VUwCBTQtsuDHk96ATLjuosVjpY6lvL+9CnCpTb4KZhQgQWHeP7qy1EwlspIBoDsZY
YC3Fih/TDW1vZxs6p1CmtfreAwMIrLfm19Mdti2BJQNbP6Wi6RXtxWofh4Nco+0Cgxn9o+7Kyfp3
aC8CA9YgsJfq0H4WIDCAwJb73D7LYQICBAYQ2Luf27n7sBAYCAwgsCUK7D6HCQgQGEBgH3hu79tR
DFgI8hFAYBNnlkGgBQYQ2OKe2wen1AsIEBhAYB97bh9ZXEpAgMAAAluKwGatUr+6/9/iMrnLqN3x
+ISaZEtdERhAYD0/t0bRhwLLsvtSll16dEfmm76+CAwgsE89t8tphG1BYEtZ+PYJAruuJEVgAIFt
vhG2OYGlXYyDpXH3h8tvBpsvB8V2h+PtV9n2XwNHDo/PT5itE5xuuTmqSXYfPz97UkuOwAACW0oj
bNJh76nDAgX222w5yyBpit26Fs8qKWxVkheL1qlPiqV9luki9elqv3GZqdYigQEEphG2mUkcV1Gc
TqEJslGy1mLjj9f9wKKtk/P9wEplpno7CQwgMI2wDW6ncm2RJf15xX7HarHKjszhPMhsR+apMgQG
YEEC+3gjbPMCO0tptPlWflBbsYrAwhpkApsqQ2AAFi2wJ+4N1uiwre/InHuqsCNzS7HSx+GGzqWq
tZQhMACLEthzHfb4vsybE1g4B2MssJZixY+/x1x/czvbcOCrUIbAAGxTYHOX4djgGNhgYOunVDS9
or1Y7eNwkOtW5nLaYEb/qLuSwAAsUGBPdNisGfPWQgSBAQTWgcMIDAQGENibBPYRhwkIEBhAYJ90
2Ledl2FHZoDANuUwAQEtMIDAunSYgACBAQS2FId9b3oaPQgMILBtOExAgMAAAuvSYQICBAYQWJcO
W93/b3Gd92XU7nh8zo7MX0vYYprAAAJ7rcPqGlulwDJfteyx9aGqzbfX332UVgMmMIDAtuKwLQhs
vH1klwLLlNXniogEBqxcYO902OYElnYxDrbn2h8uv/ktWCy2Oxxvv8r2rxw4cnh8fsJsoft0z+hR
TV7VniMwgMC6ctj3Jje0HHS9JU2xW9fiWSU3X1SLRRutJMXSPst0l5V0ufq4TFNrURciQGBbb4et
UmAjrqI4nULZZaNkrcXGH68bWg4VFO3GUisz7a90MzECAwhsGw7b+H5g1xZZ0p9X7HesFit8LM6D
HJRvKVNXdJdzEAkM2JTAvl+81tTGBHaW0mj3yPygtmIVgYU1yAQ2VaZ8A73uZklgwOYENtdh9QKb
FthP+s89FZmpsVjpY2l4Ku9CnCoTt706bXoRGLBVgbU77PECKxdYOAdjLLCWYsWP6RDV7WzDga9C
mUr1+5x2SGAAgbU6jMDqaX4wsPVTKppe0V6s9nE4yHUrczltMKN/1F0ZN79Ks1MIDCCwPh02TASP
Gw4gMIDAFuEwGQQEBhBYHw6rN8JkEBAYQGDdOEwGAYEBBNaHw2YNkgGfQj4CNiqwipAqDpM0QWAA
gS29KUZgIDCAwJaoq/scJmmCwAACW1CHYaOZCAwEBhDY4noL75OTgMAHA9gXAhCYP4FBYACBbcxh
AgIEBhBYlxoTECAwgMC6NJmAAIEBBNalxgQECAwgsC5NJiBAYACBdakxAQECAwisS5MJCBAYQGBd
akxAgMAAAuvSZAICBAYQmAwCCD+AwGQQCD8ABCaDQPgBBCaDAMIPIDAZBMIPAIHdl0EAG1oCBEZg
AIEBBEZgIDAABEZgIDCAwAgMIDCAwBYgMAEB4QcQmAwCCD+AwGQQCD8ABCaDQPgBBCaDAMIPIDAZ
BMIPAIHJIBB+AIHJIIDwAwhMBgGEH0BgMgiEH0BgMogMAuEHEJgMAgg/gMBkEAg/AAQmg0D4AQQm
gwDCDyAwGQTCzxcCEJgMAuEHEJgMAgg/gMBkEED4AQQmg0D4AQQmg8ggEH4AgckggPADCEwGgfAD
QGAyCIQfQGAyCCD8AAKTQSD8hB9AYDIIhB9AYDIIIPwAApNBAOEHEJgMAuEHeIJkEBkEwg8gMBkE
EH4AgckgEH4ACEwGgfADCEwGAYQfQGAyCISf8AMITAaB8AMITAYBhB9AYDIIIPwAApNBIPwAEJgM
AuEHEJgMAgg/gMBkEAg/AAQmg0D4AQQmgwDCDyAwGQTCT/gBBCaDQPgBBCaDAMIPIDAZBBB+AIHJ
IBB+AAhMBoHwAwhMBgGEH0BgMgiEHwACk0Eg/AACk0EA4QcQmAwCCD+AwGQQCD+AwGQQQPgBBCaD
AMIPIDAZBMIPAIHJIBB+AIHJIIDwAwhMBoHwA0BgMgiEH0BgMggg/AACk0EA4QcQmAwC4QcQmAwi
g0D4AQQmgwDCDyAwGQTCDwCBySAQfgCBySCA8AMITAaB8ANAYDIIhB9AYDIIIPwAApNBAOEHEJgM
AuEHEJgMIoNA+AEEJoMAwg8gMBkEwg8AgckgEH4AgckggPADCEwGgfATfgCBySAQfgCBySCA8AMI
TAYBhB9AYDIIhB9AYDKIDALhBxCYDAIIP4DAZBAIPwAEJoNA+AEEJoMAwg8gMBkEwk/4AQQmg0D4
AQQmgwDCDyAwGQQQfgCBySAQfgAITAaB8AMITAYBhB9AYDIIhB8AApNBIPwAApNBAOEHEJgMAuEn
/AACk0Eg/AACk0EA4QcQmAwCCD+AwGQQCD8ABCaDQPgBBCaDAMIPIDAZBMIPAIHJIBB+AIHJIIDw
AwhMBgGBCT+AwGQQCD+AwGQQQPgBBCaDAMIPIDAZBMIPAIHJIBB+AIHJIIDwAwhMBoHwA0BgMgiE
H0BgMggg/AACk0EA4QcQmAwC4QcQmAwCCD+AwGQQQPgBBCaDQPgBIDAZBMIPIDAZBBB+AIHJIBB+
AAhMBoHwAwhMBgGEH0BgMggg/AACk0Eg/AACk0FkEAg/gMBkEED4AQQmg0D4ASAwGQTCDyAwGQQQ
fgCBdZ9Bvh5DLAo/XwhAYG/KIF9vQYwKPwAE9oQM8rUMBC6BASCw1gzytWDEMYEBBCaD9OQtSiMw
gMBkkCCDvFkbfCb8fCEAgT2aQRYlBjIjMAAE9hw9dFptPiMwgMA2KrCVaZjPCAwgsPULbAvNSj4j
MIDAVpXrt9bKJDMCAwis++S+8UYnpX3k+/flAAT2aDaRTPnsI9+zLwogsPszi2+D0j74TcpHAIER
2EJ9ttYv2TcDEBi26LPu0jedAwQGPltooqdqgMBAaSAtgMBAaXQFgMDAanQFEBiwLbH5nwIIDFii
4XzPAIEBAEBgAAAQGACAwAAAIDAAAAgMAEBgAAAQGAAABAYAIDAAAAgMAAACAwCAwAAABAYAAIEB
AEBgAAACAwCAwAAAIDAAAIEBAEBgAAAQGAAABAYAIDAAAD7LP9FH0ndGhO7lAAAAAElFTkSuQmCC
------=_Part_1437_548995536.1470596463374--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Sun, 07 Aug 2016 15:26:22 -0700
Raw View
On domingo, 7 de agosto de 2016 12:01:03 PDT =D0=94=D0=B5=D0=BD=D0=B8=D1=81=
=D0=9A=D0=BE=D1=82=D0=BE=D0=B2 wrote:
> When program detect exception, then in stack unwinding operation it shoul=
d=20
> copy address of invoked function like shown on picture.
> If nobody caught exception or it would be caught in main function we woul=
d=20
> be able to understand the problem in program.
Wasn't your intention that the exception handler should have access to the=
=20
stack information? That isn't supported by your proposal.
Anyway, you're not going to get the compilers to change without a good reas=
on.=20
Your argument needs to be stronger.
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/2188059.iZgdGNbEhT%40tjmaciei-mobl1.
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Sun, 7 Aug 2016 22:12:43 -0700 (PDT)
Raw View
------=_Part_424_564730525.1470633163432
Content-Type: multipart/alternative;
boundary="----=_Part_425_1315634431.1470633163432"
------=_Part_425_1315634431.1470633163432
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2016=E5=B9=B48=E6=9C=881=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=80 UTC+=
8=E4=B8=8A=E5=8D=881:23:21=EF=BC=8CNicol Bolas=E5=86=99=E9=81=93=EF=BC=9A
>
> On Sunday, July 31, 2016 at 12:38:26 PM UTC-4, =D0=94=D0=B5=D0=BD=D0=B8=
=D1=81 =D0=9A=D0=BE=D1=82=D0=BE=D0=B2 wrote:
>>
>> =D0=B2=D0=BE=D1=81=D0=BA=D1=80=D0=B5=D1=81=D0=B5=D0=BD=D1=8C=D0=B5, 31 =
=D0=B8=D1=8E=D0=BB=D1=8F 2016 =D0=B3., 19:09:51 UTC+3 =D0=BF=D0=BE=D0=BB=D1=
=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Thiago Macieira=20
>> =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:
>> > On domingo, 31 de julho de 2016 02:57:35 PDT =D0=94=D0=B5=D0=BD=D0=B8=
=D1=81 =D0=9A=D0=BE=D1=82=D0=BE=D0=B2 wrote:
>> > > > You misunderstand what exceptions are for. You're not supposed to=
=20
>> catch
>> > >
>> > > them
>> > >
>> > > > to find out where the error occurred. You catch them so you handle=
=20
>> the
>> > > > condition wherever it happened, then continue execution because=20
>> you've
>> > > > corrected the problem.
>> >> >
>> > > > I think this is incorrect.
>> > > > How can I correct the problem or bug if I do not know where the=20
>> problem
>> > > > happened.
>>
>> > There was no bug. Exceptions are not used to signal bugs. They are use=
d=20
>> to
>> > signal perfectly fine, if exceptional, conditions. A file not being=20
>> found is not
>> > a bug.
>>
>> I said problem or bug. If somebody try get element using *arr.at=20
>> <http://arr.at>(1000)* it will throw exception.
>> *Is it bug or problem ?*
>> If we want to show user that something goes wrong we throw exception *(f=
or=20
>> example file not found as you wrote)* we need show user where it=20
>> happened.
>>
>
> If I'm *using* a GUI application, I don't know or *care* what function=20
> caused a "file not found as you wrote" exception. I don't want a stack=20
> trace; it would be of utterly *no value* to me. I don't have the code; I=
=20
> don't know what those functions mean. What I care about is whether the=20
> application can handle that circumstance or not.
>
> Crashing because of a missing file may be reasonable for some=20
> applications. In those cases, a stack trace would still not be helpful.=
=20
> Simply stopping, perhaps with an error message, is sufficient.
>
> Stack traces are only of value to *programmers*, and generally, only to=
=20
> the programmers who wrote the system in question. So what you show to "th=
e=20
> user" is irrelevant.
>
Do not assume users can't touch the source. (Though you also can't assume=
=20
they can, for sure.)
There are cases that users are programmers, e.g. developers using C++ as=20
scripts, or testers.
=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/6dfdcd08-429e-4751-acaf-6f0621a956ba%40isocpp.or=
g.
------=_Part_425_1315634431.1470633163432
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B48=E6=9C=881=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=B8=80 UTC+8=E4=B8=8A=E5=8D=881:23:21=EF=BC=8CNicol Bolas=E5=
=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div d=
ir=3D"ltr">On Sunday, July 31, 2016 at 12:38:26 PM UTC-4, =D0=94=D0=B5=D0=
=BD=D0=B8=D1=81 =D0=9A=D0=BE=D1=82=D0=BE=D0=B2 wrote:<blockquote class=3D"g=
mail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;=
padding-left:1ex"><div dir=3D"ltr">=D0=B2=D0=BE=D1=81=D0=BA=D1=80=D0=B5=D1=
=81=D0=B5=D0=BD=D1=8C=D0=B5, 31 =D0=B8=D1=8E=D0=BB=D1=8F 2016 =D0=B3., 19:0=
9:51 UTC+3 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=
=BB=D1=8C Thiago Macieira =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:<br>&g=
t; On domingo, 31 de julho de 2016 02:57:35 PDT =D0=94=D0=B5=D0=BD=D0=B8=D1=
=81 =D0=9A=D0=BE=D1=82=D0=BE=D0=B2 wrote:<br>> > > You misundersta=
nd what exceptions are for. You're not supposed to catch<br>> ><b=
r>> > them<br>> ><br>> > > to find out where the error=
occurred. You catch them so you handle the<br>> > > condition whe=
rever it happened, then continue execution because you've<br>> > =
> corrected the problem.<br>>> ><br>> > > I think this=
is incorrect.<br>> > > How can I correct the problem or bug if I =
do not know where the problem<br>> > > happened.<br><br>> There=
was no bug. Exceptions are not used to signal bugs. They are used to<br>&g=
t; signal perfectly fine, if exceptional, conditions. A file not being foun=
d is not<br>> a bug.<br><br>I said problem or bug. If somebody try get e=
lement using <b><a href=3D"http://arr.at" rel=3D"nofollow" target=3D"_blank=
" onmousedown=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F=
%2Farr.at\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFxLPUpJfWQvLx7capIm4lnJf7=
xtw';return true;" onclick=3D"this.href=3D'http://www.google.com/ur=
l?q\x3dhttp%3A%2F%2Farr.at\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFxLPUpJf=
WQvLx7capIm4lnJf7xtw';return true;">arr.at</a>(1000)</b> it will throw =
exception.<br><b>Is it bug or problem ?</b><br>If we want to show user that=
something goes wrong we throw exception <b>(for example file not found as =
you wrote)</b> we need show user where it happened.<br></div></blockquote><=
div dir=3D"ltr"><br>If I'm <i>using</i> a GUI application, I don't =
know or <i>care</i> what function caused a "file not found as you wrot=
e" exception. I don't want a stack trace; it would be of utterly <=
i>no value</i> to me. I don't have the code; I don't know what thos=
e functions mean. What I care about is whether the application can handle t=
hat circumstance or not.<br><br>Crashing because of a missing file may be r=
easonable for some applications. In those cases, a stack trace would still =
not be helpful. Simply stopping, perhaps with an error message, is sufficie=
nt.<br><br>Stack traces are only of value to <i>programmers</i>, and genera=
lly, only to the programmers who wrote the system in question. So what you =
show to "the user" is irrelevant.<br></div></div></blockquote><di=
v>Do not assume users can't touch the source. (Though you also can'=
t assume they can, for sure.)<br>There are cases that users are programmers=
, e.g. developers using C++ as scripts, or testers.<br><br>=C2=A0<br></div>=
</div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/6dfdcd08-429e-4751-acaf-6f0621a956ba%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/6dfdcd08-429e-4751-acaf-6f0621a956ba=
%40isocpp.org</a>.<br />
------=_Part_425_1315634431.1470633163432--
------=_Part_424_564730525.1470633163432--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Sun, 7 Aug 2016 22:23:32 -0700 (PDT)
Raw View
------=_Part_766_1806924891.1470633812945
Content-Type: multipart/alternative;
boundary="----=_Part_767_778845310.1470633812946"
------=_Part_767_778845310.1470633812946
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2016=E5=B9=B48=E6=9C=881=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=80 UTC+=
8=E4=B8=8A=E5=8D=882:39:58=EF=BC=8CThiago Macieira=E5=86=99=E9=81=93=EF=BC=
=9A
>
> On domingo, 31 de julho de 2016 09:38:25 PDT =D0=94=D0=B5=D0=BD=D0=B8=D1=
=81 =D0=9A=D0=BE=D1=82=D0=BE=D0=B2 wrote:=20
> > I said problem or bug. If somebody try get element using *arr.at(1000)*=
=20
> it=20
> > will throw exception.=20
> > *Is it bug or problem ?*=20
> > If we want to show user that something goes wrong we throw exception=20
> *(for=20
> > example file not found as you wrote)* we need show user where it=20
> happened.=20
>
> First of all, like Nicol replied, "showing to the user" is often an=20
> incorrect=20
> step to do. The application should not display its problems to the user.=
=20
> If=20
> they are unrecoverable, log it somewhere for the user to pass the=20
> information=20
> along to the developer, then simply report to the user that the=20
> unrecoverable=20
> error happened. If the error was recoverable, recover.=20
>
> In the aspect of specific applications, this is usually true. As the view=
=20
of the standard, this is false. It is the author of the application, not=20
others, to determine whether this should be supported or not in their=20
products, for the sake only they will know clearly enough.
=20
> The whole point of catching exceptions is to *recover*. If at(1000) throw=
s=20
> an=20
> exception and that exception is caught, then the problem was recovered an=
d=20
> you=20
> don't need to know (much less display) where the exception was thrown=20
> from.=20
>
> Generally no, esp. if you make it rethrown. (Though I think you were not=
=20
talking about this case.)
Exceptions (as some forms of delimited continuations) in essential are not=
=20
different to other control primitives, though in C++ it is quite limited by=
=20
many reasons. The specification of the language should support the probably=
=20
valuable idiomatic use, but not specify it explicitly.
=20
> If the exception wasn't caught, then it was an unrecoverable error. In=20
> that=20
> case, the uncaught exception handler is called and the program terminates=
..=20
> Often, ABI-specific information is still available at this point to help=
=20
> diagnose the issue, including the stack trace. But, as I said, stacks and=
=20
> frames are concepts that exist only in the ABI, so the standard simply=20
> can't=20
> say anything about them.=20
>
> > > You put it around any place that can throw and that your founction=20
> isn't=20
> > > expected to throw that exception.=20
> >=20
> > *Unfortunately big programs writes by many people and people make=20
> mistakes.*=20
> > Every time somebody forgets put *try ... catch* and then happens weird=
=20
> > things. You try finding problem place 2h, 4h, 1day or more ... depends=
=20
> how=20
> > big project is.=20
>
> I understand, but the point is remains: if a bug occurred, then you've=20
> stepped=20
> outside the realm of the standard. The standard can't say what happens=20
> outside=20
> of the standard.=20
>
> Like I said above, though, most ABIs can log more ABI-dependent=20
> information in=20
> the event of an uncaught exception. Yes, that often requires debug mode=
=20
> builds=20
> and debugging symbols to be present.=20
>
> Assuming that you've been using those facilities provided by your=20
> toolchain, I=20
> have to ask: why do you want to standardise them? Why can't you continue=
=20
> to=20
> use the ABI-dependent ones?=20
>
> --=20
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org=20
> Software Architect - Intel Open Source Technology Center=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/7495bdb0-233e-4eb0-adb5-b4ed70544dea%40isocpp.or=
g.
------=_Part_767_778845310.1470633812946
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B48=E6=9C=881=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=B8=80 UTC+8=E4=B8=8A=E5=8D=882:39:58=EF=BC=8CThiago Macieir=
a=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On=
domingo, 31 de julho de 2016 09:38:25 PDT =D0=94=D0=B5=D0=BD=D0=B8=D1=81 =
=D0=9A=D0=BE=D1=82=D0=BE=D0=B2 wrote:
<br>> I said problem or bug. If somebody try get element using *<a href=
=3D"http://arr.at" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.h=
ref=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Farr.at\x26sa\x3dD\x2=
6sntz\x3d1\x26usg\x3dAFQjCNFxLPUpJfWQvLx7capIm4lnJf7xtw';return true;" =
onclick=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Farr=
..at\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFxLPUpJfWQvLx7capIm4lnJf7xtw=
9;;return true;">arr.at</a>(1000)* it
<br>> will throw exception.
<br>> *Is it bug or problem ?*
<br>> If we want to show user that something goes wrong we throw excepti=
on *(for
<br>> example file not found as you wrote)* we need show user where it h=
appened.
<br>
<br>First of all, like Nicol replied, "showing to the user" is of=
ten an incorrect=20
<br>step to do. The application should not display its problems to the user=
.. If=20
<br>they are unrecoverable, log it somewhere for the user to pass the infor=
mation=20
<br>along to the developer, then simply report to the user that the unrecov=
erable=20
<br>error happened. If the error was recoverable, recover.
<br>
<br></blockquote><div>In the aspect of specific applications, this is usual=
ly true. As the view of the standard, this is false. It is the author of th=
e application, not others, to determine whether this should be supported or=
not in their products, for the sake only they will know clearly enough.<br=
>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">The whole poi=
nt of catching exceptions is to *recover*. If at(1000) throws an=20
<br>exception and that exception is caught, then the problem was recovered =
and you=20
<br>don't need to know (much less display) where the exception was thro=
wn from.
<br>
<br></blockquote><div>Generally no, esp. if you make it rethrown. (Though I=
think you were not talking about this case.)<br><br>Exceptions (as some fo=
rms of delimited continuations) in essential are not different to other con=
trol primitives, though in C++ it is quite limited by many reasons. The spe=
cification of the language should support the probably valuable idiomatic u=
se, but not specify it explicitly.<br>=C2=A0<br></div><blockquote class=3D"=
gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc so=
lid;padding-left: 1ex;">If the exception wasn't caught, then it was an =
unrecoverable error. In that=20
<br>case, the uncaught exception handler is called and the program terminat=
es.=20
<br>Often, ABI-specific information is still available at this point to hel=
p=20
<br>diagnose the issue, including the stack trace. But, as I said, stacks a=
nd=20
<br>frames are concepts that exist only in the ABI, so the standard simply =
can't=20
<br>say anything about them.
<br>
<br>> > You put it around any place that can throw and that your foun=
ction isn't
<br>> > expected to throw that exception.
<br>>=20
<br>> *Unfortunately big programs writes by many people and people make =
mistakes.*
<br>> Every time somebody forgets put *try ... catch* and then happens w=
eird
<br>> things. You try finding problem place 2h, 4h, 1day or more ... dep=
ends how
<br>> big project is.
<br>
<br>I understand, but the point is remains: if a bug occurred, then you'=
;ve stepped=20
<br>outside the realm of the standard. The standard can't say what happ=
ens outside=20
<br>of the standard.
<br>
<br>Like I said above, though, most ABIs can log more ABI-dependent informa=
tion in=20
<br>the event of an uncaught exception. Yes, that often requires debug mode=
builds=20
<br>and debugging symbols to be present.
<br>
<br>Assuming that you've been using those facilities provided by your t=
oolchain, I=20
<br>have to ask: why do you want to standardise them? Why can't you con=
tinue to=20
<br>use the ABI-dependent ones?
<br>
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.goo=
gle.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x3dD\x26sntz\x3d1\x26usg\=
x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return true;" onclick=3D"this.hr=
ef=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x=
3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return t=
rue;">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" target=3D"=
_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google.=
com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH=
GRJdo5_JYG1DowztwAHAKs80XSA';return true;" onclick=3D"this.href=3D'=
http://www.google.com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1=
\x26usg\x3dAFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return true;">kde.org</a=
>
<br>=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center
<br>
<br></blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/7495bdb0-233e-4eb0-adb5-b4ed70544dea%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7495bdb0-233e-4eb0-adb5-b4ed70544dea=
%40isocpp.org</a>.<br />
------=_Part_767_778845310.1470633812946--
------=_Part_766_1806924891.1470633812945--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Sun, 7 Aug 2016 23:35:36 -0700 (PDT)
Raw View
------=_Part_728_1515322000.1470638136893
Content-Type: multipart/alternative;
boundary="----=_Part_729_1453565569.1470638136893"
------=_Part_729_1453565569.1470638136893
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
So is it right to force the users to have new mental burden while using a=
=20
specific library solution? Then the users can give up.
I choose to not use python. I can't avoid C++, but the way provided by the=
=20
standard is good enough in most cases. Then why I should bother the *both *=
(NDEBUG=20
vs XXX_NO_DEBUG) cases when I have no need to *extend *the standardized=20
interface? The worse thing is i can't predicate how many instances will=20
eventually effective by the latter case. Then only try to read and remember=
=20
documentation for *every *dependency for *same *need of functionality *even=
=20
I don't want to use* is the correct practice, huh?
=E5=9C=A8 2016=E5=B9=B48=E6=9C=882=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C UTC+=
8=E4=B8=8B=E5=8D=889:25:05=EF=BC=8CMatthew Woehlke=E5=86=99=E9=81=93=EF=BC=
=9A
>
> On 2016-08-01 19:33, Thiago Macieira wrote:=20
> > On segunda-feira, 1 de agosto de 2016 13:17:39 PDT Wil Evers wrote:=20
> >> Qt is not the standard. The standard only talks about the NDEBUG macro=
..=20
> If=20
> >> Qt ignores its intended usage, then that's a compliance issue, among a=
=20
> few=20
> >> others, with Qt.=20
> >=20
> > The standard does not say anything about NDEBUG except in connection to=
=20
> the=20
> > assert macro's behaviour ([assertions.assert], [using.headers] and in a=
=20
> note=20
> > in [dcl.attr.unused]). From the point of view of the standard, the=20
> NDEBUG=20
> > macro is exclusively related to NDEBUG.=20
> > [...]=20
> > What I will argue is that a library that is not the Standards Library=
=20
> is, by=20
> > the very definition, not part of the Standard. It needs to be written=
=20
> compliant=20
> > with the core language standard and using the Standard Library in a=20
> compliant=20
> > manner, but that library itself is never subject to the standard.=20
> Therefore,=20
> > talking about a "standard-compliant non-standard library" is=20
> nonsensical.=20
>
> I'll throw in another point here... maybe I want debugging stuff (e.g.=20
> asserts) in my application *but not in the libraries I use* (e.g. Qt).=20
>
> In fact, I will throw out a specific example: Python. Python has this=20
> "wonderful" notion of providing a different ABI for debug and release=20
> modes, but they also have a philosophical objection to providing debug=20
> libraries. This means that the only (sane) way to build your=20
> Python-using application with full debugging (i.e. not defining NDEBUG)=
=20
> *is to also build Python yourself*.=20
>
> This is sheer idiocy that does nothing but make developers' lives=20
> harder, and I *applaud* Qt for not making the same boneheaded mistake.=20
> If Python had done the *rational* thing and used some other symbol to=20
> decide if Python itself has debugging enabled (like Qt's QT_NO_DEBUG),=20
> this problem wouldn't exist.=20
>
> So, please, drop this silly notion that the entire world must use the=20
> exact same symbol to determine if debugging is enabled or not. Doing so=
=20
> is unnecessarily restrictive, at best.=20
>
> --=20
> Matthew=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/b744af6d-7d11-48c8-aaea-ee4dbe3e5765%40isocpp.or=
g.
------=_Part_729_1453565569.1470638136893
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">So is it right to force the users to have new mental burde=
n while using a specific library solution? Then the users can give up.<br>I=
choose to not use python. I can't avoid C++, but the way provided by t=
he standard is good enough in most cases. Then why I should bother the <i>b=
oth </i>(NDEBUG vs XXX_NO_DEBUG) cases when I have no need to <i>extend </i=
>the standardized interface? The worse thing is i can't predicate how m=
any instances will eventually effective by the latter case. Then only try t=
o read and remember documentation for <i>every </i>dependency for <i>same <=
/i>need of functionality <i>even I don't want to use</i> is the correct=
practice, huh?<br><br>=E5=9C=A8 2016=E5=B9=B48=E6=9C=882=E6=97=A5=E6=98=9F=
=E6=9C=9F=E4=BA=8C UTC+8=E4=B8=8B=E5=8D=889:25:05=EF=BC=8CMatthew Woehlke=
=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On =
2016-08-01 19:33, Thiago Macieira wrote:
<br>> On segunda-feira, 1 de agosto de 2016 13:17:39 PDT Wil Evers wrote=
:
<br>>> Qt is not the standard. The standard only talks about the NDEB=
UG macro. If
<br>>> Qt ignores its intended usage, then that's a compliance is=
sue, among a few
<br>>> others, with Qt.
<br>>=20
<br>> The standard does not say anything about NDEBUG except in connecti=
on to the=20
<br>> assert macro's behaviour ([assertions.assert], [using.headers]=
and in a note=20
<br>> in [dcl.attr.unused]). From the point of view of the standard, the=
NDEBUG=20
<br>> macro is exclusively related to NDEBUG.
<br>> [...]
<br>> What I will argue is that a library that is not the Standards Libr=
ary is, by=20
<br>> the very definition, not part of the Standard. It needs to be writ=
ten compliant=20
<br>> with the core language standard and using the Standard Library in =
a compliant=20
<br>> manner, but that library itself is never subject to the standard. =
Therefore,=20
<br>> talking about a "standard-compliant non-standard library"=
; is nonsensical.
<br>
<br>I'll throw in another point here... maybe I want debugging stuff (e=
..g.
<br>asserts) in my application *but not in the libraries I use* (e.g. Qt).
<br>
<br>In fact, I will throw out a specific example: Python. Python has this
<br>"wonderful" notion of providing a different ABI for debug and=
release
<br>modes, but they also have a philosophical objection to providing debug
<br>libraries. This means that the only (sane) way to build your
<br>Python-using application with full debugging (i.e. not defining NDEBUG)
<br>*is to also build Python yourself*.
<br>
<br>This is sheer idiocy that does nothing but make developers' lives
<br>harder, and I *applaud* Qt for not making the same boneheaded mistake.
<br>If Python had done the *rational* thing and used some other symbol to
<br>decide if Python itself has debugging enabled (like Qt's QT_NO_DEBU=
G),
<br>this problem wouldn't exist.
<br>
<br>So, please, drop this silly notion that the entire world must use the
<br>exact same symbol to determine if debugging is enabled or not. Doing so
<br>is unnecessarily restrictive, at best.
<br>
<br>--=20
<br>Matthew
<br></blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/b744af6d-7d11-48c8-aaea-ee4dbe3e5765%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b744af6d-7d11-48c8-aaea-ee4dbe3e5765=
%40isocpp.org</a>.<br />
------=_Part_729_1453565569.1470638136893--
------=_Part_728_1515322000.1470638136893--
.
Author: Viacheslav Usov <via.usov@gmail.com>
Date: Mon, 8 Aug 2016 10:24:35 +0200
Raw View
--001a113fb87492447805398b25c6
Content-Type: text/plain; charset=UTF-8
On Sun, Aug 7, 2016 at 6:21 PM, Thiago Macieira <thiago@macieira.org> wrote:
> Second, there's a big problem in the design of your solution: you can't
use the stack to pass information along when the stack unwinds. That
information was lost by the time the exception handler got called.
That's not true at least in some implementations, as described earlier in
this thread.
But, fundamentally, all of this is implementation-defined, so, as I have
said a few times, the only reasonable thing we could propose here is a
couple of functions.
std::string std::trace_stack();
std::string std::trace_exception();
The content of the returned string is implementation-defined, and may need
an extra translation step, not necessarily available at the run time, to be
human readable. std::trace_exception() is meant to be called in an
exception handler, directly or indirectly (basically just like
std::current_exception()).
We could debate whether std::string is appropriate, because what we might
really have there is binary data, and how we could provide for a potential
zero-copy implementation, but those are minor things.
Cheers
V.
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg0dM2g0qK31pOMiXKQeu6kognP%3Dx%3Dr9eW3R4KVzkZ%2Bmkg%40mail.gmail.com.
--001a113fb87492447805398b25c6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
un, Aug 7, 2016 at 6:21 PM, Thiago Macieira <span dir=3D"ltr"><<a href=
=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@macieira.org</a>&g=
t;</span> wrote:<br><div><br></div><div>> Second, there's a big prob=
lem in the design of your solution: you can't use the stack to pass inf=
ormation along when the stack unwinds. That information was lost by the tim=
e the exception handler got called.</div><div><br></div><div>That's not=
true at least in some implementations, as described earlier in this thread=
..</div><div><br></div><div>But, fundamentally, all of this is implementatio=
n-defined, so, as I have said a few times, the only reasonable thing we cou=
ld propose here is a couple of functions.</div><div><br></div><div>std::str=
ing std::trace_stack();</div><div>std::string std::trace_exception();</div>=
<div><br></div><div>The content of the returned string is implementation-de=
fined, and may need an extra translation step, not necessarily available at=
the run time, to be human readable. std::trace_exception() is meant to be =
called in an exception handler, directly or indirectly (basically just like=
std::current_exception()).</div><div><br></div><div>We could debate whethe=
r std::string is appropriate, because what we might really have there is bi=
nary data, and how we could provide for a potential zero-copy implementatio=
n, but those are minor things.</div><div><br></div><div>Cheers</div><div>V.=
</div></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAA7YVg0dM2g0qK31pOMiXKQeu6kognP%3Dx%=
3Dr9eW3R4KVzkZ%2Bmkg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg0dM2=
g0qK31pOMiXKQeu6kognP%3Dx%3Dr9eW3R4KVzkZ%2Bmkg%40mail.gmail.com</a>.<br />
--001a113fb87492447805398b25c6--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Mon, 8 Aug 2016 19:49:20 -0700 (PDT)
Raw View
------=_Part_1233_541309304.1470710961038
Content-Type: multipart/alternative;
boundary="----=_Part_1234_1413932924.1470710961039"
------=_Part_1234_1413932924.1470710961039
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2016=E5=B9=B48=E6=9C=888=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=80 UTC+=
8=E4=B8=8B=E5=8D=884:24:39=EF=BC=8CViacheslav Usov=E5=86=99=E9=81=93=EF=BC=
=9A
>
> On Sun, Aug 7, 2016 at 6:21 PM, Thiago Macieira <thi...@macieira.org=20
> <javascript:>> wrote:
>
> > Second, there's a big problem in the design of your solution: you can't=
=20
> use the stack to pass information along when the stack unwinds. That=20
> information was lost by the time the exception handler got called.
>
> That's not true at least in some implementations, as described earlier in=
=20
> this thread.
>
> But, fundamentally, all of this is implementation-defined, so, as I have=
=20
> said a few times, the only reasonable thing we could propose here is a=20
> couple of functions.
>
> Strongly agree.
Interface of best effort is still far better than private wheels everywhere=
=20
for such a generic need if there is few hopes to get the concrete behavior=
=20
specified in future.
=20
> std::string std::trace_stack();
> std::string std::trace_exception();
>
> The content of the returned string is implementation-defined, and may nee=
d=20
> an extra translation step, not necessarily available at the run time, to =
be=20
> human readable. std::trace_exception() is meant to be called in an=20
> exception handler, directly or indirectly (basically just like=20
> std::current_exception()).
>
> We could debate whether std::string is appropriate, because what we might=
=20
> really have there is binary data, and how we could provide for a potentia=
l=20
> zero-copy implementation, but those are minor things.
>
> Cheers
> V.
>
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/6597009a-3eb6-4c0a-829f-5b3e2ec36152%40isocpp.or=
g.
------=_Part_1234_1413932924.1470710961039
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B48=E6=9C=888=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=B8=80 UTC+8=E4=B8=8B=E5=8D=884:24:39=EF=BC=8CViacheslav Uso=
v=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><d=
iv dir=3D"ltr"><div><div class=3D"gmail_quote">On Sun, Aug 7, 2016 at 6:21 =
PM, Thiago Macieira <span dir=3D"ltr"><<a href=3D"javascript:" target=3D=
"_blank" gdf-obfuscated-mailto=3D"J9CJA_G-CAAJ" rel=3D"nofollow" onmousedow=
n=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=
=3D'javascript:';return true;">thi...@macieira.org</a>></span> w=
rote:<br><div><br></div><div>> Second, there's a big problem in the =
design of your solution: you can't use the stack to pass information al=
ong when the stack unwinds. That information was lost by the time the excep=
tion handler got called.</div><div><br></div><div>That's not true at le=
ast in some implementations, as described earlier in this thread.</div><div=
><br></div><div>But, fundamentally, all of this is implementation-defined, =
so, as I have said a few times, the only reasonable thing we could propose =
here is a couple of functions.</div><div><br></div></div></div></div></bloc=
kquote><div>Strongly agree.<br><br>Interface of best effort is still far be=
tter than private wheels everywhere for such a generic need if there is few=
hopes to get the concrete behavior specified in future.<br>=C2=A0<br></div=
><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div cl=
ass=3D"gmail_quote"><div></div><div>std::string std::trace_stack();</div><d=
iv>std::string std::trace_exception();</div><div><br></div><div>The content=
of the returned string is implementation-defined, and may need an extra tr=
anslation step, not necessarily available at the run time, to be human read=
able. std::trace_exception() is meant to be called in an exception handler,=
directly or indirectly (basically just like std::current_exception()).</di=
v><div><br></div><div>We could debate whether std::string is appropriate, b=
ecause what we might really have there is binary data, and how we could pro=
vide for a potential zero-copy implementation, but those are minor things.<=
/div><div><br></div><div>Cheers</div><div>V.</div></div></div></div>
</blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/6597009a-3eb6-4c0a-829f-5b3e2ec36152%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/6597009a-3eb6-4c0a-829f-5b3e2ec36152=
%40isocpp.org</a>.<br />
------=_Part_1234_1413932924.1470710961039--
------=_Part_1233_541309304.1470710961038--
.
Author: "tapika via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Mon, 3 Oct 2016 06:41:33 -0700 (PDT)
Raw View
------=_Part_536_225897643.1475502093813
Content-Type: multipart/alternative;
boundary="----=_Part_537_893691119.1475502093813"
------=_Part_537_893691119.1475502093813
Content-Type: text/plain; charset=UTF-8
Cross posted here
- https://groups.google.com/a/isocpp.org/forum/?fromgroups=#!searchin/std-discussion/stack%7Csort:relevance/std-discussion/A17G1ram9ns/cVz5UJ7dGgAJ
But same message is also here:
I can provide proposal for API - from this project:
https://sourceforge.net/projects/diagnostic/
See ResolveStack.h
<https://sourceforge.net/p/diagnostic/svn/HEAD/tree/src/ResolveStack.h> /
ResolveStack.
<https://sourceforge.net/p/diagnostic/svn/HEAD/tree/src/ResolveStack.h>cpp
/ ResolveStack
<https://sourceforge.net/p/diagnostic/svn/HEAD/tree/src/ResolveStack.h>M.h
/ ResolveStackM.
<https://sourceforge.net/p/diagnostic/svn/HEAD/tree/src/ResolveStack.h>cpp
https://sourceforge.net/p/diagnostic/svn/HEAD/tree/src/
Design: https://sourceforge.net/p/diagnostic/svn/HEAD/tree/ - see chapter 7.
It has some cross links to stack overflow forum / message / posts for it.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/3f1b70a4-be8e-48ec-b42b-18f14394159e%40isocpp.org.
------=_Part_537_893691119.1475502093813
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Cross posted here -=C2=A0https://groups.google.com/a/=
isocpp.org/forum/?fromgroups=3D#!searchin/std-discussion/stack%7Csort:relev=
ance/std-discussion/A17G1ram9ns/cVz5UJ7dGgAJ<br><br>But same message is als=
o here:<br><div><br></div><div>I can provide proposal for API - from this p=
roject:<br><br>https://sourceforge.net/projects/diagnostic/<br><br>See=C2=
=A0<a class=3D"icon" href=3D"https://sourceforge.net/p/diagnostic/svn/HEAD/=
tree/src/ResolveStack.h" title=3D"ResolveStack.h" style=3D"color: rgb(0, 10=
2, 153); font-family: sans-serif; font-weight: normal; vertical-align: base=
line; background-image: initial; background-position: initial; background-s=
ize: initial; background-repeat: initial; background-attachment: initial; b=
ackground-origin: initial; background-clip: initial; outline: none; -webkit=
-tap-highlight-color: rgb(0, 119, 170); white-space: nowrap;">ResolveStack.=
h</a>=C2=A0/=C2=A0<a class=3D"icon" href=3D"https://sourceforge.net/p/diagn=
ostic/svn/HEAD/tree/src/ResolveStack.h" title=3D"ResolveStack.h" style=3D"c=
olor: rgb(0, 102, 153); font-family: sans-serif; font-weight: normal; verti=
cal-align: baseline; background-image: initial; background-position: initia=
l; background-size: initial; background-repeat: initial; background-attachm=
ent: initial; background-origin: initial; background-clip: initial; outline=
: none; -webkit-tap-highlight-color: rgb(0, 119, 170); white-space: nowrap;=
">ResolveStack.</a>cpp /=C2=A0<a class=3D"icon" href=3D"https://sourceforge=
..net/p/diagnostic/svn/HEAD/tree/src/ResolveStack.h" title=3D"ResolveStack.h=
" style=3D"color: rgb(0, 102, 153); font-family: sans-serif; font-weight: n=
ormal; vertical-align: baseline; background-image: initial; background-posi=
tion: initial; background-size: initial; background-repeat: initial; backgr=
ound-attachment: initial; background-origin: initial; background-clip: init=
ial; outline: none; -webkit-tap-highlight-color: rgb(0, 119, 170); white-sp=
ace: nowrap;">ResolveStack</a>M.h /=C2=A0<a class=3D"icon" href=3D"https://=
sourceforge.net/p/diagnostic/svn/HEAD/tree/src/ResolveStack.h" title=3D"Res=
olveStack.h" style=3D"color: rgb(0, 102, 153); font-family: sans-serif; fon=
t-weight: normal; vertical-align: baseline; background-image: initial; back=
ground-position: initial; background-size: initial; background-repeat: init=
ial; background-attachment: initial; background-origin: initial; background=
-clip: initial; outline: none; -webkit-tap-highlight-color: rgb(0, 119, 170=
); white-space: nowrap;">ResolveStackM.</a>cpp<br>https://sourceforge.net/p=
/diagnostic/svn/HEAD/tree/src/=C2=A0<br><br>Design:=C2=A0https://sourceforg=
e.net/p/diagnostic/svn/HEAD/tree/ - see chapter 7.<br><br>It has some cross=
links to stack overflow forum / message / posts for it.<br><br></div>=C2=
=A0</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/3f1b70a4-be8e-48ec-b42b-18f14394159e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/3f1b70a4-be8e-48ec-b42b-18f14394159e=
%40isocpp.org</a>.<br />
------=_Part_537_893691119.1475502093813--
------=_Part_536_225897643.1475502093813--
.
Author: Avi Kivity <avi@scylladb.com>
Date: Tue, 4 Oct 2016 17:48:59 +0300
Raw View
On 08/01/2016 07:12 AM, Thiago Macieira wrote:
> On domingo, 31 de julho de 2016 13:41:36 PDT =D0=94=D0=B5=D0=BD=D0=B8=D1=
=81 =D0=9A=D0=BE=D1=82=D0=BE=D0=B2 wrote:
>>> You're arguing for stack traces. I'm saying that stack traces isn't eno=
ugh
>>> *and* that the functionality already exists and is good enough. I don't
>>> see
>>> the point of standardising them.
>>>
>>> I also don't see the point of duplicating the ICU library or 2D graphic=
s
>>> in
>>> the standard. The standard does not need to be all-encompassing.
>> We could implement it even without ABI. Just by adding meta-information =
and
>> code for function for Debug mode.
> First of all, no, we can't. This is exactly what I said before: we'd have=
to
> standardise what a frame is before we can have a list of stack frames. Th=
at
> will inhibit a lot of possible optimisations.
It need not be fully standardized. We can have a backtrace object that=20
implements operator<< and perhaps a serializer, and leave the rest=20
implementation-specified. An implementation can choose to implement=20
empty backtraces, in the same way an implementation can choose to=20
implement multiplication using a nested loop with an incrementing body.
> Second, we can't do it for debug mode. There's absolutely no such thing a=
s
> "debug mode" in the standard. And third, you yourself said that this shou=
ldn't
> be restricted to debug mode or release mode.
With this I agree, it's useful mostly in release mode.
It's also useful when captured within an exception, though it will be=20
hard to figure out a way to avoid a reduction in performance. Perhaps=20
the catch statement could specify if it wants backtraces:
try {
...
} catch (expected_exception& ee) {
// no backtrace caught
} catch (std::exception& e, std::backtrace& bt) {
// e was thrown in a location with bt as a backtrace
}
for unwind-table implementations, it should not add large overhead.
>
>> When you call function in it first of all become to execute meta-code wh=
ich
>> put meta-information of function in to the stack object.
> That's exactly what we don't want to standardise. It constrains what an
> implementation can do.
>
>> This meta-information and meta-code will exist only for Debug Mode.
>> It can be implemented differentlly, we need desire to implement it.
> And you still did not reply to my argument that this already exists and i=
s
> good enough, just not part of the standard.
>
Why encourage unportable code? Not everything needs to be standardized,=20
but low-level functionality that cannot be itself implemented on top of=20
the standard, should.
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/bb9b5f32-4659-325a-ba71-18436cd9e4c4%40scylladb.=
com.
.