[cfe-dev] AST processing toolbox

[AlisdairM(public)]

> -----Original Message-----
> From: Ted Kremenek [mailto:kremenek at apple.com]
> Sent: 12 June 2009 21:20
> To: AlisdairM(public)
> Cc: cfe-dev at cs.uiuc.edu
> Subject: Re: [cfe-dev] AST processing toolbox

> I think even depending on TR1 might be too high (at least at this
> point), as we want Clang to compile on as many platforms as possible
> that have a "reasonable" C++ compiler. I could be wrong, but I don't
> think we want people to have to install Boost in order to compile
> Clang if they don't have an available TR1 solution.

OK, this is a good starting point?
Do we have a reasonable list of targets we would expect to build
Clang on?  This would give us a chance to survey and see if TR1
support really is an issue.

Likewise, Boost can be a big and bulky dependency to install, so
agree requiring it where not absolutely necessary would be a big
barrier to the more casual user.  What if we had a cut-down
Boost::TR1 distribution?  If we have a known set of target platforms
without native TR1 support we know which platforms to focus on
for specific 'one-click' installers.

Not that I want to force TR1 on the community!  But it would be
good to know if making it available is a realistic possibility,
and that starts with knowing our target environment.

> Another possibility, when Clang eventually has the capability to
> bootstrap itself, libraries not part of the core compiler could be
> compiled using a bootstrapped Clang and use whatever C++ features
> Clang supports.

I hope this means what I think it means for future C++0x support ;¬)

> That said, there is an ongoing discussion on which C++ features we
> should actually use in LLVM/Clang.  At the end of the day, not
> everyone who contributes to LLVM/Clang is a C++ guru, and using
> esoteric C++ features may actually be more of a detriment than a
> blessing as it may scare off potential contributors.  So when we look
> at whether or not to pull in library X or language feature Y into the
> code base, we need to consider the tradeoffs both in terms of
> technical benefits (which may be marginal) versus (a) the
> approachability and readability of the code base and (b) the
> portability of the code base.  We aren't luddites, however, as we do
> indeed use some of the more "specialized" features of C++ in LLVM/
> Clang, but they are buried deep in the code and help provide
> fundamental infrastructure instead of being used as part of the basic
> APIs.

Well, some of the trickier parts of TR1 are exploiting guru-level
Implementations to deliver simpler end-user interfaces.  tr1::function
is probably the best example of this.  Likewise, shared_ptr has a very
simple interface but is an extremely powerful component.  Conversely,
while I find tr1::bind invaluable myself, reaction from colleagues in
the past suggests it is a guru-level API.  The functional idiom is
simply not well enough understood by the 'average' C++ developer.

Now if LLVM is already providing equivalents for some of these features
it would be helpful to have documentation summarising and pointing us
in the right direction.  So far I have only stumbled over OwningPtr
which seems to be an attempt to fix auto_ptr, more like C++0x
unique_ptr than shared_ptr.  It is quite likely I have missed more
though!  (I believe we use LLVM supplied hashing containers?)

AlisdairM