[circular_buffer] Is it usable in embedded contexts?

From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2024-08-10 13:03:34

Hi Everyone,
This is a couple of questions about Boost.Circular_buffer, but also about
Boost in general.

A colleague of mine says he needs a ring buffer for usage in the embedded
context, and I am investigating why he chooses to write his own rather than
using Boost.Circular_Buffer, even though he knows the latter exists.

It is a natural expectation for containers like
static_vector/inplace_vector, array, circular_buffer to be a natural fit
for the embedded contexts, as, at least in principle, they should not
require any memory allocation.

Question 1: Is Boost a suitable place for libraries targeting systems where
exceptions, RTTI and memory allocation are banned?

I tried to check what Boost.Circular_Buffer offers, and I was surprised
that it requires at least one, initial allocation. Maybe I could get away
with a custom allocator, but then why do we have static_vector, rather than
the advice to use std::vector with "in-place allocator"?

Question 2: Is it a reasonable expectation of a ring buffer to not require
allocations?

I tried to find more details in the docs, but I found that the entire
reference documentation for class template circular_buffer is missing from
the docs.

Question 3: Is Boost.Circular_Buffer actively maintained? The last commit
is from three years ago.

One thing, my colleague says, that puts him off from even considering
Boost.Circular_Buffer is the amount of headers that circular_buffer.hpp
directly and indirectly includes. This dwarfs the number of headers in his
entire project. Also the fact that Boost.Circular_Buffer includes the
standard headers is problematic, as some standard-mandated headers are not
available on some embedded platforms.

A lot of these dependencies are for emulating C++11 features, like
static_assert, which may not be necessary if we assume some C++11 level of
compiler conformance.

Question 4: Maybe there would be a value, at least for some Boost
libraries, to provide a single-header, header-only variant that works under
some assumptions, like C++11 compiler?

My colleagues use case is that, because removals from the buffer can occur
asynchronously, when doing a pop_back() there is no way to be sure that the
buffer is non-empty, so this would require a function that does the check
and the pop_back at one go.

I am interested to learn what others think about this. Ideally, I would
like for Boost to be in a state where developers prefer to use it rather
than writing their own popular components.

Regards,
&rzej;