Quote:
|
Das sehe ich nicht unbedingt als Nachteil. Irgendwie ist es doch auch toll, wenn ein == immer das gleiche macht.
|
Wie gesagt, es ist ein zweischneidiges Schwert. Dass man Mehrfachvererbung rausgelassen hat, kann ich durchaus nachvollziehen. Operatorüberladung hat imho mehr Vorteile als Nachteile.
Es ist nicht Aufgabe des Entwicklers der Sprache, den Programmierern sauberes Programmieren beizubringen. Dass man nur offensichtliche Operatoren überladen sollte, ist eigentlich selbstverständlich.
Dass man Vektoren intuitiv mit + addieren kann, siehst du als Nachteil?
Letztendlich sorgt ja erst Operatorüberladung dafür, dass eine gewisse Menge von Operatoren immer das gleiche tun kann. Ohne sie könntest du nämlich keine eigenen Typen addieren oder vergleichen, auch wenn es Sinn machen würde.
Das wiederum macht gerade die Nutzung von String ziemlich umständlich/unnatürlich (btw. da kann man doch auch mit + konkatenieren), denn man vergleicht diese intuitiv mit == (und gerade bei einem eingebauten Typen (anders als bei C++) sollte das ja wohl drin, immerhin war Operator+ ja auch drin).
Allgemein kann ich deine Argumentation da aber nicht ganz nachvollziehen. Methodenüberladung/überschreibung (z.B. eben von equals) ist doch dann genau so schlecht, denn die Funktionalität kann geändert werden.
Letztendlich werden in C++ halt einfach Operatoren auch als Funktionen angesehen und das finde ich sinnvoll.
Quote:
|
Wieso ist das ein Nachteil?
|
Ebenfalls die Länge. Ein Zugriff über [] ist wesentlich kürzer.
Quote:
|
Wieso hast du leere catch-Blöcke?
|
Weil man nunmal Exceptions nicht nicht catchen darf. Das heißt, dass man sie entweder weiterreichen muss (was im Falle eines Wrappers nicht unbedingt möglich ist und das Problem dann ohnehin nur zum Anwender verschiebt) oder eben catchen und dann ggf. auch nichts tun.
Klar, natürlich kann man Exceptions immer loggen, aber was die Logik des Programms angeht, gibt es manche Fälle, in denen man auf einen Fehler nicht unbedingt reagieren muss oder es gibt ohnehin keine Lösung für den Fehler. Wenn ich eine Verbindung zu einer Datenbank nicht öffnen kann, klar, dann gebe ich das bekannt. Wenn ich sie nicht schließen kann, weil das System sie schon als geschlossen ansieht (z.B. wurde sie vom Gegenüber geschlossen), dann ist das halt so.
Allgemein geht mir das ganze Typsystem von Java auf den Sack, weil es einen dazu zwingt, in jeder Zwischeninstanz Exceptions zu catchen, lokale Variablen aufzuräumen und die Exception weiterzureichen. In C++ ist es dank RAII wesentlich simpler. Wenn ich einen Fehler in einer Funktion nicht behandeln kann, lasse ich es. Die Objekte räumen sich eh selbst auf. Der Fehler wird nur da behandelt, wo es wirklich Sinn macht.
Das erhöht gleichzeitig die Wartbarkeit, sollte sich etwas an der Fehlerbehandlung oder den Fehlern, die eine Funktion werfen kann, ändern.
Quote:
|
Was meinst du (ihr) damit?
|
Das ist nicht mehr ganz aktuell, damals fand ich die Unmöglichkeit von float -> int oder enum -> int ziemlich nervig. Gibt aber auch durchaus Gründe, die dafür sprechen. Imho sollte es dennoch nur eine Warnung und kein Fehler sein.
Konkret stört mich aber noch, wie Integer und int (und Äquivalente) getrennt werden. Java ist da mit der Objektorientierung nicht sehr konsequent. In C# ist ausnahmslos alles eine Klasse. In Java ist int != Integer und das nervt in manchem Kontext.
Quote:
|
Inwiefern wird der Style aufgezwungen?
|
Da steht ein "quasi" ;O
Im Grunde hat ihn jede IDE für automatische Generierung von wiederkehrenden Snippets voreingestellt, die gesamte Community programmiert darin (wenn du also mal 1-2 Zeilen kopierst, kannst du direkt die Klammersetzung abändern)...irgendwann habe ich aufgegeben und für Java angefangen, den K&R Style zu nutzen.
Dass man bei manchen IDEs die Snippets konfigurieren kann, wurde mir erst später gesagt :x
