<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 29 June 2013 11:00, Larry Evans <span dir="ltr"><<a href="mailto:cppljevans@suddenlink.net" target="_blank">cppljevans@suddenlink.net</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 06/28/13 19:07, Nick Lewycky wrote:<br>
[snip]<br>
<div class="im">> ActiveTemplateInstantiations shouldn't be a SmallVector in Sema, they<br>
> should be allocated by a BumpPtrAllocator in ASTContext. Then we can put<br>
> ActiveTemplateInstantions in the AST, which will requiring changing it a<br>
> bit (no pointers to sema:: objects), but we also want to add a template<br>
> depth, correct point-of-instantiation SourceLocation and add missing<br>
> instantiation records (such as instantiation due to overload<br>
> resolution). An awesome outcome of this will be that we'll be able to<br>
> produce template stack traces even when we aren't actively doing<br>
> template instantiation. That would in turn allow us to do other things<br>
> like flatten instantiation instead of making it recursive.<br>
><br>
</div>Would this flattening speed compile times?  Long compile times<br>
is one strong reason why boost preprocessor is used to implement tuples:<br>
<br>
<a href="http://article.gmane.org/gmane.comp.lib.boost.devel/235386" target="_blank">http://article.gmane.org/gmane.comp.lib.boost.devel/235386</a><br></blockquote><br></div></div><div class="gmail_extra">Not really, maybe only a tiny bit. What it means is that the depth of templates we can instantiate wouldn't be limited by our stack space, but by heap space.<br>

<br></div><div class="gmail_extra">I would be very surprised if clang has bad compile-time performance building tuples. Without thinking about it too hard, this sounds like something we should already be good at.<br><br>
</div>
<div class="gmail_extra">Nick<br><br></div></div>