[cfe-dev] Smart pointer usage in the Parser/Actions
steve naroff
snaroff at apple.com
Fri Dec 19 13:46:50 PST 2008
On Dec 19, 2008, at 4:21 PM, Douglas Gregor wrote:
> On Dec 19, 2008, at 3:39 PM, steve naroff wrote:
>> On Dec 19, 2008, at 3:09 PM, Fariborz Jahanian wrote:
>> A variation on the FIXME is to have a subclass of ParmVarDecl (e.g.
>> ObjCParmVarDecl) that contains the original type (to support method
>> encoding). This is still wasteful, however the waste is isolated to
>> ObjC. Note that C++ is already wasting space (with the DefaultArg
>> slot). Conceptually, I like the idea of having ObjC and C++
>> subclasses of ParmVarDecl.
>
> I'm not a fan of having separate ObjC/C++ subclasses for Decls
> unless there are differences in the data we need to store in the AST.
This is true for C++, but that's a separate issue I guess.
> In this case, the difference isn't whether we're in Objective-C or
> not; it's whether or not the original type is different from the
> converted type.
I suppose, but ObjC is the only language that currently cares about
the original type (so it can generate meta data consistent with the
source).
> So, why not have ParmVarWithOriginalTypeDecl be a subclass of
> ParmVarDecl, and create ParmVarWithOriginalTypeDecls whenever we've
> actually performed some kind of promotion of the declaration's type?
> That will capture all of the information in the source code while
> not special-casing Objective-C or introducing an extra slot into
> ParmVarDecls that aren't promoted.
From a space perspective, I really like that idea! (and it's
straightforward to implement). Conceptually it's a little odd, but
that's not very relevant/important...
snaroff
> I've been meaning to do the same thing with FieldDecl, by creating a
> subclass BitFieldDecl that's has the extra Stmt* containing the
> bitfield size. The FieldDecl class's interface won't change... but
> it will perform a dyn_cast<BitFieldDecl> in
> FieldDecl::getBitWidth(), so that clients of FieldDecl's won't ever
> have to know about BitFieldDecl.
>
> - Doug
More information about the cfe-dev
mailing list