Du bist nicht angemeldet.

Werbeanzeige

buggypixels

Treue Seele

  • »buggypixels« ist der Autor dieses Themas

Beiträge: 125

Wohnort: Meerbusch

Beruf: Programmierer

  • Private Nachricht senden

1

13.09.2017, 08:53

c_hot_reload - DLLs dynamisch zur Laufzeit nachladen

Hallo zusammen,

wie sagt man so schön "sharing means caring".
Darum schicke ich mal einen Link zu meinem kleinen Projekt "c_hot_reload" (https://github.com/amecky/c_hot_reload).
Es ist ein kleines Beispiel, wie man C Code in eine DLL auslagert und diese
dann dynamisch zur Laufzeit nachladen kann.
Also statt Scripting languages wie Lua oder ähnliches zu verwenden, kann man
das Gleiche auch mit C erreichen.

Das Ganze ist mehr ein Test und zumindest bei mir läuft es auch. Also bitte eher
als Vorschlag oder Beispiel betrachten. Wer Interesse hat kann gerne reinschauen.
Der Code läuft unter MIT Lizenz. Es steckt ja auch nicht viel spektakuläres drin.

Würde mich über Feedback freuen.

Ich hoffe, ich habe es an der richtigen Stelle gepostet. Ansonsten bitte einfach verschieben.

dot

Supermoderator

Beiträge: 9 814

Wohnort: Graz

  • Private Nachricht senden

2

13.09.2017, 11:56

nice ;)

Feedback:
1) Das ist C++ und nicht C. ;)
2) Wenn es eh schon C++ ist, wieso dann nicht ordentlich von C++ Gebrauch machen? Mit Klassen, Konstruktoren, Destruktoren, RAII, std::filesystem::path, Exceptions, std::cout, std::unordered_map wäre der Code vermutlich wesentlich sauberer, robuster, sicherer, effizienter, lesbarer und kompakter.
3) Wieso wird bei jedem Erzeugen einer Registry ein neuer RegistryContext angelegt und der alte geleaked? (static vergessen?)
3.1) Wieso muss der RegistryContext überhaupt dynamisch erzeugt werden?
4) Was wenn die DLL die geladen werden soll bereits im Current Directory liegt?
5) Was wenn irgendwie, irgendwo, irgendwann ein Pfad mal mehr als 256 Zeichen lang wird?
6) Was wenn ich mein Plugin gerne Iñtërnâtiônàlizætiøn.dll nennen würde? :P

buggypixels

Treue Seele

  • »buggypixels« ist der Autor dieses Themas

Beiträge: 125

Wohnort: Meerbusch

Beruf: Programmierer

  • Private Nachricht senden

3

13.09.2017, 12:30

Erst mal Danke fürs Feedback.
Ich hatte mich etwas mißverständlich ausgedrückt. Die Beschränkung auf C gilt nur für das Plugin (die DLL). Das ist
mit Absicht, damit die Daten und die Funktionen getrennt sind. Die Daten sollen erhalten bleiben nach einem Reload.

Den Rest schaue ich mir mal in Ruhe an. Bei ein paar Dingen hast Du recht. Das werde ich mal angehen.

dot

Supermoderator

Beiträge: 9 814

Wohnort: Graz

  • Private Nachricht senden

4

13.09.2017, 13:22

Die Beschränkung auf C gilt nur für das Plugin (die DLL).

Ok, das dachte ich mir fast. Ich verwend in einigen meiner Projekte ein ähnliches System. Während ein reines C Interface zum Plugin streng genommen natürlich das portabelste is, so ist das was du hier treibst sowieso Windows-spezifisch. Ich würde mir überlegen, ob es nicht netter ist, bei Plugins mit C++ Interfaces (Klassen mit rein virtuellen Methoden) zu arbeiten. Ist zwar nicht garantiert, aber simple Interfaces dieser Art sollten unter Windows portabel genug sein, da jeder ernsthafte Compiler unter Windows sowieso COM kompatibles Layout erstellen muss...

buggypixels

Treue Seele

  • »buggypixels« ist der Autor dieses Themas

Beiträge: 125

Wohnort: Meerbusch

Beruf: Programmierer

  • Private Nachricht senden

5

13.09.2017, 20:49

Ich habe ein wenig daran gearbeitet. Die neue Version zeigt eine Möglichkeit auf, wie man in der Release Version
die DLL als statische Lib einbindet. Das ist zwar etwas unschön, wäre aber so möglich. Dann muß man in der Release
Version nicht die ganzen DLLs mitliefern.

Werbeanzeige