Exception stack trace information.

[redr...@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.

[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

From: redr...@gmail.com Sent: Saturday, July 30, 2016 8:14 PM To: ISO C++ Standard - Future Proposals Reply To: std-pr...@isocpp.org Subject: [std-proposals] Exception stack trace information.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/a758ce2c-3750-4b9d-99e0-e9e1e3dcdb6d%40isocpp.org.

[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!

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.

[Thiago Macieira]

On sábado, 30 de julho de 2016 17:14:19 PDT redr...@gmail.com wrote:
> In *C++17* will be added a lot of new features, but no of them features

> improve quality of code and quickly fixing of the code.

I'm pretty sure a lot of people dispute that statement. Just look at the 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.

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

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

> *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?

> 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

[redr...@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 написал:

[Денис Котов]

> 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 написал:

[Bernd Lörwald]

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.

[Денис Котов]

Bernd Lörwald:

> 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 написал:

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

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!

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.

[Thiago Macieira]

On domingo, 31 de julho de 2016 02:57:35 PDT Денис Котов wrote:
> > 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.

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.

> 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]

On domingo, 31 de julho de 2016 03:51:53 PDT Денис Котов wrote:
> 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.

[Денис Котов]

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 написал:

[Денис Котов]

воскресенье, 31 июля 2016 г., 19:09:51 UTC+3 пользователь Thiago Macieira написал:

> On domingo, 31 de julho de 2016 02:57:35 PDT Денис Котов wrote:
> > > 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.

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

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

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

[Nicol Bolas]

On Sunday, July 31, 2016 at 12:38:26 PM UTC-4, Денис Котов wrote:

воскресенье, 31 июля 2016 г., 19:09:51 UTC+3 пользователь Thiago Macieira написал:
> On domingo, 31 de julho de 2016 02:57:35 PDT Денис Котов wrote:
> > > 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.

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

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.

[Денис Котов]

воскресенье, 31 июля 2016 г., 20:23:21 UTC+3 пользователь Nicol Bolas написал:

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++ ?

[Thiago Macieira]

On domingo, 31 de julho de 2016 09:38:25 PDT Денис Котов wrote:
> 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.

> > 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]

On domingo, 31 de julho de 2016 10:35:42 PDT Денис Котов wrote:
> 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.

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

[Nicol Bolas]

On Sunday, July 31, 2016 at 1:35:43 PM UTC-4, Денис Котов wrote:

воскресенье, 31 июля 2016 г., 20:23:21 UTC+3 пользователь Nicol Bolas написал:

On Sunday, July 31, 2016 at 12:38:26 PM UTC-4, Денис Котов wrote:

воскресенье, 31 июля 2016 г., 19:09:51 UTC+3 пользователь Thiago Macieira написал:
> On domingo, 31 de julho de 2016 02:57:35 PDT Денис Котов wrote:
> > > 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.

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

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 on).

They also have garbage collection. What's your point?

Guys has already mentioned that stack trace will be usefull,

Yes, stack traces are useful. That doesn't mean that:

1. We should standardize them in some way.

2. Every exception should bear the weight of a stack trace.

Even if you believe in #1, it's a lot harder to justify #2.

but only you do not like this idea, because you do not use it.
How can you know whether it usefull or not if you have never use this 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.

[Денис Котов]

воскресенье, 31 июля 2016 г., 21:39:58 UTC+3 пользователь Thiago Macieira написал:

By "user" - I mean programmers. Programmers is the first user of standard library.

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

[Денис Котов]

воскресенье, 31 июля 2016 г., 21:49:40 UTC+3 пользователь Nicol Bolas написал:

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

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

[Nevin Liber]

On 31 July 2016 at 13:49, Nicol Bolas <jmck...@gmail.com> wrote:

1. We should standardize them in some way.

2. Every exception should bear the weight of a stack trace.

I agree with 2.  Exceptions are not for programming errors.  Any stack tracing facility should be independent of exceptions.
--

 Nevin ":-)" Liber  <mailto:ne...@eviloverlord.com>  +1-847-691-1404

[D. B.]

On Sun, Jul 31, 2016 at 8:12 PM, Денис Котов <redr...@gmail.com> wrote:

воскресенье, 31 июля 2016 г., 21:49:40 UTC+3 пользователь Nicol Bolas написал:

> Yes, stack traces are useful. That doesn't mean that:

> 1. We should standardize them in some way.

No, we should. Please, count number of questions about stack trace on StackOverflow.
If something become so needed it is time to standardize it, otherwise we would code a class without keyword "class", but using keyword "struct" right now.
And somebody would say: "Why should we standatize keyword "class" ? "struct" is enough for long term." 

On Stack Overflow? We should be so lucky that people would know what a stack trace is. Most of them don't and ask horrible, incomplete, undiagnosable questions about the segfaults caused by their rubbishy code.

Firstly, show me these many, many questions.

Secondly, show me how they are directly aided by burdening exceptions with stack trace info, even if most exceptions don't need it.

Thirdly, please stop drawing meaningless analogies to completely unrelated other areas of the language. It doesn't promote whatever point you're trying to make.

[Thiago Macieira]

On domingo, 31 de julho de 2016 11:56:23 PDT Денис Котов wrote:
> > 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.

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.

[Денис Котов]

воскресенье, 31 июля 2016 г., 23:14:50 UTC+3 пользователь Thiago Macieira написал:

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.

[Nicol Bolas]

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?

[Денис Котов]

понедельник, 1 августа 2016 г., 2:13:42 UTC+3 пользователь Nicol Bolas написал:

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.

[Thiago Macieira]

On domingo, 31 de julho de 2016 13:41:36 PDT Денис Котов wrote:
> > 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.

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

> 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]

On domingo, 31 de julho de 2016 20:03:03 PDT Денис Котов wrote:
> > What is "Debug Mode"? I ask this question because the C++ standard does
> > not mention any such thing.
> If NDEBUG is not defined that is mean we in debug mode.

What's NDEBUG? I never set that in my programs, since I almost never need
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.

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

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

[Денис Котов]

понедельник, 1 августа 2016 г., 7:16:54 UTC+3 пользователь Thiago Macieira написал:

Could you enumerate them ? For different compilers, please ?
And how catch for different compilers stack in moment when exception was thrown ?

[Денис Котов]

понедельник, 1 августа 2016 г., 7:16:54 UTC+3 пользователь Thiago Macieira написал:

This header is Linux specific.

[Ren Industries]

Of course it is Linux specific; it has to be ABI specific. That's what everyone has been telling you.

