Wozu einen anderen Compiler?

[runningsoft]

Mal eine vermutlich blöde Frage: In den letzten Tagen gab es einen Thread zum paxCompiler.
Warum benötigt man einen anderen Compiler als den in Delphi eingebauten?

Hab mir um das Compilieren noch nie besondere Gedanken gemacht. Schaltfläche zum Compilieren gedrückt und gut war es :-D

[Delphi.Narium]

Mein Selbstbaueditor enthält z. B. PascalScript von RemObjects.

Damit kann ich dann Pascalscript im Editor schreiben, von dem kompilieren lassen und ausführen. Dabei entstehen aber keine neuen Programme, sondern nur vom Editor ausführbare Scripte.

Eine Entwicklungsumgebung ist dazu nicht nötig.

Auf diese Weise kann man eigene Programme zusätzlich mit 'ner Scriptengine ausstatten, ohne dass man dann für jede Erweiterung, jedes Script, ... das Programm (hier also den Editor) neu kompilieren muss.

Flapsig formuliert:

Das ist dann sowas ähnliches wie eine Batchdatei für CMD von Windows. (Nur halt vieeeeeeel leistungsfähiger.)

Man kann damit aber auch mit Delphi für den Kunden ein vollständiges und lauffähiges Programm erstellen und der Kunde kann dann per PascalScript (o. ä.) eigene Erweiterung, ... für das Programm schreiben.

Man könnte es aber auch analog zu den Makrosprachen der diversen Officepakete betrachten:

Fertige Software kann per Makro, Script, wie auch immer, erweitert, automatisiert, ... werden.

[dummzeuch]

Wir benutzen das in Fastreport eingebaute Pascal Script zur Bewertung von Daten, die je nach Projekt unterschiedlich sind. Man könnte das natürlich auch direkt ins Programm einbauen und parametrisieren, aber so ein Skript ist schlicht flexibler. Nachteil ist natürlich, dass man zumindest rudimentäre Programmierkenntnisse haben muss. Das Skript wird dann mit dem Projekt abgelegt und damit sind diese Parameter später gut nachvollziehbar.

[Uwe Raabe]

Zitat:

Zitat von runningsoft (Beitrag 1491458)

Warum benötigt man einen anderen Compiler als den in Delphi eingebauten?

Der paxCompiler läuft innerhalb der EXE beim Kunden um dessen Skripts zu compilieren. Er ist nicht dazu gedacht, deine Delphi-Sourcen zu compilieren.

[runningsoft]

Danke für die Antworten. Die geschilderten Szenarien liegen Gott sei Dank außerhalb meines Anwendungsbereiches für Delphi :lol:

[himitsu]

Jo, dieser "Compiler" erzeugt keine "eigenständigen EXEen".

Wie JavaScript, VBScript, Python usw., so wird hier einfach ein Pascal-Script ausgeführt,
nur dass des hier kein "einfacher" Interpreter ist, sondern er compiliert generiert ByteCode (quasi Assembler), welcher direkt von der CPU ausgeführt werden kann.

Andere Script-Interpreter parsend und führen direkt den Text-Code (langsam) aus,
wiederrum andere erstellen erstmal einen "eigenen" ByteCode und verarbeiten den dann selbst. (also statt direkt mit TEXT wird BINÄR gearbeitet ... z.B. siehe JAVA),
oder eben den TEXT in CPU-Befehle übersetzen und die CPU das machen lassen. (anstatt selbst jeden "BEFEHL" einzeln auszuführen)



PS: In Python kann man die Scripte auch in einen ByteCode compilieren lassen und jene dann ausführen ... geht schneller, als erst langsam den TEXT analysieren zu müssen.
python py pyc

[Jens01]

Als ich den PaxCompiler rausgeworfen habe, habe ich mir quasi eine kleine, eigene Entwicklungsumgebung geschaffen, womit ich dann kleine Skripte mit dem externen Delphi-Compiler DLLs compiliert habe, als Stream in eine Datenbank abgelegt und nach Bedarf direkt (über ein Tools von Github) in den Speicher geladen.

[freimatz]

Wenn das dann beim Anwender passieren soll, wird man eine Lizenz von EMB dazu benötigen.

[Jens01]

Zitat:

Wenn das dann beim Anwender passieren soll, wird man eine Lizenz von EMB dazu benötigen.

Schon klar. Das ist bei mir aber nicht so. Ich würde dann Freepascal o.ä. nehmen.