Java in C++ programmieren - Programmier- und Designunterschiede
-
Man kann ja hier öfter sowas wie "man kann auch Java in C++ programmieren" lesen. Was sind denn die großen Unterschiede?
1. C++ erlaubt Metaprogrammierung mit Templates. In Java kann man das manchmal mit Vererbung und Polymorphie nachbauen, manchmal muss man es ganz anders machen.
2. C++ Objekte können auf den Stack und haben hat Destruktoren -> RAII möglich. In Java muss man überall try{} finally{} darum schreiben.
3. In C++ kann man freie Funktionen in Namespaces stecken. In Java macht man das mit static Methoden in Klassen.Weitere?
-
5%Sauerstoff schrieb:
1. C++ erlaubt Metaprogrammierung mit Templates. In Java kann man das manchmal mit Vererbung und Polymorphie nachbauen, manchmal muss man es ganz anders machen.
In welchem Jahrhundert lebst du? Templates gibts in Java seit bald Jahren...
edit: Ah vieleicht meinst du Templateprogrammierung wie es in C++ seit ein oder 2 jahren populaer wird, wo der compiler quasi die berechnung macht... (im gegensatz zur originaeren Einsatzweise von templates), die gibts in Java afaik nicht
2. C++ Objekte können auf den Stack und haben hat Destruktoren -> RAII möglich. In Java muss man überall try{} finally{} darum schreiben.
Das eine hat mit dem anderen nichts zu tun (Stack vs. Exceptionkonzept). Ich glaube mal gelesen zu haben, dass es fuer Java eine Erweiterung gibt um auch den Stack nutzen zu koennen (so in Richtung Embedded und so, Gregor sollte da bescheid wissen!)
3. In C++ kann man freie Funktionen in Namespaces stecken. In Java macht man das mit static Methoden in Klassen.
Stimmt, das ist eine Umgewoehnung. Aber in meinen Augen auch nicht so verkehrt: In meinen Aktuellen Projekten ist es nur die main() die mir deplaziert erscheint. Alle anderen Funktionen gehoeren irgendwie zu Klassen, drum bau ich sie gern da rein.
Wenn du uebrigens nur Java-like in C++ programmieren willst, es gibt Sachen wie smartpointer, garbage collectors und grosse standardbibliotheken auch fuer C++...
-
Korbinian schrieb:
5%Sauerstoff schrieb:
1. C++ erlaubt Metaprogrammierung mit Templates. In Java kann man das manchmal mit Vererbung und Polymorphie nachbauen, manchmal muss man es ganz anders machen.
In welchem Jahrhundert lebst du? Templates gibts in Java seit bald Jahren...
edit: Ah vieleicht meinst du Templateprogrammierung wie es in C++ seit ein oder 2 jahren populaer wird, wo der compiler quasi die berechnung macht... (im gegensatz zur originaeren Einsatzweise von templates), die gibts in Java afaik nicht
In Java gibt es Generics und die haben nicht wirklich viel mit C++ Templates gemeinsam
2. C++ Objekte können auf den Stack und haben hat Destruktoren -> RAII möglich. In Java muss man überall try{} finally{} darum schreiben.
Das eine hat mit dem anderen nichts zu tun (Stack vs. Exceptionkonzept). Ich glaube mal gelesen zu haben, dass es fuer Java eine Erweiterung gibt um auch den Stack nutzen zu koennen (so in Richtung Embedded und so, Gregor sollte da bescheid wissen!)
In C++ gibt es einen Definierten Zeitpunkt wann der Destruktor aufgerufen wird und darum ist RAII möglich z.B. schließen des streams, wenn das Objekt vom stack genommen und dabei zerstört wird. In Java gibt es keine Destruktoren, sondern nur finallize, aber das wird irgendwann vom GC aufgerufen, also kann man nicht erst dann den Stream schließen, sondern muss ein try{...} finally{ stream.close();} machen.
-
Korbinian schrieb:
2. C++ Objekte können auf den Stack und haben hat Destruktoren -> RAII möglich. In Java muss man überall try{} finally{} darum schreiben.
Das eine hat mit dem anderen nichts zu tun (Stack vs. Exceptionkonzept).
Was hat try/finally mit Exceptionkonzept zu tun?
-
Ist das eine Scherzfrage?
-
Ad try/finally/exceptions/raii/blah...:
Es geht um "deterministische Finalisierung", die Java nicht bieten kann.
-
-
fricky schrieb:
http://blog.pwkf.org/post/2008/07/27/RAII-in-Java-to-clean-your-code
selten sowas doofes gelesen... try/finally ist kein ersatz für raii und meistens muss man auf null checken wenn man mehrere voneiannder abhängige resourcen verwendet.
Java ist viel ähnlicher zu C als zu C++.
-
[quote="Shade Of
try/finally ist kein ersatz für raii.
[/quote]
ne, aber die alternative, wenn man raii-ähnliches in java machen will.[quote="Shade Of
Java ist viel ähnlicher zu C als zu C++.
[/quote]
hmmm, deshalb ist mir java wohl so sympathisch.
-
Richtigerweise hätte ich wohl sagen sollen deterministische Finalisierung "die Java nicht unterstützt".
-
hustbaer schrieb:
Richtigerweise hätte ich wohl sagen sollen deterministische Finalisierung "die Java nicht unterstützt".
dazu müsste man den java-GC austauschen, so dass er nach der letzen referenz sofort den speicher freigibt. dann wäre finalize() deterministisch. aber so isses das leider nicht.
-
GC austauschen nützt da nichts. Der kennt ja nicht den Zeitpunkt, wann ein Objekt nicht-erreichbar wird. Das müsste man schon tiefer in der VM verankern.
In Zukunft könnten ARM-Blöcke Abhilfe schaffen, falls die denn mal realisiert werden sollten.
-
Wenn ich das richtig verstehe sind diese ARM Blöcke auch nix anderes als was "using" in C# ist? Dann wäre das zwar ... nunja, besser als nichts, aber IMO nicht wirklich ausreichend.
-
5%Sauerstoff schrieb:
Weitere?
In C++ programmierst du oft funktionaler, besonders wenn du die STL & deren Algorithmen benutzt. Mit C++0x wird sich das wohl noch verschaerfen, wenn wir Lambda's etc. kriegen.
-
hustbaer schrieb:
Wenn ich das richtig verstehe sind diese ARM Blöcke auch nix anderes als was "using" in C# ist? Dann wäre das zwar ... nunja, besser als nichts, aber IMO nicht wirklich ausreichend.
Richtig, nur dass im Gegensatz zu C# mehr als eine Ressource pro Block möglich sein sollen.
-
fricky schrieb:
hustbaer schrieb:
Richtigerweise hätte ich wohl sagen sollen deterministische Finalisierung "die Java nicht unterstützt".
dazu müsste man den java-GC austauschen, so dass er nach der letzen referenz sofort den speicher freigibt. dann wäre finalize() deterministisch. aber so isses das leider nicht.
nein. siehe c++/cli oder D
das objekt modell ist das "problem"
-
Shade Of Mine schrieb:
fricky schrieb:
hustbaer schrieb:
Richtigerweise hätte ich wohl sagen sollen deterministische Finalisierung "die Java nicht unterstützt".
dazu müsste man den java-GC austauschen, so dass er nach der letzen referenz sofort den speicher freigibt. dann wäre finalize() deterministisch. aber so isses das leider nicht.
nein. siehe c++/cli oder D
das objekt modell ist das "problem"nö, man könnte sogar den GC seine arbeit machen lassen wie bisher, nur dass 'finalize()' *sofort* aufgerufen wird, wenn die letzte referenz weg ist. dann wärs auch deterministisch.
-
Nochmal: der GC weiß nicht, wann die letzte Referenz weg ist.
-
Von welchem GC redest du?
-
fricky schrieb:
nö, man könnte sogar den GC seine arbeit machen lassen wie bisher, nur dass 'finalize()' *sofort* aufgerufen wird, wenn die letzte referenz weg ist. dann wärs auch deterministisch.
die performance kosten waeren enorm.
