limit size of Queue<T> in C++

Question

I notice the thread of similar question: http://stackoverflow.com/questions/1292/limit-size-of-queuet-in-net That's exactly what I want to do, but I am not using .net but GNU C++. I have no reference to the base class in GNU C++, so java like super.() or .net like base.() will not work. I have been trying to inherite from queue class but it turns out in vain.

What I want to do: specify the size of the queue, automatic dequeue when the queue is full. To be specific: if the maximum size of my queue is 2, when i push the 3rd item, the 1st item will be automatically popped out before pushing the new item.

How to implement such a queue?

Thanks.

Answer 1

Make a new class that encapsulates the queue and enforce a size limit in the new class.

Answer 2

Check out the standard containers here:

http://www.sgi.com/tech/stl/table%5Fof%5Fcontents.html

Answer 3

Assuming that by Queue<T> you mean std::queue<T>: A queue is just an adapter for some underlying container that's passed at compile-time. You could use a container that already does what you want. The best fit seems to be a circular buffer, if you can find one that supports the operations necessary for std::queue (I think that's push_back(), pop_front(), and size(), but I haven't checked).

Answer 4

It sounds like boost::circuclar_buffer does what you're looking for:

Writing to a Full Buffer

There are several options how to cope with the case if a data source produces more data than can fit in the fixed-sized buffer:

1. Inform the data source to wait until there is room in the buffer (e.g. by throwing an overflow exception).
2. If the oldest data is the most important, ignore new data from the source until there is room in the buffer again.
3. If the latest data is the most important, write over the oldest data.
4. Let the producer to be responsible for checking the size of the buffer prior writing into it.

It is apparent that the circular_buffer implements the third option. But it may be less apparent it does not implement any other option - especially the first two. One can get an impression that the circular_buffer should implement first three options and offer a mechanism of choosing among them. This impression is wrong. The circular_buffer was designed and optimized to be circular (which means overwriting the oldest data when full). If such a controlling mechanism had been enabled, it would just complicate the matters and the usage of the circular_buffer would be probably less straightforward.