Test cases (more as motivating examples than anything - I realize the logic is fairly simple)? Should this pass an llvm::ArrayRef rather than a pointer & size? (they're implicitly constructible from arrays anyway - so it'll require almost no change (dropping the "N" from the variadic macros and default constructing in the zero-arg case - or perhaps even passing no args in the zero-arg case, then users of this API could choose whether they could accept no args by simplify using a default value for the ArrayRef parameter, or not)
Where is this tool ultimately going to reside - inside clang itself? or could we have it build separately, and thus use C++11 features directly in its implementation? - David On Thu, Dec 15, 2011 at 3:55 AM, Chandler Carruth <[email protected]> wrote: > Hello folks, > > This patch adds a generic collection of class templates to the LLVM ADT for > building variadic-like functions in C++98. The idea, from the comments, is: > > /// Suppose we need a variadic function like this: > /// > /// ResultT Foo(const ArgT &A_0, const ArgT &A_1, ..., const ArgT &A_N); > /// > /// Instead of many overloads of Foo(), we only need to define a helper > /// function that takes an array of arguments: > /// > /// ResultT FooImpl(const ArgT *const Args[], int Count) { > /// // 'Count' is the number of values in the array; 'Args[i]' is a > pointer > /// // to the i-th argument passed to Foo(). Therefore, write > '*Args[i]' > /// // to access the i-th argument. > /// ... > /// } > /// > /// and then define Foo() like this: > /// > /// const VariadicFunction<ResultT, ArgT, FooImpl> Foo; > > We used this pattern extensively to build up the AST matcher library on top > of Clang (and so I've included cfe-commits in case anyone there is > interested). In preparation for mailing patches for those matchers, I'm > sending a patch that just adds the generic utility to the ADT library as > that seems like a natural home for it. > > Previous versions of this bit of helper code used a fully expanded source > file that would be hard to maintain. I was worried about using the > preprocessor to expand these constructs, but it turned out *much* easier > than I had feared, and I think the result is much easier to read and > maintain. That said, if anyone dislikes the preprocessor hammering, I'm > happy to switch to a more manually expanded form. > > I've also included Doug so that he can rant about adding hacks to LLVM/Clang > to work around the absence of variadic templates. ;] > > _______________________________________________ > cfe-commits mailing list > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits > _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
