On Wed, Oct 19, 2011 at 8:02 PM, Jed Brown <span dir="ltr"><<a href="mailto:jedbrown@mcs.anl.gov">jedbrown@mcs.anl.gov</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><div class="gmail_quote">On Wed, Oct 19, 2011 at 14:57, Matthew Knepley <span dir="ltr"><<a href="mailto:knepley@gmail.com" target="_blank">knepley@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">   The properly manage the clean up of partially created objects etc don't they, which our C approach cannot handle. Not that I'm advocating for using them or not.</blockquote>

<div><br></div></div><div>Hmm, I do not see how. As far as I know, you need logic to do that once you catch them, which we could also put in.</div>
<div></div></blockquote></div><br></div><div>Destructors for any live automatic (stack) allocated are called when an exception is raised. Of course it causes all manner of havoc if any of these destructors fail, but having them called means that you can use RAII and "simply" have code that can unwind cleanly. That control flow is much harder with return codes because you end up with either lots of gotos to unwind from each place that can fail or deeply nested control structures.</div>

</blockquote></div><br>Aren't all those destructors called on return too?<div><br></div><div>   Matt<br clear="all"><div><br></div>-- <br>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>
-- Norbert Wiener<br>
</div>