<div class="gmail_quote">W dniu 3 września 2010 08:51 użytkownik Ted Kremenek <span dir="ltr"><<a href="mailto:kremenek@apple.com">kremenek@apple.com</a>></span> napisał:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Sep 2, 2010, at 11:25 PM, Marcin Świderski <<a href="mailto:marcin.sfider@gmail.com">marcin.sfider@gmail.com</a>> wrote:<br>
<br>
> If we would want to model destructors of temporaries directly in CFG we would have to generate blocks structure mirroring that generated for full expression. That is because of expressions with control flow (&&, ||, ?:). But what do we need this for?<br>

> - If we want to know of all destructors that can be called at the and of full expression, we can look at CXXExprWithTemporaries in AST.<br>
> - If we want to know exactly what destructors will be called at the end of full expression we can build stack of all temporaries seen on some specific path.<br>
> Direct modeling this in CFG won't be easier to use by a client in any of this cases IMO.<br>
<br>
</div>I obviously disagree with this last point, but hopefully I can give you a good reason of why I think representing these destructors calls in the CFG is valuable.<br>
<br>
If we don't model them in the CFG, then every client has to potentially replicate some of this reasoning, which is messy at best.  Even in vanilla C, there are enough edge cases to making reasoning about control-flow tricky, especially when you compose language features that have control-flow of their own.  In this case, there are control-dependencies between destructors calls of temporaries, as well as control dependencies between these destructors and other destructors, exception handling edges, etc.  The whole point of the CFG is that we get it right in one place and clients don't have to think about any special cases.  This is crucial, as it really provides a nice decomposition of reasoning between analyses (that just care about the properties they are reasoning about) and all the logic to reason about control-flow.<br>

<br></blockquote><div>Right, if we have destructor that throws (which we shouldn't, but who knows) we probably want it directly in CFG. I'll think more about this later, maybe when what is done so far will find it's way to repository.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Finally, if you don't buy that argument, the other benefit for clients of having explicit CFGElements in the CFG for such destructors is that they provide convenient handles (i.e., ProgramPoints) to anchor dataflow facts, both in the path-sensitive engine and basic flow-sensitive analyses.</blockquote>
</div>