Wie kann ich mein C-Projekt "importieren", dass jeder Emulator sein C-Programm starten kann.
Geht das vielleicht in den Funktionsdeklarationen? Das C-Projekt ist ziemlich umfangreich und importiert so ca. 50 Files.

Für Tips wäre ich sehr dankbar.

Grüße Jens

In diesem C-Projekt sind natürlich Datenfelder definiert (structs, Variablen, ...).
Wenn ich jetzt eine 2. Emulator-Instanz starte, die dann wieder die main()-Methode des C-Projekts aufruft, greift diese auf dieselben Daten des C-Projekts zu, wie das zuerst erzeugte Objekt.
Das soll aber so nicht sein...

Jetzt bin ich auf der Suche nach einer einfachen Lösung, ohne mein C-Projekt nach C++ portieren zu müssen.

Allgemeine Abhilfe wäre jedenfalls, das C-Programm in einem eigenen Prozess laufen zu lassen, statt in einem Thread, wie du es anscheinend jetzt machst. Wie das mit Prozessen&Co geht, ist jedoch stark betriebssystemabhängig, da müsstest du uns deine Plattform verraten.

Du hast richtig eingeschätzt, dass ich das ganze derzeit in einem Thread laufen lasse, um auf die Daten (Visualisierung) zugreifen zu können.
Würde das bei einem Prozess auch noch gehen? Wohl nicht direkt oder?

Meine Plattform ist Windows (hier Win7), Visual Studio 2008 und 2010

Gibt es da keine Möglichkeit?

Gibt es da keine Möglichkeit?

Gibt es: Das C Programm so umschreiben, dass es eben keine globalen Daten verwendet.

jcp1978 schrieb:
Gibt es da keine Möglichkeit?

Gibt es: Das C Programm so umschreiben, dass es eben keine globalen Daten verwendet.

das scheidet leider aus
das C-Programm läuft so wie es ist auf einem Mikroprozessor,
da macht es wenig Sinn, das dort zu ändern.

deshalb mein Ansatz, aber scheinbar leider eine Sackgasse

Das C-Programm hat "intern" globale Daten,
genau diese hätte ich gerne aber in meinem C++-Tool instanziiert.

Gibt es da keine Möglichkeit?

Jain.
Du kannst jedes deiner C-Projekte zu einer DLL compilieren.
Dann kannst du unterschiedliche C-Projekte (=unterschiedliche DLLs) nebeneinander laufen lassen. Jede DLL hat eigene Kopien globaler Variablen, also ist alles gut.

Was damit nicht geht: du kannst so nicht mehrere Instanzen des selben C-Projekts in deinem Emulator laufen lassen. Die globalen Variablen eines einzelnen Projekts sind ja immer noch nur 1x vorhanden.

Wobei man selbst das mit einem Trick (Hack) umgehen könnte: schreib dir einen "Loader", der die DLL erstmal in irgendein Temp-Verzeichnis kopiert, und ihr dabei einen eindeutigen (im Sinn von "unique") Namen verpasst (GUID oder was auch immer). Die Kopie der DLL lädst du dann mit LoadLibrary.
Wenn ich mich nicht sehr sehr täusche, hätte dann wieder jede Kopie der DLL ihre eigenen globalen Variablen.
Pro Instanz eines Programms die du laufen lassen willst, müsstest du dann eine neue Kopie erzeugen und laden.

Da du die DLLs dann mit LoadLibrary lädst, musst du dir alle Funktionen die du in den DLLs aufrufen willst mit GetProcAddress holen. Bei vielen Funktionen kann das viel lästig werden. Üblicherweise macht man es daher so, dass man bloss eine Funktion exportiert, die einen Zeiger auf eine Instanz einer Klasse zurückgibt, deren sämtliche Funktionen "virtual pure" sind. Diese Funktionen kannst du dann über den Zeiger aus dem Emulator-Programm aufrufen, ohne dass du sie mit LoadLibrary holen müsstest oder gar "fest" binden (=über eine import-lib).

Und je länger ich darüber nachdenke, desto besser gefällt mir dieser Hack
Sieh nur zu dass du ausreichend Kommentare schreibst was dein Emulator da macht, und vor allem wieso - damit das der nächste der das Projekt warten muss auch verstehen kann.

1000 Dank an alle und besonders @hustbaer

