[cfe-commits] r60900 - in /cfe/trunk: include/clang/Parse/Ownership.h
Sebastian Redl
sebastian.redl at getdesigned.at
Sat Dec 13 12:04:08 PST 2008
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.
>
> 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.
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.
Sebastian
More information about the cfe-commits
mailing list