Discussion:
Exception stack trace information.
(too old to reply)
r***@gmail.com
2016-07-31 00:14:19 UTC
Permalink
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+***@isocpp.org.
To post to this group, send email to std-***@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.
Tony V E
2016-07-31 00:41:07 UTC
Permalink
<html><head></head><body lang="en-US" style="background-color: rgb(255, 255, 255); line-height: initial;"> <div style="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);">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. </div><div style="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="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 having a stack trace facility in the language would be useful.&nbsp;</div><div style="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="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 style="display:initial"></div> <div style="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);">Sent&nbsp;from&nbsp;my&nbsp;BlackBerry&nbsp;portable&nbsp;Babbage&nbsp;Device</div> <table width="100%" style="background-color:white;border-spacing:0px;"> <tbody><tr><td colspan="2" style="font-size: initial; text-align: initial; background-color: rgb(255, 255, 255);"> <div style="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', 'Slate Pro'; font-size: 10pt;"> <div><b>From: </b>***@gmail.com</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-***@isocpp.org</div><div><b>Subject: </b>[std-proposals] Exception stack trace information.</div></div></td></tr></tbody></table><div style="border-style: solid 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><br><div id="_originalContent" style=""><div dir="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 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>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 <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 "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:std-proposals+***@isocpp.org">std-proposals+***@isocpp.org</a>.<br>
To post to this group, send email to <a href="mailto:std-***@isocpp.org">std-***@isocpp.org</a>.<br>
To view this discussion on the web visit <a href="https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/a758ce2c-3750-4b9d-99e0-e9e1e3dcdb6d%40isocpp.org?utm_medium=email&amp;utm_source=footer">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/a758ce2c-3750-4b9d-99e0-e9e1e3dcdb6d%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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:std-proposals+***@isocpp.org">std-proposals+***@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-***@isocpp.org">std-***@isocpp.org</a>.<br />
To view this discussion on the web visit <a href="https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/20160731004107.4898897.76636.14874%40gmail.com?utm_medium=email&utm_source=footer">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/20160731004107.4898897.76636.14874%40gmail.com</a>.<br />
Patrice Roy
2016-07-31 02:22:19 UTC
Permalink
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!
Post by Tony V E
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
*Sent: *Saturday, July 30, 2016 8:14 PM
*To: *ISO C++ Standard - Future Proposals
*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
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
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+***@isocpp.org.
To post to this group, send email to std-***@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.
r***@gmail.com
2016-07-31 06:49:53 UTC
Permalink
I have prepared my first proposal. Please, dont bit hard for missing
details.
You can find it in attachment.

вПскресеМье, 31 Оюля 2016 г., 5:22:21 UTC+3 пПльзПватель Patrice Roy
Post by Patrice Roy
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!
Post by Tony V E
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
*Sent: *Saturday, July 30, 2016 8:14 PM
*To: *ISO C++ Standard - Future Proposals
*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
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
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+***@isocpp.org.
To post to this group, send email to std-***@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.org.
Patrice Roy
2016-07-31 15:16:06 UTC
Permalink
Hi!

Be careful: void main() is illegal in C++. Passing «void» as argument,
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!
Post by r***@gmail.com
I have prepared my first proposal. Please, dont bit hard for missing
details.
You can find it in attachment.
вПскресеМье, 31 Оюля 2016 г., 5:22:21 UTC+3 пПльзПватель Patrice Roy
Post by Patrice Roy
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!
Post by Tony V E
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
*Sent: *Saturday, July 30, 2016 8:14 PM
*To: *ISO C++ Standard - Future Proposals
*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
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
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
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.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/237863cb-3569-4784-b6f5-db80ac069ff6%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+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKiZDp3AuqireTRBb814bh23igbzNcOYmg-qNOvA_Pt4p2Jw9g%40mail.gmail.com.
Денис Котов
2016-07-31 16:20:42 UTC
Permalink
Patrice Roy:
Sorry me. I wrote this proposal in the morning and as you has shown me, not
very carefully,
inattentively. I wanted to show an idea in general.
Maybe I forgot drink few cups of coffee =)
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
probably not as strong.
But if we want more general solution we need support more precise exception
types like throwing interger.

Could you suggest me where I can get proposal number like N3256 ?

вПскресеМье, 31 Оюля 2016 г., 18:16:08 UTC+3 пПльзПватель Patrice Roy
Hi!
Be careful: void main() is illegal in C++. Passing «void» as argument,
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.
throw socket_error("Cannot open socket !");
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!
Post by r***@gmail.com
I have prepared my first proposal. Please, dont bit hard for missing
details.
You can find it in attachment.
вПскресеМье, 31 Оюля 2016 г., 5:22:21 UTC+3 пПльзПватель Patrice Roy
Post by Patrice Roy
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!
Post by Tony V E
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
*Sent: *Saturday, July 30, 2016 8:14 PM
*To: *ISO C++ Standard - Future Proposals
*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
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
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
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.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/237863cb-3569-4784-b6f5-db80ac069ff6%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+***@isocpp.org.
To post to this group, send email to std-***@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.org.
Tom Honermann
2016-08-01 14:46:02 UTC
Permalink
Post by r***@gmail.com
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+***@isocpp.org.
To post to this group, send email to std-***@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.
Thiago Macieira
2016-08-01 15:51:32 UTC
Permalink
Post by Tom Honermann
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+***@isocpp.org.
To post to this group, send email to std-***@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.
Tom Honermann
2016-08-01 16:28:03 UTC
Permalink
Post by Thiago Macieira
Post by Tom Honermann
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.
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+***@isocpp.org.
To post to this group, send email to std-***@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.
Bjorn Reese
2016-08-01 17:28:38 UTC
Permalink
Post by Thiago Macieira
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+***@isocpp.org.
To post to this group, send email to std-***@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.
Денис Котов
2016-08-01 18:03:33 UTC
Permalink
пПМеЎельМОк, 1 августа 2016 г., 20:27:23 UTC+3 пПльзПватель Bjorn Reese
Post by Thiago Macieira
Post by Thiago Macieira
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
http://lists.boost.org/Archives/boost/2016/06/230264.php
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.)
This will be little-bit hard to implement and get a consistent look on
different platforms.
Post by Thiago Macieira
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
we will have the same behavior on different platforms.
--
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+***@isocpp.org.
To post to this group, send email to std-***@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.org.
Thiago Macieira
2016-08-01 19:11:28 UTC
Permalink
Post by Bjorn Reese
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.
Post by Bjorn Reese
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
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+***@isocpp.org.
To post to this group, send email to std-***@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.
Thiago Macieira
2016-07-31 05:54:00 UTC
Permalink
Post by r***@gmail.com
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 whole
discussion happening right now about evaluation ordere of arguments and in
expressions. That's supposed to improve the quality of code. The new classes,
when used in new code, also improve the quality.
Post by r***@gmail.com
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.
You misunderstand what exceptions are for. You're not supposed to catch 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.
Post by r***@gmail.com
This is the main reason that even in debug mode exception is used not often.
I don't know any program that enables or disables exceptions according to
debug mode or release mode. This statement of yours lacks proof and, coupled
with the misundersanding above, indicates you either completely misunderstand
exceptions or you're talking about something else, something that is not
called "exceptions".
Post by r***@gmail.com
*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*
There was a discussion about backtraces a while ago. It's hard to have
something about it in the standard because then the standard needs to
understand the concept of "frame" and will constrain what the compiler is
allowed to do to optimise and inline functions. For example, will it be
allowed to omit the frame pointer?
Post by r***@gmail.com
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
those: I fail to see the value of standardising this fuctionality. It has
existed very well for 30 years in the realm of debuggers. The standard has no
concept of "bug", it simply declares that some behaviours are undefined and
that, under some conditions, the program is ill-formed. How those are exposed
to the user, that's implementation-defined and so is the method of their
correction.

Tooling can be improved, of course. But I argue that it's constantly in
improvement and, more importantlu, the issue of backtraces is an *already*
solved problem.

Finally, I share some of your concern. There are many things that need to be
added to the language and to the standard library to cover some of its
shortcomings. One of my biggest gripes of C++11 was the incomplete support for
the Unicode support that was added, including some basic steps, while a huge
library for ratios and random was added. But since then, I've learned that you
can't stall progress in one area that has consensus because another doesn't
have it yet. Many things need more time for discussion and implementation and
they shouldn't hold back what has been already agreed upon.
--
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+***@isocpp.org.
To post to this group, send email to std-***@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.
Денис Котов
2016-07-31 09:57:35 UTC
Permalink
Post by Thiago Macieira
You misunderstand what exceptions are for. You're not supposed to catch 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
happened.
It is impossible or I need put *try ... catch* statement in every place of
my program. But it is wasting of time. Better when exception has all needed
information for analyzing where it happened.

