I generally prefer plain English over acronyms -- especially since stack and queue are terms and concepts well-understood by computer scientists, but LIFO and FIFO may require mentally deducing which one is which. So my vote is on "stack" and "queue".
As for "ringbuffer", I would consider shortening it to just "ring".
Not bad. Alternatively, consistency with the C++ standard would argue for something like wait_free_queue.
but then, wait_free_queue or spsc_queue? spsc_queue may be better as there are probably going to be more bugs of the sort `spsc data structure used for mpmc operations' than `lock-free data structure used, but wait-free is required'
We should imagine that more specialized queues will be added. So it would be nice to somehow be able to name them, or ask for them via template param.
Here are just *some* of the options that can be combined in various ways: - single vs multiple producer and consumer (typically called spsc,mpmc,spmc,mpsc queues) - node based, array based, hybrid - bounded/unbounded - intrusive / non-intrusive
to add some more confusion: intrusive, but not ABA prone (if the program logic prevents this)
- fail/overwrite/wait on overflow, fail/wait on underflow
is `overwrite' reasonable? and there would be quite a number of options, how to wait: spin, spin-and-yield(), wait for semaphore (it there were a boost.semaphore), wait for condition variable and if, we really want to go that way: - fifo-ordered/lifo-ordered. then we won't even need the stack class and the library could be renamed as lockfree_queue ;)
Could (should?) this be done with template attributes? ie
queue< spsc, bounded, intrusive > myQueue;
Any params not given mean "I don't care, go with default". If you request a queue that is mpmc, hybrid, unbounded, shrinkable, waitable, and we don't have one yet, then it doesn't compile.
there are different opinions about this: some people say that different template arguments should not conflict, while others say this is fine to throw a compile- time error.
Note also that they queues would probably have *almost* the same interface, but some functions like 'size()' might not exist depending on which combination you choose. Maybe that makes it a bad idea.
compile-time assertions can be thrown in this case. i am using this for the (to- be-renamed) ringbuffer to ensure that the correct constructor is used when the data structures is compiled as compile-time-sized vs run-time-sized. cheers, tim