[cfe-dev] checkers: decoupling ValueManager from GRStateManager

[Ted Kremenek]

I think this is a reasonable tradeoff.  I still like to decouple GRExprEngine from GRStateManager, but this is definitely a step in the right direction.  We should probably add a comment above the new constructor indicating that it is for clients that don't want to use GRExprEngine with GRStateManager, since it will be unused elsewhere in libChecker.  That way when the refactoring eventually happens we will know if that constructor can safely be removed.

On Nov 8, 2010, at 6:04 AM, Olaf Krzikalla wrote:

> Hi Ted,
> 
>> I think a reasonable starting point is to try and sever GRStateManager from GRSubEngine.
> I've attached the probably most pragmatic approach to this mail. Making the GREngine in GRStateManager a pointer that can be 0 and adding another c'tor which doesn't rely on the manager creator functions (in order to enable manager c'tors with heterogenous argument lists) just made the trick.
> The question is whether you can live with this hack or how the ProcessRegionChange/WantsRegionChangeUpdate functions can be refactored out of GRSubEngine otherwise. Another c'tor in GRStateManager is surely unavoidable due to the manager creator functions.
> While you are going to think about this I'll try to answer the question whether I can use that GRStateManager for my problem. I'll let you know later this week.
> 
> Best Olaf
> <checker_2nd.patch>