вПскресеМье, 31 Оюля 2016 г., 8:54:04 UTC+3 пПльзПватель Thiago Macieira
Post by Thiago Macieira
Post by r***@gmail.com
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 whole
discussion happening right now about evaluation ordere of arguments and in
expressions. That's supposed to improve the quality of code. The new classes,
when used in new code, also improve the quality.
Post by r***@gmail.com
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
Post by r***@gmail.com
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 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.
Post by r***@gmail.com
This is the main reason that even in debug mode exception is used not
often.
I don't know any program that enables or disables exceptions according to
debug mode or release mode. This statement of yours lacks proof and, coupled
with the misundersanding above, indicates you either completely misunderstand
exceptions or you're talking about something else, something that is not
called "exceptions".
Post by r***@gmail.com
*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
Post by r***@gmail.com
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*
There was a discussion about backtraces a while ago. It's hard to have
something about it in the standard because then the standard needs to
understand the concept of "frame" and will constrain what the compiler is
allowed to do to optimise and inline functions. For example, will it be
allowed to omit the frame pointer?
Post by r***@gmail.com
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
those: I fail to see the value of standardising this fuctionality. It has
existed very well for 30 years in the realm of debuggers. The standard has no
concept of "bug", it simply declares that some behaviours are undefined and
that, under some conditions, the program is ill-formed. How those are exposed
to the user, that's implementation-defined and so is the method of their
correction.
Tooling can be improved, of course. But I argue that it's constantly in
improvement and, more importantlu, the issue of backtraces is an *already*
solved problem.
Finally, I share some of your concern. There are many things that need to be
added to the language and to the standard library to cover some of its
shortcomings. One of my biggest gripes of C++11 was the incomplete support for
the Unicode support that was added, including some basic steps, while a huge
library for ratios and random was added. But since then, I've learned that you
can't stall progress in one area that has consensus because another doesn't
have it yet. Many things need more time for discussion and implementation and
they shouldn't hold back what has been already agreed upon.
--
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+***@isocpp.org.
To post to this group, send email to std-***@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.org.
'Bernd Lörwald' via ISO C++ Standard - Future Proposals
2016-07-31 10:39:45 UTC
Permalink
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+***@isocpp.org.
To post to this group, send email to std-***@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.
Денис Котов
2016-07-31 10:51:53 UTC
Permalink
Post by 'Bernd Lörwald' via ISO C++ Standard - Future Proposals
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.

Yes, you are right. But a lot of mistakes happens in real work, for real
use-cases.
And it is only for this compiler and this envoriment. On *Windows *platform
we have another solution: *StackWalker *or *SEH *exception handling.
Problem, there is no standard in c++ to get stack trace when exception was
thrown and program becomes inconsistent.

вПскресеМье, 31 Оюля 2016 г., 13:39:49 UTC+3 пПльзПватель Bernd Lörwald
Post by 'Bernd Lörwald' via ISO C++ Standard - Future Proposals
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+***@isocpp.org.
To post to this group, send email to std-***@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.org.
Thiago Macieira
2016-07-31 16:10:49 UTC
Permalink
Post by Денис Котов
Yes, you are right. But a lot of mistakes happens in real work, for real
use-cases.
And it is only for this compiler and this envoriment. On *Windows *platform
we have another solution: *StackWalker *or *SEH *exception handling.
Problem, there is no standard in c++ to get stack trace when exception was
thrown and program becomes inconsistent.
You know why that is? Because the program has become inconsistent. Once you've
stepped out of the standard, the standard has no say.
--
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+***@isocpp.org.
To post to this group, send email to std-***@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.
Thiago Macieira
2016-07-31 16:09:46 UTC
Permalink
Post by Денис Котов
Post by Thiago Macieira
You misunderstand what exceptions are for. You're not supposed to catch
them
Post by Thiago Macieira
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
happened.
There was no bug. Exceptions are not used to signal bugs. They are used to
signal perfectly fine, if exceptional, conditions. A file not being found is not
a bug.

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 will
be correct. That's because after the first bug, all bets are off.
Post by Денис Котов
It is impossible or I need put *try ... catch* statement in every place of
my program. But it is wasting of time. Better when exception has all 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.
--
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+***@isocpp.org.
To post to this group, send email to std-***@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.
Денис Котов
2016-07-31 16:38:25 UTC
Permalink
вПскресеМье, 31 Оюля 2016 г., 19:09:51 UTC+3 пПльзПватель Thiago Macieira
Post by Thiago Macieira
Post by Денис Котов
Post by Thiago Macieira
You misunderstand what exceptions are for. You're not supposed to catch
them
Post by Thiago Macieira
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
happened.
There was no bug. Exceptions are not used to signal bugs. They are used to
signal perfectly fine, if exceptional, conditions. A file not being found is not
a bug.
I said problem or bug. If somebody try get element using *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
example file not found as you wrote)* we need show user where it happened.
Post by Thiago Macieira
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 will
be correct. That's because after the first bug, all bets are off.
Post by Денис Котов
It is impossible or I need put *try ... catch* statement in every place of
my program. But it is wasting of time. Better when exception has all 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.*
Every time somebody forgets put *try ... catch* and then happens weird
things. You try finding problem place 2h, 4h, 1day or more ... depends how
big project is.
--
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+***@isocpp.org.
To post to this group, send email to std-***@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.org.
Nicol Bolas
2016-07-31 17:23:21 UTC
Permalink
Post by Денис Котов
вПскресеМье, 31 Оюля 2016 г., 19:09:51 UTC+3 пПльзПватель Thiago Macieira
Post by Thiago Macieira
Post by Thiago Macieira
You misunderstand what exceptions are for. You're not supposed to
catch
Post by Thiago Macieira
them
Post by Thiago Macieira
to find out where the error occurred. You catch them so you handle
the
Post by Thiago Macieira
Post by Thiago Macieira
condition wherever it happened, then continue execution because
you've
Post by Thiago Macieira
Post by Thiago Macieira
corrected the problem.
I think this is incorrect.
How can I correct the problem or bug if I do not know where the
problem
Post by Thiago Macieira
Post by Thiago Macieira
happened.
There was no bug. Exceptions are not used to signal bugs. They are used
to
Post by Thiago Macieira
signal perfectly fine, if exceptional, conditions. A file not being
found is not
Post by Thiago Macieira
a bug.
I said problem or bug. If somebody try get element using *arr.at
<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
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
caused a "file not found as you wrote" exception. I don't want a stack
trace; it would be of utterly *no value* 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.

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 error message, is sufficient.

Stack traces are only of value to *programmers*, and generally, only to the
programmers who wrote the system in question. So what you show to "the
user" is irrelevant.
--
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+***@isocpp.org.
To post to this group, send email to std-***@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.org.
Денис Котов
2016-07-31 17:35:42 UTC
Permalink
вПскресеМье, 31 Оюля 2016 г., 20:23:21 UTC+3 пПльзПватель Nicol Bolas
Post by Nicol Bolas
Post by Денис Котов
вПскресеМье, 31 Оюля 2016 г., 19:09:51 UTC+3 пПльзПватель Thiago Macieira
Post by Thiago Macieira
Post by Thiago Macieira
You misunderstand what exceptions are for. You're not supposed to
catch
Post by Thiago Macieira
them
Post by Thiago Macieira
to find out where the error occurred. You catch them so you handle
the
Post by Thiago Macieira
Post by Thiago Macieira
condition wherever it happened, then continue execution because
you've
Post by Thiago Macieira
Post by Thiago Macieira
corrected the problem.
I think this is incorrect.
How can I correct the problem or bug if I do not know where the
problem
Post by Thiago Macieira
Post by Thiago Macieira
happened.
There was no bug. Exceptions are not used to signal bugs. They are used
to
Post by Thiago Macieira
signal perfectly fine, if exceptional, conditions. A file not being
found is not
Post by Thiago Macieira
a bug.
I said problem or bug. If somebody try get element using *arr.at
<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
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
caused a "file not found as you wrote" exception. I don't want a stack
trace; it would be of utterly *no value* 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.
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 error message, is sufficient.
Stack traces are only of value to *programmers*, and generally, only to
the programmers who wrote the system in question. So what you show to "the
user" is irrelevant.
If I'm *using* a GUI application, I don't know or *care* what function
caused a "file not found as you wrote" exception. I don't want a stack
trace; it would be of utterly *> no value* 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.

It is not needed for you, but do not say in general that this is useless.
If C++ has exceptions we should make them more frendly for users.
In Embedded programming this is very helpful feature *(stack trace)*.
Modern Programming Languages have had already it (Java, C#, Python and so
on).
Guys has already mentioned that *stack trace* will be usefull, 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
feature in C++ ?*
--
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+***@isocpp.org.
To post to this group, send email to std-***@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.org.
Thiago Macieira
2016-07-31 18:43:49 UTC
Permalink
Post by Денис Котов
It is not needed for you, but do not say in general that this is useless.
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 don't
care if the failure happened by way of an exception or an assertion or errno
being set to a value.

Displaying technical information to the user, unprompted, is often bad UX. You
shouldn't do it. It is useful to record it, though, so that the information
can be passed along to the developer (maybe the developer is the user).
Moreover, you want to log other states that are completely outside of the
standard too, like which shared libraries are loaded, what addresses they were
loaded at, which other threads were running and what their stack traces are,
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
information the developer wants is more than just an exception throw location.
Post by Денис Котов
In Embedded programming this is very helpful feature *(stack trace)*.
Modern Programming Languages have had already it (Java, C#, Python and so
on).
Guys has already mentioned that *stack trace* will be usefull, 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
feature in C++ ?*
Funny, I thought I was using it for 15 years.
--
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+***@isocpp.org.
To post to this group, send email to std-***@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.
Nicol Bolas
2016-07-31 18:49:39 UTC
Permalink
Post by Денис Котов
вПскресеМье, 31 Оюля 2016 г., 20:23:21 UTC+3 пПльзПватель Nicol Bolas
Post by Nicol Bolas
Post by Денис Котов
вПскресеМье, 31 Оюля 2016 г., 19:09:51 UTC+3 пПльзПватель Thiago
Post by Thiago Macieira
Post by Thiago Macieira
You misunderstand what exceptions are for. You're not supposed to
catch
Post by Thiago Macieira
them
Post by Thiago Macieira
to find out where the error occurred. You catch them so you handle
the
Post by Thiago Macieira
Post by Thiago Macieira
condition wherever it happened, then continue execution because
you've
Post by Thiago Macieira
Post by Thiago Macieira
corrected the problem.
I think this is incorrect.
How can I correct the problem or bug if I do not know where the
problem
Post by Thiago Macieira
Post by Thiago Macieira
happened.
There was no bug. Exceptions are not used to signal bugs. They are
used to
Post by Thiago Macieira
signal perfectly fine, if exceptional, conditions. A file not being
found is not
Post by Thiago Macieira
a bug.
I said problem or bug. If somebody try get element using *arr.at
<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
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
caused a "file not found as you wrote" exception. I don't want a stack
trace; it would be of utterly *no value* 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.
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 error message, is sufficient.
Stack traces are only of value to *programmers*, and generally, only to
the programmers who wrote the system in question. So what you show to "the
user" is irrelevant.
If I'm *using* a GUI application, I don't know or *care* what function
caused a "file not found as you wrote" exception. I don't want a stack
trace; it would be of utterly *> no value* 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.
It is not needed for you, but do not say in general that this is useless.
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
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
generate a stack trace that contains anything more than addresses? I
assumed most embedded environments didn't have the memory to waste on
loading string data for function/type names and so forth.

Modern Programming Languages have had already it (Java, C#, Python and so
Post by Денис Котов
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.
Post by Денис Котов
*How can you know whether it usefull or not if you have never use this
feature in C++ ?*
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't tell if
they'd be useful.
--
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+***@isocpp.org.
To post to this group, send email to std-***@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.org.
Денис Котов
2016-07-31 19:12:11 UTC
Permalink
вПскресеМье, 31 Оюля 2016 г., 21:49:40 UTC+3 пПльзПватель Nicol Bolas
Post by Nicol Bolas
Post by Денис Котов
вПскресеМье, 31 Оюля 2016 г., 20:23:21 UTC+3 пПльзПватель Nicol Bolas
Post by Nicol Bolas
Post by Денис Котов
вПскресеМье, 31 Оюля 2016 г., 19:09:51 UTC+3 пПльзПватель Thiago
Post by Thiago Macieira
Post by Thiago Macieira
You misunderstand what exceptions are for. You're not supposed to
catch
Post by Thiago Macieira
them
Post by Thiago Macieira
to find out where the error occurred. You catch them so you
handle the
Post by Thiago Macieira
Post by Thiago Macieira
condition wherever it happened, then continue execution because
you've
Post by Thiago Macieira
Post by Thiago Macieira
corrected the problem.
I think this is incorrect.
How can I correct the problem or bug if I do not know where the
problem
Post by Thiago Macieira
Post by Thiago Macieira
happened.
There was no bug. Exceptions are not used to signal bugs. They are
used to
Post by Thiago Macieira
signal perfectly fine, if exceptional, conditions. A file not being
found is not
Post by Thiago Macieira
a bug.
I said problem or bug. If somebody try get element using *arr.at
<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
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
caused a "file not found as you wrote" exception. I don't want a stack
trace; it would be of utterly *no value* 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.
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 error message, is sufficient.
Stack traces are only of value to *programmers*, and generally, only to
the programmers who wrote the system in question. So what you show to "the
user" is irrelevant.
If I'm *using* a GUI application, I don't know or *care* what function
caused a "file not found as you wrote" exception. I don't want a stack
trace; it would be of utterly *> no value* 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.
It is not needed for you, but do not say in general that this is useless.
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
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
generate a stack trace that contains anything more than addresses? I
assumed most embedded environments didn't have the memory to waste on
loading string data for function/type names and so forth.
Modern Programming Languages have had already it (Java, C#, Python and so
Post by Денис Котов
on).
They also have garbage collection. What's your point?
Guys has already mentioned that *stack trace* will be usefull,
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.
Post by Денис Котов
*How can you know whether it usefull or not if you have never use this
feature in C++ ?*
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't tell if
they'd be useful.
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."*
Post by Nicol Bolas
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
choice if they need compile program with additional information (in every
function put meta information with name, class and etc.)
--
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+***@isocpp.org.
To post to this group, send email to std-***@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.org.
D. B.
2016-07-31 19:32:55 UTC
Permalink
Post by Денис Котов
вПскресеМье, 31 Оюля 2016 г., 21:49:40 UTC+3 пПльзПватель Nicol Bolas
Post by Nicol Bolas
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.
--
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+***@isocpp.org.
To post to this group, send email to std-***@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.
Nevin Liber
2016-07-31 19:22:23 UTC
Permalink
Post by Nicol Bolas
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:***@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+***@isocpp.org.
To post to this group, send email to std-***@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.
FrankHB1989
2016-08-08 05:12:43 UTC
Permalink
圚 2016幎8月1日星期䞀 UTC+8䞊午1:23:21Nicol Bolas写道
Post by Nicol Bolas
Post by Денис Котов
вПскресеМье, 31 Оюля 2016 г., 19:09:51 UTC+3 пПльзПватель Thiago Macieira
Post by Thiago Macieira
Post by Thiago Macieira
You misunderstand what exceptions are for. You're not supposed to
catch
Post by Thiago Macieira
them
Post by Thiago Macieira
to find out where the error occurred. You catch them so you handle
the
Post by Thiago Macieira
Post by Thiago Macieira
condition wherever it happened, then continue execution because
you've
Post by Thiago Macieira
Post by Thiago Macieira
corrected the problem.
I think this is incorrect.
How can I correct the problem or bug if I do not know where the
problem
Post by Thiago Macieira
Post by Thiago Macieira
happened.
There was no bug. Exceptions are not used to signal bugs. They are used
to
Post by Thiago Macieira
signal perfectly fine, if exceptional, conditions. A file not being
found is not
Post by Thiago Macieira
a bug.
I said problem or bug. If somebody try get element using *arr.at
<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
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
caused a "file not found as you wrote" exception. I don't want a stack
trace; it would be of utterly *no value* 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.
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 error message, is sufficient.
Stack traces are only of value to *programmers*, and generally, only to
the programmers who wrote the system in question. So what you show to "the
user" is irrelevant.
Do not assume users can't touch the source. (Though you also can't assume
they can, for sure.)
There are cases that users are programmers, e.g. developers using C++ as
scripts, or testers.
--
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+***@isocpp.org.
To post to this group, send email to std-***@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.org.
Thiago Macieira
2016-07-31 18:39:54 UTC
Permalink
Post by Денис Котов
I said problem or bug. If somebody try get element using *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
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 incorrect
step to do. The application should not display its problems to the user. If
they are unrecoverable, log it somewhere for the user to pass the information
along to the developer, then simply report to the user that the unrecoverable
error happened. If the error was recoverable, recover.

