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. When you do buffer* buf = rb.start_write(10); The variable `buf' is stored inside the ring buffer, so that the commit operation only change the position of the write cursor. One possible way to do that is to define buffer as struct buffer { size_type size; byte_type data[]; }; a more generic interface would be useful for some use cases, where you
can directly access the storage may be useful for some use cases, but when i originally wrote the class, it didn't include it, as i was a bit afraid that the interface might be a bit too fragile. but i don't have a very strong opinion on this.
The interface is quite low level, and mostly meant to be used by subclass. Maybe I should have started with that, but the range of problems I'm trying to solve boil down to passing network packets or messages from one thread to another. This could also apply to audio software in general, were the producer and the consumer work in different threads at different pace.
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 ? -- Raphaël Londeix http://hotgloupi.fr