Delphi-PRAXiS
Seite 5 von 15   « Erste     345 67     Letzte »    

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Klatsch und Tratsch (https://www.delphipraxis.net/34-klatsch-und-tratsch/)
-   -   Find out why after 22 years more developers than ever are choosing Delphi (https://www.delphipraxis.net/193185-find-out-why-after-22-years-more-developers-than-ever-choosing-delphi.html)

Der schöne Günther 3. Jul 2017 12:19

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.

TiGü 3. Jul 2017 12:26

AW: Find out why after 22 years more developers than ever are choosing Delphi
 
Liste der Anhänge anzeigen (Anzahl: 1)
Zitat:

Zitat von Der schöne Günther (Beitrag 1375856)
Bei mir ist es anders herum. Ich fand es interessant, danke für den Post. Ich bekomme solche Mails nie.

Ich leite sie dir gerne weiter! 8-)

Bernhard Geyer 3. Jul 2017 12:27

AW: Find out why after 22 years more developers than ever are choosing Delphi
 
Zitat:

Zitat von DualCoreCpu (Beitrag 1375792)
Welche Programmiersprache die Delphi Entwickler verwenden, weiß ich auch nicht.

Müsste AFAIK Delphi, C, C++ und Assembler sein. Vor einiger Zeit war (wegen UML-Integration noch J#/.NET dabei).
Wie Assembler und C m.E. primär den Compilern geschultet sein die Teilweise noch einige Altlasten mitführen.

Der schöne Günther 3. Jul 2017 12:29

AW: Find out why after 22 years more developers than ever are choosing Delphi
 
Zitat:

Zitat von TiGü (Beitrag 1375857)
Ich leite sie dir gerne weiter! 8-)

Nein bitte nicht :shock:



Bitte nur die interessanten mit Mangas und Äffchen. Himitsu hat das schon richtig vor-gefiltert :thumb:

sakura 3. Jul 2017 12:44

AW: Find out why after 22 years more developers than ever are choosing Delphi
 
Zitat:

Zitat von TiGü (Beitrag 1375857)
Zitat:

Zitat von Der schöne Günther (Beitrag 1375856)
Bei mir ist es anders herum. Ich fand es interessant, danke für den Post. Ich bekomme solche Mails nie.

Ich leite sie dir gerne weiter! 8-)

Für mich grenzt das schon an Spam, daher habe ich die auch abbestellt. Das ist einfach viel zu viel... :?

...:cat:...

SneakyBagels 3. Jul 2017 13:34

AW: Find out why after 22 years more developers than ever are choosing Delphi
 
Zitat:

Für mich grenzt das schon an Spam, daher habe ich die auch abbestellt. Das ist einfach viel zu viel...
Dito.

So gewinnt man keine Kunden meiner Meinung nach.

EWeiss 3. Jul 2017 17:29

AW: Find out why after 22 years more developers than ever are choosing Delphi
 
Zitat:

Um die Größe von EXE-Dateien zu streiten, lohnt nicht.
Ich streite mich über den ach so großen Fortschritt der keiner ist.. wenn man das gesamt Ergebnis vor Augen hat.
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:

@TiGü Wenn du wirklich reine Non-VCL und Non-RTL Programme schreiben würdest, wäre die EXE in Turbo Pascal, Delphi 2, Delphi 7, Delphi 2010, Delphi Tokyo und so weiter annähernd gleich groß.
Quatsch mach's einfach mal dann siehst du das deine Behauptung für'n.. Ar.. ist.
Oder damit du wenig Arbeit hast erstelle ein leeres DLL/Projekt und vergleiche die Unterschiede.
Lieb sein sonst schicke ich dir den hier... https://twitter.com/realDonaldTrump/...03147168071680 LOL ;)

gruss

himitsu 3. Jul 2017 18:54

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.

SneakyBagels 3. Jul 2017 21:30

AW: Find out why after 22 years more developers than ever are choosing Delphi
 
Zitat:

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.
Aber bräuchte man dafür dann nicht schon fast einen 2-Wege-Compiler so wie bei C++?

himitsu 3. Jul 2017 23:01

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.
Seite 5 von 15   « Erste     345 67     Letzte »    

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