| |
| |
|
Uwe
''Pascal''
Niemeier | Hi Roland!
Was ich mir schon lange wünsche:
Daß beim Kompilieren nur solche Procs/Funktionen erfaßt werden, die innerhalb des
Programmes auch wirklich aufgerufen werden.
Jede eingebundene "Universal"-INC bläht das Programm bisher oft unnötig auf,
weil man ja meist nur einen Teil der enthaltenen Rotuinen wirklich verwendet.
PS: Bitte keine Kommentare in der Art "Hol dir doch ne größere Festplatte"!
Mir geht es hier um das Prinzip!
SeeYou
Pascal |
|
| |
| |
| |
|
|
Jörg
Sellmeyer | | Da würde ich ja noch eins drauflegen und den Wunsch äußern, bestimmte Programmteile/-bibliotheken (z.B. ogl) vom Compilieren ausschließen zu können. |
|
| |
| Windows XP SP2 XProfan X4... und hier mal was ganz anderes als Profan ...  | 27.12.2009 ▲ |
|
| |
|
|
RGH | @Pascal: Das umzusetzen, würde ein komplettes Redesign des Compilers nötig machen. Ich weiß nicht, ob sich da der Aufwand lohnt oder gar sinnvoll ist. "Never change a running system!" Derzeitr werden Includes, wie auch in der Hilfe beschrieben, so verwandt, als stünde der Code an der Stelle, an der er includiert (= eingefügt) wird. Das heißt, die Includes werden schon im Vorfeld vor dem Compilieren in den Quellcode eingebunden.
@Jörg: Das ist leider nicht möglich und würde auch nicht sehr viel bringen, zumindest nichts an der Geschwindigkeit verändern.Beim Linken wird das Compilat mit der Runtime verbunden. Diese ist eine EXE-Datei. Aus dieser lassen sich während des Linkens keine Teile entfernen.
Es wäre höchstens denkbar, verschiedene Runtime-Module mitzuliefern. Allerdings ist die Auswirkung auf die Größe des Programmes nicht soooo riesig. Und man müsste bei jedem Projekt überlegen, welche Runtime man benötigt: Mit oder ohne Datenbankfunktionen, mit oder ohne OGL, mit oder ohne ...
Man könnte natürlich OGL- und Datenbankfunktionen auch in eigene DLLs auslagern, die man dann nur bei Programmen mitliefert, die diese benötigen.
Gruß
Roland |
|
| |
| Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4 | 27.12.2009 ▲ |
|
| |
|
|
 | Es gibt den Schalter {$u} für Unused in XPSE, funktioniert momentan leider nicht wegen vieler Änderungen wegen der NProcs.
