[cfe-dev] Cleaning up the representation of Decls in the AST

Ted Kremenek kremenek at apple.com
Fri Aug 22 17:23:16 PDT 2008


On Aug 22, 2008, at 3:46 PM, Eli Friedman wrote:

> On Fri, Aug 22, 2008 at 2:08 PM, Ted Kremenek <kremenek at apple.com>  
> wrote:
>> Moreover, by using a smart-pointer DeclGroup instead of a chain of
>> ScopedDecls, we actually will save the space used by the
>> NextDeclarator field in ScopedDecl (since it's NULL most of the  
>> time).
>
> Are you intending to pass around DeclGroups by value?  Or will they
> have a stable address?  Passing them by value seems like it would be
> confusing, but it could lead to better performance.

Yes!  DeclGroup would just be a smart pointer, and should be treated  
as a pointer.  We can change the name to reflect it.  To do memory  
management, we would have something equivalent to llvm::OwningPtr<...>  
for DeclGroup, e.g. OwnedDeclGroup.

Here is how I would rewrite DeclStmt:

class DeclStmt : public Stmt {
  OwnedDeclGroup Decls;
  SourceLocation StartLoc, EndLoc;
public:
  DeclStmt(DeclGroup D, SourceLocation startLoc, SourceLocation endLoc)
    : Stmt(DeclStmtClass), Decls(D), StartLoc(startLoc),  
EndLoc(endLoc) {}

  virtual void Destroy(ASTContext& Ctx);

  const DeclGroup getDecls() const { return Decls.get()l; }
  DeclGroup getDecls() { return Decls.get(); }
...

In this example, the dtor for OwnedDeclGroup would actually release  
the memory pointed to by DeclGroup.  The dtor for DeclGroup would not  
do that (just like a pointer does not automatically free the memory it  
refers to).

>
>
>
> There have been multiple requests for a way to get the location of the
> type of a variable declaration; do you have any ideas for how to
> implement that?  It seems like DeclGroups will make that easier, but
> it still seems tricky.

It is tricky, and I'm not certain if it is even a well-formed  
question.  Consider:

int (*x)(int y);

Where is the location of the type?  Is it the first int?

We could certainly add this information to DeclGroup.  It would eat an  
extra 4 bytes, which we probably need to do somewhere anyway if we  
want to preserve this information.



More information about the cfe-dev mailing list