Java ist schneller als C++!

[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).

[werbeanruf]

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.

[Hausierer]

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;
}

[werbeanruf]

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
    ...
}

[werbeanruf]

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.

[werbeanruf]

Hat auch keiner behauptet, dass Java Anwendungen alle fehlerfrei sind. Natürlich schützt keine Sprache vor Logikfehlern, aber in C++ hast du zusätzlich noch ne ganz Menge Möglichkeiten mehr, einer Server komplett lahm zu legen, als in Java. Es geht auch nicht darum Java jetzt für alle Echtzeitsteuerungen zu verwenden, die werden sowieso meistens viel besser getestet und haben viel beschränktere Rahmenbedingungen, als ein Server der nach Kundenwünschen gebaut und immer wieder geändert wird, weil der Kunde noch nicht so recht weiß was er will. Für sowas ist Java halt viel besser geeignet als C++.

Shade Of Mine schrieb:

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

Nein, wir sind alle froh, wenn wir ein "Hello World" zum laufen bekommen. Einen Zeiger auf ein ungültiges Objekt hat noch keiner von uns gesehen.

[hustbaer]

@Optimizer:
Dass in der MSDN bei der Beschreibung von C4251 und C4275 viele Dinge erwähnt werden die mit den beiden Warnings garnichts zu tun haben ist ein blöder Fehler für den ich aber nichts kann.
Nun wirst du wieder sagen das sei einfach nur eine Behauptung, aber es hier lang und breit zu erklären ist mir zu aufwändig, vor allem da du sachlichen Argumenten nicht wirklich zugänglich scheinst.

Die Probleme von denen du schreibst können völlig unabhängig davon auftreten ob man nun Code schreibt der eine C4251/C4275 produziert oder nicht. Wenn du das nicht verstehst kann ich dir auch nicht helfen.

Auch lassen sich diese Warnings einfach dadurch beheben dass man zusätzliche Klassen exportiert, was aber die von dir angesprochenen Probleme in keiner Weise löst. Der eigentliche Zweck der Warnings C4251/C4275 ist den Programmierer darauf aufmerksam zu machen dass er evtl. zu wenig exportiert hat, und auf Grund von was auch immer (inlining, ...) Code in Client-Programmen nötig sein könnte der nicht exportiert wurde. Genau das kann aber nicht zu Datenverlust oder ähnlichem führen, sondern lediglich dazu dass ein Client-Programm nicht gelinkt werden kann, weil Exporte fehlen. Da das in den meisten Fällen kein Problem ist (weil man in dem Fall einfach hergeht und entweder etwas umschreibt so dass das nichtmehr passiert, oder die zusätzlich nötigen Klassen einfach auch exportiert) halte ich es für OK die Warnings zu ignorieren.

Dinge die dagegen zu Datenverlust o.ä. führen können produzieren meist KEINE Warning C4251/C4275. Können sie auch nicht, da der Compiler nicht hellsehen kann, und nicht wissen kann was man in Zukunft wo ändern wird ohne Client-Programme neu zu übersetzen.

[Simon2]

tfa schrieb:

Schön, dann sind wir uns einig....

Woraus hast Du das denn gelesen ? Da war wohl der Wunsch der Vater des Gedanken ...

tfa schrieb:

...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).

Wiederholung macht es nicht wahrer. Bring doch mal ein Argument, warum Laufzeit-boundary-checks in C++ "... eine völlig andere Qualität ..." haben sollten als in Java.

Gruß,

Simon2.

[DEvent]

Hat die Java und die Java-VM nicht einen voellig anderen Vorteil: Waehrend C++ Programme im Grunde alles zerlegen koennen, kann ein Java Programm nur im Rahmen der VM arbeiten. In Java gibts ja den SecurityManager http://java.sun.com/docs/books/tutorial/essential/environment/security.html

A security manager is an object that defines a security policy for an application. This policy specifies actions that are unsafe or sensitive. Any actions not allowed by the security policy cause a SecurityException to be thrown. An application can also query its security manager to discover which actions are allowed.

Man hat also mit Java-Programmen noch eine weitere Huerde zu nehmen, wenn man das System abschiessen will: Java Program > Java VM > System, waehrend es bei C++ so aussieht: Programm > System.

Aber im Grunde hindert einen niemanden daran auch fuer C++ Programme einen SecurityManager zu benutzen, der alle C++ Programme ueberwacht.

Wie gesagt, alles was man in Java macht ist keine Magie und ist mit C++ auch moeglich. Nur hat man bei Java schon alles mit dabei und ist bei Java standard. So hat man, ob man will oder nicht, eine sichere Umgebung fuer Java Programme. Ist halt wie mit Ada.

