IEnumerator用法 [英] IEnumerator Usage

问题描述

我一直在为这个

点的想法实验而嘲笑一个想法。我们的想法是创建一个线程安全的集合，实现IEnumerable接口的
。它通过

GetEnumerator方法创建的枚举器将与collction同步;如果

集合发生变化，现有的枚举器将通过一个事件得到通知。

随附的EventArgs派生类对象携带有关更改的信息

集合，以便枚举者可以自己更新

以使枚举保持同步。


这种方法允许在集合中对枚举进行枚举/>
被更改而没有抛出异常。这种方法

在将来的某个时候可能对我有用。


我的问题是：

MoveNext方法声明如果在创建枚举数后修改了集合，则抛出InvalidOperationException

。使用

我上面描述的方法，将不再是这种情况。那么

实现IEnumerator接口是否会被认为是糟糕的设计

但是没有强制执行这个前提条件？我应该放弃实现

IEnumerator接口吗？


使用IEnumerator接口的优点是它允许使用

枚举器与foreach构造无缝结合，所以我会非常喜欢使用它，但我对减弱IEnumerator

规范有疑问。想法？

I''ve been kicking around an idea mostly as a thought experiment at this
point. The idea is to create a thread safe collection that implements
the IEnumerable interface. The enumerators it creates via the
GetEnumerator method would be synchronized with the collction; if the
collection changes, the existing enumerators are notified via an event.
The accompanying EventArgs derived class object carries information
about the change to the collection so that the enumerators can update
themselves to keep the enumerations in sync.

This type of approach allows enumeration over a collection while it is
being changed without an exception being thrown. This type of approach
may be useful to me at some point in the future.

My question is this: the IEnumerator interface specification for the
MoveNext method states that an InvalidOperationException will be thrown
if the collection is modified after the enumerator was created. Using
the approach I described above, this would no longer be the case. So
would it be considered bad design to implement the IEnumerator interface
but not enforce this precondition? Should I abandon implementing the
IEnumerator interface?

The advantage of using the IEnumerator interface is it allows
enumerators to be used seamlessly with the foreach construct, so I would
really like to use it but have my doubts about weakening the IEnumerator
specification. Thoughts?

推荐答案

" Leslie Sanford" < JA ********** @ BiteMeHotmail.com>写道：

"Leslie Sanford" <ja**********@BiteMeHotmail.com> wrote:

我的问题是：
MoveNext方法的IEnumerator接口规范声明如果在创建枚举数后修改了集合，将抛出InvalidOperationException。使用我上面描述的方法，将不再是这种情况。那么实现IEnumerator界面会不会被认为是糟糕的设计
但是没有强制执行这个前提条件？

My question is this: the IEnumerator interface specification for the
MoveNext method states that an InvalidOperationException will be thrown
if the collection is modified after the enumerator was created. Using
the approach I described above, this would no longer be the case. So
would it be considered bad design to implement the IEnumerator interface
but not enforce this precondition?

否！


这是我的看法。还要想到收益率回报。和迭代器

块，它们提供IEnumerator接口，即使它们没有
甚至还有一个集合。


我甚至使用IEnumerator来枚举必须从集合中删除的值，其中我*需要*要删除的值

来自集合之前调用MoveNext。 （因为这就是

必须删除算法的工作原理）。 （nb。有值而不是

引用。）


-

Lucian

No!

That''s my take on it. Also think of "yield return" and iterator
blocks, which offer the IEnumerator interface even though they don''t
even have a collection at all.

I''ve even used IEnumerator to enumerate over values that must be
removed from a collection, where I *require* the value to be removed
from the collection before calling MoveNext. (because that was how the
"must-be-removed" algorithm worked). (nb. with values rather than
references.)

--
Lucian

这是一个糟糕的设计。当你迭代一个集合时，你在调用

迭代的那一刻（这些是语义）对集合'的状态感兴趣。


想象一下，在迭代一个你不能确定它是否已经改变的集合时，必须就一个事件特定时刻做出决定



已更改或者不是。


如果你想创建一个生产者/消费者模式，你应该考虑另一种设计

。


正如MSDN文档中所述通过集合枚举是

本质上不是线程安全的程序。


问候，

Tasos

It is a bad design. When you iterate over a collection you are
interested in the collection''s state at the moment you invoked the
iteration (these are the semantics).

Imagine having to take a decision a particular moment about an event
while iterating a collection that you cannot be sure if it has been
changed or not.

If you want to create a producer/consumer pattern you should consider
an alternative design.

As the MSDN documentation states "Enumerating through a collection is
intrinsically not a thread-safe procedure".

Regards,
Tasos

" Tasos Vogiatzoglou"写道：

"Tasos Vogiatzoglou" wrote:

这是一个糟糕的设计。当你迭代一个集合时，你在调用
迭代的那一刻（这些是语义）对集合的状态感兴趣。

想象一下必须采取决定某个事件的特定时刻
同时迭代一个你不能确定它是否已被改变的集合。


考虑这个例子：假设你有一个程序用于播放/编辑

MIDI文件（我的专业领域）。 MIDI文件由轨道组成

，它们本身由MIDI事件组成。换句话说，每个音轨

是MIDI事件的集合。


假设您想要编辑正在播放的曲目。对于

示例，您可能希望及时移动事件或删除它。


播放MIDI文件主要涉及迭代集合

每个音轨中的MIDI事件（迭代的速度是由定时事件驱动的
）。如果你想编辑这些曲目，因为它们正在播放，你正在修改一个正在迭代的集合

over。


因此，在上面的场景中，我正在考虑创建迭代器，

能够保持自己与轨道集合同步，因为它们正被修改。

。但是，除了IEnumerator之外，这会被认为是糟糕的设计吗？

如果你想创建一个生产者/消费者模式，你应该考虑另一种设计。


嗯，我将研究生产者/消费者的方法。鉴于以上

描述，您能否建议一种将生产者/消费者应用于我的

问题的方法？

正如MSDN文档所述枚举通过集合本质上不是一个线程安全的过程。

It is a bad design. When you iterate over a collection you are
interested in the collection''s state at the moment you invoked the
iteration (these are the semantics).

Imagine having to take a decision a particular moment about an event
while iterating a collection that you cannot be sure if it has been
changed or not.
Consider this example: Suppose you have a program for playing/editing
MIDI files (my area of expertise). MIDI files are made up of tracks
which are themselves made up of MIDI events. In other words, each track
is a collection of MIDI events.

Say that you would like to edit a track as it is being played. For
example, you may want to move an event forward in time or delete it.

Playing a MIDI file essentially involves iterating over the collection
of MIDI events in each track (with the speed of the iteration being
driven by timing events). If you want to edit these tracks as they are
being played, you are modifying a collection as it is being iterated
over.

So with the above scenario, I was thinking of creating iterators that
are capable of keeping themselves in sync with the track collections as
they are being modified.

IEnumerator aside, would this be considered bad design?
If you want to create a producer/consumer pattern you should consider
an alternative design.
Hmm, I will study the producer/consumer approach. Given the above
description, can you suggest a way of applying producer/consumer to my
problem?
As the MSDN documentation states "Enumerating through a collection is
intrinsically not a thread-safe procedure".

这对于.NET提供的集合类是正确的。 />
框架，但它是否必须适用于您自己的自定义集合

类？

This is true of true of the collection classes provided by the .NET
framework, but does it have to hold true for your own custom collection
classes?

这篇关于IEnumerator用法的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！