..."Für mich zählt das Ergebnis und das ist in beiden fällen True (Das Object wurde freigegeben und ich hab kein Speicherleck).
Widerlege mir das dann können wir darüber weiter diskutieren."...
- das True sagt, wie richtig erkannt, das(dein) Object wurde erfolgreich gelöscht, man bekommt ein ja auch "False" zurück wenn man 2x DeleteObject für das gleiche
Handle aufruft
- böse ist, das weiter ja selektierte
Handle im
DC hat nun keinen gültiges Objectspeicher mehr
- dies verletzt die Grundregel der
GDI-
API das sich jeder zu jederzeit darauf verlassen darf, das stets ein gültiger PEN und ein gültiger BRUSH im
DC aktiv und verfügbar sind
- wenn du 100% alles selbst, also ohne jemals für Client oder NonClient Bereich die DefWinProc zu nutzen, dann hast du es selbst in der Hand stets vor dem Aufruf einer Zeichenfunktion dich immer um PEN&BRUSH im
DC zu kümmern... dann kannst du auf dieses Regel pfeifen und alles wann und wie du es selbst für richtig hälst löschen
=> es geht hier nicht um "dein" Speicherleck, sondern um das Risiko das irgendwer in einer Lib oder in Code der nicht von dir davon ausgeht, er kann mal fix was ohne sich um "alle" SelectObjects zu kümmern etwas per Aufruf einer
GDI-
API Funktion zeichnen, und genau dort kann es "knallen" wenn zuviel Zeit vergangen ist und der freigegebene ObjektSpeicher nun mit völlig anderen Daten gefüllt ist weil er nun für/von XYZ verwendet ist
-> mach weiter wie du denkst, das hat mit "Qualifikation" nix zu tun... es geht um's Prinip der bestmöglichen Kompatibilität mit sehr geringem Zusatzaufwand(eine OldXX-Variable plus ein SelectObject)... Für deinen Code bekäme ich im 0815 Fall einer Standardverwendung bei uns kein Audit... ich bekäme solches nur durch, wenn es absolut auf jede Nano & Micro-Sekunde beim aufruf von sehr sehr vielen Zeichenfunktionen in RealTime ankommt(dann zählt die Zeit für das gesparte SelectObject-OldXX, wenn danach eh stets ein SelectObject-NewXX kommt, und man nur im "finaly" garantiert das wenn zum Schluss wieder etwas gültiges selektiertes im
DC hinterlässt)
GDI-
API Programmierung ist wenn man sich an ein paar GrundSätze hält eigentlich ganz einfach und logisch, aber vom Grundkonzept eben nicht objektorientiert, also muss/sollte man sich wie die alten C-Programmierer selbst zwingen, immer schön sauber zu programmieren. Windows bekam erst dann den großen Durchbruch für die Allgemeinheit als es mit MFC und viel besser
VCL eben einen Objektorientierten Ansatz zur "sinnvollen"(MFC) bzw. schönen(
VCL) Kapselung gabt. Da kümmert sich immer der vom Compiler verwaltete&garantierte Destuctor-Aufruf um solchen scheinbar nervenden internen Kleinkram... so konnte plötzlich "jeder" ohne viel Nachdenken sichere Windows-
GDI-Programme schreiben.
NonVCL ist also absolut nix besonderes, da helfen einem einfach die seit Win31 unveränderten prinzipellen Grundregeln, auch wenn diese heute sehr "OldScool" sind und es nun irgenwie oft auch so geht... "widerlegen" oder "beweisen" muss man da nix... es steht jedem frei mal einen
GDI Druckertreiber oder einen virtuellen Grafiktreiber selbst zu schreiben, da merkt man dann was für einen Mist die lieben Programmierer per
API veranstalten... Microsoft macht es sich aus Geschwindigkeitsgründen einfach, die schicken alles so direkt wie möglich durch.
Daher kann auf einem System mit sagen wir NVidia Grafiktreibern bestimmtes funktionieren, auf anderen Systemen mit ATI-Grafiktreibern aber nicht, oder man findet ganz spezielle Unterschiede bei RemoteDesktop, VMware und VirtualBox. Man darf Win10 ablehnen und muss Microsoft nicht mögen, aber es bleibt empfehlenswert sich an deren "alte Vorgaben" und "heutigen Empfehlungen" zu halten, denn eines muss man MS lassen... die achten sehr auf Langzeitkompatibilität!...
Win32-
API-Programme sagen wir ab Win95 laufen heute noch bis auf "schönes" HiDPI unter Win10.