Artikel: "Is Delphi A Memory Safe Language?"

[BigAl]

Na das gibt soch wieder Hoffnung für die Zukunft unserer geliebten Sprache: klick

[DP-Maintenance]

Dieses Thema wurde am "11. Mar 2024, 11:55 Uhr" von "TBx" aus dem Forum "Object-Pascal / Delphi-Language" in das Forum "Klatsch und Tratsch" verschoben.

[Der schöne Günther]

Das Verschieben in die Kategorie "Klatsch und Tratsch" finde ich persönlich etwas verwirrend. Soll das heißen, dass man den Artikel nicht ernst nehmen soll?

Natürlich fällt mir das schwer nachzuvollziehen, was bspw. in Sachen "Use-After-Free", "Stack-Overrun" und anderen Klassikern bei Delphi nun wirklich anders ist als bei C/C++, aber ich finde eine Diskussion im "ernsthaften" Abteil "Delphi/Object-Pascal-Language" sollte doch erlaubt sein?

Merkwürdig. Habe ich Kontext verpasst?

[TBx]

Nein, das soll keinesfalls heißen, dass man den Artikel nicht ernst nehmen sollte.
In K+T liegen unter anderem alle Beiträge, die nicht eindeutig einer Sparte zuzuordnen sind.

[Sinspin]

Ich finde die Debatte schön. Vieleicht kommt sie noch zu einer Zeit wo noch was zu retten ist.
Ich meine Delphi.

[Der schöne Günther]

Ich bin ganz ehrlich, ich habe die Analyse des "weißen Hauses" nicht einmal gelesen, und wenn Delphi da als "more memory-safe" als z.B. C++ geführt ist (so habe ich das verstanden), dann muss ich das auch nicht weiter lesen.

Was hierbei wohl unter den Tisch fällt ist das es für bspw. C oder C++ Standards wie bspw. MISRA-C gibt. Und für verbreitete Ökosysteme wie Java oder C/C++ gibt es Tonnen an Tools für statische Codeanalyse.

Währenddessen haben wir in Delphi einen Compiler der dich noch nicht einmal darauf hinweisen kann wenn du mit nicht zugewiesenem Speicher arbeitest.

[Bernhard Geyer]

Zitat:

Zitat von Der schöne Günther (Beitrag 1534444)

Ich bin ganz ehrlich, ich habe die Analyse des "weißen Hauses" nicht einmal gelesen, und wenn Delphi da als "more memory-safe" als z.B. C++ geführt ist (so habe ich das verstanden), dann muss ich das auch nicht weiter lesen.

Was hierbei wohl unter den Tisch fällt ist das es für bspw. C oder C++ Standards wie bspw. MISRA-C gibt. Und für verbreitete Ökosysteme wie Java oder C/C++ gibt es Tonnen an Tools für statische Codeanalyse.

Das "Tonnen" an Tool für statische Codeanalyse nötig sind, zeigt, das die Aussage "more memory-safe" als C++ ist.
Wäre C++ nicht so unsafe, wären diese "Tonnen" nicht nötig.

Vom Sprach-Kern gilt hier immer noch das hier:
https://www.computerwoche.de/a/von-h...s-auge,1111624

[himitsu]

Im Gundkern ist es schon rechts "sicher".


OK, um die Freigbe von Objekt-Instanzen muß man sich kümmern. (außer teilweise bei VCL/FMX)

Man könnte das teilweise durch Interfaces lösen.

Strings, dynamische Arrays und andere Managed-Typen sind per se auch sicher.


Wenn man dann aber mit Pointer und PChar anfängt, dann muß man natürlich aufpassen.




Aber selbst z.B. im .NET, oder sowas wie JavaScript/PHP, kann man sich mit Zeigern ins Bein schießen.

[Sinspin]

Es geht ja nicht um die Komponenten die dabei sind.
Es geht darum was die Sprache für Möglichkeiten hat um Programme zu erstellen die mit weniger Aufwand sicherer sind.
Das man dann Komponenten verwenden muss die diese Möglichkeiten auch nutzen, sollte klar sein.

[Stevie]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1534457)

Wäre C++ nicht so unsafe, wären diese "Tonnen" nicht nötig.

Bjarne Stroustrup beantwortet diese Behauptung am besten selbst.