[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