Java ist schneller als C++!

JustAnotherNoob

Referenzen sind nichts anderes als Aliasnamen, die für eine andere Variable oder anderes Objekt stehen.

Ich glaube nicht, dass das auch auf Javareferenzen zutrifft, nicht umsonst gibt es in C++/CLI eigene Objektzeiger, welche die Referenzen von C# darstellen sollen. Ich glaube Javas Referenzen sind näher an C++ Zeigern, als an C++ Referenzen, man kann halt nur keine Zeigerarithmetik mit ihnen betreiben und somit auf ungültige Addressen(außer null) zugreifen.

aber ich finde C++-Programme sind viel kompakter

Wirklich? C++ Programme kommen doch üblicherweise mit viel mehr Libs u.s.w.

Ich finde es irgendwie lustig, wie so eine Diskussion immer noch soo viele Seiten haben kann.

tfa

stefan2008 schrieb:

Ich finde jede Programmiersprache hat seine Stärken und seine Schwächen. Java verwendet im Gegensatz zur Programmiersprache C++ die Hotspot-Technik, mit dem sich Quelltexte schneller in Bytecodes übersetzen lassen.

Da verwechselst du was. Hotspot hat mit Quelltext in Bytecode übersetzen nichts zu tun. Das macht der Java-Compiler. Hotspot sorgt in der VM dafür, dass Bytecode in Maschinencode der Zielplattform übersetzt und so schneller ausgeführt wird.
Auch ist es falsch pauschal zu sagen, dass Java Hotspot-Technik benutzt. Das ist nur ein Implementierungsdetail bestimmter Laufzeitumgebungen. Früher wurde z.B. alles interpretiert.

Java ist zwar eine moderne Programmiersprache, da sie eine rein objektorientierte Programmiersprache ist.

Java ist auch eine Hybridsprache, zwar ist es nicht so schlimm wie C++, aber primitive Datentypen gibt es hier auch. Vollständig OO sind z.B. Smalltalk und Ruby.

Aber, es bietet nicht das, was C++ bietet. Zum Beispiel verzichtet Java auf Zeiger, das stärkste Werkzeug.

Ein starkes Werkzeug, sich selbst in den Fuß zu schießen.

Einige Java-Programmier denken, dass Referenzen sicherer sind als Zeiger.

Ich hoffe doch, dass das die meisten denken.

Zwar ist es mit der virtuellen Maschine nett gemeint, da man Quelltexte nicht für jedes System neu übersetzen muss, aber ich finde C++-Programme sind viel kompakter und gehen mit Speicheressourcen viel sparsamer um, als ein Java-Programm in Kombination mit der virtuellen Maschine.

Das ist sicherlich richtig, aber Speicher ist billig. Die Vorteile, die mit einer vermeindlich ressourcenhungrigen Laufzeitumgebung erkauft werden, gleichen die Nachteile mehr als aus.

Simon2

stefan2008 schrieb:

...Zum Beispiel verzichtet Java auf Zeiger ...

Nö - es verzichtet nur auf Zeigerarithmetik.
Ansonsten sind Java-Referenzen genau C++-Zeiger - mit ihren Schwächen (können ins Nirvana zeigen, können falsch gecastet werden, ...).
Einzige das Laufen in einer VM lässt einige Effekte dieser Probleme anders aussehen - was aber auch eher nichts mit der Sprache an sich zu tun hat, weil Dich niemand daran hindert, ein C++-Programm in einer VM laufen zu lassen, die sich exakt genauso verhält.

Gruß,

Simon2.

tfa

Eine Java-Refernenz kann ins Nirvana zeigen?

er meint wahrscheinlich NullPointer

rapso

tfa schrieb:

Eine Java-Refernenz kann ins Nirvana zeigen?

solange man arrays indizieren kann (pointer sind nichts anderes), kann man sich die uebel hereinziehen die ptr haben. einmal falsch berechnet beim indiziert und schon hast du deine korruption.

das ist kein bash gegen java ;), ich sag nur, ich hab schon korruptions und memleaks bei ultra-highlevel sprachen debuggen duerfen und das ist nicht anders als bei c++.

Simon2

tfa schrieb:

Eine Java-Refernenz kann ins Nirvana zeigen?

ich denke schrieb:

er meint wahrscheinlich NullPointer

Mit "Nirvana" meinte ich "nicht auf das erwartet Objekt"...

Simon2

rapso schrieb:

...

Nicht übel nehmen, aber ich musste Dein Post 3mal lesen, bevor ich es (semantisch!) verstanden habe, weil Du keine Groß-/Kleinschreibung verwendest.
Finde ich schade, weil es sich in meinen Augen immer lohnt, deine Post zu lesen (und zu verstehen) ...

Gruß,

Simon2.

tfa

rapso schrieb:

tfa schrieb:

Eine Java-Refernenz kann ins Nirvana zeigen?

solange man arrays indizieren kann (pointer sind nichts anderes), kann man sich die uebel hereinziehen die ptr haben. einmal falsch berechnet beim indiziert und schon hast du deine korruption.

Arraygrenzen werden bei Java gecheckt, mit C-Pointern, die irgendwohin zeigen können, kann man das nicht vergleichen. Im schlimmsten Fall zeigst du mit deinem Index auf ein Objekt, das du nicht haben wolltest oder du bekommst eine Exception.

Simon2

tfa schrieb:

...Arraygrenzen werden bei Java gecheckt, ...

Jau - zur Laufzeit. Ist in C oder C++ genauso möglich - wird aber aus Performancegründen nicht immer gemacht (gibt's aber bei genügend Entwicklungsumgebugen konfigurierbar). Der Unterschied besteht lediglich darin, dass Sun festgelegt hat, wie die Laufzeitumgebung auf solche Überschreitungen reagieren soll (selbst der Unterschied ist nicht so groß, weil MS das für C++ ja auch festgelegt hat).

tfa schrieb:

...Im schlimmsten Fall zeigst du mit deinem Index auf ein Objekt, das du nicht haben wolltest ...

Das ist wirklich der schlimmste Fall (und der ist in Java genauso möglich).... eine Exception (sei es nun eine Java- oder C++- oder eine "OS-Exception") macht wenigstens aufmerksam.

Gruß,

Simon2.

rapso

tfa schrieb:

rapso schrieb:

..Im schlimmsten Fall zeigst du mit deinem Index auf ein Objekt, das du nicht haben wolltest oder du bekommst eine Exception.

genau das hab ich gesagt, du hast es verstanden ;), genau so laeuft es ueberall, entweder du indizierst ausserhalb der boundaries, dann wird das von software/hardware massnahmen als error reported, was ne nette sache ist, oder du korrumpierst speicher, was das eigentliche uebel ist dem auch java usw. nicht trotzt.
waehrend java, dank viel mehr boundchecks, dir eher in den nacken springt wenn du ueberindizierst, springt dir eine sprache wie c++ eher in den nacken mit wilden pointern, weil du damit meisstens die objekte dermassen zersaegst, dass das program 'abkackt'. bei korrupieren in java laesst du jedoch die objekte intakt, du arbeitest nur "nicht auf das[dem] erwartet[erwarteten] Objekt".

tfa

Schön, dann sind wir uns einig. Das "ins-Nirvana-zeigen" in C++ hat eine völlig andere Qualität (genaugenommen ist es was völlig anderes). (genaugenommen würde ich einen falschen Array-Index in Java nicht als Nirvana bezeichnen).

Java hat einfach eine viel sichere Umgebung. Wenn du z.B. einen Server programmierst und irgendwo einen Logikfehler drin hast, der unter Bedingungen auftritt die sehr selten vorkommen, dann hast du irgendwo dein catch(Exception) was den Nullpointer loggt und ein rollback macht, aber nicht den ganzen Server abschießt. Sowas in C++ zu machen ist schon extrem schwierig bis unmöglich. Klar, wenn man vom Theoretischen ausgeht, dann sollten solche Fehler nicht im Programm sein und jeder Fehler ist gleich schlimm. Aber in der Praxis passieren solche Fehler halt doch und dann ist man ganz froh, wenn nicht der ganze Server steht und sich hundert Benutzer beschweren, sondern nur einer.

werbeanruf schrieb:

Sowas in C++ zu machen ist schon extrem schwierig bis unmöglich.

Nö, ist es nicht. In C++ benutzt du ja normalerweise keine C Arrays, sondern std::vector. Un std::vector::at ist genauso sicher wir das Äquivalent in Java.

#include <vector>
#include <stdexcept>

int main()
{
  try
    {
      std::vector<int> v(5);
      v.at(10);
    }
  catch(std::out_of_range &e)
    {
      // ...                                                                    
    }
  return 0;
}

Und jetzt mach das mal mit nem Nullpointer.

Shade Of Mine

werbeanruf schrieb:

Und jetzt mach das mal mit nem Nullpointer.

