the ringbuffer will be basically using the same algorithm as the spsc_queue under the hood, but basically separate 'algorithm' from 'storage', right?
That's right, but that's not the main selling point. The idea is to be able to store raw buffers of different sizes, without any external storage or indirection.
don't get me wrong, i definitely see the use case for this! i'm wondering about a good way to unify this under a common API. e.g. i wonder if the spsc_queue could be modified (or specialized for uint8_t), and provide an API that exposes the internal memory layout to the user. i also like the idea to use memory mapping for unwrapping. but again, we need to find a way to formulate this in a nice API and make it cross-platform (i don't have any experience on this)
i suppose, you already had a look at the code of the spsc_queue already?
Yes ! I was a bit confused as there is a class called basic_ringbuffer, but it's mostly there to share some common code, right ?
well, the semantics is a fixed-size single-producer/single consumer wait-free queue, which is implemented via a ringbuffer. it basically encapsulates the algorithm without knowing how the memory is allocated ...