On 11 October 2017 at 14:28, Thorsten Ottosen via Boost < boost@lists.boost.org> wrote:
The main concept of a devector is a contiguous container that can grow efficiently in both directions. Balancing strategies, resize strategies etc is something we can discuss within that framework (which we have).
Yes, agreed as to the main concept. I don't think there are many people that feel that "the main concept" is wrong. "WE" like it! But, we are discussing implementation here, so we *are* discussing re-balancing, re-sizing and reserving.... The blog you're quoting discusses the same main concept (as defined by you), but it discusses a (conceptually, in regard of implemention) different beast all-together... Nothing wrong with that, it mostly shows that there are other (and not the only) ideas floating around. One could f.e. imagine adaptive re-balancing (as proposed in another blog, previously quoted in this thread) as well, but the foot print of *that* bugger won't be 24 bytes (on 64 bit). So "horses for courses", let's have plenty... I re-frained from writing a review, mainly because I don't think a common opinion has (yet) been built around what the concept (beyond "main concept") should be. 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). On the other hand, I think that batch_deque *should* be rejected, as the main attraction of batch_deque, could be integrated in boost::container::deque. I have no clue why iterating over the segments is usefull, but I live to learn, so convince me. But to conclude this post on a positive note, I do think there is a space for a collection of "special interest" containers [1]. They should be in a separate library, so they have the "dangerous" marking (Boost.Dangerous could be a thing). Yes, they might not give the same guarantees as standard containers, or work with a statefull allocator, or deliver any other guarantee the STL provides (but those guarantees come at a cost. Obviously, something has to give!). I don't see *that* as a problem. It's like with your washing machine, you need to read the manual and stick to the rules... degski [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... -- "*Ihre sogenannte Religion wirkt bloß wie ein Opiat reizend, betäubend, Schmerzen aus Schwäche stillend.*" - Novalis 1798