Closed abeimler closed 1 year ago
Thanks! I also have been working on an implementation, but discovered a serious bug in FixedDeque
.
Going for the full FixedDeque
API.
The is_full()
vs available()
differentiation came up as well (but I haven't addressed that yet).
edit: Actually I misread available()
.
The consideration I had in mind was that while FixedCircularBuffer
can be full because size() == MAXIMUM_SIZE
, you can always still push to it anyway, which is different than all other fixed_containers.
This means the following usual pattern doesn't quite fit FixedCircularBuffer
if (is_full(x))
{
x.push_back(....);
}
May not be a problem, however.
Will push the current WIP in a few hours.
Here is what I have so far: https://github.com/teslamotors/fixed-containers/pull/80 The second to last commit ("[FixedDeque] Rework deque state/iterators to fix iterator desync ") is the aforementioned serious bug. The last commit is adding the new container.
Merged as part of #80 under the name FixedCircularQueue
, to differentiate from FixedCircularDeque
.
Hi, I added a first
FixedCircularBuffer
implementation (#76) (you can use it as a draft and extend it). I added some features I use on my own.FixedQueue
(usesFixedDeque
)_was not sure if or how to use
CircularIntegerRangeIterator
, so I used a plainsize_t
for the buffer cursor._Had to make some methods
public
inFixedDeque