Habt ihr eine Laufzeitumgebung (VM/.Net) installiert?
-
Optimizer schrieb:
Wofür sind Exceptions deiner Meinung nach da?
Also meiner Meinung nach sind sie dafür da, wenn jemand (ein böser Mensch halt) deine Klasse falsch benutzt, ihnExceptions werfe ich bei Laufzeitfehlern, die die Umgebung verursacht hat. zB. nicht gefundene Dateien, getrennte Netzwerkverbindungen etc. Vom Programmierer kann man doch aber verlangen, dass er sich an die Anforderungen hält, die die Funktion verlangt. Macht den Code einfacher und spart Laufzeit.
-
Was hat eigentlich Garbage Collection mit VM zu tun? Was hat eigentlich überhaupt irgendein Pro-Java-Argument, was in diesem Thread gefallen ist, mit der VM zu tun?
-
DrGreenthumb schrieb:
Vom Programmierer kann man doch aber verlangen, dass er sich an die Anforderungen hält, die die Funktion verlangt. Macht den Code einfacher und spart Laufzeit.
Dazu sind asserts da. Wenn ich assert(p >= 0); schreibe, heißt das für mich, «ich gehe davon aus, dass an dieser Stelle p größer gleich 0 ist.»
-
asserts sind IMHO immer nützlich, da sie erstens keinen Laufzeit Overhead erzeugen (werden ja im Release ausgeschaltet) und einem extrem das leben erleichtern können (es ist schon eindeutiger, wenn ein Fehler gemeldet wird wie "assert x<0 failed" anstelle "SegMentation fault in ??".
-
Bashar schrieb:
Was hat eigentlich Garbage Collection mit VM zu tun? Was hat eigentlich überhaupt irgendein Pro-Java-Argument, was in diesem Thread gefallen ist, mit der VM zu tun?
Weiß ich nicht, was ist eigentlich eine VM? Ich dachte, dass ist das was im Hintergrund läuft, Garbage collectiert und zur Laufzeit aufpasst, dass keine Indexüberschreitungen oder sonstiges stattfinden.
Dazu sind asserts da. Wenn ich assert(p >= 0); schreibe, heißt das für mich, «ich gehe davon aus, dass an dieser Stelle p größer gleich 0 ist.»
Ja, ich weiß. Und wenn ich bei einer Funktion sicherstellen will, dass x in einem bestimmten Bereich liegt, macht es auch sinn. Aber ich überprüfe doch nicht jeden Pointer ob er auch nicht null ist, oder so. Bei vielen Dingen gehe ich einfach davon aus, dass das Argument den Anforderungen gerecht wird.
-
GC oder Indexprüfung gibt es auch ohne VM (Lisp, Eiffel, SML, ...) Der Managed-Aspekt einer VM erstreckt sich auf Sicherheit im Binärcode, d.h. selbst ein JVM-"Assembler"-Programm kann keine Arraygrenzen überschreiten (jedenfalls soweit ich das verstanden habe.)
Bei vielen Dingen gehe ich einfach davon aus, dass das Argument den Anforderungen gerecht wird.
Das assert drückt genau das aus, dass du davon ausgehst. Liegst du mal falsch, wird dir das gesagt. Compilierst du mit -D_NDEBUG, werden alle assertions deaktiviert.
-
Der Managed-Aspekt einer VM erstreckt sich auf Sicherheit im Binärcode, d.h. selbst ein JVM-"Assembler"-Programm kann keine Arraygrenzen überschreiten (jedenfalls soweit ich das verstanden habe.)
so etwas gibt es aber auch für C und C++. OpenBSD und Trusted Debian setzen AFAIK etwas derartiges ein, um das System besser gegen Bufferoverflows zu schützen.
-
Quelle? Ich vermute, das ist etwas, das dem Stack die Ausführungsrechte nimmt, so dass man Buffer-Overflows nicht zum Einsteigen exploiten kann.
-
Ich weiß nicht ob das gemeint war:
http://kerneltrap.org/node/view/573
-
-
Sag ich ja. Die verhindern keine Array-Überläufe, sondern nur einige der sicherheitsrelevanten Auswirkungen.
-
Wenn ich eine Funktion schreibe, gehe ich davon aus, dass die Argumente richtig übergeben wurden.
Das ist dein Fehler.
Vom Programmierer kann man doch aber verlangen, dass er sich an die Anforderungen hält, die die Funktion verlangt.
Wieso sollte ich irgendetwas Vermuten, wenn ich es doch problemlos sicherstellen kann und das mit geringem Aufwand.
------------------------------------------
Ich habe Sun's VM 1.4.3, verwende Javaanwendungen und habe auch schon welche geschrieben. Ich habe Privat kein .Net-Framework, nicht-privat hingegen schon, weil ich an einem Projekt arbeite, welches in .Net entwickelt wird.
-
Optimizer schrieb:
Das toString() rockt doch. Das finde ich mal wirklich ne geniale Idee.
Rational myRational = new Rational(17, 6); System.out.println("Wert des Bruches: " + myRational);Zum Glück kann man das in C++ nicht machen. toString sieht für mich eher so aus: "Oh, wir können keine Operatoren überladen. Wär aber ganz praktisch wenn man Strings per + Operator konkatenieren könnte. Hmmm, ja dann lass uns doch einfach ein toString in Object reinbasteln."
-
MaSTaH schrieb:
Zum Glück kann man das in C++ nicht machen. toString sieht für mich eher so aus: "Oh, wir können keine Operatoren überladen. Wär aber ganz praktisch wenn man Strings per + Operator konkatenieren könnte. Hmmm, ja dann lass uns doch einfach ein toString in Object reinbasteln."
Wo siehst du den Zusammenhang zwischen toString und dem Konkatenieren von Strings?
-
Ich habe bei mir das .NET-Framework installiert, um mal in C# reinschnuppern zu
koennen.Ob man dieser Technologie die Zukunft zusprechen kann, bleibt abzuwarten. Denn
schliesslich ist Longhorn noch lang nicht zu erwarten und ohne dieses sehe ich
keinen Grund dafuer, ernsthaft .NET-Programme zu entwickeln. Und irgendwie
scheint sich .NET auch noch nicht wirklich zu durchzusetzen.Aber ob es wirklich kommen wird oder nicht, darauf muessen wir, wie schon gesagt,
warten und sehen was passiert.mfg
v R
-
Gregor schrieb:
MaSTaH schrieb:
Zum Glück kann man das in C++ nicht machen. toString sieht für mich eher so aus: "Oh, wir können keine Operatoren überladen. Wär aber ganz praktisch wenn man Strings per + Operator konkatenieren könnte. Hmmm, ja dann lass uns doch einfach ein toString in Object reinbasteln."
Wo siehst du den Zusammenhang zwischen toString und dem Konkatenieren von Strings?
Ich hatte im Eifer des Gefechts meine Gedanken ein wenig ungeordnet gepostet. Ich meinte folgendes: Wenn ich ein Objekt auf der Konsole ausgeben möchte dann kann ich nicht folgendes machen: System.out.println("Hallo" + obj1 + "!"), wenn ich nicht irgendwie eine implizite Umwandlung eines Objektes nach String realisiere. Deswegen sehe ich toString als eine Notlösung weil man sich keinen Umwandlungs-Operator überladen kann. Ich finde es auch schwachsinnig, dass man String erlaubt per + Operator konkatenierbar zu sein und einer Klasse BigInteger keine arithmetrischen Operatoren spendiert. Wenn man etwas in einer Sprache implementiert dann sollte manauch konsequent sein.
-
Helium schrieb:
Wenn ich eine Funktion schreibe, gehe ich davon aus, dass die Argumente richtig übergeben wurden.
Das ist dein Fehler.
Na wenn du meinst, ich bin bisher damit ganz gut gefahren.
Aber irgendwie verlief das jetzt in die falsche Richtung, ich habe nichts gegen asserts und verwende die auch hier und da. Ursprünglich gings mir darum, dass man im Gegensatz zu Exceptions, auf asserts auch verzichten kann. Wenn ich jetzt eine Library schreibe und die compiliere, sind die asserts ja auch raus. Und wenn dann jemand falsche Argumente übergibt, endet das halt in "undefined behaviour".
-
DrGreenthumb schrieb:
Und wenn dann jemand falsche Argumente übergibt, endet das halt in "undefined behaviour".
Ja, genau das soll es ja nicht.
MaSTaH schrieb:
Deswegen sehe ich toString als eine Notlösung weil man sich keinen Umwandlungs-Operator überladen kann.
Das sehe ich anders, weil man toString für jede Klasse selber definieren kann, anstatt in der String-Klasse für jede Kombination '+' zu definieren. Bei dem BigInteger stimme ich dir allerdings zu, Operator-Überladung vermisse ich in Java auch oft.
-
Das sehe ich anders, weil man toString für jede Klasse selber definieren kann, anstatt in der String-Klasse für jede Kombination '+' zu definieren. Bei dem BigInteger stimme ich dir allerdings zu, Operator-Überladung vermisse ich in Java auch oft.
Hör mal bitte kurz auf in Java zu denken und dafür in C++. Dann wird dir ganz schnell einfallen, dass es globale Funktionen und auch globale Operatorenüberladungen gibt. Du kannst also jederzeit deinen +-Operator definieren, auch wenn du weder die Stringklasse noch die Klasse, die du gerne in einen String umwandeln würdest geschrieben hast.