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

Fariborz Jahanian fjahanian at apple.com
Sat Dec 13 12:11:52 PST 2008


On Dec 13, 2008, at 11:42 AM, steve naroff wrote:

>
> On Dec 13, 2008, at 1:51 PM, Chris Lattner wrote:
>
>> On Dec 13, 2008, at 5:07 AM, Sebastian Redl wrote:
>>>>       return *this = moving::ASTResultMover<Destroyer>(x);
>>>>    }
>>>> private:
>>>> #endif
>>>>
>>> Yes, this is what my idea was. But I'll check the volatile idea
>>> first.
>>> It's less intrusive.
>>>
>>> Unless it's OK with Chris to switch to compiling with /Za.
>>
>> I don't really understand all the issues around /Za, and don't really
>> have an opinion.
>>
>
> Hey Chris,
>
> 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 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:

I am having the same concerns as Steve. We are adding enormous level
of abstractions without looking at its consequences down the road.  
Aren't we
concerned about potential performance implications for one (smart  
pointers don't
get smart for  cheap :). Aren't we going to limit contributers to  
clang in the
future? Aren't we concerned about portability  of clang?
I am sure  others can add a few more concerns.

- Fariborz

>



More information about the cfe-commits mailing list