sbenza added inline comments.

================
Comment at: include/clang/ASTMatchers/ASTMatchersInternal.h:80
@@ +79,3 @@
+  ResultT operator()(ArrayRef<ArgT> Args) const {
+    std::vector<const ArgT *> InnerArgs;
+    for (const ArgT &Arg : Args)
----------------
alexfh wrote:
> It's unfortunate that we need to create an array of the argument pointers 
> here, but it seems there's no larger common denominator of the two ways this 
> functions can be called.
> 
> One nit though: SmallVector will be a better container here.
> It's unfortunate that we need to create an array of the argument pointers 
> here, but it seems there's no larger  common denominator of the two ways this 
> functions can be called.

Now that we control it, we can change it to be something different.
For example, instead of passing a function pointer as template parameter we 
could pass a class that contains overloaded operator() for both ArrayRef<T> and 
ArrayRef<const T*>.

On the other hand, constructing the matchers has never been the performance 
bottleneck of the framework.
They are usually created once and used thousands/millions of times.
Might not be worth it to optimize this too much.

> One nit though: SmallVector will be a better container here.

Done.


http://reviews.llvm.org/D18275



_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to