[cfe-commits] Checker and respondsToCallback

[Jordy Rose]

I was adhering strictly to information-hiding -- once we're at this point,
it's little better than just accessing respondsToCallback directly. But it
is simpler. I think I went overboard.


On Fri, 6 Aug 2010 09:31:17 +0800, Zhongxing Xu <xuzhongxing at gmail.com>
wrote:
> Why can't we just do that:
> 
> in Checker.h:
> 
>   bool &getCallbackFlag() {
>     return respondsToCallback;
>   }
> 
> In GRExprEngine.cpp:
> 
> +    SaveAndRestore<bool> OldFlag(checker->getCallbackFlag(), true);
> 
> 
> On Fri, Aug 6, 2010 at 9:11 AM, Zhongxing Xu <xuzhongxing at gmail.com>
wrote:
>> If I understand correctly, we can add an assertion here, and remove
>> the argument 'true'.
>>
>> +  SaveAndRestore<bool> ResetCallbackFlag() {
>> +    // This looks like it's incorrect, since a non-optimizing compiler
>> will
>> +    // use a temporary and a copy here, then destroy the copy and
reset
>> the
>> +    // value of respondsToCallback. However, the only case where
>> +    // respondsToCallback is 'false' is just after calling an ignored
>> +    // callback. By the end of the block in which a client calls that
>> callback,
>> +    // the value of respondsToCallback will have been reset to 'true'.
>>
>>     assert(respondsToCallback);
>>
>> +    return SaveAndRestore<bool>(respondsToCallback, true);
>> +  }
>>
>> On Fri, Aug 6, 2010 at 3:14 AM, Jordy Rose <jediknil at belkadan.com>
wrote:
>>> Hm. Thanks to the fact that one callback may end up indirectly
invoking
>>> another, this is not so simple. On the one hand, it does let us track
>>> the
>>> response for any callback. On the other, ResetCallbackFlag is a
kludge.
>>>
>>> Holding off on committing for now.
>>>
>>>
>>> On Wed, 4 Aug 2010 17:10:17 -0700, Ted Kremenek <kremenek at apple.com>
>>> wrote:
>>>> That's not a bad idea at all.  In fact I really like it.  The value
>>>> can
>>>> still get lazily set, but just stored with the Checker object.
>>>>
>>>> On Aug 4, 2010, at 10:51 AM, Jordy Rose wrote:
>>>>
>>>>> This is not a general solution, though. Alternately, we could just
>>> stick
>>>>> the flag in Checker rather than CheckerContext.
>>> _______________________________________________
>>> cfe-commits mailing list
>>> cfe-commits at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>>>
>>>
>>