On 27 September 2017 at 00:43, Joaquin M López Muñoz via Boost < boost@lists.boost.org> 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