--

You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.

To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/0b73ccc1-a873-441b-ad74-8bb44d6b28e0%40isocpp.org.

[gmis...@gmail.com]

On Sunday, July 31, 2016 at 12:14:19 PM UTC+12, Денис Котов wrote:

In C++17 will be added a lot of new features, but no of them features improve quality of code and quickly fixing of the code.
If in program exist a bug then the best that program can do is crash. Exception is a good conception for error handling, but is useless in C++ implementation, 'cause we do not know where the problem happens. That mean catching of exception is useless, because additional information is so small that better allow program simple crash.
This is the main reason that even in debug mode exception is used not often.

PROBLEM is no standard on it about providing to user backtrace.
Operation system can get stack trace when exception was used. We can implement getting stack trace even in dummy implementation by adding to every function in compile time meta information with name of this function and code that will put this name in stack object that implicitly exists from starting the program. We can add scpecial flag BACK_TRACE or BTRACE.

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. 

 

[Viacheslav Usov]

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

[Nicol Bolas]

On Monday, August 1, 2016 at 6:31:31 AM UTC-4, Viacheslav Usov wrote:

It looks like this thread started just like this one: https://groups.google.com/a/isocpp.org/forum/#!topic/std-discussion/A17G1ram9ns

To quote:

To find the root cause of bugs easier, it is very helpful to have stack trace from the location where the exception is thrown.

Surely I can throw an exception class derived from std:exception and use backtrace on Linux or StackWalk64 on Windows, with the appropriate symbols (=> not portable), 

or have a try catch "everywhere" and add file and line information (=> too much code to add), 

or not to catch the exception at all and let the Operation System write the dump file(=>not portable, some exceptions can be handled inside the program).

I thought there should be an easy portable way to add stack information to a std::exception. Does anybody have some ideas?

(end)

It then morphed into a discussion of just getting the stack trace, not necessarily in an exception context, but some of what we discussed there, in particular the separation of capture/parse functionality, is applicable in any case.

In this new thread, more than one participant have mentioned they they find it undesirable to have exceptions carry the weight of stack tracing.

This sentiment is understandable, but I have the following two points to be considered in this respect:

1. Is the performance of exception handling really an overriding concern?

... Yes!

One of the primary reasons why SG14 wants to find alternatives to exceptions for C++ errors 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.

[Wil Evers]

On Monday, August 1, 2016 at 6:16:54 AM UTC+2, Thiago Macieira wrote:

 

What's NDEBUG? I never set that in my programs, since I almost never need
them. I'm being serious, I never set them. Qt doesn't react to NDEBUG and
since all my programs are written with Qt...

No, Nicol is right: there's no such thing as "debug mode" in the standard.
Please find some other condition to enable your feature in.

You should know what NDEBUG is; it is a standard C++ feature. #defining NDEBUG disables assertions.

Given that, it seems quite reasonable to think of a build where NDEBUG is not defined as a "debug build". Even if Qt doesn't react to NDEBUG, conforming user code can.

Wil

[Viacheslav Usov]

On Mon, Aug 1, 2016 at 4:02 PM, Nicol Bolas <jmck...@gmail.com> wrote:

> One of the primary reasons why SG14 wants to find alternatives to exceptions for C++ errors 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."

[Tom Honermann]

On 8/1/2016 6:31 AM, Viacheslav Usov wrote:
> 2. Is it true that "the weight of stack tracing" is really that much
> weight to carry? Modern C++ implementations essentially just need only
> the instruction pointer to describe fully where the exception
> originated[2, 3]. Compared to the cost of unwinding the stack in those
> implementations, the cost of storing just one pointer in the exception
> structure seems strictly negligible.

How would you make use of the pointer stored in the exception
structure? It will have been invalidated once a catch handler starts
executing as the stack will have been unwound already. Likewise,
attempts to use it during stack unwinding (e.g., from a destructor) are
similarly nonviable. Making use of it would require additional features
analogous to exception filters as provided by Microsoft's Structured
Exception Handling (SEH) so that it can be queried and used prior to
stack unwinding.

Tom.

[Viacheslav Usov]

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.

[Nicol Bolas]

And the primary reason "most existing game code fits in this second category" is because of the first category.

[Tom Honermann]

On 7/31/2016 2:49 AM, redr...@gmail.com wrote:
> I have prepared my first proposal. Please, dont bit hard for missing
> details.
> You can find it in attachment.

Regarding implementability in section V: StackWalk64 and Linux
backtrace() do not constitute a proof-of-concept implementation since
they don't actually implement the interface you proposed.

I do think a standard method of obtaining a stack trace would be
useful. I've worked on multiple products that have rolled their own and
the results have not been very good. The most successful approach
involved the process spawning a debugger to run a script to attach back
to itself to produce a stack trace. In this case, the desire for a
stack trace was only present when the process was going to terminate
anyway, so the (high) performance cost of spawning a debugger was
acceptable.

There are many ABI specific details that make obtaining a stack trace
range from difficult to impossible depending on how you define what a
valid stack trace is. On x86, if you compile with frame pointer
omission, you're not going to get a useful stack trace. On Windows, if
you don't have the right debug symbols available (which you won't in a
production environment), you're not going to get a useful stack trace
(you might get one that you can later use to reconstruct a useful stack
trace later when debug symbols are available). When functions are
inlined by the compiler, or functions use tail recursion, then you're
going to have missing frames in your stack trace which will make them
look invalid (even though they aren't). Assuming an implementation
based on Microsoft's StackWalk64 with an environment properly configured
for debug symbols, construction of a useful stack trace will require
connecting to Microsoft's symbol server, possibly accepting an EULA (I'm
not joking, that is required today), downloading symbol (.pdb) files
somewhere, loading them into the process, and then, finally, walking the
stack.

I think tying a stack trace to the C++ exception system is a non-starter
without some ability to execute code without first unwinding the stack.
See my other response to Viacheslav Usov.

Finally, if you do want to propose a standard interface for walking the
stack and/or producing a stack trace, I recommend you survey many more
platforms before coming back with a proposal (and include evaluations of
the capabilities of those platforms). The libunwind variants provide
the most comprehensive cross platform stack walking support I've seen,
so basing the interface on what is provided by them seems like a good
starting place.

Tom.

