<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Pulling back to cfe-dev.<div><br></div><div>Hi AlisdairM,</div><div><br></div><div>For the moment, I'd rather the discussion center on what technical problem you are trying to solve rather on whether or not we can depend on TR1. I'm not yet convinced we have a technical need. And, as Chris said in his other email, sometimes having an LLVM-ized library that just cherry picks out the feature you want from TR1/Boost may be sufficient. Without a technical need we're just adding dependencies for no reason.</div><div><br><div><div>On Jun 12, 2009, at 1:52 PM, AlisdairM(public) wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div><blockquote type="cite">-----Original Message-----<br></blockquote><blockquote type="cite">From: Ted Kremenek [mailto:kremenek@apple.com]<br></blockquote><blockquote type="cite">Sent: 12 June 2009 21:20<br></blockquote><blockquote type="cite">To: AlisdairM(public)<br></blockquote><blockquote type="cite">Cc: <a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br></blockquote><blockquote type="cite">Subject: Re: [cfe-dev] AST processing toolbox<br></blockquote><br><blockquote type="cite">I think even depending on TR1 might be too high (at least at this<br></blockquote><blockquote type="cite">point), as we want Clang to compile on as many platforms as possible<br></blockquote><blockquote type="cite">that have a "reasonable" C++ compiler. I could be wrong, but I don't<br></blockquote><blockquote type="cite">think we want people to have to install Boost in order to compile<br></blockquote><blockquote type="cite">Clang if they don't have an available TR1 solution.<br></blockquote></div></blockquote></div><div><blockquote type="cite"><div><font class="Apple-style-span" color="#000000"><br></font>OK, this is a good starting point?<br>Do we have a reasonable list of targets we would expect to build<br>Clang on? This would give us a chance to survey and see if TR1<br>support really is an issue.<br></div></blockquote><div><br></div><div>Not really. We want to encourage as broad as possible adoption at this point. We certainly want Clang to be easily available (among others) on the major Linux and BSD varieties, but there is also Windows support to consider. Having support on Solaris is also something we don't want to flatly rule out.</div><br><blockquote type="cite"><div><br>Likewise, Boost can be a big and bulky dependency to install, so<br>agree requiring it where not absolutely necessary would be a big<br>barrier to the more casual user. What if we had a cut-down<br>Boost::TR1 distribution? If we have a known set of target platforms<br>without native TR1 support we know which platforms to focus on<br>for specific 'one-click' installers.<br></div></blockquote><div><br></div><div>I think the consensus is that we rather cherry pick features as we need them, and pull them into LLVM-ized libraries. That makes us really decide whether or not we need some special feature in the first place, rather than bloating the codebase.</div><br><blockquote type="cite"><div><br>Not that I want to force TR1 on the community! But it would be<br>good to know if making it available is a realistic possibility,<br>and that starts with knowing our target environment.<br></div></blockquote><div><br></div><div>Understood.</div><br><blockquote type="cite"><div><br><blockquote type="cite">Another possibility, when Clang eventually has the capability to<br></blockquote><blockquote type="cite">bootstrap itself, libraries not part of the core compiler could be<br></blockquote><blockquote type="cite">compiled using a bootstrapped Clang and use whatever C++ features<br></blockquote><blockquote type="cite">Clang supports.<br></blockquote><br>I hope this means what I think it means for future C++0x support ;¬)<br></div></blockquote><div><br></div><div>That is certainly a long term goal.</div><div><br></div><div>I realized that a problem with this suggestion is that it only allows development of Clang on machines where LLVM supports codegen.</div><br><blockquote type="cite"><div><br><blockquote type="cite">That said, there is an ongoing discussion on which C++ features we<br></blockquote><blockquote type="cite">should actually use in LLVM/Clang. At the end of the day, not<br></blockquote><blockquote type="cite">everyone who contributes to LLVM/Clang is a C++ guru, and using<br></blockquote><blockquote type="cite">esoteric C++ features may actually be more of a detriment than a<br></blockquote><blockquote type="cite">blessing as it may scare off potential contributors. So when we look<br></blockquote><blockquote type="cite">at whether or not to pull in library X or language feature Y into the<br></blockquote><blockquote type="cite">code base, we need to consider the tradeoffs both in terms of<br></blockquote><blockquote type="cite">technical benefits (which may be marginal) versus (a) the<br></blockquote><blockquote type="cite">approachability and readability of the code base and (b) the<br></blockquote><blockquote type="cite">portability of the code base. We aren't luddites, however, as we do<br></blockquote><blockquote type="cite">indeed use some of the more "specialized" features of C++ in LLVM/<br></blockquote><blockquote type="cite">Clang, but they are buried deep in the code and help provide<br></blockquote><blockquote type="cite">fundamental infrastructure instead of being used as part of the basic<br></blockquote><blockquote type="cite">APIs.<br></blockquote><br>Well, some of the trickier parts of TR1 are exploiting guru-level<br>Implementations to deliver simpler end-user interfaces.</div></blockquote><div><br></div><div>Absolutely.</div><br><blockquote type="cite"><div> tr1::function<br>is probably the best example of this. Likewise, shared_ptr has a very<br>simple interface but is an extremely powerful component. Conversely,<br>while I find tr1::bind invaluable myself, reaction from colleagues in<br>the past suggests it is a guru-level API.</div></blockquote><div><br></div><div>That is my feeling as well.</div><br><blockquote type="cite"><div> The functional idiom is<br>simply not well enough understood by the 'average' C++ developer.<br></div></blockquote><div><br></div><div>I'm not certain if the functional idiom is the problem, but I'm not going to digress on that point. We're very much open to different "algorithmic" approaches, including a functional perspective, as certain approaches lend themselves elegantly to solving specific problems.</div><br><blockquote type="cite"><div><br>Now if LLVM is already providing equivalents for some of these features<br>it would be helpful to have documentation summarising and pointing us<br>in the right direction. So far I have only stumbled over OwningPtr<br>which seems to be an attempt to fix auto_ptr, more like C++0x<br>unique_ptr than shared_ptr. It is quite likely I have missed more<br>though! (I believe we use LLVM supplied hashing containers?)<font class="Apple-style-span" color="#000000"><font class="Apple-style-span" color="#144FAE"><br></font></font></div></blockquote><br></div><div>Yes, most of such support libraries are in llvm/include/ADT, but there is also llvm/include/Support and llvm/include/System.</div></div></body></html>