Evtl. ist die Variante mit mehreren Prozessen also nicht nur sauberer, sondern sogar auch noch weniger Implementierungsaufwand.

Das bezweifle ich mal stark.

Hätte aber noch andere Vorteile wenn das in verschiedenen Prozessen läuft. z.B. dass die "Systeme" dann auch wirklich weitestgehend getrennt sind, und ein Crash/krasses Fehlverhalten eines Systems (Speicher überschreiben, ...) ein anderes System nicht beeinflussen kann.
Auch könnte man einfach ausprobieren was passiert, wenn man ein System unerwartet aus dem Spiel entfernt (Taskmanager, Prozess beenden).

Dafür ist es wieder lästiger in anderen Situationen. Wenn der User das Emulator-Programm beenden will, z.B. weil es sich weggehängt hat, dann muss er danach noch alle "System-Prozesse" einzeln killen. Kann man natürlich auch so machen dass die das mitbekommen und sich dann selbst beenden, aber ... auch wieder Aufwand.

dot schrieb:

Evtl. ist die Variante mit mehreren Prozessen also nicht nur sauberer, sondern sogar auch noch weniger Implementierungsaufwand.

Das bezweifle ich mal stark.

Naja, mit dem dll-Hack muss er dann eben statt der Prozessinstanzen die einzelnen Module verwalten (abgesehen davon dass es natürlich unsauber ist, weil rumgefrickel mit temporären Dateien, der Code mehrfach gemapped wird etc.). Wenn er das prozessintern mit Threads machen will, dann muss er seinen CAN Bus immer noch selber bauen, was dann aber bedeutet er muss sich selber um die Verwaltung der Buffer und die Synchronisation kümmern. Zugegeben: Das ist jetzt auch nicht grad hochkompliziert, aber mit Pipes und separaten Prozessen braucht er all das nicht zu tun, weil es das Betriebssystem schon automatisch macht -> Nicht nur sauberer sondern auch weniger Aufwand (oder zumindest ganz sicher nicht mehr)...

Da CAN ein multidrop, multi-master Bus ist, wird er soweiso etwas selbst implementieren müssen. Und wieso sollte das mit Prozessgrenze einfacher sein als ohne? Wo hilft sie mir?
Falls Sockets/Pipes wirklich hilfreich sein sollten, dann kann man diese genau so gut innerhalb eines Prozesses verwenden. Verbietet ja keiner. Abgesehen davon dass ich nicht wüsste was damit besser gehen sollte.

Und je genauer er das Verhalten eines echten CAN Bus (z.B. Kollisionen/Arbitration) nachbilden will, desto eher wird er froh sein dass er keine lästige Prozessgrenze hat die bloss überall stört.

abgesehen davon dass es natürlich unsauber ist, weil rumgefrickel mit temporären Dateien, der Code mehrfach gemapped wird etc.

Sorry, aber das ist nur blah.
Dass der Code mehrfach gemappt wird ist jetzt genau 100% egal. Und seit wann ist mit Temp-Files arbeiten unsauber?

Da CAN ein multidrop, multi-master Bus ist [...]

Das stimmt, dafür eignen sich Pipes nicht wirklich, da hast du absolut Recht.

hustbaer schrieb:

Und wieso sollte das mit Prozessgrenze einfacher sein als ohne? Wo hilft sie mir?

Nun, ich ging davon aus, dass er sowieso sowas wie Pipes oder Sockets wird verwenden wollen. In dem Fall wär die Lösung mit mehreren Prozessen auf jeden Fall ganz sicher nicht aufwändiger. Allerdings war das natürlich ein Denkfehler meinerseits.

hustbaer schrieb:

abgesehen davon dass es natürlich unsauber ist, weil rumgefrickel mit temporären Dateien, der Code mehrfach gemapped wird etc.

Sorry, aber das ist nur blah.
Dass der Code mehrfach gemappt wird ist jetzt genau 100% egal. Und seit wann ist mit Temp-Files arbeiten unsauber?

Nun, dass der Code mehrfach gemapped wird ist einfach unschön, natürlich ist es jetzt kein wirkliches Problem oder so. Mir fällt jetzt auch kein rein objektives Argument gegen diese Lösung ein, wie gesagt, ich persönlich finds einfach nicht besonders "schön". Funktionieren tuts sicher...