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

[steve naroff]

On Dec 13, 2008, at 3:04 PM, Sebastian Redl wrote:

> steve naroff wrote:
>> I have one minor objection. Up until now, we've avoided using any  
>> "special" (i.e. non-standard) compiler switches. In general, non- 
>> standard options don't get as much exercise and may be more buggy.  
>> Since I'm not that plugged into the MS developer community, I have  
>> no idea how many developers use this switch (or if it could  
>> introduce any instability).
> I don't know how many developers use the switch, but most of the  
> examples in the library documentation use it.

That's odd. You'd think the examples would be compiled with the  
default options. In any case, this is useful info (thanks for the  
research).

>
>>
>> I have another higher level (philosophical?) concern about the  
>> "magic" that's being added. In the "early days" of clang, Chris and  
>> I thought it was important to avoid any exotic C++ usage/idioms.  
>> The rationale was two-fold:
>>
>> (1) we didn't want to require clang developers have a "PhD in C++".
>> (2) we wanted to simplify the port effort.
>>
>> That said, I'm a bit concerned about the complexity of the "moving"  
>> namespace. Since I'm not a C++ language lawyer, some of this stuff  
>> makes my head spin:-) Hopefully it's like llvm's isa/dyn_cast  
>> support, which are very useful/powerful abstractions (where  
>> developers don't need to know *how* they are implemented).
> I understand your concerns, and I shared them initially. However, I  
> believe that the benefits of compiler-supported ownership tracking  
> outweigh the necessary complexity. The moving namespace is as  
> complex as it is *because* we try to shield the normal developer  
> from the more complex mind games involved in using auto_ptr-style  
> move semantics.

Since I haven't used auto_ptr's much, the benefits don't strike a  
chord with me (though I value your opinion).

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?

Rather than worry too much about ownership, why don't we just use a  
garbage collector (like GCC:-) JUST KIDDING:-)))

>
> Oh, and also because we try to emulate something that only exists in  
> C++0x in C++03. Hopefully, in a year or two we can start to  
> integrate basic C++0x features in the codebase and get rid of all  
> this stuff. That will simplify the code enormously.

That sounds good, however it's always hard to use bleeding edge  
features if you desire portability.

snaroff

>
>
> Sebastian