tags:

views:

784

answers:

8

In the .Net BCL is there a collection data structure similar to list that has a maximum capacity, say configured to 100 items, which when item 101 is added the original first item is popped/removed from the collection thus ensuring the item count never exceeds 100.

I’m using .net 3.5

Thanks in advance

+2  A: 

There's not one available, but it should be easy to write a function to accomplish this with an array or collection.

xpda
A: 

ArrayList.FixedSize() method.

I don't believe this meets his needs. He wanted the new item added and an old one dropped, while ArrayList.FixedSize() will prevent additions to the list.
John Fisher
+1  A: 

You could inherit from whatever existing collection was most appropriate (Stack, Dequeue, List, CollectionBase, etc.) and implement this feature yourself. Just override or replace the Add() method.

John Fisher
Most of those classes won't let you override Add() as it's not virtual.
Dan Diplo
You may not be able to override them, but you can use them in the implementation of your own collection, avoiding most of the labor.
John Fisher
+14  A: 

There is no such collection available but one is fairly easy to write. The best way to do this is to create a new collection type that encapsulates an existing collection type.

For example

public class FixedSizeList<T> : IList<T> {
  private List<T> _list = new List<T>();
  private int _capacity = 100;

  public void Add(T value) {
    _list.Add(value);
    while ( _list.Count > _capacity ) {
      _list.RemoveAt(0);
    }
  }

  // Rest omitted for brevity
}

A couple of answers suggested inheritance as a mechanism. This is certainly not a good route especially if you are deriving from one of the generic collections. These collections are not designed to be inherited from and it is very easy to accidentally circumvent any checks you make an capacity as the result of an Add or Remove method.

The primary reason is that these methods are not virtual so they cannot be overridden. You would be forced to either declare an Add method with a different name (thus confusing your users) or re-declare Add with the new syntax. The latter is a very unsafe because as soon as an instance of your class is passed to a reference of the base type, all of your methods will not be called and the list can grow past capacity.

EDIT

As the comment section discussion has indicated, implementing List<T> is not the best approach here. The reason why is that it violates the substitution principle in several cases. The easiest way to display the problem is imagine if my implementation was passed to the following method. This code should pass for any IList<T> implementation but would fail in this case if the list was at capacity.

public void Example<T>(IList<T> list, T value) {
  var count = list.Count;
  list.Add(value);
  var addedValue = list[count];
}

The only collection interface that can be validly implemented for the specified collection is IEnumerable<T>. I've left my implementation up there as an example. But see ShuggyCoUk's answer for an IEnumerable<T> implementation:

JaredPar
+1 This is an _excellent_ answer! It is nice to hear such a lucid explanation of why you chose to implement `IList<T>` over inheriting from a concrete type.
Andrew Hare
@Andrew Thanks!
JaredPar
Your concept is right, but this is an incredibly inefficient data structure, where every insert once the list is full is O(n) rather than the typical O(1) for a list. A real-world implementation should probably be using a circular buffer.
Greg Beech
Why implement IList<T> here? It doesn't act like an IList<T> -- all the semantics are wrong -- e.g., items change index during Add(). Doesn't this violate the Liskov Substitution Principle? Won't methods accepting an IList<T> break in strange ways if you pass it one of these?
Ken
@Ken - How are the semantics of `IList<T>` not suitable for this implementation? There is nothing about `IList<T>` that precludes the implementation from changing the index of an item based on any of the operations defined in it. What do you think happens to a `List<T>` when you call either of the removal methods?
Andrew Hare
@Ken, yes it would break the substitution principle. I originally implemented IList<T> because the op said "like a list" and that's the first interface that popped into my head. But really if you want a collection which **strictly** implements the implicit contracts of the collection interfaces and has the behavior described by the OP, you can really only implement IEnumerable<T>.
JaredPar
@Greg, yes it is less efficient once it passes the capacity. The code is mainly meant to serve as a sample of the encapsulation principle vs. an inherenitance and not necessarily the most efficient implementation.
JaredPar
Your answer is sounds in all the right parts - feel free to take the window code from mine and just use that
ShuggyCoUk
@ShuggyCoUk, I went ahead and summarized this comment section in my answer and linked down to your implementation.
JaredPar
@Downvoter, can we get a reason please?
JaredPar
+1  A: 

You want a circular buffer. This other SO question already talks about that and it might help provide some ideas for you.

Erich Mirabal
+2  A: 

What you are describing is a circular buffer. I use these occasionally and recently ported some older code into a genericised C# class (attached). This code is part of SharpNeat V2 development.

This has O(1) performance on add and remove oprations whereas the solution posted that encapsulates a List is O(n). This is because removing the 0th item in a list causes all other items to be shuffled down to fill the gap.


using System;
using System.Collections.Generic;
using System.Text;

namespace SharpNeat.Utility
{
    /// 
    /// This is a generic circular buffer of items of type T.  A circular buffer must be assigned
    /// a capacity at construction time. Items can be enqueued indefintely, but when the buffer's 
    /// capacity is reached the oldest values in the buffer are overwritten, thus the buffer is best
    /// thought of as a circular array or buffer.
    /// 
    public class CircularBuffer
    {
        /// 
        /// Internal array that stores the circular buffer's values.
        /// 
     protected T[] _buff;

        /// 
        /// The index of the previously enqueued item. -1 if buffer is empty.
        /// 
     protected int _headIdx;

        /// 
        /// The index of the next item to be dequeued. -1 if buffer is empty.
        /// 
     protected int _tailIdx;

     #region Constructors

        /// 
        /// Constructs a circular buffer with the specified capacity.
        /// 
        /// 
        public CircularBuffer(int capacity)
     {
            _buff = new T[capacity];
      _headIdx = _tailIdx = -1;
     }

     #endregion

     #region Properties

     /// 
     /// Gets the number of items in the buffer. Returns the buffer's capacity
        /// if it is full.
     /// 
     public int Length
     {
      get
      {
       if(_headIdx == -1) 
        return 0;

       if(_headIdx > _tailIdx)
        return (_headIdx - _tailIdx) + 1;

       if(_tailIdx > _headIdx)
        return (_buff.Length - _tailIdx) + _headIdx + 1;

       return 1;
      }
     }

     #endregion

     #region Public Methods

        /// 
        /// Clear the buffer.
        /// 
     public virtual void Clear()
     {
      _headIdx = _tailIdx = -1;
     }

        /// 
        /// Enqueue a new item. This overwrites the oldest item in the buffer if the buffer
        /// has reached capacity.
        /// 
        /// 
     public virtual void Enqueue(T item)
     {
      if(_headIdx == -1)
      { // buffer is currently empty.
       _headIdx = _tailIdx = 0;
       _buff[0] = item;
       return;
      }

      // Determine the index to write to.
      if(++_headIdx == _buff.Length)
      { // Wrap around.
       _headIdx = 0;
      }

      if(_headIdx == _tailIdx)
      { // Buffer overflow. Increment tailIdx.
       if(++_tailIdx == _buff.Length) 
       { // Wrap around.
        _tailIdx=0;
       }
       _buff[_headIdx] = item;
       return;
      }

      _buff[_headIdx] = item;
      return;
     }

        /// 
        /// Remove the oldest item from the back end of the buffer and return it.
        /// 
        /// 
     public virtual T Dequeue()
     {
      if(_tailIdx == -1)
      { // buffer is currently empty.
       throw new InvalidOperationException("buffer is empty.");
      }

      T item = _buff[_tailIdx];

      if(_tailIdx == _headIdx)
      { // The buffer is now empty.
       _headIdx=_tailIdx=-1;
       return item;
      }

      if(++_tailIdx == _buff.Length)
      { // Wrap around.
       _tailIdx = 0;
      }

      return item;
     }

        /// 
        /// Pop the most recently added item from the front end of the buffer and return it.
        /// 
        /// 
     public virtual T Pop()
     {
      if(_tailIdx == -1)
      { // buffer is currently empty.
       throw new InvalidOperationException("buffer is empty.");
      } 

      T item = _buff[_headIdx];

      if(_tailIdx == _headIdx)
      { // The buffer is now empty.
       _headIdx = _tailIdx =- 1;
       return item;
      }

      if(--_headIdx==-1)
      { // Wrap around.
       _headIdx=_buff.Length-1;
      }

      return item;
     }

     #endregion
    }
}


locster
A: 

you can also just override Collection

public class FixedSizeList<T> : Collection<T>
{
    public int MaxItems {get;set;}

    protected override void InsertItem(int index, T item){
        base.InsertItem(index, item);

        while (base.Count > MaxItems) {
            base.RemoveItem(0);
        }
    }
}
Russ Bradberry
Which works fine until passed to a function that takes a List<T>, which will use the base class' Add method and bypass the checks. If you're going to derive from anything, then make it Collection<T> which is actually designed to allow you to do this type of thing.
Greg Beech
noted and changed
Russ Bradberry
You still wouldn't want to do "new void Add" though -- that's just a recipe for disaster. You'd need to override InsertItem to do the checks.
Greg Beech
I didn't even think of that, i updated to reflect this suggestion
Russ Bradberry
+3  A: 

A really simple rolling window

public class RollingWindow<T> : IEnumerable<T>
{
    private readonly T[] data;
    private int head;
    private int nextInsert = 0;

    public RollingWindow(int size)
    {
        if (size < 1)
            throw new Exception();
        this.data = new T[size];
        this.head = -size;
    }

    public void Add(T t)
    {
        data[nextInsert] = t;
        nextInsert = (nextInsert + 1) % data.Length;
        if (head < 0)
            head++;   
    }

    public IEnumerator<T> GetEnumerator()
    {
        if (head < 0)
        {
            for (int i = 0; i < nextInsert; i++)
                yield return data[i];
        }
        else
        {
            for(int i = 0; i < data.Length; i++)
                yield return data[(nextInsert + i) % data.Length];
        }
    }

    System.Collections.IEnumerator 
        System.Collections.IEnumerable.GetEnumerator()
    {
        return this.GetEnumerator();
    }
}
ShuggyCoUk
This is a much better solution for performance.
FlappySocks