On Mon, Oct 27, 2008 at 10:42 AM, Ted Kremenek <[EMAIL PROTECTED]> wrote: > > On Oct 27, 2008, at 7:34 AM, Ted Kremenek wrote: > > for example, this would mean that > > FunctionDecl would have to have its own NumParams field rather than > > looking through its type field to find the number of parameters. Then, > > order of destruction would never matter. > > Since Decls shouldn't own Types, this particular example shouldn't > actually be an issue. Are you seeing this to be a problem? Clearly > this means that Types should be destroyed after Decls are, but Types > are released when ASTContext is destroyed (which in TranslationUnit, > occurs after the Decls are released). > > Doug just kindly pointed me to an example where Types can depend on Decls to > implement basic functionality. > http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20081020/008535.html > I now recall that this occurs in several places (such as in the Objective-C > ASTs), but they don't always appear to create ownership issues. > I'm not quite certain what is the best solution for this.
For FunctionDecl, it's easy: add a NumParams field that tracks the number of parameters, so that the FunctionDecl destructor does not need to look into the type of the function. I don't know where in Objective-C land we have this same issue, although TranslationUnit::~TranslationUnit has some scary code in it that involves destruction of Objective-C Decls. - Doug _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