Das sind immer diese flache Argumentation. Wenn man solche groben Fehler hat, muss man sowieso das Subsystem neustarten und zwar so schnell wie moeglich. Natuerlich ist es leichter Fehler in C++ einzubauen als in Java - aber managed Code schuetzt nur vor Bufferoverflows - alle anderen Fehler sind in Java auch Fatal.

Man kann Fehler zwar leichter ignorieren - aber Fehler ignorieren ist boese - denn sobald man einen Fehler ignoriert, kann man nicht mehr garantieren dass der Code korrekt ausgefuehrt wird.

Aber Marketing bei managed Code hat funktioniert.
Wo managed Code natuerlich glaenzt ist beim Debuggen, keine Frage. Aber bei release Code sind Fehler immer fatal. und gerade bei sensitiven Sachen ist es gefaehrlich Fehler zu ignorieren. Und das ist alles was managed Code bieten kann.

Aber was natuerlich stimmt ist, dass man in C++ leichter Fehler machen kann wenn man sich dumm anstellt. Aber schlechter Java Code ist genauso furchtbar - der einzige Vorteil ist, dass schlechter Java Code weniger Sicherheitsluecken hat.

supertux

werbeanruf schrieb:

Und jetzt mach das mal mit nem Nullpointer.

blöde Frage, genügt es nicht zu überprüfen, ob mal einen Null-Pointer bekommen hat? Wieso muss man *alles* mit Exceptions abfangen, wenn es deutlich einfacher geht?

void foo(std::vector<int> *v)
{
    if(v == NULL) DARAUF REAGIEREN
    ...
}

supertux schrieb:

werbeanruf schrieb:

Und jetzt mach das mal mit nem Nullpointer.

blöde Frage, genügt es nicht zu überprüfen, ob mal einen Null-Pointer bekommen hat? Wieso muss man *alles* mit Exceptions abfangen, wenn es deutlich einfacher geht?
void foo(std::vector<int> *v)
{
    if(v == NULL) DARAUF REAGIEREN
    ...
}

Shade Of Mine schrieb:

werbeanruf schrieb:

Und jetzt mach das mal mit nem Nullpointer.

Das sind immer diese flache Argumentation. Wenn man solche groben Fehler hat, muss man sowieso das Subsystem neustarten und zwar so schnell wie moeglich. Natuerlich ist es leichter Fehler in C++ einzubauen als in Java - aber managed Code schuetzt nur vor Bufferoverflows - alle anderen Fehler sind in Java auch Fatal....

Toll jetzt wird es wieder auseinander gerissen. Darum gehts.

werbeanruf schrieb:

Java hat einfach eine viel sichere Umgebung. Wenn du z.B. einen Server programmierst und irgendwo einen Logikfehler drin hast, der unter Bedingungen auftritt die sehr selten vorkommen, dann hast du irgendwo dein catch(Exception) was den Nullpointer loggt und ein rollback macht, aber nicht den ganzen Server abschießt. Sowas in C++ zu machen ist schon extrem schwierig bis unmöglich. Klar, wenn man vom Theoretischen ausgeht, dann sollten solche Fehler nicht im Programm sein und jeder Fehler ist gleich schlimm. Aber in der Praxis passieren solche Fehler halt doch und dann ist man ganz froh, wenn nicht der ganze Server steht und sich hundert Benutzer beschweren, sondern nur einer.

Muss das eigentlich immer sein, dass man mit irgendwelchen Argumenten kommt, die zu einem einzigen Satz passen, aber nicht zum Kontext?

Scheppertreiber

Hochineressante Diskussion.
Und eine Menge Argumente beides nicht zu verwenden.

Der Algorithmus muß stimmen, dann hat auch Laufzeit eine Chance.

Shade Of Mine

werbeanruf schrieb:

Muss das eigentlich immer sein, dass man mit irgendwelchen Argumenten kommt, die zu einem einzigen Satz passen, aber nicht zum Kontext?

Lies meinen Post einfach nochmal. Ich wiederhole mich eh dauernd

Bestes Beispiel ist zB die Challenger Katastrophe. Wo war das Problem? Ein NULL Zeiger? Nein. Die wirklichen Probleme liegen tiefer und eine Access Violation in einem Modul (die Anwendung laeuft doch auf mehreren Modulen, oder?) ist kein Problem - vorallem da man Access Violations in C++ auch fangen kann sondern die Logikfehler die _nicht_ auffallen.

Ich koennte jetzt wieder mit den Standard Zeigern Problemen kommen, dass eben Zeiger auf outdated Objekte zeigen, aber das versteht eh wieder keiner.

Also ja: Java Anwendungen sind immer alle Fehlerfrei.