![]() |
AW: Find out why after 22 years more developers than ever are choosing Delphi
Bei mir ist es anders herum. Ich fand es interessant, danke für den Post. Ich bekomme solche Mails nie.
|
AW: Find out why after 22 years more developers than ever are choosing Delphi
Liste der Anhänge anzeigen (Anzahl: 1)
Zitat:
|
AW: Find out why after 22 years more developers than ever are choosing Delphi
Zitat:
Wie Assembler und C m.E. primär den Compilern geschultet sein die Teilweise noch einige Altlasten mitführen. |
AW: Find out why after 22 years more developers than ever are choosing Delphi
Zitat:
Bitte nur die interessanten mit Mangas und Äffchen. Himitsu hat das schon richtig vor-gefiltert :thumb: |
AW: Find out why after 22 years more developers than ever are choosing Delphi
Zitat:
...:cat:... |
AW: Find out why after 22 years more developers than ever are choosing Delphi
Zitat:
So gewinnt man keine Kunden meiner Meinung nach. |
AW: Find out why after 22 years more developers than ever are choosing Delphi
Zitat:
Ein Compiler der einem aufzwingt dinge in sein Programm mit ein zu kompilieren was nicht nötig und NICHT verwendet wird der Taugt nichts. Zitat:
Oder damit du wenig Arbeit hast erstelle ein leeres DLL/Projekt und vergleiche die Unterschiede. Lieb sein sonst schicke ich dir den hier... ![]() gruss |
AW: Find out why after 22 years more developers than ever are choosing Delphi
Bei Ressourcen weiß der Compiler es nicht.
Da müsste Emba mal beim {$R} einbauen, dass man da ein "lass weg, wenn nicht direkt referenziert"-Flag angeben kann, aber es gibt eh keine direkten Ressouren-Referenzierungen. Außnahme sind die RessourceStrings und die lässt der Compiler/Linker bereits weg, wenn sie nicht genutzt werden. {$R} "innerhalb" einer Klassen-Deklaration oder in einer Prozedur-Implementation definiert, da wäre es schön, wenn sowas der Compiler mit weglassen würde, wenn die Klasse/Prozedur auch nicht gelinkt wird. Und der Rest liegt nicht am Compiler. Es ist auch aufwändig, wenn man nachträglich versuchen wöllte alle Verbindungen dynamisch zu gestalten und zusätzlich ist es für den Entwickler schwerer, weil er alles selber einbinden müsste, was bisher automatisch immer da war. Class-Constructor/Destructor: ich verwende Jenen auch, seit paar Jährchen, anstatt alles in Initialization /Finalization zu packen, denn alles was in Letzterem ist, wird immer eingebunden, da es "dort" verwendet wird, selbst wenn es sonst kein Anderer nutzt. Und da kenne ich fast Keinen, der sowas nutzt. |
AW: Find out why after 22 years more developers than ever are choosing Delphi
Zitat:
|
AW: Find out why after 22 years more developers than ever are choosing Delphi
Nein.
Es gibt auch so schon immer zwei "Durchgänge". Compiler und Linker. Ein Pre-Compiler, wo wir uns einklinken können, wäre aber mal was Schönes. Der Compiler nimmt den Quellcode, übersetzt ihn und optimiert ihn etwas. Zum Schluß setzt der Linker alles zusammen und lässt eventuell noch paar Dinge weg. Eine Unit wird auch erstmal komplett kompiliert (zur PAS -> DCU), der Ressource-Compiler nimmt sich die unkompilierten Ressourcen vor (RC -> RES) und dann baut der Linker das zusammen. (DCU/DFM/RES -> EXE/DLL/BPL/...) Der Linker lässt dabei ungenutzte Konstanten weg (fasst Doppelte zusammen) und auch die ungenutzten Prozeduren und Typen fliegen raus. Dann noch die Offsets und Adressen anpassen, an die endgültigen Positionen. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 15:14 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz