Unterschied c c++ c#

[Strukturierter Guy]

OOP Guy schrieb:

Argumente eines Betriebsblinden wird er sicherlich hervorbringen können. Ich hoffe ja, es reicht für mehr. Aber das hat er noch nicht getan.
Das Wort "modern" in dem Zusammenhang finde ich auch irgendwie witzig.

Was denkst du, wieso er "modern" schreibt? Weil try-catch jeder Java-Programmierer kann und das nichts besonderes ist. Shade Of Mine erklärt nicht die Grundlagen von Exceptions, dafür gibts einen separaten Artikel. Er zeigt moderne C++-Idiome wie RAII auf, die wunderbar mit Exceptions zusammenarbeiten und eben nicht selbstverständlich sind. Modern, weil diese Thematik vor allem in den letzten Jahren bekannt wurde (unter anderem durch Autoren wie Scott Meyers und Herb Sutter). Es gibt leider auch heute noch massig Programmierer, die C mit Klassen ausüben und keine Ahnung von solchen Techniken haben.

Ausserdem weist Shade ausdrücklich auf Vorteile gegenüber Fehlerbehandlung in C hin und sagt er einiges über exceptionsicheren Code. Lies den Artikel bitte, da steht wirklich sehr Wertvolles drin. Du musst ja nicht den ganzen lesen, aber zumindest den Vergleich mit herkömmlicher Fehlerbehandlung: http://www.c-plusplus.net/forum/viewtopic-var-t-is-219864.html

[krümelkacker]

OOP Guy schrieb:

krümelkacker schrieb:

Bleiben wir doch mal beim Thema. Welches Problem hast Du mit meiner "Der Gag ist..."-Aussage? Meine andere Erklärung dafür, warum Du diese Gegenfrage gebracht hast, ist die, dass Du ein wichtiges Wort übersehen haben könntest und wir somit aneinander vorbeigeredet hätten. Tipp: Das Wort könnte "separat" gewesen sein. Alternativ hätte man auch "einzeln" dafür einsetzen können.

Du spielst darauf an, dass der erste Aufruf, der eine Exception auslöst andere überspringt?

Genau, aber auch nicht nur das. Die Ausführung läuft in der "entsprechenden" catch-clause weiter, welche ganz wo anders stehen kann.

OOP Guy schrieb:

Und, was ist damit?

Damit wäre gezeigt, dass ich Recht hatte: Man muss nicht jeden Funktionsaufruf mit einem eigenen try/catch-Block umhüllen. Nochmal am Beispiel nur für Dich:

doof1 und doof2:

int foo(int a, int b, int&fehler) {          int foo(int a, int b, int&fehler) {
  int x,y,z;                                   int x = fun1(a,2*b,&fehler);
  try {                                        if (fehler) return 0;
    x = fun1(a,2*b);                           int y = fun2(2*b,a,&fehler);
  } catch (soundso&) {fehler=1; return 0;}     if (fehler) return 0;
  try {                                        int z = fun3(a-b,&fehler);
    y = fun2(2*b,a);                           if (fehler) return 0;
  } catch (soundso&) {fehler=2; return 0;}     return x+y+z;
  try {                                      }
    z = fun3(a-b);
  } catch (soundso&) {fehler=3; return 0;}
  fehler = 0;
  return x+y+z;
}

toll:

// Achtung, Funktion kann Ausnahme "soundso" werfen.
int foo(int a, int b) {
  x = fun1(a,2*b);
  y = fun2(2*b,a);
  z = fun3(a-b);
  return x+y+z;
}

Daraus folgt (indirekt): Um catch per if zu emulieren, würdest Du ggf sehr sehr viele if s benötigen, die die eigentliche Ausführungslogik nur unleserlicher machen würden, da schlechtere Trennung von Fehlererkennung und Fehlerbehandlung.

Daraus folgt: Fehlerbehandlung durch if s ist nicht annähernd das gleiche wie Fehlerbehandlung per catch (zB keine 1:1 Entsprechung).

Daraus folgt: Du hast Blödsinn erzählt.

War das so schwer?

Ich finde es sehr traurig, dass man das hier zu Fuß alles nochmal erklären musste -- und zwar jemandem, der sich an einer Diskussion mit dem Titel "C vs C++ vs C#" beteiligt und es besser hätte wissen müssen.

[DEvent]

volkard schrieb:

OOP Guy schrieb:

Clown schrieb:

Wie sehen deine Kenntnisse in C++ aus?

Mittelmäßig würde ich sagen. Kann man selber schlecht einschätzen.

(Tip: *Ein* Geisterfahrer?! Nein, das sind doch hunderte!)

OOP Guy schrieb:

Clown schrieb:

Wieviele Bücher zu C++ hast du schon gelesen?

Eins, den Stroustrup.

Das ist nicht viel.

OOP Guy schrieb:

Clown schrieb:

Seit wie langem programmierst du in C++?

Zuletzt bis vor zwei Jahren, etwa 4 Jahre lang. Seitdem programmierere ich nur noch in C# und C.

Du bist nicht der Erste, der vier Jahre lang C-Code in den C++-Compiler gehauen hat.
Aber VIER Jahre lang und das mit nur einem Buch?
Da muß ich ja jetzt denken, daß Du in der Zweiklassengesellschaft zur Oberschicht, den ausgelernt geborenen Embedded-Programmierern gehörst.

Das ist auch ein Problem mit C++. Man muss erst dicke Bücher von Stroustrup und andere Lesen, um überhaupt vernünftig mit C++ arbeiten zu können. Wenn man mal sagt, dass man X Jahre in C++ programmiert hat und das man an der Sprache A und B kritisiert wird man erstmal mit Büchern erschlagen.

Was ist denn an std::string "nicht Standard"?

Weil so gut wie jede Bibliothek mit ihrem String daherkommt und man am Ende doch einfach char* nimmt.

Nun, das ist eine komplett andere "Werkzeugkiste", die Du da aufmachst. Ich denke, C++ hat seine Existenzberechtigung. Es schafft low- und high-level Programmierung ohne Overhead ("zero overhead principle") zu kombinieren und ist damit auch bequem in "eingeschränkten Umgebungen" nutzbar.

Das ist auch so ein Mythos von C++ der gerne wiederholt wird.

Wenn sich da etwes an einer Schnittstelle ändert, müsste man dann nicht auch den Code anpassen, der diese Schnittstelle benutzt? Und warum sollte man anderen Code neu kompilieren, der überhaupt nichts von dieser Schnittstelle weiß?

Natürlich muss ich das. Aber in C++ muss ich trotzdem alles neu übersetzen. Auch muss ich das komplette Projekt neu übersetzen, wenn sich das private Interface ändert, weil auch das private Interface in den Header Dateien öffentlich ist. Was ich in C übrigens nicht habe. Das ganze wird durch die Pre-Compiled-Header etwas abgemildert, trotzdem ist es absurd das private Interface in den Header Dateien öffentlich machen zu müssen.

Kann das sein, dass Du nur Java und C kennst und glaubst, etwas über C++ zu wissen? Wie viele Erfahrungen hast Du mit C++ gemacht? Wie lange hast Du C++ programmiert? Welche Bücher hast Du zu C++ gelesen?

Ich habe C++ vielleicht an die 4 oder 6 Jahre programmiert. Danach bin ich zu Java gewechselt. C habe ich ebenso 4 oder 6 Jahre programmiert, verwende es aber immer mal wieder. Dann kenne ich noch Php, Ruby, Python, Groovy.

Aber nun werde ich wieder mit Büchern erschlagen. Eine Sprache wird nicht besser, wenn man darüber ganze Bibliotheken mit Büchern füllen kann. Im Gegenteil, eine Sprache ist sehr gut, wenn es darüber überhaupt keine Bücher gibt und man sie "einfach so" verstehen und effektiv benutzen kann. Eine Sprache ist ein Werkzeug um ein Problem zu lösen, dabei soll die Sprache so wenig Hürden wie möglich bieten. Wenn ich eine Sprache für ein Problem verwende und diese Sprache baut mir ganze Berge als Hindernisse auf, dann brauche ich keine Bücher zu lesen. Ich nehme eine andere Sprache und bin glücklich.

Das Argument mit den Büchern ist wie wenn ich ein Boot kaufe, es aber nur schwimmt wenn ich rückwärts fahre. Ich sage das Boot soll auch schwimmen wenn ich vorwärts fahre und du mich erstmal fragst wie viele Bücher ich über das Boot gelesen habe um überhaupt die Nachteile beurteilen zu können.

Jede andere Sprache steht dir nicht im Weg, du kannst dich nur auf das Problem konzentrieren. Außer eben C++.

Man eine Frage an die C++: Wie viele "smart pointer" gibt es inzwischen? Müsste bestimmt an die 50 sein, oder?

[irgendwer]

volkard schrieb:

Aber VIER Jahre lang und das mit nur einem Buch?

Ich hab noch kein einziges Buch zum Thema C++ gelesen und kann besser C++ als die meisten hier. Mir reicht es ein paar Forenbeiträge oder Internetartikel zu lesen. Gut, dass das aber sonst fast keiner kann, ist mir auch schon aufgefallen. Die meisten brauchen irendwie lauter Bücher um sich das Zeugs anzueignen. OOP Guy kann es anscheinend auch nicht.

asc schrieb:

Beginnen wir also nochmal mit der Auflistung der Unterschiede von C++ Exceptions und dem typischen "C Fehlercode"-Behandlungen.

1. Exceptions fängt man genau da, wo man sie behandelt, dies kann einige Aufrufebenen von dem Fehler entfernt sein.
2. Mit Exceptions kann man längere if-Kaskaden umgeben, wenn es um die Allokierung und Freigabe von Ressourcen in Zusammenhang mit RAII-Techniken geht.
3. Ich habe schon etliche Programme gesehen wo man den Rückgabewert von Funktionen ignoriert hat (vergessen usw.), bei einer Exception FÄLLT dies auf.

Interessanterweise werden in C++ auch fast keine Exceptions verwendet, man muss sich nur mal ifstream und Co anschauen. Wer verwendet die denn so, dass sie Exceptions werfen? Die meisten fragen failbits ab. In C++ bastelt man ne ganze Menge, wie z.B. save bool, rum, um Exceptions zu vermeiden. Exceptionssicheren Code in C++ zu schreiben ist auch relativ aufwendig.

[volkard]

edit: Ach, hat ja eh keinen Zweck.

[volkard]

irgendwer schrieb:

In C++ bastelt man ne ganze Menge, wie z.B. save bool, rum, um Exceptions zu vermeiden.

Das glaube ich nicht.

[irgendwer]

volkard schrieb:

irgendwer schrieb:

In C++ bastelt man ne ganze Menge, wie z.B. save bool, rum, um Exceptions zu vermeiden.

Das glaube ich nicht.

Und warum verwendet keiner Exceptions z.B. bei fstreams?

[volkard]

irgendwer schrieb:

volkard schrieb:

irgendwer schrieb:

In C++ bastelt man ne ganze Menge, wie z.B. save bool, rum, um Exceptions zu vermeiden.

Das glaube ich nicht.

Und warum verwendet keiner Exceptions z.B. bei fstreams?

Sorry, ich hatte nur die Aussage bestritten, daß man save bool rumbastelt, um Exceptions zu sparen.

[krümelkacker]

DEvent schrieb:

Was ist denn an std::string "nicht Standard"?

Weil so gut wie jede Bibliothek mit ihrem String daherkommt und man am Ende doch einfach char* nimmt.

Unabhängig davon, ob ich mit Dir darüber einer Meinung bin, hättest Du nicht sagen dürfen "In C++ gibt es nicht einmal eine Standard String-Klasse". Denn das ist falsch. Klar soweit?

DEvent schrieb:

Nun, das ist eine komplett andere "Werkzeugkiste", die Du da aufmachst. Ich denke, C++ hat seine Existenzberechtigung. Es schafft low- und high-level Programmierung ohne Overhead ("zero overhead principle") zu kombinieren und ist damit auch bequem in "eingeschränkten Umgebungen" nutzbar.

Das ist auch so ein Mythos von C++ der gerne wiederholt wird.

Falls Du das nicht mitbekommen hast: Es gibt eine sehr große Fraktion von Leuten, die das bestätigen würden und der man nicht mit einem "Das ist nur ein Mythos" kommen kann. Das prallt einfach effektlos als Nullargument ab. Ich kann auch behaupten, dass Du Blödsinn redest. Glaubst Du mir ja auch nicht.

DEvent schrieb:

Wenn sich da etwes an einer Schnittstelle ändert, müsste man dann nicht auch den Code anpassen, der diese Schnittstelle benutzt? Und warum sollte man anderen Code neu kompilieren, der überhaupt nichts von dieser Schnittstelle weiß?

Natürlich muss ich das. Aber in C++ muss ich trotzdem alles neu übersetzen. Auch muss ich das komplette Projekt neu übersetzen, wenn sich das private Interface ändert, weil auch das private Interface in den Header Dateien öffentlich ist. Was ich in C übrigens nicht habe. Das ganze wird durch die Pre-Compiled-Header etwas abgemildert, trotzdem ist es absurd das private Interface in den Header Dateien öffentlich machen zu müssen.

Zweiter Satz ist falsch. Dritter Satz steht nicht im Widerspruch zu dem, was ich geschrieben habe. Du hast die Hälfte meiner Antwort ignoriert (bzgl "Pimpl-Idiom" welches vergleichbar mit dem Javaverhalten ist). Schreib doch mal etwas, so dass ich Dich ernst nehmen kann.

DEvent schrieb:

Kann das sein, dass Du nur Java und C kennst und glaubst, etwas über C++ zu wissen? Wie viele Erfahrungen hast Du mit C++ gemacht? Wie lange hast Du C++ programmiert? Welche Bücher hast Du zu C++ gelesen?

Ich habe C++ vielleicht an die 4 oder 6 Jahre programmiert. Danach bin ich zu Java gewechselt. C habe ich ebenso 4 oder 6 Jahre programmiert, verwende es aber immer mal wieder. Dann kenne ich noch Php, Ruby, Python, Groovy.

Fein. Zur Kenntnis genommen. Naja, die Bücherfrage kommt immer deswegen, weil es viele Leute gibt, die glauben C++ zu können, wo sie in Wirklichkeit mit der "Werkzeugkiste" nicht klar kommen und diese nicht effektiv einzusetzen wissen. Das eine oder andere gute Buch dazu gelesen zu haben ist keine besondere Leistung, sondern zeigt hauptsächlich, dass man an der Sprache interessiert ist.

DEvent schrieb:

Eine Sprache wird nicht besser, wenn man darüber ganze Bibliotheken mit Büchern füllen kann. Im Gegenteil, eine Sprache ist sehr gut, wenn es darüber überhaupt keine Bücher gibt und man sie "einfach so" verstehen und effektiv benutzen kann.
[...]
Jede andere Sprache steht dir nicht im Weg, du kannst dich nur auf das Problem konzentrieren. Außer eben C++.

Das kannst Du doch so nicht pauschalisieren bzw. von Dir selbst auf Andere schließen. Nicht in einem Thread, wo jeder empfindlich reagiert und auf den kleinsten scheinbaren Widersprich mit "Das ist FALSCH! Du redest Blödsinn!" reagiert.

DEvent schrieb:

Man eine Frage an die C++: Wie viele "smart pointer" gibt es inzwischen? Müsste bestimmt an die 50 sein, oder?

Keine Ahnung. Benutze die Dinger so gut wie gar nicht. Was soll das auch beweisen? Dass man sich in C++ gut eigene Abstraktionen bauen kann? :p Falls Du so etwas brauchst, nimm doch einfach std::tr1::shared_ptr.

[OOP Guy]

krümelkacker schrieb:

Damit wäre gezeigt, dass ich Recht hatte: Man muss nicht jeden Funktionsaufruf mit einem eigenen try/catch-Block umhüllen. Nochmal am Beispiel nur für Dich:

doof1 und doof2:

int foo(int a, int b, int&fehler) {          int foo(int a, int b, int&fehler) {
  int x,y,z;                                   int x = fun1(a,2*b,&fehler);
  try {                                        if (fehler) return 0;
    x = fun1(a,2*b);                           int y = fun2(2*b,a,&fehler);
  } catch (soundso&) {fehler=1; return 0;}     if (fehler) return 0;
  try {                                        int z = fun3(a-b,&fehler);
    y = fun2(2*b,a);                           if (fehler) return 0;
  } catch (soundso&) {fehler=2; return 0;}     return x+y+z;
  try {                                      }
    z = fun3(a-b);
  } catch (soundso&) {fehler=3; return 0;}
  fehler = 0;
  return x+y+z;
}

toll:

// Achtung, Funktion kann Ausnahme "soundso" werfen.
int foo(int a, int b) {
  x = fun1(a,2*b);
  y = fun2(2*b,a);
  z = fun3(a-b);
  return x+y+z;
}

Das wieder mal typisch. Es werden Beispiele gebracht ohne alternativen zu zeigen. Dein Argument kann ich so nicht gelten lassen.

// Achtung, ein negativer Wert gibt einen Fehler an
int foo(int a, int b) {
  int x = fun1(a,2*b);
  int y = fun2(2*b,a);
  int z = fun3(a-b);
  return x+y+z;
}

oder:

// Erklärt sich von selbst
int foo(int a, int b) {
  int err;
  int x = fun1(a,2*b, &err);
  int y = fun2(2*b,a, &err);
  int z = fun3(a-b, &err);
  return err ? err : x+y+z;
}

oder:

// Alle Funktionen setzen ein gemeinsamers Errorflag 
int foo(int a, int b) {
  int x = fun1(a,2*b, &err);
  int y = fun2(2*b,a, &err);
  int z = fun3(a-b, &err);
  return iserror() ? -1 : x+y+z;
}

Das waren nur 3 Vorschläge, wie man multiple if()s vermeiden kann, ohne soetwas wie C++ Exceptions zu brauchen. Es gibt sicherlich noch ein paar Möglichkeiten mehr.

[OOP Guy]

OOP Guy schrieb:

// Alle Funktionen setzen ein gemeinsames Errorflag 
int foo(int a, int b) {
  int x = fun1(a,2*b);
  int y = fun2(2*b,a);
  int z = fun3(a-b);
  return iserror() ? -1 : x+y+z;
}

Copy und Paste Fehler berichtigt

[otze]

OOP Guy schrieb:

Das waren nur 3 Vorschläge, wie man multiple if()s vermeiden kann, ohne soetwas wie C++ Exceptions zu brauchen. Es gibt sicherlich noch ein paar Möglichkeiten mehr.

Sind aber allesamt blödsinn, da sie darauf aufbauen, dass man die ersten auftretenden Fehelr ignorieren und weiter machen kann. leider zerschießt dir fun2 nach einem Fehler in Fun1 die Partitionstabelle deiner Festplatte. Dumm gelaufen.

[krümelkacker]

OOP Guy schrieb:

krümelkacker schrieb:

Damit wäre gezeigt, dass ich Recht hatte: Man muss nicht jeden Funktionsaufruf mit einem eigenen try/catch-Block umhüllen. [...]

Das wieder mal typisch. Es werden Beispiele gebracht ohne alternativen zu zeigen. Dein Argument kann ich so nicht gelten lassen.

Argument? Das war Behauptung (fett zitiert) + Beweis (per Beispiel). Nichts weiter. Das kannst Du drehen, wie Du willst. Wenn Du nach jedem Punkt wieder vergessen hast, worum es geht, bist Du bei mir als ernstzunehmender Gesprächspartner durchgefallen.

[MasterK]

Irgendwie isses schon lustig, wie jemand ums verrecken komm raus versucht, mittels if-statements exceptions das wasser zu reichen. Mir schauderts beim code und vor allem bei den gedankengängen von OOP Guy. Bin ich froh, dass ich mit solchen leuten nicht zusammen arbeiten muss

[Nexus]

OOP Guy, ich hätte noch ein Beispiel. Ein Konstruktor, der dynamisch Speicher anfordert. Im Folgenden siehst du meinen Code, bei dem die Konstruktoren von A , B , C und folglich foo Exceptions werfen dürfen. Aufgabe: Implementiere den äquivalenten Code ohne RAII und Exceptions. Die Klassen A , B und C haben jeweils eine Methode bool valid() const , welche angibt, ob die Konstruktion erfolgreich war. Aber abgesehen vom Flag sollte möglichst nichts an der Semantik geändert werden.

class foo
{
    public:
        foo() : a(new A), b(new B), c(new C)
        {
        }

    private:
        scoped_ptr<A> a;
        scoped_ptr<B> b;
        scoped_ptr<C> c;
};

[Nexus]

DEvent schrieb:

Ich habe C++ vielleicht an die 4 oder 6 Jahre programmiert.

Das ist sehr schwer zu glauben, wenn man solchen "C++"-Code wie auf Seite 6 sieht. Dazu kommen deine unqualifizierten Trollposts. Waren wohl nicht besonders intensive C++-Jahre.