The whole point of catching exceptions is to *recover*. If at(1000) throws an
exception and that exception is caught, then the problem was recovered and you
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
case, the uncaught exception handler is called and the program terminates.
Often, ABI-specific information is still available at this point to help
diagnose the issue, including the stack trace. But, as I said, stacks and
frames are concepts that exist only in the ABI, so the standard simply can't
say anything about them.
Post by Денис Котов
Post by Thiago Macieira
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.*
Every time somebody forgets put *try ... catch* and then happens weird
things. You try finding problem place 2h, 4h, 1day or more ... depends how
big project is.
I understand, but the point is remains: if a bug occurred, then you've stepped
outside the realm of the standard. The standard can't say what happens outside
of the standard.

Like I said above, though, most ABIs can log more ABI-dependent information in
the event of an uncaught exception. Yes, that often requires debug mode builds
and debugging symbols to be present.

Assuming that you've been using those facilities provided by your toolchain, I
have to ask: why do you want to standardise them? Why can't you continue to
use the ABI-dependent ones?
--
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+***@isocpp.org.
To post to this group, send email to std-***@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.
Денис Котов
2016-07-31 18:56:23 UTC
Permalink
вПскресеМье, 31 Оюля 2016 г., 21:39:58 UTC+3 пПльзПватель Thiago Macieira
Post by Денис Котов
Post by Денис Котов
I said problem or bug. If somebody try get element using *arr.at(1000)*
it
Post by Денис Котов
will throw exception.
*Is it bug or problem ?*
If we want to show user that something goes wrong we throw exception
*(for
Post by Денис Котов
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 incorrect
step to do. The application should not display its problems to the user. If
they are unrecoverable, log it somewhere for the user to pass the information
along to the developer, then simply report to the user that the unrecoverable
error happened. If the error was recoverable, recover.
The whole point of catching exceptions is to *recover*. If at(1000) throws an
exception and that exception is caught, then the problem was recovered and you
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
case, the uncaught exception handler is called and the program terminates.
Often, ABI-specific information is still available at this point to help
diagnose the issue, including the stack trace. But, as I said, stacks and
frames are concepts that exist only in the ABI, so the standard simply can't
say anything about them.
Post by Денис Котов
Post by Thiago Macieira
You put it around any place that can throw and that your founction
isn't
Post by Денис Котов
Post by Thiago Macieira
expected to throw that exception.
*Unfortunately big programs writes by many people and people make
mistakes.*
Post by Денис Котов
Every time somebody forgets put *try ... catch* and then happens weird
things. You try finding problem place 2h, 4h, 1day or more ... depends
how
Post by Денис Котов
big project is.
I understand, but the point is remains: if a bug occurred, then you've stepped
outside the realm of the standard. The standard can't say what happens outside
of the standard.
Like I said above, though, most ABIs can log more ABI-dependent information in
the event of an uncaught exception. Yes, that often requires debug mode builds
and debugging symbols to be present.
Assuming that you've been using those facilities provided by your toolchain, I
have to ask: why do you want to standardise them? Why can't you continue to
use the ABI-dependent ones?
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
By "user" - I mean programmers. Programmers is the first user of standard
library.
Post by Денис Котов
Assuming that you've been using those facilities provided by your toolchain, I
have to ask: why do you want to standardise them? Why can't you continue 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
not provide. Should be standard way for handling such situation.
--
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+***@isocpp.org.
To post to this group, send email to std-***@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.org.
Thiago Macieira
2016-07-31 20:14:46 UTC
Permalink
Post by Thiago Macieira
Post by Thiago Macieira
Assuming that you've been using those facilities provided by your
toolchain, I
Post by Thiago Macieira
have to ask: why do you want to standardise them? Why can't you continue
to
Post by Thiago Macieira
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
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
standard way of making bicycles exists because the circumstances for bicycles
are mostly the same.

That's not the same for diagnosing problems in ABI. Each ABI is different, and
will be able to do different things, log different things. What's important in
one ABI may be superfluous or completely inexistent in another. It's hard to
standardise what's completely different.

You're arguing for stack traces. I'm saying that stack traces isn't enough
*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 graphics in
the standard. The standard does not need to be all-encompassing.
--
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+***@isocpp.org.
To post to this group, send email to std-***@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.
Денис Котов
2016-07-31 20:41:36 UTC
Permalink
вПскресеМье, 31 Оюля 2016 г., 23:14:50 UTC+3 пПльзПватель Thiago Macieira
Post by Thiago Macieira
Post by Thiago Macieira
Post by Thiago Macieira
Assuming that you've been using those facilities provided by your
toolchain, I
Post by Thiago Macieira
have to ask: why do you want to standardise them? Why can't you
continue
Post by Thiago Macieira
to
Post by Thiago Macieira
use the ABI-dependent ones?
Because everybody implement their own bicycle if you understand what I
mean.
Post by Thiago Macieira
All programmers implement their own bicycle, because standard library
does
Post by Thiago Macieira
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
standard way of making bicycles exists because the circumstances for bicycles
are mostly the same.
That's not the same for diagnosing problems in ABI. Each ABI is different, and
will be able to do different things, log different things. What's important in
one ABI may be superfluous or completely inexistent in another. It's hard to
standardise what's completely different.
You're arguing for stack traces. I'm saying that stack traces isn't enough
*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 graphics in
the standard. The standard does not need to be all-encompassing.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
We could implement it even without ABI. Just by adding meta-information and
code for function for Debug mode.
When you call function in it first of all become to execute meta-code which
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.
--
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+***@isocpp.org.
To post to this group, send email to std-***@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.org.
Nicol Bolas
2016-07-31 23:13:42 UTC
Permalink
Post by Денис Котов
вПскресеМье, 31 Оюля 2016 г., 23:14:50 UTC+3 пПльзПватель Thiago Macieira
Post by Thiago Macieira
Post by Thiago Macieira
Post by Thiago Macieira
Assuming that you've been using those facilities provided by your
toolchain, I
Post by Thiago Macieira
have to ask: why do you want to standardise them? Why can't you
continue
Post by Thiago Macieira
to
Post by Thiago Macieira
use the ABI-dependent ones?
Because everybody implement their own bicycle if you understand what I
mean.
Post by Thiago Macieira
All programmers implement their own bicycle, because standard library
does
Post by Thiago Macieira
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
standard way of making bicycles exists because the circumstances for bicycles
are mostly the same.
That's not the same for diagnosing problems in ABI. Each ABI is different, and
will be able to do different things, log different things. What's important in
one ABI may be superfluous or completely inexistent in another. It's hard to
standardise what's completely different.
You're arguing for stack traces. I'm saying that stack traces isn't enough
*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 graphics in
the standard. The standard does not need to be all-encompassing.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
We could implement it even without ABI. Just by adding meta-information
and code for function for Debug mode.
What is "Debug Mode"? I ask this question because the C++ standard does not
mention any such thing.

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 sequence of function calls that may or may not have happened from this
function to the top of its current execution context.

Why do we need to standardize something so utterly nebulous?
--
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+***@isocpp.org.
To post to this group, send email to std-***@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.org.
Денис Котов
2016-08-01 03:03:03 UTC
Permalink
пПМеЎельМОк, 1 августа 2016 г., 2:13:42 UTC+3 пПльзПватель Nicol Bolas
Post by Nicol Bolas
Post by Денис Котов
вПскресеМье, 31 Оюля 2016 г., 23:14:50 UTC+3 пПльзПватель Thiago Macieira
Post by Thiago Macieira
Post by Thiago Macieira
Post by Thiago Macieira
Assuming that you've been using those facilities provided by your
toolchain, I
Post by Thiago Macieira
have to ask: why do you want to standardise them? Why can't you
continue
Post by Thiago Macieira
to
Post by Thiago Macieira
use the ABI-dependent ones?
Because everybody implement their own bicycle if you understand what I
mean.
Post by Thiago Macieira
All programmers implement their own bicycle, because standard library
does
Post by Thiago Macieira
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
standard way of making bicycles exists because the circumstances for bicycles
are mostly the same.
That's not the same for diagnosing problems in ABI. Each ABI is different, and
will be able to do different things, log different things. What's important in
one ABI may be superfluous or completely inexistent in another. It's hard to
standardise what's completely different.
You're arguing for stack traces. I'm saying that stack traces isn't enough
*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 graphics in
the standard. The standard does not need to be all-encompassing.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
We could implement it even without ABI. Just by adding meta-information
and code for function for Debug mode.
What is "Debug Mode"? I ask this question because the C++ standard does
not mention any such thing.
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 sequence of function calls that may or may not have happened from
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
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
would be constructively.
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 his
hands."

*I got tired. I want a constructive dialog.*
--
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+***@isocpp.org.
To post to this group, send email to std-***@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.org.
Thiago Macieira
2016-08-01 04:16:40 UTC
Permalink
Post by Денис Котов
Post by Nicol Bolas
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
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.
Post by Денис Котов
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 as
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.
Post by Денис Котов
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 his
hands."
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.
--
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+***@isocpp.org.
To post to this group, send email to std-***@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.
Денис Котов
2016-08-01 04:26:58 UTC
Permalink
пПМеЎельМОк, 1 августа 2016 г., 7:16:54 UTC+3 пПльзПватель Thiago Macieira
Post by Thiago Macieira
Post by Денис Котов
Post by Nicol Bolas
What is "Debug Mode"? I ask this question because the C++ standard
does
Post by Денис Котов
Post by Nicol Bolas
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
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.
Post by Денис Котов
And please, stop arguing with me. Make some correction of my proposal.
It
Post by Денис Котов
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 as
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.
Post by Денис Котов
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
-
Post by Денис Котов
no, just put in every place of your program try ... catch, make your
code
Post by Денис Котов
like spaghetti ... if somebody forgot put try ... catch statement, hit
his
Post by Денис Котов
hands."
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.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
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.
Could you enumerate them ? For different compilers, please ?
And how catch for different compilers stack in moment when exception was
thrown ?
--
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+***@isocpp.org.
To post to this group, send email to std-***@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.org.
Thiago Macieira
2016-08-01 15:36:16 UTC
Permalink
понедельник, 1 августа 2016 г., 7:16:54 UTC+3 пользователь Thiago Macieira
Post by Thiago Macieira
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.
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".

With older versions of gdb nor supporting that or other debuggers for the same
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
my code. But when other mistakes happen in my code, the debugger is very
helpful.
--
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+***@isocpp.org.
To post to this group, send email to std-***@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.
Денис Котов
2016-08-01 04:29:22 UTC
Permalink
пПМеЎельМОк, 1 августа 2016 г., 7:16:54 UTC+3 пПльзПватель Thiago Macieira
Post by Thiago Macieira
Post by Денис Котов
Post by Nicol Bolas
What is "Debug Mode"? I ask this question because the C++ standard
does
Post by Денис Котов
Post by Nicol Bolas
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
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.
Post by Денис Котов
And please, stop arguing with me. Make some correction of my proposal.
It
Post by Денис Котов
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 as
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.
Post by Денис Котов
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
-
Post by Денис Котов
no, just put in every place of your program try ... catch, make your
code
Post by Денис Котов
like spaghetti ... if somebody forgot put try ... catch statement, hit
his
Post by Денис Котов
hands."
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.
--
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+***@isocpp.org.
To post to this group, send email to std-***@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.org.
Ren Industries
2016-08-01 05:07:53 UTC
Permalink
Of course it is Linux specific; it has to be ABI specific. That's what
everyone has been telling you.
Post by Денис Котов
пПМеЎельМОк, 1 августа 2016 г., 7:16:54 UTC+3 пПльзПватель Thiago Macieira
Post by Thiago Macieira
Post by Денис Котов
Post by Nicol Bolas
What is "Debug Mode"? I ask this question because the C++ standard
does
Post by Денис Котов
Post by Nicol Bolas
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
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.
Post by Денис Котов
And please, stop arguing with me. Make some correction of my proposal.
It
Post by Денис Котов
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 as
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.
Post by Денис Котов
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
-
Post by Денис Котов
no, just put in every place of your program try ... catch, make your
code
Post by Денис Котов
like spaghetti ... if somebody forgot put try ... catch statement, hit
his
Post by Денис Котов
hands."
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.
--
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
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.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/0b73ccc1-a873-441b-ad74-8bb44d6b28e0%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+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAMD6iD-88mGP220z4m33-9jbsoxXV19WkDdOj8RRuBVNNmQ3MQ%40mail.gmail.com.
Wil Evers
2016-08-01 14:19:23 UTC
Permalink
Post by Thiago Macieira
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+***@isocpp.org.
To post to this group, send email to std-***@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.
Thiago Macieira
2016-08-01 15:33:57 UTC
Permalink
Post by Wil Evers
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.
Post by Wil Evers
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+***@isocpp.org.
To post to this group, send email to std-***@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.
Wil Evers
2016-08-01 19:13:10 UTC
Permalink
Post by Thiago Macieira
Post by Wil Evers
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.
Post by Thiago Macieira
Post by Wil Evers
Given that, it seems quite reasonable to think of a build where NDEBUG
is
Post by Wil Evers
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.
Post by Thiago Macieira
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+***@isocpp.org.
To post to this group, send email to std-***@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.
Thiago Macieira
2016-08-01 19:38:30 UTC
Permalink
Post by Wil Evers
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.
Post by Wil Evers
Post by Thiago Macieira
Post by Wil Evers
Given that, it seems quite reasonable to think of a build where NDEBUG
is
Post by Wil Evers
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.
Post by Wil Evers
Post by Thiago Macieira
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+***@isocpp.org.
To post to this group, send email to std-***@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.
Patrice Roy
2016-08-01 20:06:53 UTC
Permalink
Post by Thiago Macieira
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 :)
Post by Thiago Macieira
Post by Wil Evers
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.
Post by Wil Evers
Post by Thiago Macieira
Post by Wil Evers
Given that, it seems quite reasonable to think of a build where
NDEBUG
Post by Wil Evers
Post by Thiago Macieira
is
Post by Wil Evers
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
Post by Wil Evers
Post by Thiago Macieira
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.
Post by Wil Evers
Post by Thiago Macieira
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
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+***@isocpp.org.
To post to this group, send email to std-***@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.
Wil Evers
2016-08-01 20:17:39 UTC
Permalink
Post by Денис Котов
Post by Wil Evers
Sounds like you need to fix your build system. Since the effect of
NDEBUG
Post by Wil Evers
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.
Post by Денис Котов
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]
Post by Денис Котов
The point of NDEBUG is to generate *different code* in different
Post by Wil Evers
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+***@isocpp.org.
To post to this group, send email to std-***@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.
Thiago Macieira
2016-08-01 23:33:26 UTC
Permalink
Post by Wil Evers
Post by Thiago Macieira
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+***@isocpp.org.
To post to this group, send email to std-***@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.
Wil Evers
2016-08-02 06:12:06 UTC
Permalink
Post by Thiago Macieira
Post by Wil Evers
Post by Thiago Macieira
The buildsystem should be agnostic and not define things I don't want
it
Post by Wil Evers
Post by Thiago Macieira
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
Post by Wil Evers
Qt ignores its intended usage, then that's a compliance issue, among a
few
Post by Wil Evers
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+***@isocpp.org.
To post to this group, send email to std-***@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.
Thiago Macieira
2016-08-02 06:35:23 UTC
Permalink
Post by Wil Evers
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+***@isocpp.org.
To post to this group, send email to std-***@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.
Wil Evers
2016-08-02 07:18:15 UTC
Permalink
Post by Thiago Macieira
Post by Wil Evers
I would argue that a library or build system that ignores common
practice
Post by Wil Evers
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+***@isocpp.org.
To post to this group, send email to std-***@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.
Reza Jahanbakhshi
2016-08-02 08:20:44 UTC
Permalink
Post by Thiago Macieira
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.
Post by Thiago Macieira
Post by Thiago Macieira
Post by Wil Evers
I would argue that a library or build system that ignores common
practice
Post by Wil Evers
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
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+***@isocpp.org.
To post to this group, send email to std-***@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.
Thiago Macieira
2016-08-02 14:58:38 UTC
Permalink
Post by Reza Jahanbakhshi
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.
I didn't include Boost in my search because then I would also include Qt and I
could conclude that use of NDEBUG and QT_NO_DEBUG are equally common, as there
are 57 uses in Boost in 10993 header files, compared to 53 uses in Qt for 6705
header files.
--
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+***@isocpp.org.
To post to this group, send email to std-***@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.
Reza Jahanbakhshi
2016-08-02 16:00:22 UTC
Permalink
Post by Wil Evers
Post by Reza Jahanbakhshi
NDEBUG is also used in boost libraries to check debug/release
configuration
Post by Reza Jahanbakhshi
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 and I
could conclude that use of NDEBUG and QT_NO_DEBUG are equally common, as there
are 57 uses in Boost in 10993 header files, compared to 53 uses in Qt for 6705
header files.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
I'm not sure if continuing this argument 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 impact. For example
circular_buffer uses NDEBUG to define BOOST_CB_ENABLE_DEBUG and this one is
used 33 times allover circular_buffer headers. And in boost.concept NDEBUG
changes the definition of BOOST_CONCEPT_REQUIRES which essentially changes
the whole library. in boost.gil, based on NDEBUG, another
macro GIL_FORCEINLINE is defined which in turn is used 117 times allover
boost.gil headers. I can go on and on but my point is I think NDEBUG is
being used as one way to make optimization and diagnostic compile-time
decision whenever it was necessary in some boost libraries. Of course not
all libraries need such a decision and some uses other definitions like
BOOST_ASIO_ENABLE_BUFFER_DEBUGGING in boost asio.
--
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+***@isocpp.org.
To post to this group, send email to std-***@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.org.
Thiago Macieira
2016-08-02 14:52:21 UTC
Permalink
Post by Wil Evers
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.
No, I'm arguing that there aren't many uses besides assert(), which means that
it's not standard practice to use that macro for other uses.
--
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+***@isocpp.org.
To post to this group, send email to std-***@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.
D. B.
2016-08-02 14:56:25 UTC
Permalink
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+***@isocpp.org.
To post to this group, send email to std-***@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.
Thiago Macieira
2016-08-02 15:01:09 UTC
Permalink
Post by D. B.
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.
I understand that this is the use being argued. And I have seen it argued like
that before. My point is that it's not very common to do it outside of Boost,
so we can't call it "common pratice".

