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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >>> 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 >>> [email protected] >>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits >>> >>> >> _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