[Shade Of Mine]

OOP Guy schrieb:

Das wieder mal typisch. Es werden Beispiele gebracht ohne alternativen zu zeigen. Dein Argument kann ich so nicht gelten lassen.

Genau darauf habe ich gewartet. Das bringt uns zu einem interessanten Problem. Ich nehme mal den die haeufigst verwendete Variante als Beispiel:

// Erklärt sich von selbst
int foo(int a, int b) {
  int err;
  int x = fun1(a,2*b, &err);
  int y = fun2(2*b,a, &err);
  int z = fun3(a-b, &err);
  return err ? err : x+y+z;
}

Das tolle dabei ist, du hast nachher keine Ahnung mehr warum es fehlgeschlagen ist.

Denn wenn fun1 fehlschlaegt und fun2 auch nur irgendwie von fun1 abhaengig ist, hast du dir mit dem fehlschlagen von fun2 den errno von fun1 ueberschrieben.

Weil du bei einem Fehler nicht abbrichst (und genau das musst du aber tun). Wenn ein Fehler auftritt darfst du nicht weiter Code ausfuehren. Aber das ist ja ein riesen Problem des if-then-else Errorhandlings.

Lies dir mal meinen 2 Artikel ueber Exceptionhandling durch, dir fehlen alle Grundlagen zur Fehlerbehandlung... if-then-else ist intrusive. Per Definition. Exception sind es nicht. Das ist ein enormer Unterschied. Die Denkweise ist eine andere...

@DEvent:
Beim lernen geht es um Denkmuster. Die musst du in C++ genauso lernen wie in Python, Ruby und Java. In C++ schreien die Leute halt wenn man C programmiert. In Java ist der Aufschrei nicht so laut, ich glaube man hat einfach gelernt damit zu leben... Fuer Ruby musst du sowieso viele andere Denkweisen lernen und python verhindert ganz gut dass man C code schreiben kann.

Dennoch muss man Denkweisen lernen. C++ hat es hier am schwersten, da alles wie C aussieht, aber nicht C ist. Deshalb ist das Problem des C codes in C++ am schlimmsten. Java denke ich hat es aber am 2. schlimmsten erwischt. Aber durch das ewige alles in Klassen packen, kann man C Code etwas leichter abwuergen. Nur C++ erlaubt einem halt alles. Deshalb ist das Problem hier (wie du ja an dir selbst und OOP Guy schoen erkennen kannst) am groessten. Denn C code ist legaler C++ code...

zB auf die idee strings als char* zu betrachten. auf so eine idee zu kommen. ne ne ne. Da nimmst du ne Klasse dafuer. ein nocopy string der 2 zeiger auf begin und end der Zeichenkette hat. Wunderbar.

algorithmen sind eh von datenstrukturen abgekoppelt, deshalb ist es auch egal ob du CString oder std::string verwendest, der Code ist eh identisch...

[0xb.x.O51]

Shade Of Mine schrieb:

Nur C++ erlaubt einem halt alles.

C++ ist eine der restriktivsten Sprachen überhaupt - eine Waage zum Abwiegen der Sprachdokumentation und Syntaxdiagramme dürfte reichen, um sich davon zu überzeugen. Es gibt objektorientierte Sprachen, deren Syntaxdiagramme auf ein halbes Faltblatt passen: weniger Regeln heißt mehr Freiheit.

Shade Of Mine schrieb:

algorithmen sind eh von datenstrukturen abgekoppelt,

Aua

[volkard]

0xb.x.O51 schrieb:

Es gibt objektorientierte Sprachen, deren Syntaxdiagramme auf ein halbes Faltblatt passen: weniger Regeln heißt mehr Freiheit.

Das kann man so allgemein nicht sagen. Vegleiche Modula-II mit C++, vergleiche Brainfuck mit Lisp.

0xb.x.O51 schrieb:

Shade Of Mine schrieb:

algorithmen sind eh von datenstrukturen abgekoppelt,

Aua

In der STL sind die recht stark entkoppelt.

[schoklar]

volkard schrieb:

0xb.x.O51 schrieb:

Shade Of Mine schrieb:

algorithmen sind eh von datenstrukturen abgekoppelt,

Aua

In der STL sind die recht stark entkoppelt.

Da kannst du sogar fast eine map nach value sortieren. :p