[cfe-dev] Type>>isObjCInterfaceType() blows up

[Steve Naroff]

On Apr 22, 2008, at 11:53 PM, Ted Kremenek wrote:

>
> On Apr 22, 2008, at 9:24 PM, Chris Lattner wrote:
>
>>
>> On Apr 22, 2008, at 9:21 PM, Sam Bishop wrote:
>>
>>> Chris Lattner wrote:
>>>> ASTContext is very useful as a stack-based data structure.  I'm
>>>> not  sure what the right fix is, but I don't really want to lose
>>>> this  ability...
>>>
>>> What do you mean by useful?  (That's an honest question.)
>>>
>>> Emerson's proposed patch would allow TranslationUnit objects to
>>> safely delete their ASTContext objects.  (Right now, the ASTContext
>>> objects are created on the stack in the serializing case and on the
>>> heap in deserializing case.  I noticed this when tracking down
>>> memory leaks.)
>>
>> If it makes the two cases more uniform, I would be happy to "give up"
>> stack allocation of ASTContext, particularly if the new scheme is for
>> TranslationUnit to always own it.
>
> One aside: if TranslationUnit always owns ASTContext, then it doesn't
> have to be explicitly allocated in TranslationUnit, just kept as a
> field.  TranslationUnit can in turn be stack or heap allocated.
>
> I agree with Chris that ASTContext (and numerous other data structures
> in clang) are useful as stack-allocated objects.  Different clients
> can choose to stack or heap allocate ASTcontext, depending on their
> needs.  As long as their is a clear ownership policy (which includes a
> stack frame "owning" an ASTContext object), then there shouldn't be
> any issues.  Forcing ASTContext to be heap allocated just potentially
> turns one set of bugs (using released stack memory) into another
> (memory leaks from the heap) when we don't reason well about the
> lifetime of an ASTContext (or any other) object.

 From my perspective, stack allocating a "coarse grain" object that  
owns long-lived heap-allocated AST nodes seems kind of odd. Maybe it's  
my ObjC/Java background/bias showing through (i.e. both of these  
languages are reference based).

I guess you guys like the syntactic convenience of not having to  
explicitly delete the object...which I can understand.

That said, I think we need to keep our eye on making the API as  
straightforward as possible. Since many developers will be coming to  
us with Java/ObjC backgrounds, it is interesting to see what potholes  
people fall into. In this instance, I don't think we need to do  
anything now (I agree).

snaroff


> __________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev