Java...
-
knivil schrieb:
Sone schrieb:
Multithreading
Hä? Das ist doch auch schon "builtin", also die Standard-Lib gibt doch genug her.
Ach, du meinst Multithreading hoert bei std::thread auf? Was mit Concurrent Queues, Reader-Writer-Locks, Monitoren, eigenes Scheduling und andere High-Level-Synchronisationsmechanismen? All das ist einfacher, weil es schon da ist.
Readers-Writer-Locks
boost::shared_mutex
, aber der Rest, da wirste wohl Recht haben.
(Kenn mich ja mit MT nicht aus, daher hole ich mir wahrscheinlich bald die Lektüre dazu)
-
tbb
-
Kellerautomat schrieb:
tbb
Ist die eig. gut?
-
C++ erlaubt einiges an wüsten Syntax-Vergewaltigungen, die bei Java nicht durchgehen bzw gar nicht möglich sind. Preprozessor anyone?
Auch Templates ermöglichen deutlich kürzeren Code, also ist die Aussage erst mal für den Arsch.Bleibt dann eben dabei stehen dass die C++-Standardbibliothek immer noch madig ist, gibt keinen Support für irgendetwas, das nicht auch auf ner Kaffeemaschine sinnvoll einsetzbar wäre. Java ist da besser.
Warum zur Hölle kennt Standard C++ zb. das Konzept Datei aber nicht das Konzept Netzwerksocket? Macht absolut keinen Sinn in meinen Augen.
-
Mechanics schrieb:
Auf der anderen Seite verleitet der in der Java Welt übliche Stil dazu, viel Boilerplate Code zu schreiben, z.B. weil man zig DTO Klassen schreibt.
Ok ernstgmeeinte Frage: wie löst man das Problem, komplexe Domänenklassen über einen Webdienst zu serialisieren ohne DTOs, wenn man keine Serialisierungseinschränkungen in den Domänenklassen haben will?
Sowas macht man doch in C++ nicht, weil man die typischen Business-Anwendungen eher in Java/.Net schreibt, nicht etwa, weil es bessere Lösungen für die Probleme in C++ gäbe?
@volkard: Was spricht gegen Dependency Injection (das meintest du doch mit DI?)?
-
Ich würde mich nicht daran aufziehen wie viele Codezeilen man nun für welche Sprache auch immer benötigt. Wobei ich Oracle in einem Punkt recht gebe: Bei einer typischen Anwendungssoftware die mit ungefähr gleichen Prinzipien umgesetzt wird, liefern wie C# und Java durchaus Codevorteile gegenüber C++. Welcher Faktor dies ausmacht sei einmal dahin gestellt.
Das heißt aber auch nicht das wenn ich eine Anwendung in einer neuen Umgebung mit gänzlich anderen Voraussetzungen neu schreibe, ich Code einspare. Es würde beispielsweise wenig Sinn machen die Codezeilen zu vergleichen, wenn man beispielsweise bei einer Migration von C++ auf C# (zu Java kann ich weniger sagen, daher wähle ich C#) auch die "Spielregeln" ändert.
Wenn ich eine C++ Anwendung habe, deren DB-Komponenten teilweise recht stark mit der Oberfläche verzahnt sind, kaum saubere Trennungen im Programm hat, wenig flexibel ist und ohne Unittests arbeitet, so müsste ich diese auch mit einer Vergleichbar umgesetzten Java oder C#-Anwendung vergleichen.
Wenn ich jetzt aber diese Anwendung Migriere und dabei auf eine 5-Schichtenarchitektur gehe, bei der viele Codeteile sowohl mit einer Web- als auch Clientanwendung usw. zusammenarbeiten können, hier noch Unittests/DI und Co dazu gebe, so haben sich die Rahmenbedingungen auf einmal gänzlich geändert. Ein Codezeilenvergleich macht dann keinerlei Sinn mehr.
Nach meiner Erfahrung spart man aber bei gleichen Ausgangsbedingungen in einer typischen Unternehmenssoftware durchaus merklich Code wenn diese nicht in C++ sondern Java oder C# geschrieben ist. Bei einer sehr einfachen Anwendung werden die Unterschiede aber kaum eine Rolle spielen, und vielleicht sogar der Overhead wegen den zwingenden Klassen den Vorteil der Sprachen zunichte machen.
-
dto-depp schrieb:
@volkard: Was spricht gegen Dependency Injection (das meintest du doch mit DI?)?
Würde mich auch interessieren, bislang sehe ich hier eher viele Vorteile (alleine schon die bessere Testbarkeit wäre für mich ein guter Grund, selbst wenn dies nur ein kleiner Aspekt ist).
-
boost::shared_mutex, tbb
Nun, wir koennen gern alle moegliche und unmoeglichen Bibliotheken aufyaehlen, jedoch sind diese bei Java von Haus aus dabei. Bei Java ist einfach dabei, es gibt sie und alle nutzen die gleiche.
Zu Intels TBB: Deckt alles ab, was einfach zu parallelisieren ist.
Anderes Feld: IPC wie Netzwerk und Sockets. Oder mach eine einfache GUI ... es ist einfach da. Bei C++: Welches Widget-System solls denn sein, warum haben die auch Threads, ich will doch nur Fenster, etc ...
-
dto-depp schrieb:
@volkard: Was spricht gegen Dependency Injection (das meintest du doch mit DI?)?
Brauchbare Sprachen brauchen sowas nicht.
-
Was hat C++, was Java in der Hinsicht unbrauchbarer macht?
Mal ein Anwendungsbeispiel:
Habe hier eine Domänenschicht, also einen komplexen Klassenverband, welcher meine Anwendungsdomäne abbildet.
Darauf basierend eine Prozessschicht, welche Use-Cases auf Basis der Domäne implementiert.
Diese wiederrum nutzt eine Persistenzschicht.
Ganz oben gibt es Webdienste, welche auf Basis der Prozessschicht Anwendungsdienste bereitstellen.
Querschnittsfunktionen (Logging, Transformationen, Sicherheitsaspekte etc.) implementiere ich in einer Infrastrukturschicht, die jede andere Schicht verwenden darf.Mit DI kann ich nun automatisch hierarchisch Abhängigkeiten in den jeweiligen Konstruktor binden lassen, d.h.:
Die Persistenzschicht erhält über den Konstruktor automatisch Kontextinformationen (Datenbankumgebung etc.), der Prozessschicht werden automatisch die Persistenzschicht-Abhängigkeiten zugewiesen, den wichtigen Klassen wird per Konstruktor eine Protokollierungsmöglichkeit gegeben usw.Bei Modultests kann ich die ganzen Abhängigkeiten dann sehr einfach durch Mock-Objekte ersetzen, weil ich sie ja einfach im Konstruktor übergeben kann. Oder ich lass wieder alles per DI machen und ändere nur meine Konfiguration ab.
Welche Vorteile bietet C++, welche mir gegenüber DI diese Dinge vereinfachen? Meines Erachtens könnten sie kaum perfekter gelöst werden.
-
dto-depp schrieb:
Welche Vorteile bietet C++, welche mir gegenüber DI diese Dinge vereinfachen? Meines Erachtens könnten sie kaum perfekter gelöst werden.
Ja, das ist wohl Geschmackssache oder Ansichtssache. Ich find DI auch super, vor allem wie es in EJB 3 oder Spring umgesetzt ist. Wenn man an entsprechenden Anwendungen nicht gearbeitet hat, mag man die Vorteile nicht verstehen. Und DI erzeugt ja keinen Boilerplate, also nicht mehr Code. Was zwar völlig unwichtig ist, aber Thema dieses Threads war.
Das mit den DTOs war jetzt nicht unbedingt so negativ gemeint. Habe ich gesagt, dass ich viel Code schlecht finde und um jeden Preis jede Zeile sparen will? Was mich hierbei aber tatsächlich etwas stört, dass man ab und zu gezwungen wird, DTOs zu schreiben, auch wenn mand as nicht will. Ich kann mich jetzt nicht genau daran erinnern, aber ich hatte vor paar Jahren einen Fall, wo ich keine Lösung gefunden habe, wie ich einfach direkt meine Business Objekte verwenden konnte und gezwungen war, für alles nochmal DTO Klassen zu schreiben. Das hat mich damals ziemlich genervt.
@Sone: ja, in C++ gibts keine Reflection. Deswegen kann man in Java ja auch teilweise kürzeren Code schreiben, darum gings dir doch. Damit kriegt man vieles praktisch umsonst, ohne dafür irgendwas programmieren zu müssen. Das kann bei Geschäftsanwendungen dann schon wieder die Hälfte vom Boilerplate sparen, den man in C++ schreiben müsste und man konzentriert sich auf die eigentliche Business Logik.
-
Rein von der Sprache aus gesehen ist Java C++ nicht sonderlich überlegen, aber in der Praxis leidet Java nicht unter Programmierern mit Performancewahn (=besserer Code) und profitiert stark von der Standardbibliothek.
Beispiel 1: Gegeben eine Zeile aus einer CSV-Datei, "a;b;c;d;e;5;g", was ist der Zahlenwert der 7. Spalte?
1 Zeile Java, >4 Zeilen C++.Beispiel 2: Gib einen Integer i in Binärformat aus. 1 Zeile Java, >40 Zeilen C++.
Oder nehmen wir eine einfache Aufgabe: Kopiere ein Verzeichnis rekursiv. C++ kann das schlicht nicht ohne Zusatzbibliotheken.
Oder komprimiere ein Verzeichnis als Zip. Kann C++ nicht.Das läuft daraus hinaus, dass der C++-Programmierer einige Zeit damit beschäftigt ist, externe Bibliotheken einzubinden, aktuell zu halten, sich in die einzulesen, die der Kollege verwendet hat, Bibliotheken zu ersetzen und Code umzuschreiben weil sie nicht auf Solaris laufen, ...
Die Gegenrichtung ist, alles selber zu implementieren. Regex? Brauch ich nicht, ich schreib den Parser selber. Führt natürlich zu vielen unnötigen Zeilen, vielen Fehlern und langsamen Code.
Insgesamt ist man deshalb in Java produktiver.
-
busibusi schrieb:
externe Bibliotheken einzubinden, aktuell zu halten
Das wär eigentlich alles gar kein Problem wenn es vernünftige Dependency Management-/Buildsysteme für C++ geben tät, a la Maven oder Gradle. Danach suchste aber vergebens...
-
busibusi schrieb:
Beispiel 2: Gib einen Integer i in Binärformat aus. 1 Zeile Java, >40 Zeilen C++.
#include <iostream> int main(){ for(int i=0;i<20;++i){ unsigned n=i; char d[12],*e=d+12; do *--e='0'+n%2; while(n/=2); std::cout.write(e,12-(e-d))<<'\n'; } }
Wie sieht das in Java aus, also ein ganzen Programm, damit ich es auch testen kann?
Nebenbei, wir wissen doch beide, daß Java längst tot ist. *hihi*
-
Eine Zeile? Kein Ding.
#include <iostream> template <typename T> void print_binary(std::ostream& stream, T i) { i && (print_binary(stream, i / 2), stream << i % 2 ? '1' : '0'); } int main() { print_binary(std::cout, 77); }
-
cooky451 schrieb:
stream << i % 2 ? '1' : '0');
wtf
denk da nochmal drueber nach
-
In Java die Fibonaccizahlen ausgeben, sollte mit 10 Zeilen leicht gehen. In C++ brauchen erfahrene Programmierer schon mal 40 oder mehr Zeilen
http://www.c-plusplus.net/forum/311250
-
allweare schrieb:
In Java die Fibonaccizahlen ausgeben, sollte mit 10 Zeilen leicht gehen. In C++ brauchen erfahrene Programmierer schon mal 40 oder mehr Zeilen
http://www.c-plusplus.net/forum/311250
-
volkard schrieb:
Nebenbei, wir wissen doch beide, daß Java längst tot ist. *hihi*
ich bin kein riesen java-fan, aber: schwachsinn!
mach mal lieber hin, ich will meine fragen an dich von oben beantwortet sehen (mit der DI).
-
dto-depp schrieb:
mach mal lieber hin, ich will meine fragen an dich von oben beantwortet sehen (mit der DI).
Ich merke schon, daß Du die Anforderungen um DI herumgestrickt hast, am Ende also fragst, wie macht man DI ohne DI?
Ich verzettele mich ungern in eine ernsthafte Diskussion mit Unregistrierten. Erst recht nicht in einem so klaren Trollthread.