Weitergabe Storage

[Upro]

Besten Dank für die Antwort

Es handelt sich eher um (b)

Ich denke, diese Info reicht mal aus.... Aber schön wäre es trotzdem, wenn sowas in C möglich wäre!

[dachschaden]

IPC (Inter-process communication) hat nichts mit C zu tun. C kennt das nicht. Wenn, dann musst du auf Betriebssystemebene oder Frameworkebene schauen. Meist bietet irgendwas irgendwo ein C-Interface an.

Dafür gibt es dann verschiedene Möglichkeiten - du kannst die Daten in einer Datei speichern und dann Prozess B sagen, dass Daten in die gemeinsame Datei geschrieben wurden (Signalhandler). Aber I/O ist langsam, deswegen gibt es die Möglichkeit, sogenannte Ramdisks zu erstellen. Das sind Dateisysteme im RAM, die nach dem Neustart verschwinden. Unter Linux mit Bordmitteln (mount) zu machen, unter Windows gibt es (meiner 60-Sekunden-Recherche nach) mindestens zwei Programme, die das machen können.

Eine weitere Möglichkeit wäre eine Pipe - Programm A wartet, bis Programm B signalisiert, dass es jetzt ließt, und dann schaufelt A halt Daten in die Pipe, und B ließt sie. Linux hat dies auf jeden Fall, bei Windows bin ich mir nicht 100%-ig sicher.

Oder du machst es wie viele andere UNIX/Linux-Software da draußen auch und machst einen Socket auf einen bestimmten Port auf, der fungiert dann als Server. Und die Kommunikation erfolgt dann über TCP/IP. So kommunizieren beispielsweise bestimmte Datenbankentreiber mit einem Server.

Notfalls kannst du auch halt das native OS-API verwenden. Stichwort ptrace für Linux, WriteProcessMemory für Windows.
Oder du liest dich in D-Bus ein, was ein Framework für IPC ist. Habe ich aber bisher noch nicht verwendet, kann dazu also nichts sagen.

[supertux]

relativ Konfortable IPC (und system unabhängig) kann man mit 0MQ machen.

[Andromeda]

Upro schrieb:

Geht das mit C? - Oder stehe ich da gerade auf dem Schlauch?

Was in C nicht geht, das geht in keiner anderen Sprache, ausser vielleicht in Assembler.

Soll dein Unterprogramm ein parallel laufender Prozess sein?

[SeppJ]

Andromeda schrieb:

Upro schrieb:

Geht das mit C? - Oder stehe ich da gerade auf dem Schlauch?

Was in C nicht geht, das geht in keiner anderen Sprache, ausser vielleicht in Assembler.

So? Dann programmier doch mal Exceptions auf die Art und Weise, wie sie in anderen Sprachen umgesetzt werden, d.h. ohne Laufzeitkosten.

[dachschaden]

Ohne Laufzeitkosten? Geht doch gar nicht. Abgesehen davon, dass der Stack um mitunter ganze Frames zurückgesetzt werden muss, muss ja auch noch geprüft werden, welchen Typ die gerade geworfene Exception hat, damit man auch ja den richtigen Handler erwischt. Ich glaube nicht, dass das statisch geht - sonst könnte man ja direkt zur Kompilierzeit sagen "Hör mal, dein Aufruf von xy wird fehlschlagen".

Außerdem hat man noch Kosten für das Bauen und hinterher Abbauen des Exceptionobjektes.
Und andere Sprachen wollen das ohne Laufzeitverlust implementiert haben, was C noch mit Fehlercodes hinbekommt?

[SeppJ]