[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?

Tom.

[Viacheslav Usov]

On Mon, Aug 1, 2016 at 4:45 PM, Nicol Bolas <jmck...@gmail.com> wrote:

> And the primary reason "most existing game code fits in this second category" is because of the first category.

You have some very special idea on the meaning of "primary". The document talks at length how exceptions are difficult for exception-unaware code and how making code exception aware is such an impossible task; how the exception support data/code bloats the application and interacts badly with the branch predictor. Your "primary reason" is mentioned in passing.

Cheers,

V.

[Thiago Macieira]

On segunda-feira, 1 de agosto de 2016 07:19:23 PDT Wil Evers wrote:
> You should know what NDEBUG is; it is a standard C++ feature. #defining
> NDEBUG disables assertions.

I was slightly exagerating my ignorance. But it has happened, more than once,
that I see assert() left in my release code until I remember that I needed to
set it.

> Given that, it seems quite reasonable to think of a build where NDEBUG is
> not defined as a "debug build". Even if Qt doesn't react to NDEBUG,
> conforming user code can.

We could have inline features and other macros that react to NDEBUG. But that
can't affect code generation by the compiler.

We could have the opposite though: compiler switches that affect code
generation get a predefined macro added or suppressed.

[Thiago Macieira]

On domingo, 31 de julho de 2016 21:26:58 PDT Денис Котов wrote:
> понедельник, 1 августа 2016 г., 7:16:54 UTC+3 пользователь 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.

[Viacheslav Usov]

On Mon, Aug 1, 2016 at 4:52 PM, Tom Honermann <t...@honermann.net> wrote:

> So, you would require dynamic memory allocation, or require a thread specific statically sized buffer (multiple buffers actually since exceptions can nest) that limits the number of supported frames, in order to throw an exception?

Memory allocation for exception objects is already explicitly unspecified by [except.throw], so discussing this further would be discussing how a hypothetical implementation could optimise that. Are we going to achieve anything substantial by going there?

Cheers,

V.

[Thiago Macieira]

On domingo, 31 de julho de 2016 23:54:11 PDT gmis...@gmail.com wrote:
> If this means someone could configure a program to get a basic stack trace
> on program failure and also be able to dump that on demand and all without
> having to know anything special about the platform or compiler or debug
> options and without a lot of stress on vendors to power it, what's so
> unreasonable?

You know what could be a reasonable suggestion:

a) add a function std::dump_backtrace, whose behaviour is suggested by the
standard, but a compliant implementation could simply do nothing.

b) let the user do:
std::set_terminate_handler(std::dump_backtrace);

Note that this won't catch Unix signals, like SIGSEGV or SIGABRT. If you want
that, you should instead use signal(2) or sigaction(2). That will also catch
uncaught exceptions, since the termination handler usually raises SIGABRT.

[Thiago Macieira]

On segunda-feira, 1 de agosto de 2016 10:46:02 PDT Tom Honermann wrote:
> I've worked on multiple products that have rolled their own and
> the results have not been very good. The most successful approach
> involved the process spawning a debugger to run a script to attach back
> to itself to produce a stack trace.

Off-topic, but explaining:

That's because the backtrace() function in <execinfo.h> only reads the symbol
table that is avaialble to the dynamic linker. That table lacks completely the
symbols from the executable, as nothing usually links to the executable, and
all the internal functions (static and hidden visibility).

The debugger, on the other hand, reads the debug symbols, which on modern
Linux distros, are not contained in the libraries themselves, but in a
separate file in /usr/lib/debug. Or, in the case of Microsoft debuggers, it can
also download the symbol tables from Microsoft servers. Moreover, debugger-
produced backtraces are superior because they often contain the values of
local variables and parameters to functions, file names and line numbers.

I have solved numerous problems just by following the value of "this" in the
parameter list, or by noticing pointer values that shouldn't exist.

[Thiago Macieira]

On segunda-feira, 1 de agosto de 2016 07:54:36 PDT
loic.act...@numericable.fr wrote:
> - It is easy to implement, since a compiler could just return an empty
> string, everything else being a question of QOI.

Then someone should write a paper that standardises <execinfo.h> or something
very similar to it.

[Tom Honermann]

On 8/1/2016 11:40 AM, Viacheslav Usov wrote:

On Mon, Aug 1, 2016 at 4:52 PM, Tom Honermann <t...@honermann.net> wrote:

> So, you would require dynamic memory allocation, or require a thread specific statically sized buffer (multiple buffers actually since exceptions can nest) that limits the number of supported frames, in order to throw an exception?

Memory allocation for exception objects is already explicitly unspecified by [except.throw], so discussing this further would be discussing how a hypothetical implementation could optimise that.

Yes, but today, the amount of memory required for the exception object is statically knowable.  That would no longer be true if the depth of the stack at the point of the throw were a consideration.

Are we going to achieve anything substantial by going there?

Probably not.

Tom.

[Viacheslav Usov]

On Mon, Aug 1, 2016 at 6:24 PM, Tom Honermann <t...@honermann.net> wrote:

> Yes, but today, the amount of memory required for the exception object is statically knowable.

True, but at least one major implementation does not seem to use that and allocates memory dynamically anyway [1, 2, search for __cxa_allocate_exception in both].

Cheers,

V.

[1] https://monoinfinito.wordpress.com/series/exception-handling-in-c/

[2] https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/libsupc%2B%2B/eh_alloc.cc

[Tom Honermann]

On 8/1/2016 11:51 AM, Thiago Macieira wrote:
> On segunda-feira, 1 de agosto de 2016 10:46:02 PDT Tom Honermann wrote:
>> I've worked on multiple products that have rolled their own and
>> the results have not been very good. The most successful approach
>> involved the process spawning a debugger to run a script to attach back
>> to itself to produce a stack trace.
> Off-topic, but explaining:
>
> That's because the backtrace() function in <execinfo.h> only reads the symbol
> table that is avaialble to the dynamic linker. That table lacks completely the
> symbols from the executable, as nothing usually links to the executable, and
> all the internal functions (static and hidden visibility).

In our case, that isn't why. We weren't using backtrace(), we really
rolled our own. But yes, the absence of debug info makes generation of
a useful stack trace effectively impossible for some ABIs.

Tom.

[Tom Honermann]

On 8/1/2016 12:27 PM, Viacheslav Usov wrote:

On Mon, Aug 1, 2016 at 6:24 PM, Tom Honermann <t...@honermann.net> wrote:

> Yes, but today, the amount of memory required for the exception object is statically knowable.

True, but at least one major implementation does not seem to use that and allocates memory dynamically anyway [1, 2, search for __cxa_allocate_exception in both].

