Should an IEnumerable iterator on a Queue dequeue an item

I have created a custom generic queue which implements a generic IQueue interface, which uses the 开发者_JAVA百科generic Queue from the System.Collections.Generic namespace as a private inner queue. Example has been cleaned of irrelevant code.

public interface IQueue<TQueueItem>
{
    void Enqueue(TQueueItem queueItem);
    TQueueItem Dequeue();
}

public class CustomQueue<TQueueItem> : IQueue<TQueueItem>
{
    private readonly Queue<TQueueItem> queue = new Queue<TQueueItem>();
    ...
    public void Enqueue(TQueueItem queueItem)
    {
        ...
        queue.Enqueue( queueItem );
        ...
    }

    public TQueueItem Dequeue()
    {
        ...
        return queue.Dequeue();
        ...
    }
}

I want to keep things consistent with the core implementations and have noticed that the core Queue implements IEnumerable so I will do the same either by explicitly implementing IEnumerable on the class or inheriting it with the IQueue interface.

What I want to know is when enumerating over the queue should each move next dequeue the next item? I have used reflector to see how Microsoft has done it and all they do is step through the queues private array but Microsoft is far from infallible so I wanted to get a general opinion.

public class CustomQueue<TQueueItem> : IQueue<TQueueItem>, IEnumerable<TQueueItem>
{
    ...

    public IEnumerator<TQueueItem> GetEnumerator()
    {
        while (queue.Count > 0)
        {
            yield return Dequeue();
        }
    }

    //Or

    public IEnumerator<TQueueItem> GetEnumerator()
    {
        return queue.GetEnumerator();
    }

    ...
}

I am in two minds, on one hand I feel that iterating through a collection should not changed the collections state but on the other hand and especially with my particular implementation it would make the usage look clean.

EDIT

To put things into context. The class that I am implementing does a Monitor.Wait when Dequeuing and there are no items in the queue. When an item is put onto the queue there is a Monitor.Pulse. This allows for one thread to push stuff onto the queue and the other to essentially "watch" the queue.

From a coding point of view I am trying to decide which it looks cleaner:

foreach(QueueItem item in queue)
{
    DoSomethingWithThe(item);
}

//Or

while(systemIsRunning)
{
    DoSomethingWithThe(queue.Dequeue());
}

For my particular implementation it wouldn't matter if there were multiple process dequeuing items. Because it is a queue they can both pick of an item as no item should be processed more than once, hence the use of a queue.

EDIT

Interestingly enough I have found a blog post where someone has done exactly this.

Link

EDIT

One last stab at this before I close this off. How do people feel about the class not implement IEnumerable but having an IEnumerator GetEnumerator() method that dequeues items? The .net language supports duck typing, foreach being one of the uses. Perhaps this deserves it's own question?

EDIT

Have raised the question of implementing a GetEnumerator method without implementing IEnumerable in another question.

---

Iterators should always be idempotent, that is, don't modify the queue as you iterate over it.

There are no guarantees that there won't be two concurrent iterations...

---

Edit to address your new comments:

When another programmer (such as your future self ;) ) comes along to add features to the code, they may not assume that the iterators are single-use. They might add a log statement that lists what's in the queue just before using it (oops).

Another thing I just thought of is that the visual studio debugger will often enumerate your classes for display. That would cause some extremely confusing bugs :)

If you're implementing a sub-interface of IEnumerable, and don't want to support IEnumerable, you should throw a NotSupportedException. Although this will not give you any compile time warnings, the run time error will be very clear, while a strange IEnumerable implementation could waste future you hours.

---

Absolutely positively there is no way you should be mutating a collection as you iterate it. The whole point of iterators is that they provide a read-only non-destructive view of a collection. It would be deeply surprising to anyone using your code that looking at it changes it.

In particular: you do not want examining the state of your queue in the debugger to change it. The debugger calls IEnumerable just like any other consumer, and if that has side effects, they are executed.

---

I would suggest that you might want to have a method called something like DequeueAll which returns an item of a class that features a GetEnumerator method that represents everything in the queue, and clears the queue (if a queue item is added around the time the iEnumerable is created, the new item should either appear in the present all to AllItemsDequeued and not in the queue, or in the queue but not the present call). If this class implements iEnumerable, it should be constructed in such a way that the returned object will remain valid even after the an enumerator has been created and disposed (allowing it to be enumerated multiple times). If that would be impractical, it may be useful to give the class a name that suggests objects of the class should not be persisted. One could still do

foreach(QueueItem theItem in theQueue.DequeueAll()) {}

but would be less likely to (wrongfully) save the result of theQueue.DequeueAll to an iEnumerable. If one wanted maximum performance while allowing the result of theQueue.DequeueAll to be used as an iEnumerable, one could define a widening cast that would take a snapshot of the DequeueAll result (thus allowing the old items to be discarded).

---

I am going to leave the bandwagon behind and say yes. This seems like a reasonable approach. Though I have to make one suggestion. That is, do not implement this consuming iterator in the GetEnumerator method. Instead call it GetConsumingEnumerator or something similiar. That way it is plainly obvious what is going to happen and the foreach mechanism will not be using it by default. You will not be the first person to do this. In fact, Microsoft already does this in the BCL via the BlockingCollection class and they even used GetConsumingEnumerator as the method¹. I think you know what I am going to suggest next right?²

¹_{How do you think I came up with the name suggestion?} ²_{Why not just use BlockingCollection? It does everything you have asked for and more.}

---

I would say no, do it the second way.

Not only is this more consistent with the built-in Queue class, but it is also more consistent with the fact that the IEnumerable<T> interface is meant to be read-only.

Also, does this really seem intuitive to you?:

//queue is full
foreach(var item in queue)
    Console.WriteLine(item.ToString());
//queue is empty!?

---

Strictly speaking, queue provides only push-back, pop-front, is-empty and maybe get-size operations. Everything that you add beside that is not a part of a queue, so if you decide to provide additional operations, you don't need to keep to the queue's semantics.

In particular, iterators are not a part of the standard queue interface, so you don't need to have them remove the item current being iterated. (As others have pointed out, this would contradict the expectations on iterators as well.)

---

Iterating through the queue should NOT dequeue.

This is designed to see examine the content of the Queue not to dequeue. This is also how MSMQ or MQ Series works.

---

I don't think that it should. It would be very implicit, and it does not communicate that intent to anyone that is used to using the .net framework.

---

I'd say the second one. Your enumerator definitely should not change the state of the collection.

---

I had code where a propperty get was not idempotent... It was such a pain to decode. Please stick with the manual Dequeue.

Also you might not be the only one working on the queue, so it could get messy with more then one consumer.