Herausgefiltert werden ungenutzte Procs damit, dass alle Procnamen einen Referenzzähler haben und der Source wortweise rekursiv abgegangen wird um Zähler zu erhöhen. Procs mit Zähler <1 werden dann einfach nicht aufgeschrieben. 2 Problem/Ausnahmefälle waren Units/Procaddr. ^^
Wenn die NProcs in der Beta-Phase sind, dann repariere ich das Feature sodass man dann wieder z.B. riesige Includes nutzen kann die nicht aufblähen wenn man nur ein paar Funktionen daraus nutzt. |
|
| |
| |
| |
|
|
Uwe
''Pascal''
Niemeier | Hi Leute!
RGH
Never change a running system!
Schon wahr...
Ich dachte nur: Da PROCs ja vorwärtsdeklariert werden können (also im Quelltext hinter
ihrem ersten Aufruf stehen dürfen) und der Kompiler den Code sowieso mehrmals durchgeht,
könnte man da was machen in der Art, wie iF beschrieben hat. Also eine Form von Filter,
der vor den eigendlichen Kompiler gesetzt wird.
Bin als Hardcore-Coder ja eigendlich kein Freund von Prekompilern (Sorry iF),
aber vielleicht bastele ich mir da selbst mal was...
SeeYou
Pascal |
|
| |
| |
| |
|
|
| Uwe Pascal Niemeier, Beitrag=55618, Zeitpunkt=28.12.2009
Bin als Hardcore-Coder ja eigendlich kein Freund von Prekompilern (Sorry iF),
Hm, das halte ich aber für einen Widerspruch in sich, auch weil XPSE doch grad fürs Hardcore-Coden mit XProfan wie geschaffen ist.
Es gibt auch keine ernstzunehmende Programmiersprache, die ohne (meist dann aber eingebauten) Präkompiler auskommmt. Da Roland nicht so viel Energie ins Präkompilerschreiben steckt, ist es doch gewissermassen Aufgabe des XPSE, übrigbleibende Potentiale anzuzapfen. |
|
| |
| |
| |
|
|
Uwe
''Pascal''
Niemeier | Hi iF!
Hm, das halte ich aber für einen Widerspruch in sich,
auch weil XPSE doch grad fürs Hardcore-Coden mit XProfan wie geschaffen ist.
Ich meine das eher in dem Sinne, daß ich lieber volle Kontrolle über meinen Quellcode habe,
weshalb ich auch selten auf fertige PCUs und INCs zurückgreife.
Bei den abstrusen Sachen, mit denen ich mich beschäftige... 
SeeYou
Pascal |
|
| |
| |
| |
|
|
Jörg
Sellmeyer | Dabei fällt mir ein, daß man seine Procs ja eigentlich auch in ph-Dateien unterbringen könnte:
KompilierenMarkierenSeparieren
Wenn dann die Prozedur verwendetwerden soll, braucht im Programm nur:
KompilierenMarkierenSeparieren
stehen. Wenn man sich konsequent seine Standardprozeduren, so anpaßt, dürfte das Einiges einparen... |
|
| |
| Windows XP SP2 XProfan X4... und hier mal was ganz anderes als Profan ... | 06.01.2010 ▲ |
|
| |
|
|
| Ersparen kann man sich bereits einiges, fängt beim @ an und geht über zum Tilde - kenne aber niemanden ausser mir, der
KompilierenMarkierenSeparieren schreibt.
Sparen=Kauderwelsch sagen die Leute, und Leute haben immer Recht. |
|
| |
| |
| |
|
|
Matthias
Arlt | Sparen ist ja prinzipiell gut. Und ich würde das Urteil "Kauderwelsch" mal eher schmunzelnd quittieren.  Das Problem, so es denn eines ist, liegt doch woanders. Am Ende der Vereinfachung steht eine sehr individuelle, oftmals komplett veränderte Syntax, die, wenn sie nicht im eigenen Hinterkopf gereift ist, so ihre Tücken hat. Der Einsteiger ist verwirrt und z.T. überfordert, bietet ihm das "Standard-Profan" doch auch so schon genügend Lernpensum. Der erfahrene Programmierer hat sich über die Jahre seinen eigenen Stil angewöhnt und ist zumeist darin auch etwas verfestigt. Eine breite Akzeptanz zu erreichen, kann da schon sehr lange dauern.
Ich verwende ja selbst seit Jahren eigene kleine Precompiler. Sehr viel bescheidener im Funktionsumfang und eben auf meine Wünsche und Gewohnheiten zugeschnitten. Ob andere darin für sich auch einen Vorteil sähen, sei mal dahingestellt... |
|
| |
| WinXP SP2, Win7 - XProfan 10/11/FreeProfan32 - Xpia | 06.01.2010 ▲ |
|
| |
|
|
| Allgemein ja, konkret aber nicht, denn
KompilierenMarkierenSeparieren hat mit "Stil" und "Jahre" und "eigen" nicht wirklich etwas zu tun und auch nicht mit dem schnelleren Programm. ^^ |
|
| |
| |
| |
|
|
Nico
Madysa | Jörg Sellmeyer, Beitrag=55760, Zeitpunkt=06.01.2010
Zonk, klappt meines Wissens leider nicht. Die Idee hatte ich auch mal, aber in den Procs darf dann (unsinnigerweise) kein Istgleich vorkommen -- dann wird sie nämlich nur bis zu diesem Istgleich in den Kode eingebaut.
Habe dazu auch irgendwo hier was geschrieben, was aber im Sande verlief und auch nicht mehr auffindbar ist. |
|
| |
| |
| |
|
(767)
Deutsch
English
Français
Español
Italia