The signature for that function follows.  Note that it is invoked with the statically known size.  Yes, in this case, it could then compute additional storage required for the stack and add that to the allocation request without (I think) an ABI change.  But do you really want to require that of all ABIs?  I'm willing to bet some could not accommodate that change without an ABI change.

void* __cxa_allocate_exception(size_t thrown_size)

Cheers,

V.

[1] https://monoinfinito.wordpress.com/series/exception-handling-in-c/

[2] https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/libsupc%2B%2B/eh_alloc.cc

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.

To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg2iON%2BcuqzWkN%3DCQVz5x9_iAEako_SmxCD48GMh6GSxbA%40mail.gmail.com.

[Viacheslav Usov]

On Mon, Aug 1, 2016 at 6:38 PM, Tom Honermann <t...@honermann.net> wrote:

> The signature for that function follows.  Note that it is invoked with the statically known size.

Your earlier argument was about the need for dynamic allocation, which I interpreted as if you had thought that existing implementations could dispense with that. I mentioned that was unspecified by the standard, and I have demonstrated that at least one major implementation does perform dynamic memory allocation when an exception is thrown.

I am not really sure what you argument is now. Is it about that more than one dynamic memory allocation may be required? But many, if not all, standard exception classes would need that, too, because they have to hold arbitrary strings passed into their constructors. So is it now three allocations vs two? I'm pretty sure the implementation could trivially collapse subsequent memory allocations into one, but even if we assume they are dumb, is that really a deal breaker at this stage?

Cheers,

V.

[Bjorn Reese]

On 08/01/2016 05:51 PM, Thiago Macieira wrote:

> That's because the backtrace() function in <execinfo.h> only reads the symbol

Bringing it slightly back on-topic, there seems to be two fundamentally
different solutions.

The first solution is to extract the call stack frames via some kind of
platform-dependent functionality (whether that is backtrace() or
attaching a debugger as described in the comp.unix.programmer FAQ
section 6.5.)

The second solution is to let the C++ compiler annotate the code with
information that can be collected and displayed.

The suggestions in this forum (both in this and earlier threads) have
mainly been about the annotation solution.

The discussions on the Boost mailing-list about a portable stack trace
library have been about the extraction solution:

http://lists.boost.org/Archives/boost/2016/06/230264.php

[Tom Honermann]

On 8/1/2016 12:49 PM, Viacheslav Usov wrote:

On Mon, Aug 1, 2016 at 6:38 PM, Tom Honermann <t...@honermann.net> wrote:

> The signature for that function follows.  Note that it is invoked with the statically known size.

Your earlier argument was about the need for dynamic allocation, which I interpreted as if you had thought that existing implementations could dispense with that. I mentioned that was unspecified by the standard, and I have demonstrated that at least one major implementation does perform dynamic memory allocation when an exception is thrown.

I do think that existing implementations can dispense with dynamic allocation, at least for non-nested exceptions.  Such implementations would necessarily dynamically allocate for copying an exception object to satisfy lifetime requirements for std::current_exception(), so I do accept that dynamic allocation is required in some cases.  The fact that one implementation unconditionally uses dynamic allocation does not imply that they all do.

I am not really sure what you argument is now.

My initial response was to your claim that the cost overhead of including the stack trace for exception objects is negligible.  I claim that it may not be; that some ABIs may require changes to support a dynamically dependent allocation size.  I don't know of any particular ABIs that would require changes.

Is it about that more than one dynamic memory allocation may be required? But many, if not all, standard exception classes would need that, too, because they have to hold arbitrary strings passed into their constructors. So is it now three allocations vs two? I'm pretty sure the implementation could trivially collapse subsequent memory allocations into one, but even if we assume they are dumb, is that really a deal breaker at this stage?

There is a distinction between dynamic allocation performed by the constructor of a thrown object vs the allocation for the thrown object itself.

Tom.

[Денис Котов]

понедельник, 1 августа 2016 г., 17:02:23 UTC+3 пользователь Nicol Bolas написал:

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.

[Денис Котов]

понедельник, 1 августа 2016 г., 20:27:23 UTC+3 пользователь Bjorn Reese написал:

This will be little-bit hard to implement and get a consistent look on different platforms.

> The second solution is to let the C++ compiler annotate the code with
> information that can be collected and displayed.

This one is pretty good too. Maybe it is the better solution, in this case we will have the same behavior on different platforms.
 

[Thiago Macieira]

On segunda-feira, 1 de agosto de 2016 19:28:38 PDT Bjorn Reese wrote:
> Bringing it slightly back on-topic, there seems to be two fundamentally
> different solutions.
>
> The first solution is to extract the call stack frames via some kind of
> platform-dependent functionality (whether that is backtrace() or
> attaching a debugger as described in the comp.unix.programmer FAQ
> section 6.5.)
>
> The second solution is to let the C++ compiler annotate the code with
> information that can be collected and displayed.

It would be nice if this information were out-of-line, stored in sections of
the file that weren't loaded at all during normal conditions. Since this isn't
loaded, it can contain a lot more detailed information, such as file names and
line numbers, location of variables, their names and types, etc.

This exists and is called "debug symbols".

So, no, I don't think we're talking about two different solutions.

> The suggestions in this forum (both in this and earlier threads) have
> mainly been about the annotation solution.
>
> The discussions on the Boost mailing-list about a portable stack trace
> library have been about the extraction solution:
>
> http://lists.boost.org/Archives/boost/2016/06/230264.php

That's basically standardising the backtrace() function from <execinfo.h> in a
C++ form. I suggest that if we do this, we start with C functions that the C
committee could adopt. A C++ wrapper might be nice, but it's not required.

[Wil Evers]

On Monday, August 1, 2016 at 5:34:11 PM UTC+2, Thiago Macieira wrote:

On segunda-feira, 1 de agosto de 2016 07:19:23 PDT Wil Evers wrote:
> You should know what NDEBUG is; it is a standard C++ feature. #defining
> NDEBUG disables assertions.

I was slightly exagerating my ignorance. But it has happened, more than once,
that I see assert() left in my release code until I remember that I needed to
set it.

Sounds like you need to fix your build system. Since the effect of NDEBUG is defined in the standard, I would expect any build system, on any platform, do #define NDEBUG in release builds, it it makes such a distinction. If it doesn't, you have more serious problems to worry about.

> Given that, it seems quite reasonable to think of a build where NDEBUG is
> not defined as a "debug build". Even if Qt doesn't react to NDEBUG,
> conforming user code can.

We could have inline features and other macros that react to NDEBUG. But that
can't affect code generation by the compiler.

