[cfe-dev] AST processing toolbox

[Ted Kremenek]

Pulling back to cfe-dev.

Hi AlisdairM,

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.

On Jun 12, 2009, at 1:52 PM, AlisdairM(public) wrote:

>> -----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.

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.

>
> 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.

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.

>
> 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.

Understood.

>
>> 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 is certainly a long term goal.

I realized that a problem with this suggestion is that it only allows  
development of Clang on machines where LLVM supports codegen.

>
>> 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.

Absolutely.

>  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.

That is my feeling as well.

>  The functional idiom is
> simply not well enough understood by the 'average' C++ developer.

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.

>
> 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?)

Yes, most of such support libraries are in llvm/include/ADT, but there  
is also llvm/include/Support and llvm/include/System.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20090612/213b002e/attachment.html>