Ohne Kosten, so lange nichts geworfen wird. Das ist möglich. Weil es mit speziellen Assemblertricks auf manchen Plattformen möglich ist. Da einige Sprachen nun aber nativ Exceptions unterstützen, C aber nicht, und C auch die unterliegende Plattform komplett weg abstrahiert, kann man diese Tricks in C nicht nutzen, Implementierungen anderer Sprachen hingegen schon. Nach dem gleichen Prinzip könnte man sicherlich noch jede Menge mehr Beispiele finden, denn reine Maschinensprache kann, wie Andromeda korrekt feststellte, eben hier und da ein paar Tricks, die man mit C nicht machen kann. Wenn andere Sprachen das Ergebnis dieser Tricks direkt als Feature anbieten, dann können diese Sprachen etwas, das man in reinem C niemals machen kann. Kostenlose Exceptions waren bloß das erste Beispiel, das mir einfiel.

[Andromeda]

SeppJ schrieb:

Andromeda schrieb:

Upro schrieb:

Geht das mit C? - Oder stehe ich da gerade auf dem Schlauch?

Was in C nicht geht, das geht in keiner anderen Sprache, ausser vielleicht in Assembler.

So? Dann programmier doch mal Exceptions auf die Art und Weise, wie sie in anderen Sprachen umgesetzt werden, d.h. ohne Laufzeitkosten.

Die haben immer Laufzeitkosten. Falls nicht, sind sie in Hardware implementiert (z.B. Division durch Null, unerlaubter Speicherzugriff).

Die Compiler/Interpreter/Runtimes anderer Sprachen sind oft in C geschrieben. Warum? Weil C einfach DIE Programmiersprache ist. Wie ein Auto ohne Katalysator, ohne Gurte, ohne Airbag, aber mit Hochleistungsmotor und Rennfahrwerk. In der Hand eines Profis das mächtigste Tool überhaupt. Aber für den Laien oft kaum beherrschbar.

[Wutz]

Prinzipiell ist es eine schlechte Idee, im Prozessspeicher eines anderen Prozesses rumzufrickeln, das funktioniert nur mit sauberen Schnittstellen. Eine gängige+flexible Lösung sind Callbacks.
Bei Threads sieht es dann wieder anders aus.
Ich habe den Verdacht, dass es bei der Aufgabe überhaupt kein externer Prozess sein muss und es auch eine simple Funktion tut.
Außerdem werden bei deinem Beispiel die 3 int-Variablen sowieso (in den 'externen' Speicher) kopiert, d.h. du arbeitest dort dann mit Kopien aber im prozesseigenen Speicher.

[Marthog]

Andromeda schrieb:

Die haben immer Laufzeitkosten. Falls nicht, sind sie in Hardware implementiert (z.B. Division durch Null, unerlaubter Speicherzugriff).

Das sind keine zusaetzlichen Laufzeitkosten. Die Ueberpruefung muss man bei Error flags genauso machen. Moderne implementierungen haben bei Exceptions nur dann laufzeitkosten, wenn sie auch exceptions werden, was wie der Name sagt, die Ausnahme ist.

Wenn der code nicht gerade auf exotischen systemen laufen soll, wuerde ich die zwei Programme nach unix-philosophie ueber pipes kommunizieren lassen und das ganze per shell-script verbinden.

[Andromeda]

Marthog schrieb:

Andromeda schrieb:

Die haben immer Laufzeitkosten. Falls nicht, sind sie in Hardware implementiert (z.B. Division durch Null, unerlaubter Speicherzugriff).

Das sind keine zusaetzlichen Laufzeitkosten. Die Ueberpruefung muss man bei Error flags genauso machen.

Nope, wenn das OS hardwaregestützt bereits den Fehler abfängt, brauchst du ihm nur die Adresse der Handler-Routine mitzuteilen. Alles weitere geschieht vollautomatisch. C++ Exceptions erfordern eine Art Laufzeitsystem oder Instrumentation des Codes. Der Programmierer merkt freilich nix davon.

[SeppJ]

Andromeda schrieb:

Marthog schrieb:

Andromeda schrieb:

Die haben immer Laufzeitkosten. Falls nicht, sind sie in Hardware implementiert (z.B. Division durch Null, unerlaubter Speicherzugriff).

Das sind keine zusaetzlichen Laufzeitkosten. Die Ueberpruefung muss man bei Error flags genauso machen.

Nope, wenn das OS hardwaregestützt bereits den Fehler abfängt, brauchst du ihm nur die Adresse der Handler-Routine mitzuteilen. Alles weitere geschieht vollautomatisch. C++ Exceptions erfordern eine Art Laufzeitsystem oder Instrumentation des Codes. Der Programmierer merkt freilich nix davon.

Quatsch auf jeder Ebene. Informier dich, bevor du solchen Quark weiter verbreitest.

[hustbaer]

Upro schrieb:

Ziel wäre es, dass das aufrufende Programm dem Unterprogramm einen klar definierten Storage zur Verfügung stellt und ich in meinem Unterprogramm alle Freiheiten eines Hauptprogramms habe....

Was verstehst du unter "alle Freiheiten eines Hauptprogramms"?
Und warum willst du diese haben?

Grund meiner Frage: normalerweise sollte man so programmieren dass es egal ist in welchen Programm der eigene Code ausgeführt wird. Der Wunsch nach "allen Freiheiten eines Hauptprogramms" deutet also darauf hin dass man gerade dabei ist sich ein paar schlechte Angewohnheiten anzugewöhnen, oder aber mit Code von anderen Leuten arbeiten muss die sich ein paar schlechte Angewohnheiten angewöhnt haben.
(Gegen letzteres kann man natürlich oft nichts tun.)

[dachschaden]

Andromeda schrieb:

Nope, wenn das OS hardwaregestützt bereits den Fehler abfängt, brauchst du ihm nur die Adresse der Handler-Routine mitzuteilen. Alles weitere geschieht vollautomatisch.

A-ha. Vollautomatisch, mit Unterstützung des OS. Ohne Laufzeitkosten.
Frage: Woher weiß denn das OS, welcher Handler jetzt aufgerufen werden soll? Jetzt class exception_1, oder doch exception_2? Oder exception_372192? Nicht nur, dass man damit im Voraus angeblich weiß, welche Fehler eine Subroutine auslösen kann - bisher haben wir in den catch-Blöcken halt nur ausgewählte Typen, oder halt alles, wennde lustig bist, da könnte man dann tatsächlich von einem Universal-Handler sprechen - nein, jetzt wissen wir auch auf einmal, welche Exceptions Unterfunktionen, die von der eigentlichen Funktion aufgerufen werden, werfen können.

Dass nicht ausgelößte C-Fehlercodes wie nicht ausgelößte C++-Exceptions den gleichen Laufzeitverlust besitzen (außer vielleicht ein bisschen mehr Code im C++-Handler, aber das kann ein Compiler gut kompensieren, indem er den kritischen Pfad Im Binary möglichst beeinanderhält und den Handler ans Ende der Routine packt), das mag ich noch glauben.
Aber das von dir angegebene Schema würde eine vollständige Linkzeitüberprüfung des Programmes erfordern. Möglich ist das, klar. Aber erst einmal muss für den Linker irgendwie ersichtlich sein, welche Exceptions von welcher Funktion geworfen werden können und in welchen Codepfaden welche Handler für welche Typen erlaubt werden.

Und C++ kompiliert langsam, das wissen wir auch schon seit langer Zeit. Aber das Linken geht meiner Erfahrung nach recht fix. Für das von dir beschriebene Verhalten müsste der Linker meines Erachtens bei einer Linkzeitüberprüfung sehr viel länger rodeln, als er das normalerweise tut. Außerdem ist damit auch noch nicht das Problem gelöst, dass der Handler im Kontext eines bestimmten Stackframes ausgeführt werden muss und bis dahin auch erst einmal zurückgedreht werden muss. Wie will das OS sowas hardwareunterstützt hinbekommen?