Huh?  The point of NDEBUG is to generate *different code* in different build configurations.

We could have the opposite though: compiler switches that affect code
generation get a predefined macro added or suppressed.

How would that differ from what NDEBUG currently has to offer?

Wil

[Thiago Macieira]

On segunda-feira, 1 de agosto de 2016 12:13:10 PDT Wil Evers wrote:
> On Monday, August 1, 2016 at 5:34:11 PM UTC+2, Thiago Macieira wrote:
> Sounds like you need to fix your build system. Since the effect of NDEBUG
> is defined in the standard, I would expect any build system, on any
> platform, do #define NDEBUG in release builds, it it makes such a
> distinction. If it doesn't, you have more serious problems to worry about.

I disagree. The standard only talks about assert.h, not other features. That
has nothing to do with release mode and debug mode. And maybe I want
assertions left in my code, even in release mode, so automatically doing it is
not a good idea.

The buildsystem should be agnostic and not define things I don't want it to.
And besides, in a Qt-centric buildsystem (like qmake), it would define
QT_NO_DEBUG, not NDEBUG.

> > > Given that, it seems quite reasonable to think of a build where NDEBUG
> >
> > is
> >
> > > not defined as a "debug build". Even if Qt doesn't react to NDEBUG,
> > > conforming user code can.
> >
> > We could have inline features and other macros that react to NDEBUG. But
> > that
> > can't affect code generation by the compiler.
>
> Huh? The point of NDEBUG is to generate *different code* in different
> build configurations.

And so is QT_NO_DEBUG, QT_NO_DEBUG_OUTPUT, QT_FORCE_ASSERTS,
QT_NO_CAST_FROM_ASCII, QT_NO_CAST_TO_ASCII, and many other flags.

My point is the compiler reacting to NDEBUG is putting the cart ahead of the
oxen. In a traditional compiler, the compiler doesn't see the code until it's
been fully preprocessed, so it can't react to a macro being defined or not. The
macro can expand to different code that you could call, but it can't change my
generic function that didn't use the macro.

At worst, someone could #define throw and do something "evil" with it, to
accomplish what was discussed.

I would advise instead for a #pragma.

> > We could have the opposite though: compiler switches that affect code
> > generation get a predefined macro added or suppressed.
>
> How would that differ from what NDEBUG currently has to offer?

Cart ahead of the oxen.

For example, the -O option with any value except 0 with GCC causes the
__OPTIMIZE__ macro to be defined. But defining or undefinining it in my code will
not change how the compiler generates code. Same for __i386__, __x86_64__,
__SSE2__, __SSE_MATH__, etc.

"#pragma GCC optimize" and "#pragma GCC target" do change how the compiler
generates code, like their equivalent __attribute__ attributes do.

[Patrice Roy]

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 :)

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.

To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4176746.l6UKp6CGP7%40tjmaciei-mobl1.

[Wil Evers]

On Monday, August 1, 2016 at 9:38:34 PM UTC+2, Thiago Macieira wrote:

On segunda-feira, 1 de agosto de 2016 12:13:10 PDT Wil Evers wrote:
> On Monday, August 1, 2016 at 5:34:11 PM UTC+2, Thiago Macieira wrote:
> Sounds like you need to fix your build system. Since the effect of NDEBUG
> is defined in the standard, I would expect any build system, on any
> platform, do #define NDEBUG in release builds, it it makes such a
> distinction. If it doesn't, you have more serious problems to worry about.

I disagree. The standard only talks about assert.h, not other features. That
has nothing to do with release mode and debug mode. And maybe I want
assertions left in my code, even in release mode, so automatically doing it is
not a good idea.

You were complaining about your build system not disabling assertions when you expected it to. To me, that still sounds like a problem in your build system.

That said, I agree that it should allow for an override to enable (standard) assertions in release mode (possibly for a specific set of source files), but only when explicitly told  to do so. 

 

The buildsystem should be agnostic and not define things I don't want it to.
And besides, in a Qt-centric buildsystem (like qmake), it would define
QT_NO_DEBUG,  not NDEBUG.

Qt is not the standard. The standard only talks about the NDEBUG macro. If Qt ignores its intended usage, then that's a compliance issue, among a few others, with Qt.

[snip]

> The point of NDEBUG is to generate *different code* in different
> build configurations.

And so is QT_NO_DEBUG, QT_NO_DEBUG_OUTPUT, QT_FORCE_ASSERTS,
QT_NO_CAST_FROM_ASCII, QT_NO_CAST_TO_ASCII, and many other flags.

Interesting, but irrelevant as far as standard conformance is concerned.

[snip]

Wil

[gmis...@gmail.com]

Hi Thiagp

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.

[Thiago Macieira]

On segunda-feira, 1 de agosto de 2016 13:17:39 PDT Wil Evers wrote:
> > The buildsystem should be agnostic and not define things I don't want it
> > to.
> > And besides, in a Qt-centric buildsystem (like qmake), it would define
> > QT_NO_DEBUG, not NDEBUG.
>
> Qt is not the standard. The standard only talks about the NDEBUG macro. If
> Qt ignores its intended usage, then that's a compliance issue, among a few
> others, with Qt.

The standard does not say anything about NDEBUG except in connection to the
assert macro's behaviour ([assertions.assert], [using.headers] and in a note
in [dcl.attr.unused]). From the point of view of the standard, the NDEBUG
macro is exclusively related to NDEBUG.

Therefore, I can argue that using it for anything besides that would be wrong
and, therefore, Qt creating its own macro is more standards-compliant than
other code that reacts to NDEBUG. (Though I'm not going to)

What I will argue is that a library that is not the Standards Library is, by
the very definition, not part of the Standard. It needs to be written compliant
with the core language standard and using the Standard Library in a compliant
manner, but that library itself is never subject to the standard. Therefore,
talking about a "standard-compliant non-standard library" is nonsensical.

[Thiago Macieira]

On segunda-feira, 1 de agosto de 2016 15:34:41 PDT gmis...@gmail.com wrote:
> > a) add a function std::dump_backtrace, whose behaviour is suggested by the
> > standard, but a compliant implementation could simply do nothing.
> >
> > b) let the user do:
> > std::set_terminate_handler(std::dump_backtrace);

> a) is exactly what I was proposing.
>
> b) would come under what I referred to as spicing things up. But I agree.
>
> But to elaborate I purposely didn't dig into b) yet - spicing things up
> - because I wanted to avoid people using it to prove that a minimum viable
> product was not possible. Because I think it is and the start of this
> thread was beginning to go like most of the threads on here go with people
> saying "oh that's not possible" because they are overly focusing on what
> people say rather than helping them achieve what they are trying to achieve
> or inching towards their goal.

