>> It is pretty subjective. We do use almost all C++ features >> somewhere in the (greater llvm) code base. It's really more about >> making clear and simple code than it is about banning specific >> language features. Some coding guidelines are available here: >> http://llvm.org/docs/CodingStandards.html > > Bookmarked; thanks! > > Note, the reference to "Effective C++" at the bottom is a little > out of date; the third edition was published two years ago and > contains some significant changes: > > http://tinyurl.com/26gch4 > > Also the other two links (for the strings "available as well" and > "Large-Scale C++ Software Design" appear to be broken.
Thanks, fixed! >> That said, there are two features we don't like: RTTI and EH. >> This is because they violate the "don't pay for it if you don't >> use it" principle. If building with GCC, clang disables both RTTI >> and EH support (-fno-rtti and -fno-exceptions). The main llvm >> repository has a couple of places that still use RTTI, but we'd >> like to fix that. >> >> The main problem with RTTI and EH is the impact on binary size. >> Many clients of LLVM and at least one client of clang use them in >> a JIT context. Having the binaries be as small as possible makes >> it easier for people to distribute them with their apps. > > I think that may be the least-flaky objection to EH that I've heard > so far. (: :) It is actually really frustrating, because certain pieces of the compiler (e.g. error recovery in the parser) could be slightly cleaner with exceptions. -Chris _______________________________________________ cfe-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