At best, I can conclude it is "Google pratice", since three projects from
Gooogle I have lying around (Google test, Google log and Google protobuf) are
the largest users.
--
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+***@isocpp.org.
To post to this group, send email to std-***@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.
Matthew Woehlke
2016-08-02 13:25:02 UTC
Permalink
Post by Thiago Macieira
Post by Wil Evers
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+***@isocpp.org.
To post to this group, send email to std-***@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.
Wil Evers
2016-08-02 13:58:18 UTC
Permalink
Post by Денис Котов
Post by Thiago Macieira
Post by Wil Evers
Qt is not the standard. The standard only talks about the NDEBUG macro.
If
Post by Thiago Macieira
Post by Wil Evers
Qt ignores its intended usage, then that's a compliance issue, among a
few
Post by Thiago Macieira
Post by Wil Evers
others, with Qt.
The standard does not say anything about NDEBUG except in connection to
the
Post by Thiago Macieira
assert macro's behaviour ([assertions.assert], [using.headers] and in a
note
Post by Thiago Macieira
in [dcl.attr.unused]). From the point of view of the standard, the
NDEBUG
Post by Thiago Macieira
macro is exclusively related to NDEBUG.
[...]
What I will argue is that a library that is not the Standards Library
is, by
Post by Thiago Macieira
the very definition, not part of the Standard. It needs to be written
compliant
Post by Thiago Macieira
with the core language standard and using the Standard Library in a
compliant
Post by Thiago Macieira
manner, but that library itself is never subject to the standard.
Therefore,
Post by Thiago Macieira
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+***@isocpp.org.
To post to this group, send email to std-***@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.
Reza Jahanbakhshi
2016-08-02 14:04:12 UTC
Permalink
Post by Денис Котов
Post by Thiago Macieira
Post by Wil Evers
Qt is not the standard. The standard only talks about the NDEBUG macro.
If
Post by Thiago Macieira
Post by Wil Evers
Qt ignores its intended usage, then that's a compliance issue, among a
few
Post by Thiago Macieira
Post by Wil Evers
others, with Qt.
The standard does not say anything about NDEBUG except in connection to
the
Post by Thiago Macieira
assert macro's behaviour ([assertions.assert], [using.headers] and in a
note
Post by Thiago Macieira
in [dcl.attr.unused]). From the point of view of the standard, the
NDEBUG
Post by Thiago Macieira
macro is exclusively related to NDEBUG.
[...]
What I will argue is that a library that is not the Standards Library
is, by
Post by Thiago Macieira
the very definition, not part of the Standard. It needs to be written
compliant
Post by Thiago Macieira
with the core language standard and using the Standard Library in a
compliant
Post by Thiago Macieira
manner, but that library itself is never subject to the standard.
Therefore,
Post by Thiago Macieira
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+***@isocpp.org.
To post to this group, send email to std-***@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.
FrankHB1989
2016-08-08 06:35:36 UTC
Permalink
So is it right to force the users to have new mental burden while using a
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
standard is good enough in most cases. Then why I should bother the *both *(NDEBUG
vs XXX_NO_DEBUG) cases when I have no need to *extend *the standardized
interface? The worse thing is i can't predicate how many instances will
eventually effective by the latter case. Then only try to read and remember
documentation for *every *dependency for *same *need of functionality *even
I don't want to use* is the correct practice, huh?

圚 2016幎8月2日星期二 UTC+8䞋午9:25:05Matthew Woehlke写道
Post by Денис Котов
Post by Thiago Macieira
Post by Wil Evers
Qt is not the standard. The standard only talks about the NDEBUG macro.
If
Post by Thiago Macieira
Post by Wil Evers
Qt ignores its intended usage, then that's a compliance issue, among a
few
Post by Thiago Macieira
Post by Wil Evers
others, with Qt.
The standard does not say anything about NDEBUG except in connection to
the
Post by Thiago Macieira
assert macro's behaviour ([assertions.assert], [using.headers] and in a
note
Post by Thiago Macieira
in [dcl.attr.unused]). From the point of view of the standard, the
NDEBUG
Post by Thiago Macieira
macro is exclusively related to NDEBUG.
[...]
What I will argue is that a library that is not the Standards Library
is, by
Post by Thiago Macieira
the very definition, not part of the Standard. It needs to be written
compliant
Post by Thiago Macieira
with the core language standard and using the Standard Library in a
compliant
Post by Thiago Macieira
manner, but that library itself is never subject to the standard.
Therefore,
Post by Thiago Macieira
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+***@isocpp.org.
To post to this group, send email to std-***@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.org.
Thiago Macieira
2016-08-01 04:12:13 UTC
Permalink
Post by Денис Котов
Post by Thiago Macieira
You're arguing for stack traces. I'm saying that stack traces isn't enough
*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 graphics 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. That
will inhibit a lot of possible optimisations.

Second, we can't do it for debug mode. There's absolutely no such thing as
"debug mode" in the standard. And third, you yourself said that this shouldn't
be restricted to debug mode or release mode.
Post by Денис Котов
When you call function in it first of all become to execute meta-code which
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.
Post by Денис Котов
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
good enough, just not part of the standard.
--
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+***@isocpp.org.
To post to this group, send email to std-***@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.
FrankHB1989
2016-08-08 05:23:32 UTC
Permalink
圚 2016幎8月1日星期䞀 UTC+8䞊午2:39:58Thiago Macieira写道
Post by Денис Котов
Post by Денис Котов
I said problem or bug. If somebody try get element using *arr.at(1000)*
it
Post by Денис Котов
will throw exception.
*Is it bug or problem ?*
If we want to show user that something goes wrong we throw exception
*(for
Post by Денис Котов
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 incorrect
step to do. The application should not display its problems to the user. If
they are unrecoverable, log it somewhere for the user to pass the information
along to the developer, then simply report to the user that the unrecoverable
error happened. If the error was recoverable, recover.
In the aspect of specific applications, this is usually true. As the view
of the standard, this is false. It is the author of the application, not
others, to determine whether this should be supported or not in their
products, for the sake only they will know clearly enough.
Post by Денис Котов
The whole point of catching exceptions is to *recover*. If at(1000) throws an
exception and that exception is caught, then the problem was recovered and you
don't need to know (much less display) where the exception was thrown from.
Generally no, esp. if you make it rethrown. (Though I think you were not
talking about this case.)

Exceptions (as some forms of delimited continuations) in essential are not
different to other control primitives, though in C++ it is quite limited by
many reasons. The specification of the language should support the probably
valuable idiomatic use, but not specify it explicitly.
Post by Денис Котов
If the exception wasn't caught, then it was an unrecoverable error. In that
case, the uncaught exception handler is called and the program terminates.
Often, ABI-specific information is still available at this point to help
diagnose the issue, including the stack trace. But, as I said, stacks and
frames are concepts that exist only in the ABI, so the standard simply can't
say anything about them.
Post by Денис Котов
Post by Thiago Macieira
You put it around any place that can throw and that your founction
isn't
Post by Денис Котов
Post by Thiago Macieira
expected to throw that exception.
*Unfortunately big programs writes by many people and people make
mistakes.*
Post by Денис Котов
Every time somebody forgets put *try ... catch* and then happens weird
things. You try finding problem place 2h, 4h, 1day or more ... depends
how
Post by Денис Котов
big project is.
I understand, but the point is remains: if a bug occurred, then you've stepped
outside the realm of the standard. The standard can't say what happens outside
of the standard.
Like I said above, though, most ABIs can log more ABI-dependent information in
the event of an uncaught exception. Yes, that often requires debug mode builds
and debugging symbols to be present.
Assuming that you've been using those facilities provided by your toolchain, I
have to ask: why do you want to standardise them? Why can't you continue to
use the ABI-dependent ones?
--
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+***@isocpp.org.
To post to this group, send email to std-***@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.org.
g***@gmail.com
2016-08-01 06:54:11 UTC
Permalink
Post by r***@gmail.com
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.*
The idea has 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 relevant, won't the Standard have to wakeup to debug mode
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
BTRACE is defined as 1, the compiler might emit extra trace information
that might aid debugging. If that information is generated, an exit via an
unhandled exception will cause std::dump_stacktrace to be automatically
called. If BTRACE==0 or not defined, std::dump_stacktrace will not be
called."


Enabling the facility in "release mode" seems to be another reason why
debug mode seems mostly irrelevant to the debate.


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?


One could spice up the options or the mechanism but I don't see why the
basic idea isn't workable as a starting or ending point. I also don't
see debug mode as a reason to reject the idea.
--
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+***@isocpp.org.
To post to this group, send email to std-***@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.org.
Thiago Macieira
2016-08-01 15:41:09 UTC
Permalink
Post by g***@gmail.com
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+***@isocpp.org.
To post to this group, send email to std-***@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.
g***@gmail.com
2016-08-01 22:34:41 UTC
Permalink
Hi Thiagp
Post by Денис Котов
Post by g***@gmail.com
If this means someone could configure a program to get a basic stack
trace
Post by g***@gmail.com
on program failure and also be able to dump that on demand and all
without
Post by g***@gmail.com
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?
a) add a function std::dump_backtrace, whose behaviour is suggested by the
standard, but a compliant implementation could simply do nothing.
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+***@isocpp.org.
To post to this group, send email to std-***@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.
Thiago Macieira
2016-08-01 23:39:53 UTC
Permalink
Post by g***@gmail.com
Post by Thiago Macieira
a) add a function std::dump_backtrace, whose behaviour is suggested by the
standard, but a compliant implementation could simply do nothing.
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.
Post by g***@gmail.com
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+***@isocpp.org.
To post to this group, send email to std-***@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.
g***@gmail.com
2016-08-02 02:22:35 UTC
Permalink
Post by Thiago Macieira
Post by g***@gmail.com
Post by Thiago Macieira
a) add a function std::dump_backtrace, whose behaviour is suggested by
the
Post by g***@gmail.com
Post by Thiago Macieira
standard, but a compliant implementation could simply do nothing.
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.
Post by g***@gmail.com
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
Post by g***@gmail.com
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
Post by g***@gmail.com
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
Post by g***@gmail.com
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 read it as the OP was trying to achieve the type of feature that
I described, they just framed it with things that didn't seem necessary to
their goal and then those things got picked up and used to defeat the whole
idea. That's not helpful nor it seems even correct either.
Post by Thiago Macieira
Post by g***@gmail.com
I know everyone has bad days (me too) but I'd generally like to see
this
Post by g***@gmail.com
forum adopt a more nurturing tone to posters. I think that starts by
more
Post by g***@gmail.com
people embracing the concept that you can nurture an idea without having
to
Post by g***@gmail.com
adopt it, nor kill it or even agree with it. And not getting overly tied
up
Post by g***@gmail.com
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
Post by g***@gmail.com
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?
Yes I'm sure the OP did make a few factually incorrect statements. As did
everyone it seems. I do it all the time. But I think we need to get in the
habit of not letting inaccuracies get in the way of progress. There was
good to be had from the OP's post and I hate we lose that too
often. Correctness must not be everything otherwise we all may as well quit
this forum as only Richard Smith or Daniel KrÃŒgler could participate in a
forum based on that criteria and we all know those guys weren't born they
were genetically engineered.
Post by Thiago Macieira
"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
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.
--
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+***@isocpp.org.
To post to this group, send email to std-***@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.org.
Thiago Macieira
2016-08-02 04:06:41 UTC
Permalink
Post by g***@gmail.com
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+***@isocpp.org.
To post to this group, send email to std-***@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.
Viacheslav Usov
2016-08-01 10:31:27 UTC
Permalink
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+***@isocpp.org.
To post to this group, send email to std-***@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.
Nicol Bolas
2016-08-01 14:02:23 UTC
Permalink
Post by Viacheslav Usov
https://groups.google.com/a/isocpp.org/forum/#!topic/std-discussion/A17G1ram9ns
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
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
Post by Viacheslav Usov
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+***@isocpp.org.
To post to this group, send email to std-***@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.
Viacheslav Usov
2016-08-01 14:20:14 UTC
Permalink
Post by Nicol Bolas
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+***@isocpp.org.
To post to this group, send email to std-***@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.
Nicol Bolas
2016-08-01 14:45:38 UTC
Permalink
Post by Nicol Bolas
Post by Nicol Bolas
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+***@isocpp.org.
To post to this group, send email to std-***@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.
Viacheslav Usov
2016-08-01 15:07:51 UTC
Permalink
Post by Nicol Bolas
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+***@isocpp.org.
To post to this group, send email to std-***@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.
Денис Котов
2016-08-01 17:47:04 UTC
Permalink
пПМеЎельМОк, 1 августа 2016 г., 17:02:23 UTC+3 пПльзПватель Nicol Bolas
Post by Nicol Bolas
Post by Viacheslav Usov
https://groups.google.com/a/isocpp.org/forum/#!topic/std-discussion/A17G1ram9ns
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
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
Post by Viacheslav Usov
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.
If Standard committee has been thinking about it since last century, maybe
that can mean there is no better solution ?
If you have possibility to handle an issue you have to pay for this
possibility ! Another way, compile *-fno-exceptions* with flag.
--
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+***@isocpp.org.
To post to this group, send email to std-***@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.org.
Tom Honermann
2016-08-01 14:21:58 UTC
Permalink
Post by Viacheslav Usov
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+***@isocpp.org.
To post to this group, send email to std-***@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.
Viacheslav Usov
2016-08-01 14:43:34 UTC
Permalink
Post by Viacheslav Usov
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+***@isocpp.org.
To post to this group, send email to std-***@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.
Tom Honermann
2016-08-01 14:52:22 UTC
Permalink
Post by Viacheslav Usov
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+***@isocpp.org.
To post to this group, send email to std-***@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.
Viacheslav Usov
2016-08-01 15:40:13 UTC
Permalink
Post by Tom Honermann
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+***@isocpp.org.
To post to this group, send email to std-***@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.
Tom Honermann
2016-08-01 16:24:06 UTC
Permalink
Post by Tom Honermann
Post by Tom Honermann
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.
Post by Tom Honermann
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+***@isocpp.org.
To post to this group, send email to std-***@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.
Viacheslav Usov
2016-08-01 16:27:48 UTC
Permalink
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+***@isocpp.org.
To post to this group, send email to std-***@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.
Tom Honermann
2016-08-01 16:38:16 UTC
Permalink
Post by Tom Honermann
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
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+***@isocpp.org.
To post to this group, send email to std-***@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.
Viacheslav Usov
2016-08-01 16:49:56 UTC
Permalink
Post by Tom Honermann
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+***@isocpp.org.
To post to this group, send email to std-***@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.
Tom Honermann
2016-08-01 17:45:49 UTC
Permalink
Post by Tom Honermann
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+***@isocpp.org.
To post to this group, send email to std-***@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.
Viacheslav Usov
2016-08-02 13:42:08 UTC
Permalink
Post by Tom Honermann
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.
Post by Tom Honermann
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.
Post by Tom Honermann
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+***@isocpp.org.
To post to this group, send email to std-***@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.
Tom Honermann
2016-08-02 15:05:44 UTC
Permalink
Post by Tom Honermann
Post by Tom Honermann
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).
Post by Tom Honermann
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).
Post by Tom Honermann
Post by Tom Honermann
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.
Post by Tom Honermann
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+***@isocpp.org.
To post to this group, send email to std-***@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.
Viacheslav Usov
2016-08-02 15:16:51 UTC
Permalink
Post by Tom Honermann
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+***@isocpp.org.
To post to this group, send email to std-***@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.
Thiago Macieira
2016-08-01 15:57:04 UTC
Permalink
On segunda-feira, 1 de agosto de 2016 07:54:36 PDT
- 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+***@isocpp.org.
To post to this group, send email to std-***@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.
Денис Котов
2016-08-03 06:19:31 UTC
Permalink
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
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
exception according to ABI of current platform.

