[C#] Hitta dubbletter i en ListView?

loopa igenom och kolla om alla läggs till i ett set, om någon inte läggs till beror det på att den redan finns (dvs dubblett)

är inte helt hundra på om jag skrivit bra C# kod, är mer Java-utvecklare. (går att göra hasDuplicates mer generisk, ta en lista av typen T och kolla om alla läggs till)

using System;
using System.Collections.Generic;

public class Test
{
	public static void Main()
    {
        string[] text = new string[7] {"hej","jag","heter","viktor","hej","hallo","hej"};

        Console.WriteLine(hasDuplicates(text));;
    }
    
    public static bool hasDuplicates (string[] strings) {
        HashSet<String> noDups = new HashSet<string>(); 
        foreach (string s in strings) {
            if(!noDups.Add(s)) {
                return true;
            }
        }
        return false;
    }
}

EDIT:
går även med

 myStrings.Distinct().Count() != myStrings.Count());

eller bara distinct om du endast vill ha en lista med unika exemplar

bool duplicates = false;
for (int a = 0; a < listView1.Items.Count; a++)
{
    string ext = listView1.Items[a].SubItems[2].Text;
    for (int b = a+1; b < listView1.Items.Count; b++)
    {
        string ext2 = listView1.Items[b].SubItems[2].Text;
        if (ext == ext2) duplicates = true;
    }
}

Kolla så att varje listitems subitem[2]-text förekommer exakt en gång i hela listan:

listView.Items.All(item =>
    listView.Items.Count(x =>
        x.SubItems[2].Text == item.SubItems[2].Text) == 1)

Det där ska vara ett fungerande exempel.

var duplicates = och sedan det jag skrev (förutsatt att din lista heter listView naturligtvis)

Du behöver importera System.Linq med using System.Linq;

Verkligen inte snabbast, men trevlig om du snabbt vill ha tillgång till de items som är dubbletter.

var dict = listView1.Items.GroupBy(item => item.SubItems[1].ToUpper()).ToDictionary(g => g.Key, g => g.ToList())

Bör du få en dictionary med lista av items per filsuffix. Enkel sak därefter att traversera uppslaget och agera på de filsuffixer med fler än en item.

Nåt sånt...

Skickades från m.sweclockers.com

Av alla lösningar som föreslagits här är den med HashSet<> överlägset bäst sett till tidskomplexitet, den är linjär med avseende på antal element i din lista, d.v.s. O(N). Enda mindre nackdelen är att den är den också tar utrymme linjärt mot N, (auxiliary space är O(N)). Denna lösning ger svaret snabbt och du kan även reda ut vilka element som är duplikat.

Näst bäst, om du bara vill veta om det finns duplikat eller ej, är varianten som använder Distinct(). Den kommer ta N*log(N) tid och, förutsatt att man sorterar på ett vettigt sätt, ta utrymme motsvarande log(N) (så är bättre än HashSet<> om utrymme är ett problem).

Sedan kommer dubbel loop, den har fördelen att ta konstant utrymme men har kvadratisk tidskomplexitet, O(N^2)

Värst på alla sätt och vis är Linq lösning (testade bara den som avgör om det finns duplikat eller ej, den som även kan visa duplikaten har samma tidskomplexitet men äter ännu lite mer RAM). Den är överlägset långsammast, den genererar väldigt mycket kortlivade objekt som (temporärt) äter RAM och slöar ner systemet då skräpsamlaren reder ut vilket minne som inte längre används. Rent tidskomplexitetsmässigt är denna O(N^2) och är rätt omöjligt att veta hur mycket utrymme den tar utan att gå igenom implementationen av de saker Linq använder.

Gjorde ett snabbt test på en array med 100.000 element. Varianten med HashMap fixar det i princip omedelbart, Distinct ligger väldigt nära men är något långsammare. Dubbla for-loopar är ca 1000 gånger långsammare än HashMap medan Linq är ungefär en tiopotens till långsammare.

Med Linq kan man göra en del eleganta lösningar, men man ska nog undvika denna finess om effektivitet är ett krav och alltid undvika det i fall där indata är väldigt stort då det blir en hel del overhead.

Gör det som är lättast att läsa och tyda din avsikt med. Jag gissar att det rör sig om så få objekt att eventuella optimeringsvinster är försumliga på vilken dator som helst denna sida 2000-talet.

I ett GUI-fall är tidskomplexitet kanske inte så viktigt. Vad är det för temporära objekt du menar att den booleska Linq-lösningen skapar? Den borde inte skapa något förutom två anonyma funktioner.

Rätt 100 på att

item => arr.Count(x => x == item)

skapar en iterator internt och det löser C#/.Net med att skapa ett objekt som implementerar en tillståndsmaskin. Detta görs för varje element i listan. Men svårt att se hur det skulle kunna förklara en tio till ett skillnad i prestanda mot varianten med två for-loopar, så måste finnas mer overhead än så.

Tidskomplexiteten i GUI är inte viktigt, men däremot så är total exikveringstid för alla saker som körs i GUI-tråden kritiskt om man vill ha ett GUI som inte "laggar". Sedan skapade TS denna tråd för att fråga om det fanns en mer effektiv lösning än den som visas i första posten, Linq-lösningarna är de enda som är mindre effektiva.

Skulle också säga att lösningen med HashSet inte bara är den mest effektiva, det är den som är absolut lättast att förstå av de versioner som även kan peka ut exakt vilka element som är duplikat. Enklast är väl varianten som använder Distinct().

item => arr.Count(x => x == item)

Count borde väl kunna lösa det internt med en vanlig loop men du har nog rätt.

Count är en Linq-metod implementerad via "extension methods" (hela Linq är implementerat så). Det sätt som C# implementerar "extension methods" gör det inte möjligt att optimera implementation beroende på underliggande dynamisk typ, utan man måste göra en implementation som inte antar något annat än IEnumerable vilket betyder att man får iterera igenom allt. C++ skulle kunna göra optimeringar via template specialisering, Java8 kan optimera (vilket även sker i praktiken) motsvarande sak i "streams" då "default/defender methods" har dynamisk binding och inte statisk binding som C#.

Man kan i.o.f.s. använda AsParallel()

var duplicate = arr.AsParallel().All(item => arr.Count(x => x == item) == 1);

skalade väldigt bra i det exempel jag gjorde men trots det så blev det långsammare än två for-loopar + PLinq använder alla 8 CPU-trådar till 100% mot bara 1 för andra lösningar, så inte speciellt effektivt och inte så snällt mot andra saker som eventuellt kör i systemet.

var duplicate = arr.AsParallel().All(item => arr.Count(x => x == item) == 1);

Om jag inte minns fel så görs vissa sådana optimeringar genom att de kollar på runtime-typen av T.

edit: Dock inte för Count(Func<>...)
http://www.dotnetframework.org/default.aspx/4@0/4@0/untmp/DEV...

Vilket Egentligen är ett anti-pattern, eftersom uppsättningen av optimeringar effektivt begränsas till de typer man tog med i beräkningen när man implementerade Enumerable. Detta är en av nackdelarna med reification av typparametrar, vilket i sig är ett väldigt intressant ämne men även väldigt orelaterat till frågan som ställdes så jag får lugna ner mig nu

Det är exakt den slutsats jag dragit när jag suttit och testat ganska mycket olika saker i C#/.Net. Om folk verkligen skrev saker i .Net där det man själv utvecklade var prestandakritiskt skulle man inte längre använda .Net för det presterar rätt dåligt. Frågan är varför MS inte jobbar mer på att fixa till det, för något hände mellan Java6 och Java7 som resulterade i rejält boost i många CPU-bunda program. Oracle har också sagt att runtime-plattformen effektivitet är något de ser som det mest kritiska för dem vad det gäller Java.

Java har idag en väsentligt mycket effektivare runtime-plattform än .Net. Skriver man om just det här Linq-exemplet med Java8 streams så blir det ungefär en tiopotens snabbare på min maskin. Även dubbla for-loop versionen blir 3-4 gånger snabbare.

Men precis som du säger är det säkert ett icke-problem i de program folk typiskt skriver i .Net för det man skriver är bara ett tunt lager mellan en databas och någon form av nätverksanslutet server-ramverk (typiskt IIS).