Moin Moin,

kommt es mir nur so und fehlt hier wirklich "unbedingt" eine Warnung,
oder ist das schon OK/egal so?

markieren

Delphi-Quellcode:

var
  str: string;
  obj: TEdit;
begin
  str := string(obj);
  obj := TEdit(str);
  if obj = nil then
end;

Kurzfassung aus https://www.delphipraxis.net/205781-...astermind.html
Das ist jetzt nichts Neues ... hatte ich erst vermutet, aber ist schon mindestens 10 Jahre oder gar schon immer so.


Als Erstes hätte ich wegen OBJ ein "nicht initialisiert" erwartet.
Nur bei ARC, würde es stimmen, dass es initialisiert wäre, auch wenn hier die unterschiedlichen Referenz-Mechianismen hätten es komplett verrecken lassen.

Aber vor allem den Cast zwischen Objekt und String würde ich als schwerwiegenden Programmier-Fehler ansehn
und davor sollte doch der Compiler "unbedingt" warnen, oder nicht?
Für unschönen AltCode, wo man doch mal sowas machen wöllte, wären "absichtliche" Casts über einen untypiisiterten Pointer ja noch tollerierbar, auch wenn es dennoch "Mist" wäre.
z.B. einen "String" im Data bei Items von StringList/ListBox/VirtualStringTree/...


Oder wie wäre es mit einem indirekten Cast wie bei String<->PChar, wo implizit eine Funktion dazwischen liegt? (quasi sowas wie ein Makro mit Self.FindComponent bzw. .ToString)
Und eigentlich bei Integer NativeInt<->Object ein Makro mit GetHashCode. (da HashCode aktuell einfach der Objektzeiger ist, würde es Casts in Bestandscode nicht zerballern)


-->> Noch ein paar Meinungen einholen, bevor ich den Bugreport schreibe, oder auch nicht, falls es doch nicht soooooo schlimm ist.

Jo, fehlt ne W1036 imo - witzigerweise gibt's eine, wenn man die linke seite hardcastet.
Zu unsinnigen/gefährlichen Hardcasts allerdings sagt der Compiler nix, kann und soll er auch nicht.
Dafür könntest du aber ein Featurerequest bei FixInsight eröffnen.

Ein echt gutes Feature für den Delphicompiler wäre, wenn man als Debugkonfiguration auch zusätzliche Assertions für eine automatische Typprüfung aktivieren könnte. Der Compiler kennt ja den Typ der Variablen und könnte dementsprechende Prüfungen zur Laufzeit einbauen. Nicht für alles, aber für einen Teil schon...

Ja ja, man wird ja noch träumen dürfen...

In unseren eigenen Quelltexten sind dank Generics aber ohnehin kaum noch Casts drin.

Zitat von jaenicke:

In unseren eigenen Quelltexten sind dank Generics aber ohnehin kaum noch Casts drin.

Dafür vermutlich zigfach duplizierter Binärcode

Zitat von Stevie:

Zu unsinnigen/gefährlichen Hardcasts allerdings sagt der Compiler nix, kann und soll er auch nicht.

Warum sollte er nicht?

Gerade da sollte er zumindestens eine (abschaltbare) Warnung bringen, wäre zumindestens meine Meinung, wenn ich sehe was da so Mancher versucht, siehe anderer Thread.
Wer wirklich absichtlich sowas machen will, der darf ja weiterhin gern über einen untypisierten Pointer gehen, oder schaltet vorübergehend die Warnung ab.

Zitat von Stevie:

Dafür vermutlich zigfach duplizierter Binärcode

Ach, das bissl fällt nu och nimmer auf.

800 kB: FinalBuilder mit XE kompiliert, wo Eurekalogs ECC an den Parametern rumgepfuscht
3-4 MB im DelphiXE kompiliert (DLLs und Packages muß ich vorher einmal dort kompilieren, um sie "komplett" debuggen zu können und dabei auch Parameter und Variablen sehen zu können
10 MB im 10.4 kompiliert (auch inkl. Debuginfos)
... für über 80 BPL/DLL/EXE ergibt das schon ganz schön Mehrwert

Zitat von himitsu:

Zitat von Stevie:

Zu unsinnigen/gefährlichen Hardcasts allerdings sagt der Compiler nix, kann und soll er auch nicht.

Warum sollte er nicht?

Hardcasts sind nunmal hardcasts - wenn man die verwendet, dann sollte man schon wissen, was man macht. Dass nun Anfänger ggf Fehler machen und es ihnen die Sprache erlaubt ist dann nunmal so. Dafür gibts Lehrmaterial.

Zitat von himitsu:

800 kB: FinalBuilder mit XE kompiliert, wo Eurekalogs ECC an den Parametern rumgepfuscht
3-4 MB im DelphiXE kompiliert (DLLs und Packages muß ich vorher einmal dort kompilieren, um sie "komplett" debuggen zu können und dabei auch Parameter und Variablen sehen zu können
10 MB im 10.4 kompiliert (auch inkl. Debuginfos)
... für über 80 BPL/DLL/EXE ergibt das schon ganz schön Mehrwert

Fun fact: der meiste Zuwachs gerade in den letzten Jahren kommt eben genau dadurch: dass auch die RTL/VCL/FMX/Drittanbieter mit Generics durchsetzt sind und somit aufgeblasen werden.
Mach mal ne Button/Edit/ListBox-Anwendung in FireMonkey und schau wieviel des Binärcodes nur von TList kommt.

Spoiler: In der ca 9MB großen Exe, die ich hier mit nem 10.4 herausbekomme, sind über 2.5MB nur Binärcode und RTTI aus diversen TList<T> etc.

Und dazu kommen dann noch so dämliche Benutzungen von Generics wie in TStyledControl.FindStyleResource<T: TFmxObject> - gerade FMX ist durchsetzt von dümmlicher Benutzung von Generics - TStyledPresentationProxy<T: TStyledPresentation, constructor> ist auch so ein Beispiel und es gibt zahlreiche davon.