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: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-09-29 17:04:37

>     Me personally, my biggest complaint with the STL containers is that you
>     don't get direct control over when they call malloc or free.
> 
> 
> Which standard library containers are you concerned about doing
> allocations beyond those allocations where they use the given Allocator
> instance and invoke its allocate() member function?

My biggest peeve is std::vector. I absolutely hate that it can ever
allocate new storage on its own.

In my preferred STL2 design, a vector would only ever occupy its
capacity which is given to it at the time of construction. It cannot
change its capacity at all. You the programmer can, of course, create a
new vector of larger capacity and have all the contents from the old
vector moved/copied into the new vector.

All the remaining STL2 containers are then built in layers atop this
STL2 vector, muxed in with Ranges and Views.

BTW STL1 containers don't go away. They're still available for when you
don't care and just need something quick and dirty. And for legacy code
of course.

You can see some of my STL2 container ideas in AFIO v2 where memory
mapped files are "malloc" and `afio::algorithm::mapped_view<T>` is a
typed view of some mapped file storage. I haven't implemented
`afio::algorithm::vector<T>` yet, but it's on the plan.

One of the super cool things with this design is constant time vector
extensions when the type has a trivial move and copy constructor because
we simply map the underlying file storage to a new address. No memory
copying needed. The other super cool thing is sparse storage, so you can
allocate trillion element vectors without issue on any system.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/