[cfe-commits] r60900 - in /cfe/trunk: include/clang/Parse/Ownership.h

[steve naroff]

On Dec 14, 2008, at 5:14 AM, Sebastian Redl wrote:

> steve naroff wrote:
>>
>> Since I haven't used auto_ptr's much, the benefits don't strike a  
>> chord with me (though I value your opinion).
> I think Howard's post was an excellent explanation of the benefits  
> of type-encoded ownership.

I just read Howard's post closely. While his explanation of the  
"mechanics" are interesting, it doesn't tell me why this idiom is  
compelling for clang's Parser/Action subsystems.

>
>>
>> I'm curious...does compiler-supported ownership tracking actually  
>> fix any existing clang bugs? (e.g. crashers, leaks, etc.). If not,  
>> I assume this work is targeted at future-proofing the front-end as  
>> we embark on more complex C++ features?
> There are still 300 bytes worth of leaks in the Parser/statements.c  
> testcase. I'm pretty sure they come from discarded Declarator  
> structures.
> Also, there's still a lot of places where, in the case of an error,  
> existing Stmt and Expr nodes are dropped and leaked in the Sema.  
> There used to be a lot such places in the Parser too, since manual  
> deletion in the case of error was just too much hassle. Now, with  
> the smart pointers, such places are reduced to where the nodes are  
> hidden within larger structures (Declarator is the worst offender, I  
> think). I haven't quantified the improvement, but it was pretty easy  
> to prove from the code logic that some places simply leaked.

Since Declarator's are stack allocated, they can't be leaked. I guess  
you are talking about Declarator's leaking their contents? Please be  
more specific...300 bytes worth of leaks is hardly compelling. In  
general, the Parser doesn't do much dynamic memory allocation (yet  
you've had to make *many* changes to the Parser/Action API's).

While I sympathize with the idea of type-encoded ownership, I'm trying  
to understand how it helps the Parser/Action interface *specifically*.  
I think having to add an ActionBase class to make all this stuff work  
is bizarre.

>
>>
>> Rather than worry too much about ownership, why don't we just use a  
>> garbage collector (like GCC:-) JUST KIDDING:-)))
>>
> Even though it's a joke, I'd just like to point out that garbage  
> collectors would have horrible problems with all the masked pointers  
> we use.
>

For most general purpose collector's this would certainly be true. If  
clang had it's own special purpose collector (like GCC does), it could  
be taught about the games we play (in clang).

In any event, it was a joke!

snaroff

> Sebastian