вПскресеМье, 31 Оюля 2016 г., 3:14:19 UTC+3 пПльзПватель ДеМОс КПтПв
Post by r***@gmail.com
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+***@isocpp.org.
To post to this group, send email to std-***@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.org.
g***@gmail.com
2016-08-03 08:22:05 UTC
Permalink
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?

I'd ask you/the experts Is it necessary or good to define this interface to
the back trace in terms of exceptions or debug mode? Sorry if it is and I'm
missing something obvious.

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. So I'm wondering if having to get an
exception pointer to get at that stack trace would seem to expose more
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
exposed as or aren't tied to the facility that you want. Please anyone
enlighten me here.
Post by Денис Котов
*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
calls.
test.so: __func(int)
two.so: __test(int)
three.so: __cal(int)
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
exception according to ABI of current platform.
вПскресеМье, 31 Оюля 2016 г., 3:14:19 UTC+3 пПльзПватель ДеМОс КПтПв
Post by r***@gmail.com
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+***@isocpp.org.
To post to this group, send email to std-***@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.org.
Viacheslav Usov
2016-08-03 08:38:25 UTC
Permalink
Post by g***@gmail.com
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+***@isocpp.org.
To post to this group, send email to std-***@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.
g***@gmail.com
2016-08-03 09:26:10 UTC
Permalink
Post by g***@gmail.com
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+***@isocpp.org.
To post to this group, send email to std-***@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.
Matthew Woehlke
2016-08-03 12:48:05 UTC
Permalink
Post by g***@gmail.com
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+***@isocpp.org.
To post to this group, send email to std-***@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.
Matthew Woehlke
2016-08-01 14:19:23 UTC
Permalink
Post by r***@gmail.com
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+***@isocpp.org.
To post to this group, send email to std-***@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.
Денис Котов
2016-08-05 21:44:32 UTC
Permalink
What is the result of our TOPIC ?

Result is *ZERO *!!!!! How many *human*hours* has been spent, but nothing !
Can somebody from *сommittee *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+***@isocpp.org.
To post to this group, send email to std-***@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.
Patrice Roy
2016-08-05 21:53:05 UTC
Permalink
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!
Post by Денис Котов
What is the result of our TOPIC ?
Result is *ZERO *!!!!! How many *human*hours* has been spent, but nothing !
Can somebody from *сommittee *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
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-76bc-4cc0-8d9b-155999d7ade2%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+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKiZDp0V8a%2B3wf_BJJQrJ20vhHcOxDeXemXpSzNmnrYY5fjfDQ%40mail.gmail.com.
Денис Котов
2016-08-06 13:05:06 UTC
Permalink
Okay,

Where could I submit my reworked proposal ?
Could you privde me with link ?
Post by Patrice Roy
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!
Post by Денис Котов
What is the result of our TOPIC ?
Result is *ZERO *!!!!! How many *human*hours* has been spent, but nothing !
Can somebody from *сommittee *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
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-76bc-4cc0-8d9b-155999d7ade2%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+***@isocpp.org.
To post to this group, send email to std-***@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.
Patrice Roy
2016-08-06 13:19:04 UTC
Permalink
I'd say https://isocpp.org/std/submit-a-proposal is a starting point :)

Good luck!
Post by Денис Котов
Okay,
Where could I submit my reworked proposal ?
Could you privde me with link ?
Post by Patrice Roy
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!
Post by Денис Котов
What is the result of our TOPIC ?
Result is *ZERO *!!!!! How many *human*hours* has been spent, but nothing !
Can somebody from *сommittee *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
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=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
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-933e-4a92-a2d4-77a1cca213c1%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+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKiZDp3VuW_zi5CecXpth-sp81z25bArWyrJYzaMGfeR8JG0LQ%40mail.gmail.com.
Денис Котов
2016-08-07 09:43:06 UTC
Permalink
In this topic some one has mentioned that we need dinamic structure to keep
stacktrace information.
I have another idea.

What if compiler would support stacktrace first 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:



In this case we no need any other dynamic structure data. We have already
the main dynamic structure of our program *A STACK OF CURRENT THREAD !!!!!!*

Invoked function that does not support stacktrace would never know about
this additional information, only our program that would be compiled with
stacktrace support would know about this information !

*What do you think about it ? *

вПскресеМье, 31 Оюля 2016 г., 3:14:19 UTC+3 пПльзПватель ДеМОс КПтПв
Post by r***@gmail.com
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+***@isocpp.org.
To post to this group, send email to std-***@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.org.
Денис Котов
2016-08-07 09:55:40 UTC
Permalink
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 =)
вПскресеМье, 7 августа 2016 г., 12:43:07 UTC+3 пПльзПватель ДеМОс КПтПв
Post by Денис Котов
In this topic some one has mentioned that we need dinamic structure to
keep stacktrace information.
I have another idea.
What if compiler would support stacktrace first of all put on stack of
current thread an address of function that would be invoked and then put
In this case we no need any other dynamic structure data. We have already
the main dynamic structure of our program *A STACK OF CURRENT THREAD !!!!!!*
Invoked function that does not support stacktrace would never know about
this additional information, only our program that would be compiled with
stacktrace support would know about this information !
*What do you think about it ? *
вПскресеМье, 31 Оюля 2016 г., 3:14:19 UTC+3 пПльзПватель ДеМОс КПтПв
Post by r***@gmail.com
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+***@isocpp.org.
To post to this group, send email to std-***@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.org.
Thiago Macieira
2016-08-07 16:21:42 UTC
Permalink
Post by Денис Котов
What if compiler would support stacktrace first of all put on stack of
current thread an address of function that would be invoked and then put
In this case we no need any other dynamic structure data. We have already
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,
instead of allocating heap memory, but it's still dynamic. This means the
application now needs a larger stack by the same amount as it would have
needed before in the heap (probably more). So you've only shifted the OOM
problem elsewhere, and to an even more difficult place to fix since it there's no
exception thrown when a stack overflow happens.

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.
--
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+***@isocpp.org.
To post to this group, send email to std-***@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.
Денис Котов
2016-08-07 19:01:03 UTC
Permalink
Post by Thiago Macieira
First of all, that's still dynamic. The information is kept on the stack,
instead of allocating heap memory, but it's still dynamic. This means the
application now needs a larger stack by the same amount as it would have
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
pushing parameters on stack for function.
And if user will compile with stack support information - then it is deal
of user !!!
Post by Thiago Macieira
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.
It is not true. Stack unwinding shown below:




When program detect exception, then in stack unwinding operation it should
copy address of invoked function like shown on picture.
If nobody caught exception or it would be caught in main function we would
be able to understand the problem in program.

вПскресеМье, 7 августа 2016 г., 19:21:47 UTC+3 пПльзПватель Thiago Macieira
Post by Thiago Macieira
Post by Денис Котов
What if compiler would support stacktrace first 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
In this case we no need any other dynamic structure data. We have
already
Post by Денис Котов
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,
instead of allocating heap memory, but it's still dynamic. This means the
application now needs a larger stack by the same amount as it would have
needed before in the heap (probably more). So you've only shifted the OOM
problem elsewhere, and to an even more difficult place to fix since it there's no
exception thrown when a stack overflow happens.
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.
--
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+***@isocpp.org.
To post to this group, send email to std-***@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.org.
Thiago Macieira
2016-08-07 22:26:22 UTC
Permalink
Post by Денис Котов
When program detect exception, then in stack unwinding operation it should
copy address of invoked function like shown on picture.
If nobody caught exception or it would be caught in main function we would
be able to understand the problem in program.
Wasn't your intention that the exception handler should have access to the
stack information? That isn't supported by your proposal.

Anyway, you're not going to get the compilers to change without a good reason.
Your argument needs to be stronger.
--
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+***@isocpp.org.
To post to this group, send email to std-***@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.
Loading...