[cfe-dev] CFG temporary objects destructors

Marcin Świderski marcin.sfider at gmail.com
Fri Oct 22 10:59:09 PDT 2010


W dniu 22 października 2010 11:22 użytkownik Zhongxing Xu <
xuzhongxing at gmail.com> napisał:

> When the binary operator is logical operator, why we need to replicate the
> control flow when adding the dtors in LHS and RHS? Could we just add the
> dtor right after where the LHS and RHS are evaluated?
>
> That is, for code
>
> A && B
>
> we generate CFG like this:
>
> A && B
> ~A()
> |      \
> |       B
> |       ~B()
> |        |
> A && B
>
> Since in logical binary operator, we only need the boolean value. The
> temporary object can be destroyed right after it is evaluated.
>
> This depends on how much we want to simulate real control flow of
expression. C++ standard states that destructors of temporaries should be
called at the end of full expression and in reverse order of their
construction. Your example does not satisfy this. It only guaranties that
destructor for temporary will be called.


> 2010/10/18 Marcin Świderski <marcin.sfider at gmail.com>
>
>> Hi
>>
>> I'm currently working on modeling destructors of temporary objects in CFG.
>> I've attached patch with prototype implementation and some tests.
>>
>> After some thinking I've decided to add additional step with forward
>> traversing of AST for every CXXExprWithTemporaries node. During this step
>> destructors are added to CFG for every CXXBindTemporaryExpr (with special
>> case for binding const reference to temporary). However I have a problem
>> with branching for destructors that have to be called conditionaly. Blocks
>> structure that is constructed is fine, but I don't know what to use for
>> terminator of block initiating the branch and for first element in block
>> closing the branch (I didn't check this yet, but I think that it could be
>> used during backward analysis). Could I use fake if/else statement for this?
>> Similar solution is used to make every declaration into separate statement.
>>
>> - Marcin
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20101022/bf14ba0b/attachment.html>


More information about the cfe-dev mailing list