[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