boostorg/container
1
0
Fork 1
mirror of https://github.com/boostorg/container.git synced 2025-08-01 05:24:31 +02:00
Code Issues Packages Projects Releases Wiki Activity

Fix typos and bad link

Browse Source
This commit is contained in:
Ion Gaztañaga
2024-03-29 22:05:04 +01:00
parent 6291e6c1bd
commit c9e544df83
1 changed files with 4 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
doc/container.qbk
View File

@@ -485,13 +485,13 @@ To avoid unbounded memory waste, Boost.Container's `devector` uses a different s
* If elements are inserted near one extreme and the free space on that extreme is exhausted, all existing elements
are relocated (moved) to the center of the internal memory buffer. This makes room in the exhausted extreme
to insert more elements whihout allocating a new buffer.
to insert more elements without allocating a new buffer.
* Potentially, the maximum number of possible relocations (movements) reusing the memory buffer are Olog(N),
but that would lead non-amortized constant-time insertion at the extremes. In consequence, the number of
relocations must be limited ('relocation limit') and a reallocation (allocation of a new memory buffer) will be
performed if the load-factor of the container defined as (size()/length_of_buffer) surpasses the relocation limit (see
Lars Greger Nordland Hagen's [href http://larshagencpp.github.io/blog/2016/05/22/devector"Double-ended vector - is it useful?"]
Lars Greger Nordland Hagen's [@http://larshagencpp.github.io/blog/2016/05/22/devector "Double-ended vector - is it useful?"]
article for more details.
* This approach offers a reasonable balance between a reasonable memory overhead and performance.
@@ -505,14 +505,14 @@ However, this strategy has also some downsides:
the number of insertions to perform before a reallocation is performed. Depending on which extreme a insertion
takes place, a reallocation might occur or not (maybe there is free capacity at that extreme)
* Instead of removing the `capacity()` member or renaming it to "minimum_capacity()", the definition has been changed
* Instead of removing the `capacity()` member or renaming it to "`minimum_capacity()`", the definition has been changed
to tell the *minimum* number of elements that can be inserted without reallocating. This allows the typical pattern
where:
* If `reserve(n)` is called, `capacity() >= n`
* If `capacity() == n` it is guaranteed that if `size() <= n` no reallocation will occur.
* However the usual container invariant where `size() <= capacity()` does not hold. `size()` can be bigger than
`capacity()` because elements can be always inserted at a extreme with free capacity without reallocation.
`capacity()` because elements can be always inserted at an extreme with free capacity without reallocation.
[endsect]