From: Richard Hodges (hodges.r_at_[hidden])
Date: 2020-05-29 08:09:25
Thank you for your response.
On Fri, 22 May 2020 at 21:30, Emil Dotchevski via Boost <
> On Fri, May 22, 2020 at 3:51 AM Richard Hodges via Boost <
> boost_at_[hidden]> wrote:
> > - From looking at the tutorial it appears that in order to use this
> > I would need to write functions that are interested in catching errors in
> > terms of a group of lambdas. Is this correct in general, or is this
> > an artefact of the example code?
> The lambdas aren't so much to catch errors, but to access additional
> information associated with the exception (a-la Boost Exception, but a lot
> more efficient and with better syntax). If you just want to catch the
> exception, you can do a plain old try...catch (of course).
> - Does LEAF incur any memory or runtime performance overhead in the
> non-error case?
I think I understand now. The construct of try_handle_all(lambdas...) is
building an "error context" into which later leaf-enabled functions down
the call stack can emplace error info. The address of this context is
maintained by logically a separate "context stack" which lives in the call
stack. To be strictly correct, would it be fair to say that there is memory
allocation, it just happens to be on the call stack and therefore requires
very little book-keeping overhead and no mutual exclusion?
Additionally, a small (presumably small) deterministic setup cost is
incurred whether or not error information will be produced.
Would that be accurate?
> I do not have open source production code to share, but I could possibly
> show you some code personally.
This would be helpful.
At the moment, I get the impression that this is a very elegant solution to
a problem I don't have. I want to be even handed during the review. It
would be helpful to see some code from a domain where this solution solves
a very real problem, or have a domain described where LEAF clearly solves a
real problem. For that "Oh Wow!" moment that you have presumably personally
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk