Archief - C# lijst met fixed size

Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.

SideShow

Legacy Member
Hallo

Ik heb een lijstobject nodig. Daarbij moet het volgende gebeuren: bij het inserten van een nieuw item, valt de laatste er af, zodanig dat er steeds maar x (in mijn geval 4) aantal waarden aanwezig zijn.

Bestaat er reeds zoiets? Linked list, stack, .. lijkt me allemaaal niet geschikt? Beste oplossing is om zelf een lijst objectje te maken dit gedrag beheert?

NeverwinterX

Legacy Member
Dat zit niet standaard in de library denk ik.
Gebruik een queue of stack met pseudocode toevoeging
Code:
if(lib.count >= max)
   lib.remove
lib.add(element)

SideShow

Legacy Member
Handig, ik had ook gedacht aan de queue, maar ik wil kunnen indexen op de lijst.

SideShow

Legacy Member
Hm, voorlopig simpel opgelost met

Code:
    public class PushArray<T>
    {
        //Fields
        private readonly T[] array;

        //Ctor
        public PushArray(int size)
        {
            if (size < 1) throw  new ArgumentException("Size should be at least 1.", "size");
            array = new T[size];
        }

        //Methods
        public void Add(T newItem)
        {
            array[0] = array[1];
            array[1] = array[2];
            array[2] = array[3];
            array[3] = newItem;
        }

        public T this[int index]
        {
            get
            {
                return array[index];
            }
        }
    }

Vin

Legacy Member
Maak een "circulaire buffer":
- Tabel (array) met vaste grootte
- "back" pointer (int, index waar nieuw element wordt toegevoegd)
- "front" pointer (int, index van eerste element)
- "count" houdt bij hoeveel elementen de buffer bevat

Nieuwe buffer:
- back = front = count = 0

element toevoegen:
- if (back == front && count == array.length) { ++front; front %= array.length)
- array[back] = value; ++back; back %= array.length

voorste element van queue weergeven:
- return array[front];

element verwijderen uit queue:
- ++front; front %= array.length; --count;

indexeren van tabel (index i):
- return array[(i - front + array.length) % array.length];

Kan zijn dat er hier en daar een foutje staat maar je begrijpt het idee wel denk ik.

SideShow

Legacy Member
Recipe4hate zei:
Jouw 'Add' methode ziet er redelijk hard-coded uit?

idd, was een fout

@vin: dat zou idd een betere methode zijn, zeker voor grotere arrays, maar voorlopig ben ik te lui en heb het maar nodig voor 4 elementen

Cycloon

Legacy Member
Niet om nukkig te doen, maar als je de lijst écht enkel voor 4 elementen wil gebruiken dan kan je beter die 'hard coded' add methode gebruiken en geen grootte meegeven. Dit zal qua performantie een kleine verbetering geven. Uiteraard gaat er een klein beetje flexibiliteit verloren, maar zelf dan nog, deze code heb je zo terug gewijzigd als je meerdere elementen wil kunnen toevoegen.

SideShow

Legacy Member
hoe bedoel je? momenteel is de add methode het overschrijven van 1 element in de array en het overschrijven van 1 nummertje, die "current index"

in het andere "hard coded" geval ga je toch net 3 waardes opvragen en 4 waardes wegschrijven?

in ieder geval is het vershil in performantie zeer klein in dit geval .. ik denk dat er weinig commando's zo snel zijn dan een array indexeren en/of primitive values updaten
Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
Terug
Bovenaan