<div dir="ltr">Yeah, not sure - wouldn't mind some other voices here to see how people feel.<br><br>Reserve isn't part of any STL concept so far as I can tell, so, yes, to that degree it is an implementation detail. </div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Apr 4, 2016 at 11:03 AM, Matthias Braun via llvm-commits <span dir="ltr"><<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">MatzeB added a comment.<br>
<span class=""><br>
In <a href="http://reviews.llvm.org/D18579#391254" rel="noreferrer" target="_blank">http://reviews.llvm.org/D18579#391254</a>, @dblaikie wrote:<br>
<br>
> That seems like a somewhat strange API - calling reserve down into the<br>
>  vector (& possibly the set, for things like DenseSet) seems more<br>
>  appropriate, no?<br>
<br>
<br>
</span>After the discussions here I felt that reserve()/resize() are details of the underlying set not necessarily a common agreed interface supported by all sets, what if the next set implementation has additional methods for tuning? An alternative to that strange constructor would be to expose the set object so people can call reserve()/resize() on it directly though it breaks isolation.<br>
<span class="im HOEnZb"><br>
<br>
Repository:<br>
  rL LLVM<br>
<br>
<a href="http://reviews.llvm.org/D18579" rel="noreferrer" target="_blank">http://reviews.llvm.org/D18579</a><br>
<br>
<br>
<br>
</span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@lists.llvm.org">llvm-commits@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits</a><br>
</div></div></blockquote></div><br></div>