@ASM-Sources:
Dass der Compiler manchmal etwas pingelig mit Operandengrößen ist, finde ich sogar in Ordnung ...
Wer meint, in seinem Source unbedingt
Delphi-Quelltext
1:
2:
3:
| asm
MOVZX EAX, [ESI]
end; |
schreiben zu müssen, der sollte sehr wohl vom Compiler ein paar geknallt bekommen, da diese Anweisung NICHT eindeutig ist: Will ich nun 8 Bit oder 16 Bit von [ESI] in das EAX-Register kopieren und dieses dann mit Nullen auffüllen. Wer jetzt meint, dass muss der Compiler erraten, programmiert nicht sauber. Eine winzige Änderung des Codes in
Delphi-Quelltext
1:
2:
3:
| asm
MOVZX EAX, WORD PTR [ESI]
end; |
schadet wohl keinem UND erhöht nebenbei sogar die LEsbarkeit.
Dass der Compiler manchmal einfach nur veralteten Source ausgibt, ist dann gleich die nächste Geschichte ... Wir sind inzwischen bei 64-Bit-Prozessoren und erhalten vom Compiler Source, der auf Prozesoren optimal läuft, die vor 15 Jahren Mode waren ... Nostalgie in allen Ehren, aber mindestens MMX und SSE für die Verarbeitung wären eine Verbesserung.
Auch fehlen mir die Generics in Delphi. Die Anonymen Methoden wären zwar Nice, müssen aber nicht sein (Hab mit den Teilen unter Java genug Scheiß angestellt und übersichtlicher wurde es damit nicht wirklich). Was aber interessant wäre, wären die aus Java bekannten Inline-Interfaces als Ersatz für Methoden-Zeiger zu haben. Weilim Wesentlichen sind Methodenzeiger ja nichts als ein Interface mit einer Methode drin, die aufgerufen werden kann.
Wogegen ich bin ist die Abschaffung der Typensicherheit: Genau da liegt ja die Stärke von Delphi ... Wer sauber programmiert, wird in den seltensten Fällen wirklich Probleme mit der Typenprüfung bekommen.
Was mir in diesem Zusammenhang allerdings fehlt, ist die Pointer-Arithmetik aus C:
C#-Quelltext
1:
| typ* var = somelistofvars, var2 = var + 5; |
Wer einmal uall's Sources gelesen hat, weiß, wieso das für Delphi wünschenswert wäre ;-)
Ferner würde ich mich über einen ECHTEN Präprozessor in Delphi freuen, mit dem eine Makro-Sprache ähnlich wie in C möglich ist. Das hat zwar immer auch den Nachteil, dass es in den falschen Händen einfach nur unübersichtlichen Code produziert, aber
Delphi-Quelltext
1:
| uses Windows, {$IFDEF Test}Graphics, {$ELSE} QGraphics, {$ENDIF} |
könnte um einiges übersichtlicher über ein Makro geschrieben werden, was einmal am Unit-Anfang steht und dort wenn nötigdas Q vor dem Unit-Namen ergänzt
Außerdem wäre eine solche Funktion für die Übersetzung von C-Headern sehr hilfreich ...
Ferner würd ich mir wünschen, dass CG in Delphi die eingbauten Features nicht nur so oberflächlich implementiert. Was bringt mir Inlining von 3-Zeiligen Pascal-Routinen, wenn die meisten Routinen, die ich inlinen möchte in ASM geschrieben sind (da diese so kurz sind, dass der Overhead des Delphi-Compilers jedes Inlining zu Nichte macht?
Auch würd ich das Operator Overloading mit C-Style bevorzugen, auch wenn ich für die verwendeten Zeichen für Operatoren Einschränkungen einbauen würde:
1. Kein Überladen von Leerzeichen und Tabulatoren
2. Kein Überladen von Klammern (Auch wenn das sicherlich sehr unlesbaren Code erzeugen würde *G*)
3. Kein Überladen von Buchstaben, Zahlen und Unterstrichen
4. Begrenzung auf maximal 5 Zeichen pro Operator
Eine weitere nette Funktion, die mir schon seit langem fehlt, ist das Abschalten bestimmter Funktionen der Funktions- und Klassenbibliothek. Wenn ich für eine Anwendung kein Drag&Drop brauche, dann brauch auch mein Form diese Funktion nicht zu unterstützen. Jeder Code macht eine EXE nur unnötig Größer. Ich hab letztens auf einem Mikrocontroller (MC68HC908GP32) gearbeitet, wo man mit 512 Byte RAM (-64 Byte Stuerregister - Stack) und 32 KB Flash-ROM (-512 Byte Flash Control) auskommen musste. Ein Delphi-Programm in Minimalfassung mit Form passt nicht mal in den Flash-Chip gepasst, geschweige denn in den RAM. Was jetzt nicht heißen soll, dass ich mit Delphi auf nem Mikrocontroller programmiern können möchte, aber wer mal die Delphi-Versionen vergleicht, dem ist sicherlich schon aufgefallen, dass eine leere Form von D3 bis D10 doppelt so großen Code erzeugt, OHNE mehr zu können (außer halt eben leer zu sein).
Auch würde ich mir vom Compiler mal eine VOLLSTÄNDIGE RTTI wünschen. Was bringt es mir, wenn ich für alle Typen außer Pointer und Records ne Typeinfo habe, aber für die elementaren Typen diese nicht zugänglich ist??? Wobei die Typeinfo für Records ja sogar existiert (denn irgendwoher muss ja SetLength wissen, wie groß ein Eintrag eines Arrays von Record-Strukturen ist). Und für Pointer ist das Generieren einer TypeInfo ja auch kein Problem: Pointer der auf einen Typ mit folgender Typeinfo zeigt.
Eine weitere Nette Einschränkung, die der Compiler hat (und die manchmal recht nervig sein kann) ist die relative Adress-Berechnung beim Deklarieren von Konstanten.
Beispiel:
Delphi-Quelltext
1:
2:
3:
| const
TypeInfo_Void : TTypeInfo = (Kind: tkUnknown;);
TypeInfo_Pointer : TTypeInfo = (Kind: tkPointer; PointerType: @TypeInfo_Void;); |
Das Beste, was ich bei solchen Deklarations-Versuchen bekommen hab, waren sinnlose Fehlermeldungen über Typ-Inkompatibilität oder Meldungen, dass die angegebene Adresse nicht Konstant sei ... (H)AHA!!!
Nehmen wir dann noch dazu, dass der Delphi-Compiler nicht optimiern kann, wäre eine weitere Diskussion über wünschenswerte Features sinnlos, da das eine so große Baustelle ist, dass die netten Herren von CG in Jahrzehnten noch nicht wirklich was Brauchbares hätten. Aber wenn ich eine EXE compiliere und den erzeugten Source im Debugger anschaue, dann kommt mir ehrlich gesagt manchmal das Grauen:
Wozu muss ich einen in EAX zurückgelieferten Rückgabewert nach EAX kopieren? Was bringt es, ein Register hin und Zurückzukopieren??? Hat der Compiler noch nichts von Sicheren Annahmen gehört??? Code, der im Wesentliche die Register EAX, EDX und ECX nutzt und die anderen Register unberührt lässt, "weil ja was wichtiges drin stehen könnte" ist einfach nicht zeitgemäß. Wenn der Delphi-Compiler für ne RISC-CPU geschrieben wäre, würde er wahrscheinlich auch alles allein in Register R0 ausführen! :twisted:
Auch das Fehlen einer ordentlichen Klassenbibliothek ist in meinen ein großes Manko von Delphi. Die in Delphi mitgelieferte VCL liefert seit nunmehr 10 Jahren IMMER NOCH KEINEN Unicode-Support und vorhandene AccessViolations auf Grund von Funktionen, die nur für bestimmte OS verfügbar sind (Ich sag nur AlphaBlend := True auf Win98
) werden lapidar ignoriert mit der Begründung, die QA für diesen Fehler wäre zu Aufwändig ... AHJA!!! Eine einfach If-Abfrage einbauen, die prüft, ob ein Methodenzeiger wirklich gesetzt ist ist also aufwändig und aus Sicht der QA ein kritischer Eingriff in die Integrität des Gesamtsystems. Sorry, aber verscheißern kann ich mich selbst. Zumal in fast allen anderen Routinen genau eben eine solche Abfrage (insbesondere bei Eventhandlern) Standard!!! ist!
Als letzten Wunsch für diesen Post würde ich gern noch die direkte Nutzung von C-Headern für Delphi-Projekte mir wünschen, d.h. ich sag dem Compiler, dass er einen bestimmten C-Header nehmen soll und aus diesem die dort angegebenen Funktionen dem Delphi-Programm verfügbar macht (sei's durch Übersetzen des Headers in eine Unit ODER durch Anbinden des Sources, wie man's vom C++-Builder bzgl. Delphi-Units gewohnt ist).
Naja ... ich will andere auch noch zu Wort kommen lassen ...
Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.
COMMANDER86
