Delphi-PRAXiS - Delphi Zahlen Soritieren nach größe

Zitat:

Zitat von Sherlock (Beitrag 1445731)

Es gilt immer noch die Maxime den Datentypen zu verwenden, der am ehesten den Daten entspricht.

Das ist immer eine Frage der Sichtweise. Unter der Annahme, daß es sich immer noch um das in dem anderen Thread beschriebene Problem handelt (und der gezeigte Code lasst das vermuten), liegen die Eingangsdaten in Form einer durch Komma und Leerzeichen separierten Liste von Zahlen vor (string), die am einfachsten durch Zuweisen von CommaText in eine StringList aufgelöst werden kann. Einen recht simplen Weg, diese StringList in die gewünschte Sortierung zu bringen, habe ich gezeigt. Danach werden die einzelnen Zahlen in das Items-Property einer ListBox transferiert, wobei man das entgegen dem gezeigten Code-Beispiel einfach durch Zuweisung der StringList erledigen kann.

Berücksichtigt man all das, reduziert sich der Code auf diese Zeilen:

Delphi-Quellcode:

			function NumberCompareStrings(List: TStringList; Index1, Index2: Integer): Integer;

begin

  Result := string.Compare(List[Index1], List[Index2], [coDigitAsNumbers]);

end;

procedure TForm4.Button1Click(Sender: TObject);

var

  lst: TStringlist;

begin

  lst := TStringlist.create;

  try

    lst.CommaText := Edit1.text;

    lst.CustomSort(NumberCompareStrings);

    ListBox1.Items := lst;

  finally

    lst.Free;

  end;

end;

Man sollte bedenken, daß die einzige Rechtfertigung, das Ganze mit einer TList<Integer> oder Ähnlichem zu realisieren, auf dem Wunsch nach einer bestimmten Sortierung basiert. Sowohl bei der Eingabe im TEdit als auch bei der Ausgabe in die Listbox wird ausschließlich mit Strings gearbeitet. Ändert sich der Sortierwunsch, weil plötzlich keine reinen Zahlen, sondern sowas wie "M1, M2, MM11' oder sonstwas im Editfeld steht, würde der TList<Integer> Ansatz einen womöglich recht aufwändigen Umbau des Codes erfordern und schlimmstenfalls zu einer vollkommen redundanten TList<string> Implementierung führen.

Die hier gezeigte Implementierung ist gegen einen derartigen Requirement-Change stabil oder lässt sich durch eine geeignete Anpassung der Compare-Function mit minimalem Aufwand anpassen. Eine Lösung mit TList<Integer> geht meiner Meinung nach an der Problemstellung vorbei und ist unter den bisher bekannten Rahmenbedingungen vollkommen over-engineered.