c++ vs. java... was hat zukunft
-
Gast++ schrieb:
Man könnte das Konzept von IDispatch
http://en.wikipedia.org/wiki/IDispatch
übernehmen.soll man das halbe windows nachbauen
btw: Java bringt seine eigene infrastruktur schon mit, deshalb war die aufgabe von Gregor auch etwas unfair...
-
Gregor schrieb:
Du darfst die C++ Standardbibliothek selbstverständlich verwenden. IMHO gehört die zur Sprache dazu. Ich nutze auch die Java-Standardbibliothek. Allerdings nur den ganz zentralen Kern davon.
So kann man das nicht vergleichen.
Entweder wir lassen auch in Java alle Bibliotheken heraus oder wir lassen in C++ alle externen Bibliotheken zu.Dsss Java eine grössere Laufzeitbibliothek hat als ein Standard-C++ ist unbestreitbar.
Allrdings glaube ich dass eine Lösung mit dem IDispatch-Konzept, ggf RTTI und wenns ganz ganz schlimm kommt mit der Symboltabelle schon recht komplett wäre.
Statt AWT/Swing würde ich dann die MFC, Qt o.ä. einsetzen; das muss erlaubt sein.
Grüsse
*this
-
pale dog schrieb:
btw: Java bringt seine eigene infrastruktur schon mit, deshalb war die aufgabe von Gregor auch etwas unfair...
Es ist unter C++ eine bewusste Designentscheidung, so eine Standardbibliothek zu haben, wie sie existiert und es ist auch eine bewusste Designentscheidung, C++ nicht in einen Pseudocode zu kompilieren, der in einer virtuellen Maschine läuft. Natürlich hat das Auswirkungen auf die Spracheigenschaften und darauf, wie man die Sprache nutzt, was man mit Ihr macht usw..
Daran ist nichts unfaires.
-
pale dog schrieb:
soll man das halbe windows nachbauen
Nein; ich will nicht OLE nachbauen wollen, sondern nur eine Klasse mit einem Introspektionsinterface schaffen und ableiten.
Ich würde sie dann auch IMyDispatch nennen; meinetwegen auch im namespace "pale_dog_scepticism" ...
Grüsse
*this
-
Gregor schrieb:
phlox81 schrieb:
Zum Thema "Java ist sicherer":
http://www.heise.de/newsticker/meldung/89821"Java ist sicherer" ist wie folgt zu verstehen: In Java gibt es Sicherheitskonzepte. Natürlich haben die auch Lücken (Die JVM ist schließlich in C++ geschrieben). In C++ gibt es aber erst gar keine.
In C++ ist dafür das OS zuständig. Z.B. sollte ein OS ein C++-Programm daran hindern, in das OS-Verzeichnis zu schreiben. Oder ebend über Speicherschutz ein Programm zu hindern, auf fremde Speicherbereiche zu zugreifen. Und wer will, kann auch virtualisieren, was einer JVM ähnlich kommt. (mehrere JVM-Instanzen unter Windows
mehrere VirtualPC-Instanzen... als Beispiel) Das was unter Java die VM macht, macht unter C++ das Betriebssystem. Am Ende ist das Verfahren das gleiche: irgendeiner kontrolliert das Programm. Und wenn eine JVM eine Lücke hat, kann das auch ein OS haben. Die Sicherheit ist nur so gut, wie ihr Kontrolleur.
-
Artchi schrieb:
In C++ ist dafür das OS zuständig.
und woher weiss ein OS dass es ein C++ programm ist und kein TurboPascal, Assembler oder ArtchiScript?
-
Sehr witzig! Das Programm wird am Ende in Maschinencode ausgeführt. Kann auch Assembler sein. Und stell dir vor: auch Assembler-Programme unterliegen der Kontrolle des OS. Muss ich dir aber eigentlich nicht erklären, da ich mir denke, das du sowas als C-Programmierer weißt und nur stänkern willst. Du weißt aber genau was ich mit C++-Programm gemeint habe.
-
Artchi schrieb:
Gregor schrieb:
phlox81 schrieb:
Zum Thema "Java ist sicherer":
http://www.heise.de/newsticker/meldung/89821"Java ist sicherer" ist wie folgt zu verstehen: In Java gibt es Sicherheitskonzepte. Natürlich haben die auch Lücken (Die JVM ist schließlich in C++ geschrieben). In C++ gibt es aber erst gar keine.
In C++ ist dafür das OS zuständig. Z.B. sollte ein OS ein C++-Programm daran hindern, in das OS-Verzeichnis zu schreiben. Oder ebend über Speicherschutz ein Programm zu hindern, auf fremde Speicherbereiche zu zugreifen. Und wer will, kann auch virtualisieren, was einer JVM ähnlich kommt. (mehrere JVM-Instanzen unter Windows
mehrere VirtualPC-Instanzen... als Beispiel) Das was unter Java die VM macht, macht unter C++ das Betriebssystem. Am Ende ist das Verfahren das gleiche: irgendeiner kontrolliert das Programm. Und wenn eine JVM eine Lücke hat, kann das auch ein OS haben. Die Sicherheit ist nur so gut, wie ihr Kontrolleur.Meinst Du, die Sicherheitslücke, die da in dem Artikel genannt wurde, hat Ihren Ursprung im Java-Code der Standardbibliothek? Ich denke ja eher, dass man da im C++-Code suchen müsste, der in der JVM ist oder über JNI genutzt wird. Also: Warum schützt das Betriebssystem da nicht?
-
@Gregor
die meisten Betriebssysteme und die meiste Hardware überwacht eben die Prozesse nicht. Das heißt aber nicht das man dafür eine VM braucht. Man siehe zB ADA. Dort gibt es einen sehr hohen Schutz und das ohne eine VM.
-
Es geht ja auch garnicht darum, dass es anders nicht geht, sondern dass der Schutz bei Java halt da ist und bei C++ bei ner typischen Umgebung eben nicht. Das ist doch eigentlich ein ganz klarer Punkt!?
-
Artchi schrieb:
Sehr witzig! Das Programm wird am Ende in Maschinencode ausgeführt. Kann auch Assembler sein. Und stell dir vor: auch Assembler-Programme unterliegen der Kontrolle des OS. Muss ich dir aber eigentlich nicht erklären, da ich mir denke, das du sowas als C-Programmierer weißt und nur stänkern willst.
weiss ich auch.
ich wollte dir nur zeigen, wie peinlich dein versuch war, dem hund ein weiteres bein anzunageln, das ihm noch nicht mal gehört.Artchi schrieb:
Du weißt aber genau was ich mit C++-Programm gemeint habe.
ja, den begriff 'C++' hättest du in deinem beitrag auch ganz weglassen können
-
rüdiger schrieb:
Man siehe zB ADA. Dort gibt es einen sehr hohen Schutz und das ohne eine VM.
naja, 'ne ariane hat's trotzdem zerrissen, obwohl ada verwendet wurde.
aber bitte nicht falsch verstehen: ada ist schon was feines
-
c++ is an insult to the human brain
-
pale dog schrieb:
rüdiger schrieb:
Man siehe zB ADA. Dort gibt es einen sehr hohen Schutz und das ohne eine VM.
naja, 'ne ariane hat's trotzdem zerrissen, obwohl ada verwendet wurde.
aber bitte nicht falsch verstehen: ada ist schon was feines Wenn man W. Kahan glauben darf, dann ist die Striktheit sogar Schuld an dem Desaster. ADA behandelt nämlich Overflows als Exception (bzw. im IEEE754-Sinn als Trap) und nicht als Exception im IEEE754-Sinn (also nur eine Signalisierung des Fehlers).
http://www.cs.berkeley.edu/~ejr/Projects/ieee754/meeting-minutes/02-07-18.html#formal
-
Hier mal eine andere Meinung zu IEEE754:
-
rüdiger schrieb:
Wenn man W. Kahan glauben darf, dann ist die Striktheit sogar Schuld an dem Desaster. ADA behandelt nämlich Overflows als Exception (bzw. im IEEE754-Sinn als Trap) und nicht als Exception im IEEE754-Sinn (also nur eine Signalisierung des Fehlers).
http://www.cs.berkeley.edu/~ejr/Projects/ieee754/meeting-minutes/02-07-18.html#formal
habe da eine andere quelle gefunden die es etwas näher beschreibt...
Ziel war es, die Systemauslastung des SRI-Computers auf 80% zu halten.
Deswegen hat man auch nicht alle Variablen auf einen Überlauf überprüft. Um
eventuelle Probleme bei dem ungeschützten Code auszuschließen, wurde eine
Analyse für jede Variable, die eine Exception verursachen könnte, durchgeführt.
Die Gefahr eines Überlaufs bestand bei sieben Variablen, dabei wurden vier
geschützt, während drei ungeschützt blieben. Bei den drei ungeschützten
Variablen meinte man, dass sie entweder physikalisch limitiert waren und
deswegen keinen Überlauf verursachen konnten, oder man hatte einen großen
Sicherheitsspielraum gelassen, so dass die Werte die obere Grenze nie erreichen
konnten. Jedoch wurden für die Analyse keine Flugdaten der Ariane 5
verwendet, sondern ging von Werten der Ariane 4 aus. Es sollte auch erwähnt
werden, dass die Entscheidung einige Variablen nicht zu schützen in
Übereinstimmung mit den Projektpartnern in mehreren Verträgen erfolgte.http://www4.in.tum.de/lehre/seminare/ps/WS0203/desaster/Riedl-Arianne5-Ausarbeitung-27-11-02.pdf
-
Gregor schrieb:
Hier mal eine andere Meinung zu IEEE754:
Hier ist die Darstellung von Kahan http://www.cs.berkeley.edu/~wkahan/ieee754status/754story.html
naja, ich weiß nicht was stimmt und wie schlecht/gut IEEE754 ist (mache eh nur sehr selten etwas mit Floatingpoint-Arithmetik). Aber immerhin hat der Kahan dafür einen Turing Award bekommen.
-
rüdiger schrieb:
Aber immerhin hat der Kahan dafür einen Turing Award bekommen.
Ob Stroustrup auch einen kriegt?
...schließlich hat der auch nen tollen Standard initiiert.
-
Gregor schrieb:
Meinst Du, die Sicherheitslücke, die da in dem Artikel genannt wurde, hat Ihren Ursprung im Java-Code der Standardbibliothek? Ich denke ja eher, dass man da im C++-Code suchen müsste, der in der JVM ist oder über JNI genutzt wird. Also: Warum schützt das Betriebssystem da nicht?
das OS schützt davor, z.B. das OS-Verzeichnis zu löschen. Ein ganz triviales Beispiel. Und kann der genannte Bug z.B. unter Windows im normalen Benutzer-Modus das OS-Verzeichnis o.a. wichtige Systemeeinheiten kaputt machen? Nein, er kann nur im Userkontext handeln.
Der Bufferoverflow ist erstmal nebensächlich, da der Sicherheitskontext des OS schützt. Der Schadcode kann nur im Userkontext handeln. Oder siehst du das anders?
Ich kann auch in Java das komplette Userhome-Verzeichnis boshaft löschen, ohne das der User es mitbekommt. Die JVM erlaubt das Userhome-Verz. zu löschen, weil das der Userkontext des OS erlaubt. Ist also nicht viel anders als ein natives Programm ohne VM.
Natürlich kann im Java-Bytecode auf der JVM kein Bufferoverflow passieren. Aber das hat dann nichts direkt mit Java als Sprache zu tun. Ich kann auch Jython, JRuby u.a. Sprachen auf der JVM benutzen. Oder müssen diese Sprachen ihr eigenen Bufferoverflow-Check oder andere Sicherheitsmassnamhem "mitbringen"? Ich denke nicht. Letztendlich kontrolliert die JVM und nicht die Java-Sprache böse Aktionen. Oder?
Für diese Schutzmechanismen muß erstmal die JVM sorgen können! Wer sagt denn, das Java-Byte-Code auf einer JVM mit Bufferoverlow-Kontrolle laufen muß? (außer über die SUN-Zertifizierung, dann gibts erst ein Java-Siegel, ich weiß) Ich kann eine schlechte oder abgespeckte JVM programmieren und das Ding in produktiven Einsatz bringen. Wenn mir das jemand "abkauft", kann jedes Java-Programm Mist anstellen. Da hilft mir Java-Code nichts, wenn meine gebastelte JVM keine Runtime-Checks auf den Java-Bytecode macht. Im schlimmsten Fall kann ich mit einer rekursiven Funktion das Systemverzeichnis des PCs mit Java-Code löschen, wenn der User im Admin-Modus die JVM laufen lässt. Kann er bestimmt sogar mit der SUN JVM... habs aber nie ausprobiert.
Wenn wir also über Bufferoverflow-Kontrolle u.a. Schutzmechanismen reden, dann bitte auf Runtime-/OS-Ebene. Und da gibt es bei den C++-Compilern und C++-Runtimes sehr wohl Bufferoverflow-Mechanismen. Sowohl die Secure-C-Library, die von MS sogar per Compiler-Warnings dem Programmierer darauf hinweist, wenn man sie nicht nutzt. Als auch per Compiler-Schalter, der Bufferoverflow-Jumps mit Laufzeit-Checks überprüft (ohne das ich meinen Code anpassen muß). Die muß man zwar erstmal einschalten, aber man kann sie einschalten. Und dann fliegt eine Exception mit aussagefähigem Fehlerdialog bei einem Bufferoverflow und die C/C++-Runtime bricht das Programm wegen einem Bufferoverflow-Vergehen ab.
Das Sun hier wahrscheinlich eine 10 Jahre alte JPEG-C-Library benutzt, zeigt nur, das sie ihre Runtime (egal ob auf Bytecode- oder Maschinencode-Ebene) vernachlässigt haben. Ich habe mal in einem Java 1.4-Memorydump (oder war es doch 1.5?) unserer produktiven Java-Anwendung einen MSVC6-Logeintrag gesehen. Hallo??? Warum benutzen die nicht den MSVC7.1 und schalten den Bufferoverflow-Checker per Compilerschalter oder schreiben die JPEG-Lib auf Secure-C-Library-Funktionen um? Der MSVC8.0 zeigt nervig die Warnings an den passenden Stellen auf. Das zeugt nur von Ignoranz von Seiten SUN.
Meine Kernaussage bleibt aber erstmal: das OS/Virtualisierung schützt erstmal selbst wichtige Systemeinheiten vor Schadcode. Kann das OS dieses nicht leisten, scheint auch die Umgebung nicht kritisch zu sein. Weiterhin kann der Compiler Runtime-Checks per Compilerschalter einbringen (was nicht praxisfern ist, sondern von MSVC angeboten wird).
-
omh