Java...
-
std::adjacent_difference ist in <numeric> und nicht in <algorithm> definiert.
-
tntnet schrieb:
Java Programme können 4 mal kürzer sein als C++. Manchmal ist es so, manchmal anders herum. Und was für eine sinnfreie Aussage.
Die Frage ist durchaus interessant, da sie einen Einblick in die Abstraktionsmöglichkeiten unterschiedlicher Programmiersprachen gewährt. Mit der "alle haben Recht"-Einstellung kommen wir hier leider nicht weiter.
tntnet schrieb:
Wenn Programme schneller laufen, weniger Speicher verbrauchen, gut wartbar sind oder skalierbar. Das sind Vorteile. Aber wie kurz oder lang der Code ist, ist kein Qualitätskriterium. Das kann ein Hinweis sein. Längerer Code kann schlechter wartbar sein.
Natürlich ist die Länge des Codes ein Qualitätskriterium. Und natürlich muss man dabei Codes vergleichen, die im Bezug auf andere Kriterien einigermassen äquivalent sind -- wie sonst auch immer.
Wenn du die gleiche Funktionalität mit weniger Code erreichen kannst, ohne dabei Vorteile wie Wartbarkeit oder Performance einzubüssen, dann ist der kürzere Code besser. Alleine schon, weil man ihn schneller schreiben und lesen kann, wodurch wiederum weniger Fehler entstehen. Als Konsequenz benötigen Entwicklung und Wartung weniger Zeit.
-
Michael E. schrieb:
std::adjacent_difference ist in <numeric> und nicht in <algorithm> definiert.
Kompiliert aber.
-
In Java ist OOP das zentrale Paradigma, wodurch gewisse Ansätze eher umständlich zu lösen sind. Generell sieht man in Java viel öfter tiefere Vererbungshierarchien als in C++ (z.B. wenn man Collections und STL vergleicht). Beispielsweise werden Callbacks in Java über implementierte Interfaces realisiert, wodurch mehrere Klassen definiert werden müssen. C++ erlaubt hier mit
std::function,std::bind()und Lambda-Ausdrücken viel kompakteren Code, der keineswegs schlechter verständlich ist. Allerdings wird immer wieder erkannt, dass Features fehlen, und entsprechend nachgerüstet. Java soll in Version 8 auch Lambda-Ausdrücke bekommen.Andererseits ist in Java schon vieles vorgefertigt. Gerade wenns um weiterführende Zeichenkettenverarbeitung geht, sucht man in der C++-Standardbibliothek vergebens und muss auf Bibliotheken wie Boost zurückgreifen, oder selbstgestrickte Lösungen verwenden. Zum Beispiel hat die
std::string-Klasse wahnsinnig viele Memberfunktionen, aber sehr viele wichtige Fälle sind doch nicht abgedeckt. Globale Funktionen helfen oft auch nur begrenzt weiter. Für weiterführende Funktionalität wie GUI trifft das umso mehr zu -- mit den richtigen Bibliotheken zur Hand kann man in C++ aber schnell viel erreichen, sofern man genügend Sprachkenntnisse hat. Was leider bei sehr vielen C++-Programmierern ein ernstes Problem ist, wodurch diese mit Java schneller ans Ziel kämen.Die STL-Algorithmen in C++ sind nicht immer ideal. Gerade wenn man etwas Spezielleres braucht, muss man oft komplizierte Lambda-Ausdrücke zusammenbauen. Das hat zur Folge, dass einfache Schleifen oder Range-Based-For gleich viel Code wie die STL-Lösung benötigen, aber besser zu verstehen sind. Gerade Stream-Iteratoren sind recht unelegant in der Anwendung. Iteratoren im Allgemeinen führen zu teilweise kompliziertem Code, alleine schon weil man ständig begin-end-Paare übergeben muss. Hier ist mit Ranges enorm viel Verbesserungspotential vorhanden.
Nathan schrieb:
Kompiliert aber.
Und? Wie dein Compiler die Header handhabt, ist irrelevant -- die automatische Inkludierung ist nicht vom Standard garantiert.
-
Den Teil des Codes habe ich von den Vorpostern übernommen, gebe keine Garantie und so.
-
volkard schrieb:
dto-depp schrieb:
@volkard: Was spricht gegen Dependency Injection (das meintest du doch mit DI?)?
Brauchbare Sprachen brauchen sowas nicht.
+1
-
Nexus schrieb:
Natürlich ist die Länge des Codes ein Qualitätskriterium. Und natürlich muss man dabei Codes vergleichen, die im Bezug auf andere Kriterien einigermassen äquivalent sind -- wie sonst auch immer.
Wenn du die gleiche Funktionalität mit weniger Code erreichen kannst, ohne dabei Vorteile wie Wartbarkeit oder Performance einzubüssen, dann ist der kürzere Code besser. Alleine schon, weil man ihn schneller schreiben und lesen kann, wodurch wiederum weniger Fehler entstehen. Als Konsequenz benötigen Entwicklung und Wartung weniger Zeit.
Verstehe, wir betrachten also Code, der *gleich gut* wartbar ist. Und unter all diesen gleich *gleich gut wartbaren* Codes ist dann der kürzere besser, weil er *besser wartbar* ist. Ja das klingt sinnvoll...
-
Nexus schrieb:
In Java ist OOP das zentrale Paradigma, wodurch gewisse Ansätze eher umständlich zu lösen sind. Generell sieht man in Java viel öfter tiefere Vererbungshierarchien als in C++...
Wobei tiefe Vererbungshierachien meines Erachtens nichts durch "OOP als zentrales Paradigma" zu tun hat. Ich glaube man hätte die Java-Bibliotheken insgesamt sauberer hinbekommen, wenn man sich nicht so verkrampft auf reine Vererbung gestützt hätte. Komposition ist häufig die bessere Variante, und Vererbungshierachien können durchaus auch flach gestaltet werden, ohne flexibilität einzubüsen (eher im Gegenteil).
Nexus schrieb:
Andererseits ist in Java schon vieles vorgefertigt. Gerade wenns um weiterführende Zeichenkettenverarbeitung geht, sucht man in der C++-Standardbibliothek vergebens und muss auf Bibliotheken wie Boost zurückgreifen,...
Wenn es doch nur Themen wie Zeichenketten wären. In anderen Sprachen hat man häufig mehr oder weniger GUI-Standards (selbst wenn es meist mehrere sind, ist die Zahl noch überschaubar und weitgehend im gleichen Stil wie die restliche Bibliothek gehalten), DB-Bibliotheken usw. Das mag den Ansatz der C++ Standardbibliothek zuwieder laufen, ist aber eben eines der Vorteile von Sprachen wie C# und Java.
-
Jester schrieb:
Verstehe, wir betrachten also Code, der *gleich gut* wartbar ist. Und unter all diesen gleich *gleich gut wartbaren* Codes ist dann der kürzere besser, weil er *besser wartbar* ist. Ja das klingt sinnvoll...
Nexus hat nicht "gleich gut wartbar" geschrieben, sondern Code der mehrere vergleichbare Kriterien erfüllt. Wenn ich z.B. unsere Architektur an vergleichbaren Stellen mit ähnlichen Kriterien in C++ und C# vergleiche, habe ich in C# in der Regel den kürzeren lesbareren Code. In einzelnen Bereichen bekomme ich es umgekehrt her, ist aber bislang eher die Ausnahme (und das obwohl meine C++ Kenntnisse besser als in C# sind). Im Endeffekt wird der C# und C++ Code dann doch etwa gleich umfangreich sein, da ich in C# wesentlich mehr umsetze was vorher nicht gegeben war (stärkere Schichtentrennung, Unittests...).
Und nein, ich vergleiche nicht Mathematische Formeln, die machen bei uns den kleinsten Teil aus, sondern alles angefangen von Datenbankzugriffen, Im- und Exportschnittstellen, Algorithmen bis hin zur UI. In rein mathematischen oder akademischen Programmen sieht es vielleicht anders aus, in typischen Businessanwendungen kommt mir C# und Java besser weg, was Wartbarkeit und Umfang bei gleichen Kritierien angeht - natürlich mit anderen Nachteilen (unter C++ würde ich mehr Performance erhalten usw.
-
-lowbyte- schrieb:
volkard schrieb:
dto-depp schrieb:
@volkard: Was spricht gegen Dependency Injection (das meintest du doch mit DI?)?
Brauchbare Sprachen brauchen sowas nicht.
+1
Was hat Dependency Injection mit der Sprache zu tun bzw. wie löst man etwas, dass man in Java mit DI macht in C++?
-
Michael E. schrieb:
std::adjacent_difference ist in <numeric> und nicht in <algorithm> definiert.
Ich weiss zwar gerade nicht auswendig, ob ausser ein paar numerischen Algorithmen noch was anderes in <numeric> ist, aber das ist ein weiteres Problem in C++. Die Standardlibrary ist total unuebersichtlich aufgeteilt. Numerische Algorithmen hat man willkuerlich in einen eigenen Header gesteckt, die Stdlib ist generell schlecht bis gar nicht gegliedert. Von Hierarchien brauch ich gar nicht erst anfangen.
Ich hoffe mal, dass sich da mit dem Modulsystem was tun wird. Ansonsten sehe ich schwarz fuer C++.
-
Was hat Dependency Injection mit der Sprache zu tun bzw. wie löst man etwas, dass man in Java mit DI macht in C++?
Die Frage wurde jetzt mindestens fünf Mal gestellt und keiner beantwortet sie, sondern umgeht sie einfach nur mit hohlen Phrasen wie "das braucht man in C++ nicht".
Das Einzige, was da bisher kam, war knivils Vorschlag die Schichten als Services zu implementieren. Wäre natürlich interessant, wie man dort die Messagequeue implementieren würde. Hat sonst niemand was?
Der Link zu DI bei Stackoverflow pointiert aber die Java-Vorteile nicht in den ersten Antworten. Die Antwort von Adam N (~50 Upvotes) erklärt es imo besser: http://stackoverflow.com/questions/130794/what-is-dependency-injection
Keine Ahnung. Java bietet sich für so Geschäftsanwendungen wahrscheinlich wirklich besser an, weil das Framework bereits da ist. Aber die Sprachmittel von C++ dürften etwas Vergleichbares wohl auch erlauben, aber das ist einfach nicht dafür gemacht? Trotzdem werden ja viele große Entwicklungen mit C++ gemacht, auch von Leuten, die was drauf haben und auch Java kennen. Und mit C++11 kommen viele Sprachmittel dazu, die im Unternehmensbereich ja noch gar nicht verbreitet sind. Hier muss sich erstmal das Wissen durchsetzen, dann kann es ganz neue Chancen geben. Für einen Boom in diversen Feldern wären neue Frameworks, die C++11 auch nutzen, vermutlich sehr förderlich.
Also ist es doch wohl auch für Architekturen gut zu gebrauchen, hat hier niemand andere Lösungen als DI für komplexe und flexible Verbindungen von Objekten zueinander?
-
ähh DI sind Policies? Das ist alles? Man kann auch alles kompliziert ausdrücken
-
Ich kann mit Policies nichts anfangen. Ich kenne von C++ nur policy-based-design und das hat damit nix zu tun...
-
asc schrieb:
Jester schrieb:
Verstehe, wir betrachten also Code, der *gleich gut* wartbar ist. Und unter all diesen gleich *gleich gut wartbaren* Codes ist dann der kürzere besser, weil er *besser wartbar* ist. Ja das klingt sinnvoll...
Nexus hat nicht "gleich gut wartbar" geschrieben, sondern Code der mehrere vergleichbare Kriterien erfüllt.
Ja, gut erkannt, aber jetzt weiter: Wenn ich das Kriterium "gut wartbar" hier nicht benutzen darf, weil dann unsinniger quatsch rauskommt, was heißt das? Ganz klar: kurzer Code geht im wesentlichen in Kriterien wie Korrektheit, Robustheit und Wartbarkeit auf. Es ist daher kein für sich stehendes Qualitätskriterium (anders als von nexus behauptet). Das hätte man aber natürlich auch einfach rausfinden können... http://de.wikipedia.org/wiki/Softwarequalität
-
Ich verstehe, was du meinst. Aber nach dieser Argumentation wären Lesbarkeit und Wartbarkeit auch keine orthogonale Qualitätskriterien, da letzteres stark von ersterem abhängt.
Ah, wie ich sehe, hast du das editiert
Aber es gilt weiterhin: Die Grenzen zwischen den Qualitätskriterien sind teilweise willkürlich gezogen. In deinem Standard überschneiden sich die einzelnen Kriterien (z.B. Modifizierbarkeit-Anpassbarkeit; Zuverlässigkeit-Richtigkeit).
-
otze schrieb:
ähh DI...?
Da sieht man realtiv gut, was man mit DI macht.
http://insidecoding.com/2012/02/03/guice-a-lightweight-di-framework-alternative-to-spring-part-1/
-
Eisflamme schrieb:
Keine Ahnung. Java bietet sich für so Geschäftsanwendungen wahrscheinlich wirklich besser an, weil das Framework bereits da ist. Aber die Sprachmittel von C++ dürften etwas Vergleichbares wohl auch erlauben, aber das ist einfach nicht dafür gemacht? Trotzdem werden ja viele große Entwicklungen mit C++ gemacht, auch von Leuten, die was drauf haben und auch Java kennen. Und mit C++11 kommen viele Sprachmittel dazu, die im Unternehmensbereich ja noch gar nicht verbreitet sind.
Ich arbeite als C++ Entwickler an einer großen Software, und ich hab eine ganze Weile mit Java und C# gearbeitet. Das ist aber keine "Geschäftssoftware", was wir schreiben, dafür würde ich tatsächlich auf jeden Fall Java oder C# nehmen (für Webanwendungen J2EE). Ich finde, das hat nichts mit Sprachmitteln zu tun. Große Teile von unserem Code sind tatsächlich auch einfach unsauber, einiges ist schon über 15 Jahre alt, vieles ist historisch bedingt gewachsen, ohne dass man Zeit für Refactoring fand usw... Ist aber egal, das ist halt eine typische große Real Life Software und viele neuere Module sind recht elegant, insgesamt kann ich gut damit leben. Was mich aber oft stört, sind "Klassen" (bzw. allgemein Funktionalität), die man nicht wiederverwenden kann. Ich denk mir oft, ich brauch irgendwas, sowas ähnliches haben wir doch schon irgendwo, schau mir an, wie das implementiert ist, und kanns dann nicht ohne weiteres wiederverwenden, weil die entsprechenden Klassen bestimmte andere Klassen verwenden, Config Dateien lesen oder sonstiges. Muss es dann meist umbauen und auf "DI" umstellen, in dem ich z.B. Konfigurationsparameter von außen reingebe, Schnittstellen extrahiere und als Strategieklassen reingebe usw. Das hat für mich nichts mit Sprachmitteln zu tun. Das Problem ist, dass viele beim Schreiben einer Klasse nur das konkrete Projekt vor Augen haben und nicht dran denken, das ganze auch etwas flexibler aufzubauen.
Aus meiner Sicht wird C++11 kaum etwas ändern, zumindest bei uns. Das ist ganz interessant für Bibliotheken, vielleicht auch für mathematische/physikalische Programme, aber in unserer eigentlichen Software seh ich erstmal nichts, wo wir irgendwelche C++11 Features brauchen würden.
-
Mechanics schrieb:
Was mich aber oft stört, sind "Klassen" (bzw. allgemein Funktionalität), die man nicht wiederverwenden kann. Ich denk mir oft, ich brauch irgendwas, sowas ähnliches haben wir doch schon irgendwo, schau mir an, wie das implementiert ist, und kanns dann nicht ohne weiteres wiederverwenden...
Anderen wirds mit deinem Code irgendwann auch so gehen. Man kann nie alles für alle richtig machen.
-
........--.. schrieb:
Mechanics schrieb:
Was mich aber oft stört, sind "Klassen" (bzw. allgemein Funktionalität), die man nicht wiederverwenden kann. Ich denk mir oft, ich brauch irgendwas, sowas ähnliches haben wir doch schon irgendwo, schau mir an, wie das implementiert ist, und kanns dann nicht ohne weiteres wiederverwenden...
Anderen wirds mit deinem Code irgendwann auch so gehen. Man kann nie alles für alle richtig machen.
Natürlich. Ist auch jetzt so, ich bau durchaus auch meinen eigenen Code um oder andere bauen meinen Code um. Es geht ja nur ums Prinzip DI vs. "nicht-DI" und was das mit der Programmiersprache zu tun hat.