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-28 06:48:51

On 28 September 2017 at 00:07, Benedek Thaler via Boost <
boost_at_[hidden]> wrote:

> This is to allow further customization points without an additional policy
> argument.
> One issue with the approach above: It isn't clear whether 512 is a number
> of elements or bytes.
> de::batch_deque<int, de::elements_per_segment<512>> is conceivable tough.
>

In a different but related application, I considered the underlying
allocator (all Windows here), VirtualAlloc
<https://msdn.microsoft.com/en-us/library/windows/desktop/aa366887(v=vs.85).aspx>.
Requesting memory from the OS (bar my understanding) results in at least
one memory page (4096 Kb) to be allocated (or a multiple of that). Not
wanting to let any memory go to waste (it's already allocated anyway), I
defined a template parameter that stipulates the *minimum* number of
objects to be allocated in one segment. One can then calculate the number
of pages required to make up that segment and following that, the number of
objects that are actually being reserved in that segment. All this can
obviously be static constexpr C++14 member functions.

Please comment (anyone), as I might be totally deluded (as I'm still not
really sure on this) and don't mind being put straight (preferably).

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