On Thu, 29 Apr 2021 at 17:46, Andrey Semashev via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On 4/29/21 7:32 PM, Edward Catmur wrote:
> > It works in the most performance-sensitive case.
>
> No, it doesn't. It only works in your toy example where you call
> std::current_exception_stacktrace directly from the catch block and
> nothing else. This breaks in practically any other case that is even
> remotely close to anything real-world, where you do something useful in
> the exception handler that involves a cross-TU call. No, that doesn't
> sound like "works" to me, sorry.
>

I may have been unclear. The logic is that the compiler sets the flag on
the handler to request stacktrace unless it can prove that the catch block
does not call anything that might require it.

> Perhaps you can get
> > your vendor to give you a compiler flag or attribute to suppress
> > exception stacktraces.
>
> It's clearly not acceptable to me. Maybe you, or the author of the
> proposal, should ask a compiler vendor to implement such a flag to
> *enable* stacktraces and then experiment with it on a real code base.
> Field trial would be a valuable addition to the proposal.
>

Compiler support is not necessary to test the facility, as demonstrated by
the demo library linked from the head of this thread.

Is it really the allocation that you're objecting to, or is there something
else at stake?