[cfe-dev] Smart pointer usage in the Parser/Actions

[Fariborz Jahanian]

On Dec 19, 2008, at 1: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. 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. 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.
>
> 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.

Does't c++ mangles the decayed type or the original type (like Objc)?  
If the latter, then the same issue exists for c++ as well.
In any case, seems like the ParmVarWithOriginalTypeDecls is the way to  
go.

- Fariborz

>
>
> 	- Doug