Den 11-10-2017 kl. 14:24 skrev degski via Boost:
On 11 October 2017 at 14:28, Thorsten Ottosen via Boost < boost@lists.boost.org> wrote:
As it stands, the relocation-policy can be qualified as extreme, which I could adhere to, if that particular concept gave use a quantifiable benefit. My own experiments say it doesn't and one can have a "more balanced result", while still achieve the same performance (I wrote about that earlier).
Sure, and we have certainly floated various ideas. I leaning towards the following principles: A. insert never allocates if it can avoid it B. insert, when allocation is needed, balances the free capacity C. a push at either end by default does not balance the free capacity D. in certain situations push at either end may choose to balance the free capacity, say of the free capacity in the opposite end is larger than size() or perhaps larger or equal to size(). I would hate to see a push artificially create capacity in the opposite end, only to reclaim it later by an expensive operation.
[1] f.e. I wrote a 16 byte footprint vector (limited to size_type = std::uint32_t). It is, on push_back, as fast as std::vector on VS2017. I don't have the capacity to write a boost::proof thing, but that doesn't take away that *it* can be done, I would be a taker...
You can always store extra stuff in the allocated buffer instead of directly in the class. I don't if that is what you did. But you don't actually same memory that way, you just moved the location. kind regards -Thorsten