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 _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
