On 25/04/2015 05:03, Marvin Humphrey wrote:
On a related note: `Resize` was omitted from the list of public methods at the top of this thread, but it's important. It should be public, and its semantics should be clarified to indicate that it will grow the backing array if necessary but never shrink it.
+1, seems that I overlooked this one.
If we keep that the functionality of `Grow`, I think we should consider renaming it to `Reserve`, a la std::vector.
Additionally, if we supply `Reserve`, we should also supply a function which triggers non-destructive shrinking of the allocation. In C++, this is `shrink_to_fit`, in Java it's `trimToSize`. I suggest `Compact`.
Right, this needs more thought. Let's keep `Grow` private for now (or remove it).
This same suite of methods -- `Resize`, `Get_Capacity`, `Reserve`, and `Compact` -- should also be considered for CharBuf and ByteBuf.
+1 for `Get_Capacity` and `Reserve`. But I can't see how `Resize` would work with append-only buffers. The benefits of `Compact` also seem limited.
This topic was discussed extensively back in 2010 on both the Lucene dev list and the Perl 5 Porters list: http://markmail.org/message/x427sku4wrnc3rjf http://markmail.org/message/up4cgq322lmtx5tw I'm OK with 1.25. The ideal ratio is case-dependent.
Yes, it depends. Actually, we should consider a larger factor for CharBufs since they're typically short-lived.
Nick
