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-09-27 06:03:58

On 27 September 2017 at 00:43, Joaquin M López Muñoz via Boost <
boost_at_[hidden]> wrote:

> ... but libraries, in my opinion, should start with a minimal and
> well grounded design and add more stuff as demand proves their need.
>

This sounds good in theory, but doesn't work like that in practice.
Libraries tend to get "stuck" in their inital state.

As an example of this: I recently proposed to add variadic move
construction for nodes to boost::pool (a trivial change). And even though
this has obvious advantages (and would get rid for C++11 capable compilers
of the use of M4 to generate the necessary code), this was received with:
file a PR, including tests (?) and change to documentation. Enough to put
me off, so I just changed it locally.

Another example is the VS std::deque, where chunk size is the greater of 16
bytes and the size of one object and makes std::deque have std::list
performance for anything other than chars, shorts and ints (luckily there's
boost!!! It's the greater of 512 bytes and the size of one object b.t.w.).

4. Same goes for the growing policy. Not even boost::container::vector
> features a growing policy, which seems an indication that this is not a
> heavily demanded customization point.
>

The fact that it's not there, does not proof anything and might be related
to the point I raised in the above. This implementation of a vector
<https://github.com/aguinet/pector>, which shares ideas (and has some other
ones) with devector has a growth policy (although not as flexible and neat
as devector).

That implementation also provides, next to a multiplicative growth
strategy, an additive growth strategy. The current devector design makes
implementing this a trivial exercise.

> 5.  Defining size_type as unsigned int for the sake of class size seems to
> me overzealous.
>

I dis-agree, the above pt::pector goes further in this respect and (can)
reduce(s) it's footprint to 16 bytes (64 bits app.) if required (at the
cost of a small performance penalty). The use case I referred to above is a
DAG with adjacency vectors! i.e. every node (many in my use case) has 2
vectors (in and out), shaving of 8 bytes makes a difference (in improved
locality and overall memory use).

Why not make this decision a template parameter (as in pt::pector) and be
done with it?

degski
-- 
"*Ihre sogenannte Religion wirkt bloß wie ein Opiat reizend, betäubend,
Schmerzen aus Schwäche stillend.*" - Novalis 1798