3 ms·
Cases where the exact buffer size doesn't matter are ubiquitous, for example: * read a file(-like) in streaming mode. Whenever the buffer is empty, fill it. Th
by o11c 2y ago
Cases where the exact buffer size doesn't matter are ubiquitous, for example:
* read a file(-like) in streaming mode. Whenever the buffer is empty, fill it. The actual allocated size does not matter at all for most kinds of file.
* push objects onto a vector when the capacity is used up, reallocate at a larger size and keep pushing. The actual allocated capacity doesn't matter at any point.
* implement a bloom filter for approximate set membership. If the allocator happens to give you a little more than your mathematical estimation for the chances you want, you might as well use it.
In fact, I dare say: every allocation size that is neither `0` or `sizeof(T)` doesn't fundamentally care about the size (a given implementation may care, but if the standard bothered to implement useful new functionality we would change the implementations).
This is unlike, say, my desire for skewed-alignment allocators, which is but not particularly useful for most programs.
- nickelpro 2y agoI hadn't thought about the `sizeof(T)` point before, and I can think of a handful of exceptions, but it's a great and expressive rule of thumb.
- dataflow 2y ago> In fact, I dare say: every allocation size that is neither `0` or `sizeof(T)` doesn't fundamentally care about the size Not true? When you copy an array (common case: string) that is passed to you, you want the copy to the the same size. No more (that wastes memory) and no less (then you don't have a copy), just as with sizeof(T).