<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 28, 2013 at 7:04 PM, Shuxin Yang <span dir="ltr"><<a href="mailto:shuxin.llvm@gmail.com" target="_blank" class="cremed">shuxin.llvm@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>I just personally abhor the practice that promote private func
      (especially for the fundamental data structure)<br>
      to public func without strong reasons.  It is just my personal
      taste.</div></blockquote></div><br>Just for the record, I think most of us agree with you.</div><div class="gmail_extra"><br></div><div class="gmail_extra" style>I think the interesting difference of opinion is in what constitutes a "strong reason". Personally, I find the use of pool allocators with APInt an important use case, and others have demonstrated very serious performance issues with unilaterally running destructors when deallocating memory in some of these cases. Given these two concerns, exposing a way for code to avoid running destructors when safe while not leaking memory, even if that way is ugly, is a simple necessity of the situation we are in.</div>
<div class="gmail_extra" style><br></div><div class="gmail_extra" style>I would certainly love to find a better way to use pool allocation and avoid undue cost of destructors that happen to be no-ops, all while avoiding the further exposition of internal state in the public API, but I have not yet found such a pattern. Until then, I think it is a reasonable pragmatic solution -- avoid destructors where we can, ensure we don't leak memory, and compromise the API in the least bad way while satisfying those two goals.</div>
</div>