That's not how I read it. This thread started talking about exceptions and
adding stack frame information to the exceptions, which adds cost and violates
the "don't pay for what you don't use" rule. Adding the function above has
nothing to do with exceptions and doesn't add cost if you don't ever use it.
Moreover, it's based on existing practice, tested and tried.

> I know everyone has bad days (me too) but I'd generally like to see this
> forum adopt a more nurturing tone to posters. I think that starts by more
> people embracing the concept that you can nurture an idea without having to
> adopt it, nor kill it or even agree with it. And not getting overly tied up
> nit picking too early. Perhaps it's like interviewing with the style of
> helping people find out what people know by giving them the answers to what
> they don't know instead of just going "ding, wrong answer, you fired" at
> the first hurdle.

You mean the OP that contained many factually incorrect statements and
insulted to the intelligence of the people in this list and the committee
members?

"In *C++17* will be added a lot of new features, but no of them features
improve quality of code and quickly fixing of the code."

"Exception is a good conception for error handling, but is useless in C++
implementation"

"This is the main reason that even in debug mode exception is used not often."

"In we can implement *backtrace*, but are thinking about coroutine. Without
strong *base *we cannot implement something good." (implies that the base
isn't strong and that coroutines are not good)

[gmis...@gmail.com]

On Tuesday, August 2, 2016 at 11:39:56 AM UTC+12, Thiago Macieira wrote:

On segunda-feira, 1 de agosto de 2016 15:34:41 PDT gmis...@gmail.com wrote:
> > a) add a function std::dump_backtrace, whose behaviour is suggested by the
> > standard, but a compliant implementation could simply do nothing.
> >
> > b) let the user do:
> >         std::set_terminate_handler(std::dump_backtrace);

> a) is exactly what I was proposing.
>
> b) would come under what I referred to as spicing things up. But I agree.
>
> But to elaborate I purposely didn't dig into b) yet - spicing things up
> - because I wanted to avoid people using it to prove that a minimum viable
> product was not possible. Because I think it is and the start of this
> thread was beginning to go like most of the threads on here go with people
> saying "oh that's not possible" because they are overly focusing on what
> people say rather than helping them achieve what they are trying to achieve
> or inching towards their goal.

That's not how I read it. This thread started talking about exceptions and
adding stack frame information to the exceptions, which adds cost and violates
the "don't pay for what you don't use" rule. Adding the function above has
nothing to do with exceptions and doesn't add cost if you don't ever use it.
Moreover, it's based on existing practice, tested and tried.

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

> 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?

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.

 

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

[Thiago Macieira]

On segunda-feira, 1 de agosto de 2016 19:22:35 PDT gmis...@gmail.com wrote:
> FWIW, I do agree the OP was not appreciating how uncharitable he was
> sounding with his C++17 comments, but I chose to overlook that so it didn't
> detract him from his goal. I personally think C++17 is exactly what it
> should be so I'm elated with it. I got what I thought was ready and didn't
> get what I wasn't sure about. And I did get some nice surprises. The OP may
> be somewhat correct that his areas of interest didn't get much love, I
> don't know, but hey now's the chance to address that. But I love C++17's
> new if statements and it's new guarantees. I'm just keen to see
> the momentum sustained.

I'm not so kind, as you can see from my first reply to the OP.

There are a few people who have earned the right to be uncharitable. A few
others have earned the make sarcastic or ironic comments.

An unknown person in this list has not earned those rights yet. If you start
by insulting, intentionally or not, people will be on the defensive. It's up
to the poster to either prove the credentials or have the humility to admit
where gaps in his/her knowledge may exist.

And yes, technical discussion to this level often requires a good command of
English. Sorry, that's reality.

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

Wil
 

[Thiago Macieira]

On segunda-feira, 1 de agosto de 2016 23:12:06 PDT Wil Evers wrote:
> I would argue that a library or build system that ignores common practice
> backed by a standard specification is harder to use than it need be.

What common practice? Like I said, NDEBUG is only used for assert.h. Aside
from that, I see absolutely zero uses in the standard C or C++ libraries, in
glibc as a whole (so, POSIX and GNU extensions), and a couple of uses in
sqlite3.h, eigen3, plus google log, test, and protobuf. That hardly looks like
common practice to me.

[Wil Evers]

On Tuesday, August 2, 2016 at 8:35:32 AM UTC+2, Thiago Macieira wrote:

On segunda-feira, 1 de agosto de 2016 23:12:06 PDT Wil Evers wrote:
> I would argue that a library or build system that ignores common practice
> backed by a standard specification is harder to use than it need be.

What common practice? Like I said, NDEBUG is only used for assert.h. Aside
from that, I see absolutely zero uses in the standard C or C++ libraries, in
glibc as a whole (so, POSIX and GNU extensions), and a couple of uses in
sqlite3.h, eigen3, plus google log, test, and protobuf. That hardly looks like
common practice to me.

NDEBUG is used all over the place, even when you don't see it. Every direct or indirect call to the standard assert macro depends on the presence or absence of a definition for NDEBUG. Are you arguing that using assert is not common practice? I give up.

Wil

[Reza Jahanbakhshi]

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.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.

To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/a0969adb-38b1-450c-b4b7-2c5cf3bef4db%40isocpp.org.

[Matthew Woehlke]

On 2016-08-01 19:33, Thiago Macieira wrote:
> On segunda-feira, 1 de agosto de 2016 13:17:39 PDT Wil Evers wrote:
>> Qt is not the standard. The standard only talks about the NDEBUG macro. If
>> Qt ignores its intended usage, then that's a compliance issue, among a few
>> others, with Qt.
>
> The standard does not say anything about NDEBUG except in connection to the
> assert macro's behaviour ([assertions.assert], [using.headers] and in a note
> in [dcl.attr.unused]). From the point of view of the standard, the NDEBUG
> macro is exclusively related to NDEBUG.

> [...]

> What I will argue is that a library that is not the Standards Library is, by
> the very definition, not part of the Standard. It needs to be written compliant
> with the core language standard and using the Standard Library in a compliant
> manner, but that library itself is never subject to the standard. Therefore,
> talking about a "standard-compliant non-standard library" is nonsensical.

I'll throw in another point here... maybe I want debugging stuff (e.g.
asserts) in my application *but not in the libraries I use* (e.g. Qt).

