[cfe-dev] AST processing toolbox

[AlisdairM(public)]

> -----Original Message-----
> From: cfe-dev-bounces at cs.uiuc.edu [mailto:cfe-dev-bounces at cs.uiuc.edu]
> On Behalf Of Olaf Krzikalla
> Sent: 12 June 2009 11:15
> To: cfe-dev at cs.uiuc.edu
> Subject: [cfe-dev] AST processing toolbox

> 1. I use boost, in particular boost::bind and boost::function (that is,
> header only for the moment). Unless there is something similiar in llvm
> (which I didn't found yet), I won't like to change this. However this
> would add dependencies to boost and I don't know the opinions of the
> main developers regarding this issue.

I'm too new around here to know Clang policy wrt the C++ standard library,
but I notice that both the libraries you mention are part of TR1, so it
might be better to use the TR1 names for those components instead?

Note that Boost has a pretty good TR1 configuration for those that would
be using Boost rather than their compiler's TR1.  Both GCC and MSVC ship
with TR1 now, although I'm not sure what the state of TR1 was in GCC 4.2.
Other vendors are doing the same, although I presume GCC/MSVC cover most
of our builds at the moment.

There is a bonus here for those building with a GCC 4.3 or later - the
GCC TR1 implementation is based on variadic templates which should show
as a minor compile-time optimization.

Also, if we ever transition to the C++0x standard library (and I would
love to do this for unique_ptr alone!) then all we need to do is remove
the tr1 qualification.

Actually, if we set a precedent for TR1 we get shared_ptr, array and
tuple along for the ride, which would be a nice bonus.  Not sure the
other TR1 components buy us much in this project though (regex, random
numbers, hash containers [vs. llvm], special math, type traits and C99
standard library - which I think we assume is already in std?)

AlisdairM