<div dir="ltr"><div><div><div>Nice.<br></div>I tried to do the perfect forwarding by storing a 'bound' wrapper function which calls new and got linker errors for a few tools.<br></div>Your idea seems better anyway.<br></div><div>I will try to use your patch locally.<br><br></div><div>Thanks<br></div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 23, 2014 at 1:26 AM, David Blaikie <span dir="ltr"><<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Mon, Dec 22, 2014 at 11:32 AM, Manasij Mukherjee <span dir="ltr"><<a href="mailto:manasij7479@gmail.com" target="_blank">manasij7479@gmail.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div>Hi,<br></div>In a lot of the examples, a clang tool is invoked in the following way:<br><br>Tool.run(newFrontendActionFactory<ActionType>().get());<br><br></div>The problem is that this does not allow the user to construct their object with arguments.<br></div>The solution is implementing a FrontendActionFactory and overriding create.<br></div><br>This is overkill in my opinion and can be easily integrated into the SimpleFrontendActionFactory class defined in the library function as follows.<br><br>template <typename T><br>std::unique_ptr<FrontendActionFactory> newFrontendActionFactory() {<br>  class SimpleFrontendActionFactory : public FrontendActionFactory {<br>  public:<br>    clang::FrontendAction *create() override { return new T; }<br>  };<br><br>  return std::unique_ptr<FrontendActionFactory>(<br>      new SimpleFrontendActionFactory);<br>}<br><br></div>This can be adapted to to use variadic templates, store the arguments somehow and use them when constructing the new T.<br><br></div>Is that a viable idea?</div></blockquote></div></div><div><br>I have a patch somewhere that provides a couple of more generalized utilities that accept lambdas... <br><br>(see this thread: <a href="http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20140915/115084.html" target="_blank">http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20140915/115084.html</a>  and the 'makeTrivialFrontendActionFactory" and "makeLessTrivialFrontendActionFactory" - clearly some naming improvements would be in order at least - this all got mixed up along with some other refactoring I was doing at the time & I couldn't really settle on how to separate it due to some unresolved underlying design issues)<br><br>Perfect forwarding is tricky here - since the values would need to be stashed into the SimpleFrontendActionFactory, then used in the construction of the new T object. That's why I went with something more general, the lambda, so the state capturing was clearer/more flexible.<span class="HOEnZb"><font color="#888888"><br><br>- David</font></span></div></div></div></div>
</blockquote></div><br></div>