[*john 0]

DEvent schrieb:

Aber im Grunde hindert einen niemanden daran auch fuer C++ Programme einen SecurityManager zu benutzen, der alle C++ Programme ueberwacht.

Da die JVM Teil des laufenden Prozesses ist, kann man ihr nicht vertrauen, es könnten Exploits in ihr vorhanden sein, die es erlauben, daß sich das Java Programm wie ein C++ Programm verhält. Also, muß das OS laufenden Prozesse reglementieren und nicht irgend eine Laufzeitumgebung, da das OS andere Möglichkeiten hat die Rechte einzuschränken wie etwa getrennte Adreßräume, definierte Schnittstellen zu anderen Prozessen etc.

Eine sichere Laufzeitumgebung gibt es nur dann, wenn man das OS entsprechend aufrüstet - siehe Trusted Solaris oder SELinux. Dann ist das Thema unabhängig von der Programmiersprache vom Tisch.

[hehehe]

~john schrieb:

DEvent schrieb:

Aber im Grunde hindert einen niemanden daran auch fuer C++ Programme einen SecurityManager zu benutzen, der alle C++ Programme ueberwacht.

Da die JVM Teil des laufenden Prozesses ist, kann man ihr nicht vertrauen, es könnten Exploits in ihr vorhanden sein, die es erlauben, daß sich das Java Programm wie ein C++ Programm verhält. Also, muß das OS laufenden Prozesse reglementieren und nicht irgend eine Laufzeitumgebung, da das OS andere Möglichkeiten hat die Rechte einzuschränken wie etwa getrennte Adreßräume, definierte Schnittstellen zu anderen Prozessen etc.

Eine sichere Laufzeitumgebung gibt es nur dann, wenn man das OS entsprechend aufrüstet - siehe Trusted Solaris oder SELinux. Dann ist das Thema unabhängig von der Programmiersprache vom Tisch.

Die JVM ist das OS für Java. Dein Argument hebt sich somit selber wieder auf.

[Kenner der OS]

Die JVM ist das OS für Java. Dein Argument hebt sich somit selber wieder auf.

Richtig! Und somit ist das Argument gegen C++ wieder hinfällig. Denn als C++-Anwendung kann man hier die Schuld an das OS schieben. Als C++-Programm hat es mich nicht zu interessieren, wie sicher die Umgebung ist. Ich mache einfach. Denn das OS kann sehr wohl z.B. eine Sandbox liefern und somit die Java-Sandbox für C++-Programme als Ersatz bieten. Für Windows gibts sowas:
http://www.sandboxie.com/

Auf FreeBSD gibt es serienmäßig sowas ähnliches wie eine Sandbox, nennt sich dort Jails (Gefängnisse). Man kann mit wenigen Handgriffen eine Software in einem Gefängnis laufen lassen.

Und ja... die JVM mit ihrer Sandbox ist nur eine andere Abstraktionebene, aber kein besserer Effekt, als ob ich ein C++-Programm in einer Sandboxie oder Jail laufen lasse. Also was soll die Diskussion, das C++ unsicherer ist? Java-Programme sind es auch nicht, da dafür die JVM-Sandbox zuständig ist.

[*john 0]

hehehe schrieb:

Die JVM ist das OS für Java. Dein Argument hebt sich somit selber wieder auf.

Nein, die JVM ist nur unter ganz bestimmten Bedingungen mit einem OS vergleichbar, und zwar dann wenn sie das OS ersetzt. Im Regelfall ist sie nur eine Laufzeitumgebung, die die Stabilität des Programm verbessert und die mögliche Fehlersuche vereinfacht. Eine JVM auf einem normalen OS jedenfalls bietet keinerlei Sicherheit, denn die kann nur vom OS garantiert werden.

[DEvent]

Kenner der OS schrieb:

Und ja... die JVM mit ihrer Sandbox ist nur eine andere Abstraktionebene, aber kein besserer Effekt, als ob ich ein C++-Programm in einer Sandboxie oder Jail laufen lasse. Also was soll die Diskussion, das C++ unsicherer ist? Java-Programme sind es auch nicht, da dafür die JVM-Sandbox zuständig ist.

Mein Punkt war eigentlich der, das man bei Java alles schon standardmaessig hat, ob man will oder nicht. Also Java: Keine Wahl, bei anderen Programmen ist es Optional.

[nananu]

is halt so, hier wird die wirklichkeit einfach mit theoretischen möglichkeiten und spezialfällen vermischt und dann sind alle C++ Programme plötzlich theoretisch so sicher wie Java Programme praktisch immer sind.