Ich hatte eher ein schlankes Profan ohne die Sachen, die man nicht immer braucht,
gemeint. Da könnte z.b. die dBase funktionen, das OGL, Multimedia u. Sound, SQL usw.
extern gehalten werden.
Inline-Assembler
-
-
-
@H.Brill: Vermutlich wäre das dann nicht mehr XProfan ... Ob ein großes oder kleines File statisch im Speicher liegt, müsste bei den heutigen Speichergrößen und Ladegeschwindigkeiten mehr oder weniger egal sein. Fehlerabfragen halten aber extrem auf, weil der D A U hier das Maß ist. XProfan selbst sollte sich m.E. nicht ändern, jedenfalls rückwärtskompatibel bleiben ( - das ist ja eine große Stärke!). Ich schreibe hier auf einem Vista-System, und Profan läuft und läuft und läuft ... fast schon ein Volxprofan ;-). Ein Performanz-Modul ohne ständige Fehlerabfragen müsste doch eigentlich schneller sein - ausgiebiges Testen im bisherigen System als "Entwicklungssystem" vorausgesetzt?
P.S.: Ich hoffe, ich begehe da keinen Denkfehler und die Fehlerchecks kommen von den verwendeten Windows-APImodulen selbst ...
-
@p.specht: Fehlerchecks kommen von den verwendeten Windows-APImodulen selbst
Das wird sicher auch überwiegend so sein, soweit es nicht die Profan-Syntax selbst betrifft. Da bleibt also wenig "Sparpotential" unterhalb von ErrorLevel 0. Mit dem, was die API zurückliefert, muß Profan intern ja trotzdem irgendwie umgehen, auch wenn es letztlich nicht zum Anwender durchgereicht wird.
Im Übrigen sehe ich das auch so, daß die Abwärtskompatibilität ein ein wesentliches Pro-Argument für XProfan ist, so reizvoll der Gedanke auch sein mag, ganze Funtionalitäten optional zu inkludieren. Und nicht nur die Möglichkeit, jede beliebige PRC (auch fremder Herkunft...Hauptsache versionskonform) mit dem Runtime-Modul zu starten, wäre damit dann passe.
Der allfällig mitgeschleppte "Rücksack" hat denn doch schon so seine Vorteile...
-
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!