Zitat von
alzaimar:
Wenn Hubble der Ansicht ist, das Objekte auf dem Stack toll und schnell sind, kann ich ihm nicht widersprechen, aber ist nicht ein Zusammenhang mit diesem Speichermodell und den Exploits, die doch gerade versuchen, den Stack zu manipulieren?
Prinzipiell ist es egal, ob ich den Stack oder den Heap eines fremden Prozesses ändere. Was aber richtig ist, ist, daß der Stack überlaufen kann, dann nämlich, wenn das Frame zu klein ist. Idealerweise sollte man dann 'ne
Exception um die Ohren geworfen kriegen. Was auch richtig ist, ist, daß man prinzipiell durch Injizierung von Code den Stack durch manipulieren kann, beispielsweise auch den Call-Trace manipulieren. Ob dann meine Objekte auf dem Stack liegen oder ob auf dem Heap, ist egal, wenn ich mal Code injiziert habe, habe ich mehr oder weniger freies Spiel.
Für mich haben daher Objekte auf dem Stack nur einen echten Vorteil: Ich brauche mich nicht um sie zu kümmern.
Zitat von
alzaimar:
denn Sicherheit geht immer auf Kosten der Freiheit (Gruss an unsere Innenminister, gell?).
Big Brother Award für Borlands Lebenswerk?
Zitat von
alzaimar:
Vermutlich werden wir uns per Options-Dialog unsere eigenen Keywords 'begin','{' etc. zusammenklicken können, so das nun wirklich Keiner mehr meckern kann
Das wäre mal was... Ein selbstprogrammierbarer Lexer für den Compiler. Lass dir das patentieren, sonst macht noch jemand 'ne Raubkopie von der Idee
Zitat von
Hubble:
Natürlich geht in Delhpi auch irgendwie. Ist aber umständlicher kostet mehr Zeit und Übersicht.
'n Bleistift:
Delphi-Quellcode:
begin TSomeType.SomeMethod(someparams: TSomeOtherType): TSomeResult;
type
TLocalClass = class
public blubb();
end;
var
LocalInstance: TLocalClass;
begin
LocalInstance := TLocalClass.Create();
FreeAndNil(LocalInstance);
end;
Das einzige, was bleibt, ist, daß man die Instanz eben nicht auf dem Stack haben kann, aber von der Übersichtlichkeit her macht dieses Beispiel kaum einen Unterschied zu deinem. Plus: Hier ist die Klasse tatsächlich nur innerhalb dieser einen Methode zu sehen, bei dir wäre die Klasse auch für alle nachfolgenden Klassen als Typ sichtbar.
Zitat von
Hubble:
Ein mehrfach verwendetes Objekt würde ich nie mitten in den C++ Code hocken.
Das beruhigt mich sehr! Bei deiner ersten Ausführung habe ich schon einen leichten Schock gekriegt.
Zitat von
Hubble:
Mir ist keine auch nur annähernd so elegante und schnelle Lösung in Delhpi bekannt.
Hier im Forum schwirrt irgendwo 'ne Hashtable rum, die ist ebenfalls elegant, wenn es darum geht, ein String-indiziertes Array zu basteln.
Zitat von
Hubble:
Natürlich kann ich anstatt des Strings auch ein beliebiges anderes Objekt verwenden.
Das kann diese Stringklasse nicht, stimmt, es sei denn man castet alles anch TObject und wieder zurück.
Prinzipiell gebe ich dir vollkommen Recht, die STL ist eine enorme Erleichterung, wenn man sich mal eben 'ne Datenstruktur basteln will, die vollständig typsicher ist (und zwar garantiert typsicher, schon zur compile-time).