In fact, I will throw out a specific example: Python. Python has this
"wonderful" notion of providing a different ABI for debug and release
modes, but they also have a philosophical objection to providing debug
libraries. This means that the only (sane) way to build your
Python-using application with full debugging (i.e. not defining NDEBUG)
*is to also build Python yourself*.

This is sheer idiocy that does nothing but make developers' lives
harder, and I *applaud* Qt for not making the same boneheaded mistake.
If Python had done the *rational* thing and used some other symbol to
decide if Python itself has debugging enabled (like Qt's QT_NO_DEBUG),
this problem wouldn't exist.

So, please, drop this silly notion that the entire world must use the
exact same symbol to determine if debugging is enabled or not. Doing so
is unnecessarily restrictive, at best.

--
Matthew

[Viacheslav Usov]

On Mon, Aug 1, 2016 at 7:45 PM, Tom Honermann <t...@honermann.net> wrote:

> I do think that existing implementations can dispense with dynamic allocation, at least for non-nested exceptions.

As I indicated earlier, this moves the discussion into a hypothetical domain. If you think it acceptable to postulate that some implementations dispense with dynamic allocation through the use of magic allocation, then I could equally think it acceptable to postulate magic exceptions that need no memory allocation at all to capture a stack trace. I do not think either postulate is ultimately convincing.

Just to stay in the real domain, your postulate is true for one major implementation, and mine can also be true for the same implementation. It is MSVC, on the AMD64 architecture at least, where the underlying hardware stack (as opposed to the abstract machine's stack) is not unwound till an exception is fully handled (i.e., a catch clause exits normally), and the exception object is constructed on the stack. I cannot reference my sources, but this can be easily confirmed with a debugger.

Since the entire stack is present till exception handling is fully complete, it can be captured directly without any intermediate allocations.

>  Such implementations would necessarily dynamically allocate for copying an exception object to satisfy lifetime requirements for std::current_exception(), so I do accept that dynamic allocation is required in some cases.

In which case an implementation can just have a statically-sized list that handles "most common cases", and an overflow list that handles everything else. Then your acceptance criterion is trivially met.

>  There is a distinction between dynamic allocation performed by the constructor of a thrown object vs the allocation for the thrown object itself.

Does dynamic allocation solely in the constructor of a thrown object meet your criteria? This can, again, be trivially accomplished for a variable-length list of pointers.

Cheers,

V.

[Wil Evers]

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

[Reza Jahanbakhshi]

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.

[Thiago Macieira]

On terça-feira, 2 de agosto de 2016 00:18:15 PDT Wil Evers wrote:
> NDEBUG is used all over the place, even when you don't see it. Every 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.

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

[Thiago Macieira]

On terça-feira, 2 de agosto de 2016 16:20:44 PDT Reza Jahanbakhshi wrote:
> 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]

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.

[Tom Honermann]

On 8/2/2016 9:42 AM, Viacheslav Usov wrote:

On Mon, Aug 1, 2016 at 7:45 PM, Tom Honermann <t...@honermann.net> wrote:

> I do think that existing implementations can dispense with dynamic allocation, at least for non-nested exceptions.

As I indicated earlier, this moves the discussion into a hypothetical domain. If you think it acceptable to postulate that some implementations dispense with dynamic allocation through the use of magic allocation, then I could equally think it acceptable to postulate magic exceptions that need no memory allocation at all to capture a stack trace. I do not think either postulate is ultimately convincing.

All I am saying is that there *may* be ABIs that would require changes to accommodate this feature.  Thus, the price of the feature includes potential ABI impact.  Likewise, there is clearly some performance cost to walking the stack to collect information for each frame, thus, there would likely be some performance cost to existing code.  Perhaps it would be negligible, but it should be measured.

Rather than collecting a stack trace for every exception thrown, an alternative approach would be to define a base exception class (std::exception_with_backtrace) that captures the call stack in its constructor.  This would enable capturing a stack trace when desired without imposing an additional cost on all exceptions.  The downside of this approach, of course, is that it places the onus of throwing an exception with such support on the thrower rather than on the catcher (who is in a better position to determine if the trace is desired).

Just to stay in the real domain, your postulate is true for one major implementation, and mine can also be true for the same implementation. It is MSVC, on the AMD64 architecture at least, where the underlying hardware stack (as opposed to the abstract machine's stack) is not unwound till an exception is fully handled (i.e., a catch clause exits normally), and the exception object is constructed on the stack. I cannot reference my sources, but this can be easily confirmed with a debugger.

Since the entire stack is present till exception handling is fully complete, it can be captured directly without any intermediate allocations.

I wasn't aware of that.  I took very brief look at some disassembly and it looks like MSVC restores the frame base pointer before executing the catch handler (and uses a frame base pointer even if compiled with /Oy), but doesn't restore the stack pointer.  In theory, an implementation that does this could delay capturing the stack until/unless it is actually requested (or std::current_exception() is called).

>  Such implementations would necessarily dynamically allocate for copying an exception object to satisfy lifetime requirements for std::current_exception(), so I do accept that dynamic allocation is required in some cases.

In which case an implementation can just have a statically-sized list that handles "most common cases", and an overflow list that handles everything else. Then your acceptance criterion is trivially met.

>  There is a distinction between dynamic allocation performed by the constructor of a thrown object vs the allocation for the thrown object itself.

Does dynamic allocation solely in the constructor of a thrown object meet your criteria? This can, again, be trivially accomplished for a variable-length list of pointers.

To be clear, the only reason I brought this up was because of potential impact to existing ABIs.  The dynamic allocation isn't something I'm actually concerned about.

Tom.

[Viacheslav Usov]

On Tue, Aug 2, 2016 at 5:05 PM, Tom Honermann <t...@honermann.net> wrote:

> Rather than collecting a stack trace for every exception thrown, an alternative approach would be to define a base exception class (std::exception_with_backtrace) that captures the call stack in its constructor.  This would enable capturing a stack trace when desired without imposing an additional cost on all exceptions.  The downside of this approach, of course, is that it places the onus of throwing an exception with such support on the thrower rather than on the catcher (who is in a better position to determine if the trace is desired).

That would essentially make all exceptions thrown by the standard library untraceable, and I think this is exactly the wrong thing to do.

Here is another idea: we can have something like std::trace_current_exception, with semantics similar to that of std::current_exception. The downside is that with this one cannot store just an exception and get its stack trace later, the stack trace would need to be dealt with when storing the exception.

Cheers,

V.

[Reza Jahanbakhshi]

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.

[Денис Котов]

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 пользователь Денис Котов написал:

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.

[gmis...@gmail.com]

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.

[Viacheslav Usov]

On Wed, Aug 3, 2016 at 10:22 AM, <gmis...@gmail.com> wrote:

> I can imagine a world without exceptions or where they are turned off but you might still want to dump the call stack on an error situation that isn't even in an exception state.

This has already been discussed in this and the previous thread(s). My personal understanding is that we need a couple of classes or functions, not bound with exceptions or exception pointers.

1. std::current_stack_trace. This gets the stack trace at its invocation point.

2. std::exception_stack_trace. This gets the stack trace at the throw point of the currently handled exception (semantics similar to std::current_exception).

As discussed earlier, both return information in an implementation-defined format, which is not necessarily human-readable without an extra translation step; this covers the case when symbolic information is not available at runtime.

Cheers,

V.

[gmis...@gmail.com]

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.

[Matthew Woehlke]

On 2016-08-03 04:22, gmis...@gmail.com wrote:
> I can imagine a world without exceptions or where they are turned off but
> you might still want to dump the call stack on an error situation that
> isn't even in an exception state.

I can imagine a world where you might want to dump a stack trace as part
of routine logging :-). Pretty sure I've done that, in fact.

(Another thing I *know* I've done at one point is implement "poor man's
valgrind", i.e. I collect my own stack traces on memory allocations and
*possibly* use them to help track down errors such as double-frees or
leaks. Most of the collected traces are never used in any meaningful
way. So, yes, there are most definitely reasons to want to collect a
stack trace - and in particular, one which has not had address to symbol
resolution performed yet - outside of exceptions.)

--
Matthew

[Matthew Woehlke]

On 2016-07-30 20:14, redr...@gmail.com wrote:
> In *C++17* will be added a lot of new features, but no of them features

> improve quality of code and quickly fixing of the code.
> If in program exist a bug then the best that program can do is crash.
> Exception is a good conception for error handling, but is useless in C++
> implementation, 'cause we do not know where the problem happens. That mean
> catching of exception is useless, because additional information is so
> small that better allow program simple crash.
> This is the main reason that even in debug mode exception is used not often.
>

> *PROBLEM *is no standard on it about providing to user *backtrace*.

> Operation system can get stack trace when exception was used. We can
> implement getting stack trace even in dummy implementation by adding to
> every function in compile time meta information with name of this function
> and code that will put this name in stack object that implicitly exists

> from starting the program. We can add scpecial flag *BACK_TRACE* or *BTRACE*
> .

Didn't we have this conversation already?

https://groups.google.com/a/isocpp.org/forum/#!topic/std-discussion/A17G1ram9ns

Yup, there it is...

--
Matthew

[loic.act...@numericable.fr]

---- Message d'origine ----
De : "Thiago Macieira" <thi...@macieira.org>

On domingo, 31 de julho de 2016 20:03:03 PDT Денис Котов wrote:
> > > What is "Debug Mode"? I ask this question because the C++ standard does
> > > not mention any such thing.
> > If NDEBUG is not defined that is mean we in debug mode.
>
> What's NDEBUG? I never set that in my programs, since I almost never need
> them. I'm being serious, I never set them. Qt doesn't react to NDEBUG and
> since all my programs are written with Qt...

NDEBUG is defined in the C standard and is referenced in the C++ standard (17.6.2.2). It
modifies the meaning of the <cassert> header.
You may not use it, but it exists nevertheless. Just like my never having used
gslice_array does not mean it does not exist.
 
[...]
> This is useful, but the feature already exists.

Which is a very good reason for standardization. In fact, standardizing something that
does not already exist in some way would be very dangerous...


> We don't need what you're
> suggestion because it cannot be standardised and it will just be a poor
> comparison to the tools that already exist.

I agree that anything that could be standardized would probably be very poor compared
to existing vendor specific tools. It would probably just boil down to something like
"returns an unspecified string". But I still think it might be worthwile:
- Getting it in the code instead of as part of external tools can be useful to debug
  on customer site when the customer cannot install any software
- Getting it in the standard allows a standard way of generating it, even if understanding
  it will probably be limited to human parsing, since the content would not be normalized.
  Right now, if I have to write cross platform code with some basic error reporting, there
  is nothing I can do except did into the documentation of 20 different toolchains
- Getting it in the standard would not prevent other tools from existing and providing
  much more features
- It is easy to implement, since a compiler could just return an empty string, everything
  else being a question of QOI.

---
Loïc

[Денис Котов]

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 !!!

[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!

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.

To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.

To post to this group, send email to std-pr...@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.

[Денис Котов]

Okay,

Where could I submit my reworked proposal ?
Could you privde me with link ?

суббота, 6 августа 2016 г., 0:53:08 UTC+3 пользователь 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!

2016-08-05 17:44 GMT-04:00 Денис Котов <redr...@gmail.com>:

What is the result of our TOPIC ?

Result is ZERO !!!!! How many human*hours has been spent, but nothing !
Can somebody from с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-proposal...@isocpp.org.

To post to this group, send email to std-pr...@isocpp.org.

[Patrice Roy]

I'd say https://isocpp.org/std/submit-a-proposal is a starting point :)

Good luck!

To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.

To post to this group, send email to std-pr...@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.

[Денис Котов]

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 пользователь Денис Котов написал:

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.

[Денис Котов]

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 пользователь Денис Котов написал:

[Thiago Macieira]

On domingo, 7 de agosto de 2016 02:43:06 PDT Денис Котов wrote:
> 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 !!!!!!*

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 wrote:
> 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 !!!

> 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 написал:

[Thiago Macieira]

On domingo, 7 de agosto de 2016 12:01:03 PDT Денис Котов wrote:
> 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.

[FrankHB1989]

在 2016年8月1日星期一 UTC+8上午1:23:21，Nicol Bolas写道：

On Sunday, July 31, 2016 at 12:38:26 PM UTC-4, Денис Котов wrote:

воскресенье, 31 июля 2016 г., 19:09:51 UTC+3 пользователь Thiago Macieira написал:
> On domingo, 31 de julho de 2016 02:57:35 PDT Денис Котов wrote:
> > > 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.

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

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.

 

[FrankHB1989]

在 2016年8月1日星期一 UTC+8上午2:39:58，Thiago Macieira写道：

On domingo, 31 de julho de 2016 09:38:25 PDT Денис Котов wrote:
> 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.

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.
 

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.
 

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.

> > 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?