Delphi-PRAXiS

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Sonstige Fragen zu Delphi (https://www.delphipraxis.net/19-sonstige-fragen-zu-delphi/)
-   -   Delphi .inc VS .pas (https://www.delphipraxis.net/9416-inc-vs-pas.html)

TopDogg 25. Sep 2003 22:39


.inc VS .pas
 
h! alle.
nur mal so ne frage.
wo is der unterschied zwischen dem einbinden einer .inc und einer .pas?

.inc
Delphi-Quellcode:
program
  Test;

uses
  Windows,
  Messages;

{$INCLUDE Test.inc}

...
und hier .pas

Delphi-Quellcode:
program
  Test;
 
uses
  Windows,
  Messages,
  Test{.pas};

...
ich weiss das ne .pas anders aufgebaut ist, aber is das der einzige unterschied?

thnx

Luckie 25. Sep 2003 22:51

Re: .inc VS .pas
 
Angeblich erzeugt eine pas-Datei einen Overhead oder so. Assarbad kann dir da genaueres sagen. Deswegen nutze ich auch wenn es geht und ich nur Code auslagern will Include-Dateien. Soll es eigenständiger Code sein, also eien Klasse oder so, dann nehme ich pas-Dateien.

Chewie 25. Sep 2003 22:52

Re: .inc VS .pas
 
Die Dateiendung spielt keine Rolle.
Der Unterschied ist der:

In der uses-Klausel werden ganze Units eingebunden, die mindestens vollständige interface- und implementation-Abschnitte haben.

Die Compilerdirektive $INCLUDE fügt den Inhalt einer Datei so in den Quelltext ein, als wäre er an diese Stelle geschrieben worden, allerdings mit der Einschränkung, dass dies nicht innerhalb eines Anweisungsblocks geschehen kann.

negaH 25. Sep 2003 22:54

Re: .inc VS .pas
 
Nein, es gibt noch mehr Unterschiede.
Eine *.INC Datei, sprich Include, wird wie es der name verät als Quelltext in die entsprechende Pascal Source "hineinkopiert". Das bedeutet auch das ein Include in mehreren Pascal Sourcen eben dann auch mehrmals eingeklinkt wird und somit der evtl. Code in der Include mehrmals in der EXE vorkommt. Man sollte in der Include nur ordinale Konstanten oder globale Kompilerschalter einbauen.

Gruß Hagen

Luckie 25. Sep 2003 23:04

Re: .inc VS .pas
 
Aber nur, wenn ich ihn mehrmal "inklude", oder?

Brüggendiek 25. Sep 2003 23:49

Re: .inc VS .pas
 
Hallo!

Includes haben gegenüber Units noch einen Nachteil: sie müssen beim Compilieren des Sources immer mit compiliert werden.
Units werden nur dann neu compiliert, wenn es nötig ist.

Bei einer geänderten Include-Datei, die in mehrenen Units eines Projekts vorkommen, weiß ich nicht, was da passiert. Es kann sein, daß Delphi die Änderung erkennt und die ganze Unit übersetzt, kann aber auch anders sein.

Wenn man in mehreren Units Compilerschalter verstellen will oder Ähnliches, sollte man das über "Projekt", "Optionen", "Verzeichnisse/Bedingungen", "Bedingungen" in Verbindung mit bedingter Compilierung erledigen. Nach einer Änderung einfach mit "Projekt", "Erzeugen" alles durchcompilieren und gut is.

Includes stammen aus der Turbo-Pascal-Zeit (bis Version 6). Da mußten die Entwicklungsumgebung, der Source, das ausführbare Programm und die verarbeiteten Daten in den Speicher reinpassen, den MS-DOS und die Treiber von den 640KByte übriggelassen hatten.
Die .INC-Dateien waren dann bei dem Speicherverbrauch nicht relevant. Also alles, was fertig ist, in die .INC und damit wieder Platz schaffen.
Bei Version 7 gab es einen Compiler, der alles in den Erweiterungsspeicher packte (jenseits von 1MByte) und sich nur ca. 10KByte Speicher genehmigte. Da war es dann wieder möglich, mehrere Dateien offenzuhaben und trotzdem zu testen.

Fazit: Für .INC finde ich heute keine sinnvolle Anzuwendung mehr.

Gruß

Dietmar Brüggendiek

negaH 26. Sep 2003 00:14

Re: .inc VS .pas
 
Zitat:

Includes stammen aus der Turbo-Pascal-Zeit (bis Version 6). Da mußten die Entwicklungsumgebung, der Source, das ausführbare Programm und die verarbeiteten Daten in den Speicher reinpassen, den MS-DOS und die Treiber von den 640KByte übriggelassen hatten.
Die .INC-Dateien waren dann bei dem Speicherverbrauch nicht relevant. Also alles, was fertig ist, in die .INC und damit wieder Platz schaffen.
Bei Version 7 gab es einen Compiler, der alles in den Erweiterungsspeicher packte (jenseits von 1MByte) und sich nur ca. 10KByte Speicher genehmigte. Da war es dann wieder möglich, mehrere Dateien offenzuhaben und trotzdem zu testen.

Fazit: Für .INC finde ich heute keine sinnvolle Anzuwendung mehr.

Diesen Aussagen kann ich so nicht zustimmen. Includes erfüllen eine bestimmte Aufgabe, nämlich mehrfachverwendeten Source auch mehrfach verwendbar zu machen ohne diesen jedesmal in den Source reinkopieren zu müssen. Es gibt auch heute noch solche sinnvollen Aufgaben für Includes.

Dies hat rein garnichts mit Speicherproblemen oder historischen Begebenheiten zu tun, es erscheint nur veraltet weil das Wissen um Includes langsam ausstirbt. Die Behauptung das dadurch Speicher gespart wird ist sogar unlogisch, denn die Include wird in den Pascal Source beim compilieren eingefügt so als wäre es Source. Somit erhöht sich der Speicherverbrauch der Sourcen bei Includes, und erst recht bei Mehrfachverwendung der gleichen Includes. Ebenfalls leidet die Compilergeschwindigkeit darunter, denn nun wird der gleiche Source aus einer Include jedesmal erneut compiliert. D.h. wenn 5 Pascal Source die gleiche Include benutzen so muß der Compiler diesen included Source auch 5 mal separat compilieren.

Es gab aber bis BP4 bestimmte "Speicherbegrenzungen" die aber nur darin begründet waren das der IDE Texteditor nur 64Kb große Quelltexte bearbeiten konnte. Bei größeren Datenmengen, z.B. hardcoded Datentabellen, wurden diese dann in Includes ausgelagert damit der Sourceeditor arbeiten konnte.


Gruß Hagen

TopDogg 26. Sep 2003 00:22

Re: .inc VS .pas
 
Danke fuer die antworten.
Ich wollte das nur mal so wiessen.
Bleiben tu ich dennoch bei den .INC da es irgendwie "sauberer" im code fuer mich aussieht.
Grosse projeket habe ich e nicht.
Nur einfache mit 5-6 funktionen, und da gefaellt mir die methode mit .INC besser. Ueber geschmack kann man streiten.
:lol: :lol: :lol:


Alle Zeitangaben in WEZ +1. Es ist jetzt 21:12 Uhr.

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz