Re: [boost] [review] The review of Boost.DoubleEnded starts today: September 21 - September 30

Subject: Re: [boost] [review] The review of Boost.DoubleEnded starts today: September 21 - September 30
From: degski (degski_at_[hidden])
Date: 2017-10-11 12:24:30

On 11 October 2017 at 14:28, Thorsten Ottosen via Boost <
boost_at_[hidden]> 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