c++ vs. java... was hat zukunft
-
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
-
pale dog schrieb:
Simon2 schrieb:
pale dog schrieb:
...
ja, flache kopien, das konnte C ohne ++ schon mit structs machen, als struppi noch die wolle aus'm teddybär'n gezupft hat.
Naja, ein bischen mehr schon. Immerhin werden auch selbstgeschriebene CopyCtoren von tief verschachtelten Klassen aufgerufen ...
...die man aber erst schreiben muss und die für jede klasse anders aussehen.
...Du hast mich mißverstanden: Wenn ICH für meine Klasse keinen speziellen CopyCtor brauche, reicht der implizite auch dann, wenn irgendeine verschachtelte Klasse (irgendwo unten in der Vererbungshierarchie - von irgendjemand anders vor Jahren geschrieben) einen selbstgeschriebenen hat.
Das ist schon ein wenig mehr als mit C-Structs möglich war."Nicht vergessen können" bedeutet: Ich schreibe einfach jedesmal (unabhängig vom Typen)
TYP a; TYP b = a;und brauche nicht nachzuschlagen, ob ich jetzt eina.CopyMeHappily()oder eina.CloneMyButt()aufrufen muss.Aber wie gesagt: Kein wirklicher "Kriegsentscheider"....
Gruß,
Simon2.
-
Simon2 schrieb:
Wenn ICH für meine Klasse keinen speziellen CopyCtor brauche, reicht der implizite auch dann, wenn irgendeine verschachtelte Klasse (irgendwo unten in der Vererbungshierarchie - von irgendjemand anders vor Jahren geschrieben) einen selbstgeschriebenen hat.
Das ist schon ein wenig mehr als mit C-Structs möglich war.nö, das ist exakt das gleiche was C macht. wenn du in C eine struct hast, die ihrerseit wieder structs beinhaltet, dann wird mit '=' eine bitweise kopie erzeugt. beispiel:
struct a { int ma; }; struct b { int mb; struct a a; }; ... struct b b1 = {123, 456}; struct b b2; ... b2 = b1; // b2 hat danach: mb==123 und a.ma==456 ...C kann zwar keine vererbung, aber aggregation (bzw. verschachtelte objekte)
und das beispiel macht eben eine flache kopie, da bietet C++ nix neues.
ok, in c++ könnte man's noch mit den default copy-ctor machen: b b2(b1);
aber der macht ja das selbe, ausser dass der überflüssige aufruf des standard-konstruktors (nehme ich an) dann nicht passiert.
bemerkenswert (oder bedenklich) bei C++ ist dabei allerdings, dass das default-verhalten von '=' und das des copy-ctors verändert werden können, ohne dass der anwender der klasse davon kenntnis hat (aber zu dem thema hatten wir ja schon einen thread)
-
@pale dog:
Mir fällt auf dass Du mit C++ wohl nicht wirklich zufrieden bist.
Hast Du Dich eigentlich schon mal mit Python beschäftigt?
zu der Sprache würde mich mal Deine Meinung interessieren!Grüsse
*this
-
Gast++ schrieb:
@pale dog:
Hast Du Dich eigentlich schon mal mit Python beschäftigt?
zu der Sprache würde mich mal Deine Meinung interessieren!nein, leider hatte ich noch keine gelegenheit dazu.
...aber ich hab' ausschliesslich positives darüber gehört.
-
pale dog schrieb:
...
nö, das ist exakt das gleiche was C macht. wenn du in C eine struct hast, die ihrerseit wieder structs beinhaltet, dann wird mit '=' eine bitweise kopie erzeugt. ...Sag mal - Du kannst mich doch verstehen - warum tust Du denn nicht ?
C kann eben in "impliziten CopyCtoren" NUR "implizite CopyCtoren" (=flache Kopien) aufrufen (weil es eben keine anderen kennt). C++ dagegen kann in "impliziten CopyCtoren" AUCH "explizite CopyCtoren" aufrufen.
Dieses "AUCH" ist das Quentchen Mehr, das ich meine.
Ja - C++ kann keine impliziten CopyCtoren für "tiefe Kopien" erzeugen, aber sie können eben dieses bischen mehr, so dass ich eine "ausreichend tiefe Kopie" bekomme (wenn mir für meine Klasse eine "flache" reicht, kann ich trotzdem implizit eine "tiefe" für meine Attribute/Basisklassen bekommen, wenn die das brauchen).Übrigens sind "tiefe Kopien" nicht der einzige Grund für einen eigenen CopyCtor ... ud spätestens da ist C am Ende.
Gruß,
Simon2.
-
Simon2 schrieb:
C kann eben in "impliziten CopyCtoren" NUR "implizite CopyCtoren" (=flache Kopien) aufrufen (weil es eben keine anderen kennt).
unsinn, C kennt überhaupt keine konstruktoren.
Simon2 schrieb:
C++ dagegen kann in "impliziten CopyCtoren" AUCH "explizite CopyCtoren" aufrufen.
Dieses "AUCH" ist das Quentchen Mehr, das ich meine.dass C++ mehr möglichkeiten bietet als C will keiner bestreiten. ob alles davon wirklich sinnvoll und nützlich ist, ist natürlich ein anderes thema.
Simon2 schrieb:
Übrigens sind "tiefe Kopien" nicht der einzige Grund für einen eigenen CopyCtor ... und spätestens da ist C am Ende.
ich hatte vor ein paar postings C erwähnt, weil CStoll 'implizite copy-ctors' als ein tolles C++ feature angepriesen hast, aber C die gleiche funktionalität für structs schon seit urzeiten hat - auch ganz ohne konstruktoren.
ein vergleich (oder flamewar ) C gegen C++ wäre genau so absurd wie C++ gegen Java.
gleichberechtigte flamewar-kontrahenten wären z.b. C# vs. Java oder etwa C vs. Pascal.
C++ kann man, meiner meinung nach, schlecht mit anderen sprachen vergleichen, weil es so'n schlüpfriges zwitterding und deshalb einzigartig ist.
... und wenn man's doch macht, kommen die seltsamsten argumente (wie etwas dass das OS für C++'s sicherheit zuständig ist. so ein quatsch!).
-
OK, da hilft nur, Dein Gedächtnis auffrischen:
pale dog schrieb:
Simon2 schrieb:
C kann eben in "impliziten CopyCtoren" NUR "implizite CopyCtoren" (=flache Kopien) aufrufen (weil es eben keine anderen kennt).
unsinn, C kennt überhaupt keine konstruktoren....
Erstaunlich - ich hätte Dir die Transferleistung zugetraut - sag nicht, dass ich mich getäuscht habe....
pale dog schrieb:
...
Simon2 schrieb:
Übrigens sind "tiefe Kopien" nicht der einzige Grund für einen eigenen CopyCtor ... und spätestens da ist C am Ende.
ich hatte vor ein paar postings C erwähnt, weil du 'implizite copy-ctors' als ein tolles C++ feature angepriesen hast, ...
Zur Erinerung:
Simon2 schrieb:
pale dog schrieb:
...
CStoll schrieb:
In C++ kannst du (fast) jedes Objekt von Haus aus kopieren.
ja, flache kopien, das konnte C ohne ++ schon mit structs machen, als struppi noch die wolle aus'm teddybär'n gezupft hat.
Naja, ein bischen mehr schon. ...Letztlich finde ich den Unterschied aber eher marginal ...
Simon2 schrieb:
...können eben dieses bischen mehr, ...
Merke: "Bischen", "marginal", "bischen"
Irgendwie bringe ich das nicht mit Deinem "... tolles C++ feature angepriesen ..." in Einklang und ebensowenig mit einem "flamewar", wie Du ihn herufziehen siehst...Gruß,
Simon2.
-
Um nochmal auf die Originalfrage zu kommen, halt was hat Zukunft.
Ich denke das die Diskussion einfach (wie so oft) komplett falsch geführt wird und damit meine ich nicht diesen: Ich-hab-aber-doch-recht-Stil einiger Leute.
Nein, ich meine, die Frage ist so falsch gestellt, denn sie impliziert die Annahme, daß eine Spache für sich betrachtet so etwas wie eine Zukunft haben könnte. Das aber ist falsch, denn die Gebiete der Programmierung sind nurmal sehr unterschiedliche und es gibt viele davon.
Selbst eine Exotische Sprache wie Erlang haben eine definierte Zukunft, weil sie ein Gebiet der Programmierung bedient auf dem sie genau das bietet was die entwickler brauchen.
Bevor man also über Zukunft redet muß man sagen, in welchem Bereich man denn arbeiten will. Wenn ich hardwarenah Programmieren muß, sagen wir z.B. Treiberentwicklung dann sage ich auf diesem Gebiet einer Sprache wie Java gar keine Zukunft vorraus,denn dafür ist die Sprache nicht gedacht.
Wenns um Anwendungsentwicklung geht sieht die Welt wieder anders aus, aber auch hier muß man die Frage weiter detailieren. Will man z.B. ausschließlich auf Microsoft-Plattform arbeiten, dann sehe ich eine riesige Zukunft für C#, eher wenig für C++ und gar keine für Java.
Anders sieht es bei Applicationen aus die entweder auf möglichst vielen Plattformen laufen sollen oder halt von vorneherein *nix basiert sind, da wird Java noch lange Zeit die Nase vorne haben wohingegen C++ hier schon jetzt kaum eine Gegenwart hat.
Bei reiner Systementwicklung, Realtime-Anwendungen und Performancekritischen Sachen wieder denke ich das C++ am meisten Punktet und auch hier noch lange Zeit einfach dei Sprache der Wahl sein wird. (Als kleiner randbemerkung, die VM von java ist soweit ich weis auch in C++ geschrieben, korrigiert mich wenn ich falsch liege... go figure)
Nur in solchen Zusammenhängen lassen sich sinnvolle Aussagen machen, eine pauschale Zukunft irgendeiner Sprache gibt es einfach nicht, denn welchen Nutzen hätte auch die beste aller Sprachen wenn es keine Anwendungsgebiete dafür gäbe...
Und gerade wenns im Professionelle Entwicklung geht zählt am ende nur eines wirklich: Wirtschaftlichkeit. Das heisst, man wählt immer die Sprache mit der man ein gegebenes Problem am einfachsten, schnellsten und saubersten Lösen kann. Ich gehe sogar soweit zu behaupten, daß ein guter Programmierer sich dadurch auszeichnet, daß er nicht auf eine einzige Sprache eingefahren ist.
-
pale dog schrieb:
CStoll schrieb:
pale dog schrieb:
CStoll schrieb:
Sag blos, ich kann jedes Objekt ohne Vorbereitungen durch so einen ObjektStream jagen, um es zu kopieren. Der Link, den du dort oben gegeben hast, sagt da etwas anderes:
normalerweise reicht ein 'implements Serializable' im kopf der klassen, die man 'klonen' will, das wirkt sich auch auf unterklassen aus.
wenn irgendwelche feinheiten gebraucht werden, kann man's noch erweitern, indem man 'readObject' und 'writeObject' überschreibt. im normalfall braucht man's aber nicht.
guckst du: http://java.sun.com/developer/technicalArticles/Programming/serialization/
Ist immer noch reichlich kompliziert (vor allem verstehe ich nicht, daß man für eine einfache Kopie immer den Umweg über einen Byte-Stream gehen muß).
was ist daran kompliziert 2 wörtchen hinzuschreiben?
Wenn es wirklich nur darum ginge, "2 wörtchen hinzuschreiben", gar nichts. Aber dann wäre der Artikel auch nach der ersten Seite zu Ende. Auch bei Java mußt du noch die ganzen Sonderfälle beachten, in denen diese "2 wörtchen" nicht ausreichen. Im Vergleich dazu mußt du in C++ normalerweise gar nichts machen, wenn du Okjekte kopierbar machen willst (und ebenfalls einige Sonderfälle beachten, in denen dieses Default-Verhalten nicht reicht).
das mit den streams hat einen einfachen grund: man kann komplexe objekte auf eine einheitliche weise in dateien ablegen oder sie über netzwerke senden.
Ich will dir gar nicht die Vorteile von Streams absprechen, aber sie für eine simple Kopier-Operation zu nutzen, hat was von "mit Kanonen auf Spatzen schießen". Wozu der Umweg? Gibt es denn keine Möglichkeit, ein Objekt direkt zu kopieren?
Gregor schrieb:
lokos schrieb:
C++ kann ALLES was Java kann (naja, und vieles mehr halt).
Interessant. Ich mach mit Java folgendes:
Ich habe ein Programm, das aus einzelnen völlig unzusammenhängenden Bausteinen besteht. Es wird an keiner Stelle im Programm gesagt, welche Bausteine da sind und welche nicht. Es gibt auch keine externe Datei, in der die Bausteine eingetragen sind. Und die Bausteine haben auch keine Methoden, durch die sie sagen können, was sie sind und wie sie zu benutzen sind. Mein Programm untersucht sich beim Start dann praktisch selbst, findet heraus, was es kann, und generiert aus diesen Informationen eine grafische Benutzungsschnittstelle, um alle Bausteine inklusive ihrer Kombinationen für den Benutzer nutzbar zu machen.
Echt, das geht? Es ist zwar eine Weile her, daß ich mich mit Java beschäftigt habe, aber afair gibt es dort auch eine main()-Methode, die als Ausgangspunkt des Programms dient (und die wissen muß, was da ist, und was du benötigst).
PS: Nur damit niemand meine Aussagen in den falschen Hals bekommt:
Ich vertrete hier zwar die C++ Seite, aber deswegen will ich Java noch lange nicht verdammen. Ich versuche hier nur, die ständigen "C++ ist sch***"-Argumente einiger Java-Anhänger genauer auseinanderzunehmen.
-
Hi lokos,
ich stimme Dir zu ! Gut formuliert !!
lokos schrieb:
... Ich gehe sogar soweit zu behaupten, daß ein guter Programmierer sich dadurch auszeichnet, daß er nicht auf eine einzige Sprache eingefahren ist.
Oder wie ich schon auf Seite 3 sagte:
Simon2 schrieb:
Hi,
mein einziger Tipp:
Lerne keine Sprache, sondern lerne Programmieren !!!Alles Andere wird nicht zukunftsfähig sein.
Gruß,
Simon2.
Gruß,
Simon2.
-
CStoll schrieb:
Echt, das geht? Es ist zwar eine Weile her, daß ich mich mit Java beschäftigt habe, aber afair gibt es dort auch eine main()-Methode, die als Ausgangspunkt des Programms dient (und die wissen muß, was da ist, und was du benötigst).
Naja, man muß schon unterscheiden, ob die nötigen Informationen nochmals hinterlegt werden müssen, oder ob sie aus dem Rest automatisch generiert werden.
Wenn man sich natürlich auf den Standpunkt stellt, dass das kein Mehrwert sei (die Information muß schließlich vorliegen), dann sollte man sich vielleicht auf mal die Frage nach dem Mehrwert von templates stellen.