patterncsharpMinor
Collection that can be modified in a foreach
Viewed 0 times
cancollectionmodifiedthatforeach
Problem
Sometimes you want to add/remove items from a collection inside of a
I'm wondering if this can be automated.
Here's one attempt. I haven't tested this too extensively, but it does pass my tests. Also, since I have very little experience with threads, I have not tried to make it thread safe in any way.
Does this approach work? Are there any potential problems? Can it be improved?
```
#region ForwardingCollection
// A utility class for collection wrappers
public class ForwardingCollection : ICollection
{
public ICollection Items { get; private set; }
public ForwardingCollection(ICollection coll)
{
Items = coll;
}
public virtual void Add(T item)
{
Items.Add(item);
}
public virtual void Clear()
{
Items.Clear();
}
public virtual bool Contains(T item)
{
return Items.Contains(item);
}
public virtual void CopyTo(T[] array, int arrayIndex)
{
Items.CopyTo(array, arrayIndex);
}
public virtual int Count
{
get { return Items.Count; }
}
public virtual bool IsReadOnly
{
get { return Items.IsReadOnly; }
}
public virtual bool Remove(T item)
{
return Items.Remove(item);
}
public virtual IEnumerator GetEnumerator()
{
return Items.GetEnumerator();
}
System.Collections.IEnumerator System.Collections.IEnumerable.GetEnumerator()
{
return GetEnumerator();
}
}
#endregion
#region LoopingCollection
// Probably not a good name
public class LoopingCollection : ForwardingCollection
{
#region FlushingEnumerator
private class FlushingEnumerator : IEnumerator
{
private LoopingCollection coll;
private IEnumerator enumerator;
public FlushingEnumerator(Loo
foreach loop. Since this isn't possible, a common pattern is to add the items to a separate collection, then add/remove those items to the original collection after the foreach is finished.I'm wondering if this can be automated.
Here's one attempt. I haven't tested this too extensively, but it does pass my tests. Also, since I have very little experience with threads, I have not tried to make it thread safe in any way.
Does this approach work? Are there any potential problems? Can it be improved?
```
#region ForwardingCollection
// A utility class for collection wrappers
public class ForwardingCollection : ICollection
{
public ICollection Items { get; private set; }
public ForwardingCollection(ICollection coll)
{
Items = coll;
}
public virtual void Add(T item)
{
Items.Add(item);
}
public virtual void Clear()
{
Items.Clear();
}
public virtual bool Contains(T item)
{
return Items.Contains(item);
}
public virtual void CopyTo(T[] array, int arrayIndex)
{
Items.CopyTo(array, arrayIndex);
}
public virtual int Count
{
get { return Items.Count; }
}
public virtual bool IsReadOnly
{
get { return Items.IsReadOnly; }
}
public virtual bool Remove(T item)
{
return Items.Remove(item);
}
public virtual IEnumerator GetEnumerator()
{
return Items.GetEnumerator();
}
System.Collections.IEnumerator System.Collections.IEnumerable.GetEnumerator()
{
return GetEnumerator();
}
}
#endregion
#region LoopingCollection
// Probably not a good name
public class LoopingCollection : ForwardingCollection
{
#region FlushingEnumerator
private class FlushingEnumerator : IEnumerator
{
private LoopingCollection coll;
private IEnumerator enumerator;
public FlushingEnumerator(Loo
Solution
Your logic has a serious flaw: you expect that the consumer of the collection will iterate it till the end. In reality there are
I think the whole idea of working around this limitation (which was placed intentionally by the .NET team) is not very good. It would be good if you provide examples where you think you will benefit from a collection like this in separate code review posts, and community may suggest a better approach.
break or return keywords, and exceptions that will not follow your expected workflow, and thus you will be stuck with positive numLoops. Note that even moving coll.numLoops-- to Dispose method won't help, as you cannot enforce the user of your collection to call it in case they iterate manually, without foreach.I think the whole idea of working around this limitation (which was placed intentionally by the .NET team) is not very good. It would be good if you provide examples where you think you will benefit from a collection like this in separate code review posts, and community may suggest a better approach.
Context
StackExchange Code Review Q#83419, answer score: 9
Revisions (0)
No revisions yet.