[cfe-dev] [PATCH]: Preparing AST for C++ declarations

Eli Friedman eli.friedman at gmail.com
Wed Jun 4 12:20:10 PDT 2008

On Wed, Jun 4, 2008 at 11:15 AM, Argiris Kirtzidis <akyrtzi at gmail.com> wrote:
> Eli Friedman wrote:
>> Most important issue: you're adding an Access member to TypeDecl, a
>> class which isn't C++-specific.  This will increase the size of all
>> TypeDecls for C code by 4 bytes.  Adding new members to data
>> structures requires additional scrutiny, because it affects memory
>> usage.  In this case, it doesn't appear to be worthwhile to bloat the
>> memory usage for C code.  There are a couple of possible ways to fix
>> this: the simplest is to add a CXXEnumDecl and CXXTypedefDecl, and
>> shuffle the Access member down to the C++-specific classes.  This
>> isn't exactly pretty, but it's straightforward to implement.
> I've suggested this in a previous patch, but it seemed ugly wasn't well
> received:
> http://lists.cs.uiuc.edu/pipermail/cfe-dev/2008-May/001780.html

Hmm, maybe... I think that the original comment was more about
disliking multiple inheritance, though.

>> This will increase the size of all TypeDecls for C code by 4 bytes
> Two suggestions about this:
> 1) "Swizzle" the access specifier bits into the "TypeForDecl" member
> pointer.
> 2) Or move the access specifier bits to NamedDecl, thus they get packed with
> the bitfields from Decl
> I'm more fond of (2), since it also simplifies things by letting the access
> specifier be shared by all C++ decls.

That's a possibility; you also have to consider how this interacts
with serialization, though.

>> The instance fields of CXXRecord are stored in the members array of
>> RecordDecl, thus the data layout of CXXRecord is calculated through the
>> Record.
>> All the other members (including the static fields), are ScopedDecls with
>> the CXXRecord as declaration context, so they can be iterated through a
>> general DeclContext member iterator (not implemented yet).
>> Name lookup for class members will be efficient through the use of the
>> IdentifierResolver.
> The Nth member (as "getMember(N)") will be the Nth instance field of a
> specific Record. It seems to me that it makes sense even when inheritance
> comes into the picture, do you disagree ?

The issue is the following: class B inherits from class A.  class A
has a member x.  Is x accessible through getMember(N)?  If so, how do
you figure out the ownership of a FieldDecl once it's in the

> Well, I've come to the point where simple stuff like this gets passed
> through -fsyntax-only:
> class S {
> public:
>  int f1(int p) {
>   A z = 6;
>   return p + x + this->y + z;
>  }
>  typedef int A;
> private:
>  int x,y;
> };

Oh, cool; that's a lot of progress.


More information about the cfe-dev mailing list