Zwei Prozesse mit Klassen-Sharing

[Heinz-Mario Frühbeis]

Hallo zusammen!

Hauptprogramm[P_A] soll eine Klasse[K1], die sie selber besitzt,
initialisieren, in einem fork()-Aufruf [Prozess_2].

In dieser Klasse[K1] wï¿œrde dann
eine Klasse[K2] aus einer SharedLibary initialisiert werden
ein Programm[P_B] aufgerufen werden

Klasse[K2] soll mit Klasse[K1] kommunizieren kï¿œnnen
Programm[P_B] soll mit Klasse[K2] kommunizieren kï¿œnnen

[1]

Wie bekommt man denn so was hin?

In boost::interprozess habe ich mich natï¿œrlich per Internet eingelesen.
Aber da verstehe ich nicht, wie man z. Bsp. eine Klasse in dieses
SharedMemory hinein bekommt.
Auch zu Pipes habe ich mich informiert, aber da ist immer nur von Text
"die Rede".

Fï¿œr jede Hilfe dankbar,
mit Gruￜ
Heinz-Mario Frï¿œhbeis

[1] Es kￜme eigentlich noch ein Event-Loop dazu, nur weiￜ ich rein noch
gar nicht, wo ich den starten lassen kann, da es ja nach dem exec-Aufruf
erst nach dem Beenden des Programms[P_B] weitergeht <salopp>.

[Rainer Weikusat]

Heinz-Mario Fr�hbeis <Earl...@web.de> writes:
> Hauptprogramm[P_A] soll eine Klasse[K1], die sie selber besitzt,
> initialisieren, in einem fork()-Aufruf [Prozess_2].
>

> In dieser Klasse[K1] w�rde dann

> eine Klasse[K2] aus einer SharedLibary initialisiert werden
> ein Programm[P_B] aufgerufen werden
>

> Klasse[K2] soll mit Klasse[K1] kommunizieren k�nnen
> Programm[P_B] soll mit Klasse[K2] kommunizieren k�nnen

Diese Text hat keinen mir verstaendlichen Sinn ...

[Heinz-Mario Frühbeis]

Am 09.05.2013 16:05, schrieb Rainer Weikusat:

> Heinz-Mario Frï¿œhbeis <Earl...@web.de> writes:
>> Hauptprogramm[P_A] soll eine Klasse[K1], die sie selber besitzt,
>> initialisieren, in einem fork()-Aufruf [Prozess_2].
>>

>> In dieser Klasse[K1] wï¿œrde dann

>> eine Klasse[K2] aus einer SharedLibary initialisiert werden
>> ein Programm[P_B] aufgerufen werden
>>

>> Klasse[K2] soll mit Klasse[K1] kommunizieren kï¿œnnen
>> Programm[P_B] soll mit Klasse[K2] kommunizieren kï¿œnnen

>
> Diese Text hat keinen mir verstaendlichen Sinn ...
>

*Was gibt's daran nich' zu verstehen? Fï¿œr mich ist das eindeutig, was da
geschehen soll.
Es geht darum, wie man das jetzt mittels boost::interpprozess hin
bekommt..., oder mittels Pipe?

Was ist eigentlich mit dem Rest vom OP? Worum ging es dir denn jetzt
eigentlich in _deiner Antwort?

[Rainer Weikusat]

Heinz-Mario Fr锟絟beis <Earl...@web.de> writes:
> Am 09.05.2013 16:05, schrieb Rainer Weikusat:

>> Heinz-Mario Fr锟絟beis <Earl...@web.de> writes:
>>> Hauptprogramm[P_A] soll eine Klasse[K1], die sie selber besitzt,
>>> initialisieren, in einem fork()-Aufruf [Prozess_2].
>>>

>>> In dieser Klasse[K1] w锟絩de dann

>>> eine Klasse[K2] aus einer SharedLibary initialisiert werden
>>> ein Programm[P_B] aufgerufen werden
>>>

>>> Klasse[K2] soll mit Klasse[K1] kommunizieren k锟絥nen
>>> Programm[P_B] soll mit Klasse[K2] kommunizieren k锟絥nen

>>
>> Diese Text hat keinen mir verstaendlichen Sinn ...
>

> *Was gibt's daran nich' zu verstehen? F锟絩 mich ist das eindeutig,
> was da geschehen soll.

Natuerlich. Aber ein 'unstrukturierter' brain dump von Dir ist nicht
notwendigerweise fuer irgendjemand anderen verstaendlich, der Deine
Gedanken nicht lesen kann. ZB bezeichnet 'Klasse' ueblicherweise eine
Spezifikation fuer eine beliebige Menge von 'Objekten' eines
bestimmten Typs. Das impliziert, dass Klassen nicht initialisiert
werden und auch nicht kommunizieren. Wahrscheinlich ist hier 'Objekt'
oder 'Objektinstanz' gemeint, aber moegliche Interpretationen unklarer
Texte gibt es immer sehr viele, dh die Chance, bei diesem froehlichen
Sinn-Erraten vollkommen danebenzuliegen, sind gross. 'Die sie selber
besitzt' muesste sich wegen das grammatischen Geschlechtes auf K1
beziehen, aber 'Klasse die sie selber besitzt' gibt keinen
Sinn. Vermutlich sollte sich dieser Relativsatz auf 'P_A' beziehen und
der Artikel ist falsch. Und so fort.

> Es geht darum, wie man das jetzt mittels boost::interpprozess hin
> bekommt..., oder mittels Pipe?
>
> Was ist eigentlich mit dem Rest vom OP? Worum ging es dir denn jetzt
> eigentlich in _deiner Antwort?

Um den Hinweise, dass Du Dich 'etwas unklar' (untertrieben)
ausgedrueckt hast: Vermutlich koennte 'jemand' die Frage beanworten,
aber solange nicht geklaert ist, was 'die Frage' denn genau ist,
lautet die einzige moegliche Antwort "42".

[Heinz-Mario Frühbeis]

Am 10.05.2013 16:22, schrieb Rainer Weikusat:

> Heinz-Mario Frï¿œhbeis <Earl...@web.de> writes:
>> Am 09.05.2013 16:05, schrieb Rainer Weikusat:

>>> Heinz-Mario Frï¿œhbeis <Earl...@web.de> writes:
>>>> Hauptprogramm[P_A] soll eine Klasse[K1], die sie selber besitzt,
>>>> initialisieren, in einem fork()-Aufruf [Prozess_2].
>>>>

>>>> In dieser Klasse[K1] wï¿œrde dann

>>>> eine Klasse[K2] aus einer SharedLibary initialisiert werden
>>>> ein Programm[P_B] aufgerufen werden
>>>>

>>>> Klasse[K2] soll mit Klasse[K1] kommunizieren kï¿œnnen
>>>> Programm[P_B] soll mit Klasse[K2] kommunizieren kï¿œnnen

>>>
>>> Diese Text hat keinen mir verstaendlichen Sinn ...
>>

>> *Was gibt's daran nich' zu verstehen? Fï¿œr mich ist das eindeutig,

>> was da geschehen soll.
>
> Natuerlich. Aber ein 'unstrukturierter' brain dump von Dir ist nicht
> notwendigerweise fuer irgendjemand anderen verstaendlich, der Deine
> Gedanken nicht lesen kann. ZB bezeichnet 'Klasse' ueblicherweise eine
> Spezifikation fuer eine beliebige Menge von 'Objekten' eines
> bestimmten Typs. Das impliziert, dass Klassen nicht initialisiert
> werden und auch nicht kommunizieren. Wahrscheinlich ist hier 'Objekt'
> oder 'Objektinstanz' gemeint, aber moegliche Interpretationen unklarer
> Texte gibt es immer sehr viele, dh die Chance, bei diesem froehlichen
> Sinn-Erraten vollkommen danebenzuliegen, sind gross. 'Die sie selber
> besitzt' muesste sich wegen das grammatischen Geschlechtes auf K1
> beziehen, aber 'Klasse die sie selber besitzt' gibt keinen
> Sinn. Vermutlich sollte sich dieser Relativsatz auf 'P_A' beziehen und
> der Artikel ist falsch. Und so fort.
>
>> Es geht darum, wie man das jetzt mittels boost::interpprozess hin
>> bekommt..., oder mittels Pipe?
>>
>> Was ist eigentlich mit dem Rest vom OP? Worum ging es dir denn jetzt
>> eigentlich in _deiner Antwort?
>
> Um den Hinweise, dass Du Dich 'etwas unklar' (untertrieben)
> ausgedrueckt hast: Vermutlich koennte 'jemand' die Frage beanworten,
> aber solange nicht geklaert ist, was 'die Frage' denn genau ist,
> lautet die einzige moegliche Antwort "42".
>

Es ist ï¿œberhaupt nicht unklar. *Du willst dich nur nicht darauf
einlassen...und lￜￜt statt dessen einen "Wissenden" heraus hￜngen.
Wenn du nicht willst, oder nicht kannst, dann lasse es ganz und vergeude
deine Zeit nicht mir und meiner Welt in deiner Welt.
EOD

[Rainer Weikusat]

Heinz-Mario Fr�hbeis <Earl...@web.de> writes:

[...]

>> Natuerlich. Aber ein 'unstrukturierter' brain dump von Dir ist nicht
>> notwendigerweise fuer irgendjemand anderen verstaendlich, der Deine
>> Gedanken nicht lesen kann. ZB bezeichnet 'Klasse' ueblicherweise eine
>> Spezifikation fuer eine beliebige Menge von 'Objekten' eines
>> bestimmten Typs. Das impliziert, dass Klassen nicht initialisiert
>> werden und auch nicht kommunizieren. Wahrscheinlich ist hier 'Objekt'
>> oder 'Objektinstanz' gemeint, aber moegliche Interpretationen unklarer
>> Texte gibt es immer sehr viele, dh die Chance, bei diesem froehlichen
>> Sinn-Erraten vollkommen danebenzuliegen, sind gross. 'Die sie selber
>> besitzt' muesste sich wegen das grammatischen Geschlechtes auf K1
>> beziehen, aber 'Klasse die sie selber besitzt' gibt keinen
>> Sinn. Vermutlich sollte sich dieser Relativsatz auf 'P_A' beziehen und
>> der Artikel ist falsch. Und so fort.
>>
>>> Es geht darum, wie man das jetzt mittels boost::interpprozess hin
>>> bekommt..., oder mittels Pipe?
>>>
>>> Was ist eigentlich mit dem Rest vom OP? Worum ging es dir denn jetzt
>>> eigentlich in _deiner Antwort?
>>
>> Um den Hinweise, dass Du Dich 'etwas unklar' (untertrieben)
>> ausgedrueckt hast: Vermutlich koennte 'jemand' die Frage beanworten,
>> aber solange nicht geklaert ist, was 'die Frage' denn genau ist,
>> lautet die einzige moegliche Antwort "42".
>>
>

> Es ist �berhaupt nicht unklar.

Man koennte das auch ein bisschen weniger freundlich ausdruecken, als
ich das mit viel Muehe getan: Du schreibst Deutsch ungefaehr so, wie
ein Japaner Englisch, dh ein wahlloses Kauderwelsch falsch verwendeter
Begriffe, und wenn man nachfragt, wirst Du pampig.

Und dafuer ist mir meine Zeit zu schade.

[Heinz-Mario Frühbeis]

Am 10.05.2013 16:55, schrieb Rainer Weikusat:

> Heinz-Mario Frï¿œhbeis <Earl...@web.de> writes:
>
> [...]
>
>
>>> Natuerlich. Aber ein 'unstrukturierter' brain dump von Dir ist nicht
>>> notwendigerweise fuer irgendjemand anderen verstaendlich, der Deine
>>> Gedanken nicht lesen kann. ZB bezeichnet 'Klasse' ueblicherweise eine
>>> Spezifikation fuer eine beliebige Menge von 'Objekten' eines
>>> bestimmten Typs. Das impliziert, dass Klassen nicht initialisiert
>>> werden und auch nicht kommunizieren. Wahrscheinlich ist hier 'Objekt'
>>> oder 'Objektinstanz' gemeint, aber moegliche Interpretationen unklarer
>>> Texte gibt es immer sehr viele, dh die Chance, bei diesem froehlichen
>>> Sinn-Erraten vollkommen danebenzuliegen, sind gross. 'Die sie selber
>>> besitzt' muesste sich wegen das grammatischen Geschlechtes auf K1
>>> beziehen, aber 'Klasse die sie selber besitzt' gibt keinen
>>> Sinn. Vermutlich sollte sich dieser Relativsatz auf 'P_A' beziehen und
>>> der Artikel ist falsch. Und so fort.
>>>
>>>> Es geht darum, wie man das jetzt mittels boost::interpprozess hin
>>>> bekommt..., oder mittels Pipe?
>>>>
>>>> Was ist eigentlich mit dem Rest vom OP? Worum ging es dir denn jetzt
>>>> eigentlich in _deiner Antwort?
>>>
>>> Um den Hinweise, dass Du Dich 'etwas unklar' (untertrieben)
>>> ausgedrueckt hast: Vermutlich koennte 'jemand' die Frage beanworten,
>>> aber solange nicht geklaert ist, was 'die Frage' denn genau ist,
>>> lautet die einzige moegliche Antwort "42".
>>>
>>

>> Es ist ï¿œberhaupt nicht unklar.

>
> Man koennte das auch ein bisschen weniger freundlich ausdruecken, als
> ich das mit viel Muehe getan: Du schreibst Deutsch ungefaehr so, wie
> ein Japaner Englisch, dh ein wahlloses Kauderwelsch falsch verwendeter
> Begriffe, und wenn man nachfragt, wirst Du pampig.
>
> Und dafuer ist mir meine Zeit zu schade.
>

DANN ANTWORTE MIR NICHT! Verstehst du das nicht? *EOD*

[Rainer Weikusat]

Heinz-Mario Fr�hbeis <Earl...@web.de> writes:

> Am 10.05.2013 16:55, schrieb Rainer Weikusat:

[...]

>> Man koennte das auch ein bisschen weniger freundlich ausdruecken, als
>> ich das mit viel Muehe getan: Du schreibst Deutsch ungefaehr so, wie
>> ein Japaner Englisch, dh ein wahlloses Kauderwelsch falsch verwendeter
>> Begriffe, und wenn man nachfragt, wirst Du pampig.
>>
>> Und dafuer ist mir meine Zeit zu schade.
>>
>
> DANN ANTWORTE MIR NICHT! Verstehst du das nicht? *EOD*

s/A.*MIR/LESE MICH/

Habe ich auch nicht vor.

[Marcel Müller]

Hallo,

On 10.05.13 09.30, Heinz-Mario Fr�hbeis wrote:
> *Was gibt's daran nich' zu verstehen? F�r mich ist das eindeutig, was da
> geschehen soll.

ich habe ehrlich gesagt auch nicht verstanden was Du da vor hast. Es ist
nur eine wilde Kombination von Programmen, Prozessen und Forks angekommen.

> Es geht darum, wie man das jetzt mittels boost::interpprozess hin
> bekommt..., oder mittels Pipe?

boost::interprocess ist nur ein Wrapper um verschiedene, g�ngige
IPC-Mechanismen, um das eine oder andere Plattformspezifika wegzukapseln.
Was Du davon zu nutzen gedenkst, erschlie�t sich nicht.

Man hat ein wenig das Gef�hl, dass Du auf einem Holzweg bist, aber auch
das ist nicht sicher.

Fakt ist, dass saubere C++-Programme und fork() sich weitgehend
ausschlie�en.

Des weiteren hei�t Interprocess-Kommunikation �ber Pipes und �hnliches
Serialisierung/Deserialisierung. Also keine Pointer, keine Referenzen
und auch sonst nichts, was nicht irgendwie als POD darstellbar ist. Mit
beliebig viel Aufwand bekommt man nat�rlich auch komplexere
Objektstrukturen serialisiert - so tickt ja schlie�lich jede
OO-Dokumentendatenbank. Aber am Ende des Tages schickt man immer etwas
Message-artiges �ber die Leitung. Also �hnlich, wie bei einer
Client-Server Anwendung.

Die Alternative ist Shared Memory. Aber wenn man bei C++-Objekten im
Shared Memory auch nur halbwegs definiertes Verhalten haben will, muss
man die Ohren schon ganz gut anlegen. Ohne Zweifel, man bekommt das hin;
aber wenn man nur einen bl�den String-Allocator nicht umgeleitet hat -
kablamm! Oder einmal mit die zwei Prozesse mit verschiedenen
Runtime-Versionen compiliert - kablamm! Oder gemeiner, es scheint erst
mal zu gehen, und nach zwei Wochen Produktiveinsatz knallt es dann.


Also, wenn Du Dir einen pers�nlichen Gefallen tun m�chtest, dann
schreibe *einen* Prozess, und mache alles weitere mit Threads. Da kann
man auch noch genug falsch machen, aber zumindest muss man nicht auch
noch auf Sachen aufpassen, von deren Existenz man gar nichts wei�. Aber
mit Threads stellen sich zwei drittel der Fragen erst gar nicht.

Und wenn Du einen wirklich guten Grund hast /nicht/ alles in einen
Prozess zu packen, dann versuche es mit einem klassischen
Service-Konzept. Also Prozess X stellt auf irgendeinem standardisierten,
technischen Weg einen Service bereit, der von andere Prozessen genutzt
werden kann. Und wenn Du keine wirklich guten Gr�nde hast, die dagegen
sprechen, dann verwende daf�r Web-Services (SOAP). Das XML kostet Dich
zwar den einen oder anderen Taktzyklus extra, aber die Servicability und
Maintainability wird es Dir doppelt und dreifach danken.


Marcel

[Thomas Orgelmacher]

Am 10.05.2013 09:30, schrieb Heinz-Mario Frï¿œhbeis:
>
> *Was gibt's daran nich' zu verstehen? Fï¿œr mich ist das eindeutig, was da
> geschehen soll.
> Es geht darum, wie man das jetzt mittels boost::interpprozess hin
> bekommt..., oder mittels Pipe?

Oder Shared Memory oder Sockets oder Message Queues...

Davon abgesehen, dass ich von Boost (oder auch C++) keine Kenne habe:
ich verstehe auch nicht was Du willst.


--
I have seen things you lusers would not believe. I've seen Sun
monitors on fire off the side of the multimedia lab. I've seen
NTU lights glitter in the dark near the Mail Gate. All these
things will be lost in time, like the root partition last week.

[Heinz-Mario Frühbeis]

Am 11.05.2013 00:15, schrieb Marcel Mï¿œller:
> Hallo,
>

> On 10.05.13 09.30, Heinz-Mario Frï¿œhbeis wrote:
>> *Was gibt's daran nich' zu verstehen? Fï¿œr mich ist das eindeutig, was da

>> geschehen soll.
>
> ich habe ehrlich gesagt auch nicht verstanden was Du da vor hast. Es ist
> nur eine wilde Kombination von Programmen, Prozessen und Forks angekommen.
>
>> Es geht darum, wie man das jetzt mittels boost::interpprozess hin
>> bekommt..., oder mittels Pipe?
>

> boost::interprocess ist nur ein Wrapper um verschiedene, gï¿œngige

> IPC-Mechanismen, um das eine oder andere Plattformspezifika wegzukapseln.

> Was Du davon zu nutzen gedenkst, erschlieï¿œt sich nicht.
>
> Man hat ein wenig das Gefï¿œhl, dass Du auf einem Holzweg bist, aber auch

> das ist nicht sicher.
>
> Fakt ist, dass saubere C++-Programme und fork() sich weitgehend

> ausschlieï¿œen.
>
> Des weiteren heiï¿œt Interprocess-Kommunikation ï¿œber Pipes und ï¿œhnliches

> Serialisierung/Deserialisierung. Also keine Pointer, keine Referenzen
> und auch sonst nichts, was nicht irgendwie als POD darstellbar ist. Mit

> beliebig viel Aufwand bekommt man natï¿œrlich auch komplexere
> Objektstrukturen serialisiert - so tickt ja schlieï¿œlich jede

> OO-Dokumentendatenbank. Aber am Ende des Tages schickt man immer etwas

> Message-artiges ï¿œber die Leitung. Also ï¿œhnlich, wie bei einer

> Client-Server Anwendung.
>
> Die Alternative ist Shared Memory. Aber wenn man bei C++-Objekten im
> Shared Memory auch nur halbwegs definiertes Verhalten haben will, muss
> man die Ohren schon ganz gut anlegen. Ohne Zweifel, man bekommt das hin;

> aber wenn man nur einen blï¿œden String-Allocator nicht umgeleitet hat -

> kablamm! Oder einmal mit die zwei Prozesse mit verschiedenen
> Runtime-Versionen compiliert - kablamm! Oder gemeiner, es scheint erst
> mal zu gehen, und nach zwei Wochen Produktiveinsatz knallt es dann.
>
>

> Also, wenn Du Dir einen persï¿œnlichen Gefallen tun mï¿œchtest, dann

> schreibe *einen* Prozess, und mache alles weitere mit Threads. Da kann
> man auch noch genug falsch machen, aber zumindest muss man nicht auch

> noch auf Sachen aufpassen, von deren Existenz man gar nichts weiￜ. Aber

> mit Threads stellen sich zwei drittel der Fragen erst gar nicht.
>
> Und wenn Du einen wirklich guten Grund hast /nicht/ alles in einen
> Prozess zu packen, dann versuche es mit einem klassischen
> Service-Konzept. Also Prozess X stellt auf irgendeinem standardisierten,
> technischen Weg einen Service bereit, der von andere Prozessen genutzt

> werden kann. Und wenn Du keine wirklich guten Grï¿œnde hast, die dagegen
> sprechen, dann verwende dafï¿œr Web-Services (SOAP). Das XML kostet Dich

> zwar den einen oder anderen Taktzyklus extra, aber die Servicability und
> Maintainability wird es Dir doppelt und dreifach danken.
>
>
> Marcel

Vorab:
Es geht mir ja einzig darum, daￜ nicht irgendein Programm, daￜ durch
mein Hauptprogramm aufgerufen wird, mein Hauptprogramm mitreiï¿œt, wenn es
mal knallt. Und AFAIK kriegt man das mit Threads nicht hin...

Ich versuche es mal anders:
Mein Programm erstellt eine Klasse "IDA".
In dieser Klasse wird das Programm konfiguriert.
Zusï¿œtzlich gibt es dann noch eine DynamicLibary "IDASection".so.
Diese Libary enthï¿œlt eine Klasse "IDASection", die die Klasse "IDA" als
Friend fï¿œhrt.

Dann gibt es zusï¿œtzliche externe Programme, die ebenfalls die Klasse
"IDASection" nutzen sollen, aber *erst* nachdem sie von "IDA"
initialisiert wurde (also ein Key wird ï¿œbergeben, und noch einige
Kleinigkeiten).

Deshalb muss die Klasse "IDASection" mit dem externen Programm
kommunizieren kï¿œnnen _und mit der Klasse "IDA".
"IDASection" hat Funktionen, wie z. Bsp. "Create_IDASection()" (ein
Fenster erstellen), etc.), wobei dann die Klasse "IDA" benachrichtigt
wird, daￜ jetzt eine Sektion geￜffnet wurde. Und sie soll, wenn z. Bsp.
"Remove_IDASection()" aufgerufen wurde durch das externe Programm, eine
Nachricht an die Klasse "IDA" senden, daￜ _diese Sektion beendet wurde.

So will ich das haben...aber leider finde ich im Internet nichts
Vergleichbares, wo ich mich durch ein Bsp. einarbeiten kï¿œnnte.
Die Klasse "IDASection" der DynamicLibary "IDASection".so muss also
irgendwie in ein SharedMemory...und ich weiￜ einfach nicht wie.

Wobei ich natￜrlich hoffe, daￜ ich unter SharedMenory das auch richtig
verstehe, daￜ _zwei Prozesse auf _eine Ressource zugreifen kￜnnen.

Besser kann ich es nicht beschreiben...
Was alles evtl passieren kann, und was evtl nicht...das ist mir im
Moment vollkommen Schnurz. Mir wￜre es wichtig, daￜ es _ￜberhaupt zu
realisieren ist.

Mit Gruￜ
Heinz-Mario <der einfach nicht glauben will, daￜ das nicht mit C++ und
Co. zu realisieren ist> Frï¿œhbeis

[Marcel Müller]

On 11.05.13 02.43, Heinz-Mario Fr�hbeis wrote:
> Vorab:

> Es geht mir ja einzig darum, da� nicht irgendein Programm, da� durch
> mein Hauptprogramm aufgerufen wird, mein Hauptprogramm mitrei�t, wenn es

> mal knallt. Und AFAIK kriegt man das mit Threads nicht hin...

Wenn man sauber testet, schon. Aber technisch hast Du recht. Wenn das
Testen nicht praktikabel oder unverh�ltnism��iger Mehraufwand ist, dann
bieten Prozesse definitiv eine wesentlich bessere Isolation.

Allerdings ist diese Isolation nahezu auf einen Schlag dahin, wenn beide
komplexe Objekte im Shared Memory ablegen. Wolltest Du sie Isolation
aufrecht erhalten, m�sste dein Rahmenprogram praktisch mit jedem bin�ren
Datenschrott, der zu jedem x-beliebigen Zeitpunkt in den Shared Memory
geschreiben wird, noch definiertes Verhalten aufweisen. Das
hinzubekommen ist sicher mehr Aufwand, als das Unterprogramm absturzfrei
zu bekommen.

Hei�t: f�r eine saubere Isolation, solltest Du jegliche Art von bin�ren
Schnittstellen zwischen Haupt- und Unterprozess vermeiden, oder
zumindest mit �u�erster Vorsicht einsetzen (also nur BLOBs und �hnliches).

> Ich versuche es mal anders:
> Mein Programm erstellt eine Klasse "IDA".
> In dieser Klasse wird das Programm konfiguriert.

> Zus�tzlich gibt es dann noch eine DynamicLibary "IDASection".so.
> Diese Libary enth�lt eine Klasse "IDASection", die die Klasse "IDA" als
> Friend f�hrt.
>
> Dann gibt es zus�tzliche externe Programme, die ebenfalls die Klasse

> "IDASection" nutzen sollen, aber *erst* nachdem sie von "IDA"

> initialisiert wurde (also ein Key wird �bergeben, und noch einige

> Kleinigkeiten).

> Deshalb muss die Klasse "IDASection" mit dem externen Programm

> kommunizieren k�nnen _und mit der Klasse "IDA".

> "IDASection" hat Funktionen, wie z. Bsp. "Create_IDASection()" (ein
> Fenster erstellen), etc.), wobei dann die Klasse "IDA" benachrichtigt

> wird, da� jetzt eine Sektion ge�ffnet wurde. Und sie soll, wenn z. Bsp.

> "Remove_IDASection()" aufgerufen wurde durch das externe Programm, eine

> Nachricht an die Klasse "IDA" senden, da� _diese Sektion beendet wurde.

Du Hast einen Denkfehler. Du brauchst in deinem Modell /drei/ Klassen.

IDA, IDSectionClient und IDASectionServer. Die letzteren beiden
kommunizieren �ber Messages oder �ber Request/Reply �ber die
Prozessgrenzen hinweg miteinander. F�r diese Kommunikation gelten die
oben genannten Einschr�nkungen bez�glich bin�rer Inhalte.

IDAServer und IDAClient sind aber komplett unterschiedliche Klassen.
IDAClient wird von IDA und dessen Programm verwaltet. IDAServer hingegen
ist dein Unterprogramm und stellt remote-f�hige Funktionen bereit, und
evtl. ein paar Notifications, wenn bestimmte Ereignisse (wie z.B.
Completion) eintreten.

> So will ich das haben...aber leider finde ich im Internet nichts

> Vergleichbares, wo ich mich durch ein Bsp. einarbeiten k�nnte.

Das liegt daran, dass es so nicht funktioniert. Du kannst nicht einfach
eine Klasse im Programm A erstellen und dann an Programm B �bergeben und
dann auch noch mit beiden Programmen gleichzeitig darin herumackern.

> Die Klasse "IDASection" der DynamicLibary "IDASection".so muss also

> irgendwie in ein SharedMemory...und ich wei� einfach nicht wie.

Mach das blo� nicht. Das ist sowas von undefiniertes Verhalten. Ich habe
nicht den Eindruck, dass Du tief genug in der systemnahen Programmierung
bzw. in den Implementierungsdetails deiner Compilerplattform drin
steckt, als das das mit definiertem Verhalten enden k�nnte.

> Wobei ich nat�rlich hoffe, da� ich unter SharedMenory das auch richtig
> verstehe, da� _zwei Prozesse auf _eine Ressource zugreifen k�nnen.

Ja, das passt schon, aber Klassen dulden out of the Box erst mal keine
fremden G�tter, da es zugeh�rige, versteckte Metadaten gibt, die
zus�tzliche Informationen halten, derer Du dir im Normalfall gar nicht
bewusst sein kannst. Das geht mit den Allocation-Heaps los, die man noch
selber durch konsequentes �berladen aller new/delete Operatoren im
Shared Memory implementieren kann. Aber damit ist der Spa� noch nicht
vorbei. Die �blicherweise von C++-Compiler genutzten RTTI-Informationen
wie z.B. VTables liegen im Private-Memory des jeweiligen Programms und
verweisen auch direkt auf compilierten Code in eben demselben private
Memory. Letzteres kannst Du nat�rlich mit deiner Dynamic Library
halbwegs einfangen. Dem liegt die Annahme zugrunde, dass die konstanten
Segmente einer DLLs aus Sicht aller Prozesse die sie nutzen auf
dieselben virtuellen Adressen geladen werden. Unter x86 mit gcc h�ttest
Du da vermutlich sogar Gl�ck. Aber es gibt auch Plattformen, wo jeder
Code per se nicht an absolute Adressen gebunden ist.

Allerdings muss Dir eins klar sein. Selbst wenn Du das am Ende sogar
hinbekommst, hast Du den Sinn der ganzen Aktion die Isolation von
Rahmen- und Unterprogrammen, komplett kompromittiert. Wenn z.B. ein
Unterprogramm just in dem Moment absemmelt, wo es ein Mutex zum Zugriff
auf die gemeinsamen Daten h�lt, hast Du einen Deadlock im
Rahmenprogramm. Wenn es durch einen Programmfehler die Datenstrukturen
im Shared Memory besch�digt, st�rzt das Rahmenprogramm mit gro�er
Wahrscheinlichkeit auch ab.

Du h�ttest letztlich dieselben Sicherheitsanforderungen zu bew�ltigen,
die auch f�r andere IPC-Mechanismen gelten. Mit allen Spielchen, wie
Buffer-Overuns etc. Und das �berl�sst man besser den Kernel- und
Framework-Programmierern.

> Was alles evtl passieren kann, und was evtl nicht...das ist mir im

> Moment vollkommen Schnurz. Mir w�re es wichtig, da� es _�berhaupt zu
> realisieren ist.

Nicht mit vertretbarem Aufwand.

> Mit Gru�
> Heinz-Mario <der einfach nicht glauben will, da� das nicht mit C++ und
> Co. zu realisieren ist> Fr�hbeis

Es /ist/ zu realisieren. Aber willst Du wirklich das Rad neu erfinden?

Nimm die eine dokumentierte RPC-Schnittstellenl�sung, und setzte darauf
auf. Daf�r gibt es Frameworks ohne Ende. Web-Services war nur ein
Vorschlag. Es gibt auch noch dutzende, komplett andere. CORBA, DBUS, was
auch immer. Aber Du solltest ein High-Level Framework nehmen, und nicht
auf unterster Ebene alles neu aufbauen.
Das einzige, was man noch ohne viel Overhead halbwegs direkt bedienen
kann, sind Message-Pipes mit kurzen String-Messages. (Bei l�nger wird es
schon wieder komplizierter, wegen der Paketierung.)

Als erstes, w�rde ich eine Liste der Befehle machen, die das
Hauptprogramm an die Server-Prozesse senden k�nnen soll (z.B. Init,
GetData, Cancel ...).
Dann die Ereignisse, die vom Unterprogramm bereitgestellt werden sollen
(z.B. CalculationCompleted). Dann braucht man zu jedem der Aufrufe die
Parameter in serialisierbarer Form (also am besten nur Strings). Wenn
die zu �bergebenden Datenstrukturen komplex sind, w�rde ich ein
XML-Format nehmen. Das ist per se serialisierbar und halbwegs sicher vor
Kompromittierung. Also XSD f�r Request und Reply basteln. Das XSD-kann
man dann in Frameworks importieren, die daraus den ben�tigten Code f�r
Client und Server erzeugen.
Andere Frameworks setzen auf anderen Protokolldefinitionen auf. Also
z.B. Methodensignaturen, wobei aber alle verwendeten Datentypen
serialisierbar sein m�ssen. Also faktisch nur int, string etc. oder halt
solche, f�r die man eine eigene Serialisierung bereitstellt.

Die Entscheidung f�r eine IPC-Technik w�rde ich erst treffen, wenn ich
die Anforderungen zusammen habe, und wei�, mit welchen Datentypen es
�ber IPC zu hantieren gilt.


Marcel

[Rainer Weikusat]

Marcel M�ller <news.5...@spamgourmet.org> writes:

[...]

> Fakt ist, dass saubere C++-Programme und fork() sich weitgehend
> ausschlie�en.

Das ist zunaechst mal eine Behauptung (es waere auch noch zu klaeren,
was ein 'sauberes' Programm eigentlich sein soll). Auf die Frage nach
einer Begruendung fuer diese kam beim letzten mal 'irgendwelches wilde
Gerede' ueber 'Kernel-Ressourcen die der kernel nicht kopieren
koennte und die "irgendwie" mit phtread-Synchronisationsobjekten
zusammenhingen'. Diese 'Kernel-ressourcen' gibt es allerdings nicht
und die etwas 'wurstigen' Interaktionen zwischen POSIX threads und
fork haben mit C++ per se nichts zu tun.

[...]

> Und wenn Du einen wirklich guten Grund hast /nicht/ alles in einen
> Prozess zu packen, dann versuche es mit einem klassischen
> Service-Konzept. Also Prozess X stellt auf irgendeinem
> standardisierten, technischen Weg einen Service bereit, der von andere
> Prozessen genutzt werden kann. Und wenn Du keine wirklich guten Gr�nde
> hast, die dagegen sprechen, dann verwende daf�r Web-Services
> (SOAP). Das XML kostet Dich zwar den einen oder anderen Taktzyklus
> extra, aber die Servicability und Maintainability wird es Dir doppelt
> und dreifach danken.

Wenn die einzige Loesung fuer 'das Kommunikationsproblem' 'mach einen
Webservice draus' ist, dann nimmt es nicht wunder, dass IPC als
ungemein komplizierter Overkill gilt ...

[Hergen Lehmann]

On 11.05.2013 21:30, Rainer Weikusat wrote:

> Das ist zunaechst mal eine Behauptung (es waere auch noch zu klaeren,
> was ein 'sauberes' Programm eigentlich sein soll). Auf die Frage nach
> einer Begruendung fuer diese kam beim letzten mal 'irgendwelches wilde
> Gerede' ueber 'Kernel-Ressourcen die der kernel nicht kopieren
> koennte und die "irgendwie" mit phtread-Synchronisationsobjekten
> zusammenhingen'.

Ein Problem ergibt sich z.B. in Verbindung mit pthread, fork, exec und
Sockets:

Da man das FD_CLOEXEC-Flag bei Sockets erst im Nachhinein setzen kann,
kann jeder in einem Thread erzeugte Socket potenziell unkontrolliert per
fork() und exec() in Subprozesse gelangen. Man kann das mit einem
geeignet platzieren Mutex zwar umschiffen, schafft dann aber a)
Abh�ngigkeiten zwischen Programmteilen, die *NICHTS* miteinander zu tun
haben sollten, und b) ben�tigt man direkten Quellcode-Zugang zu jedem
einzelnen Aufruf von socket(), accept(), fork() und exec(), was bei
Verwendung von Libraries oft nicht gegeben ist.

Das hat mich (beruflich) schon m�chtig Nerven gekostet, zumal das eine
Race-Condition ist, die sich kaum gezielt reproduzieren l�sst...

> Diese 'Kernel-ressourcen' gibt es allerdings nicht
> und die etwas 'wurstigen' Interaktionen zwischen POSIX threads und
> fork haben mit C++ per se nichts zu tun.

Im Prinzip ACK.
Die Kapselung der pthread-Systemcalls durch boost oder neuere
C++-Versionen erschwert allerdings die Kontrolle dieser "wurstigen
Interaktionen" durch den Programmierer...

Hergen

[Rainer Weikusat]

Hergen Lehmann <hlehmann.e...@snafu.de> writes:
> On 11.05.2013 21:30, Rainer Weikusat wrote:
>> Das ist zunaechst mal eine Behauptung (es waere auch noch zu klaeren,
>> was ein 'sauberes' Programm eigentlich sein soll). Auf die Frage nach
>> einer Begruendung fuer diese kam beim letzten mal 'irgendwelches wilde
>> Gerede' ueber 'Kernel-Ressourcen die der kernel nicht kopieren
>> koennte und die "irgendwie" mit phtread-Synchronisationsobjekten
>> zusammenhingen'.
>
> Ein Problem ergibt sich z.B. in Verbindung mit pthread, fork, exec und
> Sockets:
>
> Da man das FD_CLOEXEC-Flag bei Sockets erst im Nachhinein setzen kann,
> kann jeder in einem Thread erzeugte Socket potenziell unkontrolliert
> per fork() und exec() in Subprozesse gelangen.

Das ist aber wiederum kein C++-Problem sondern eines, das von der
mangelhaften (IMHO) Integration von threads und 'tradionellen'
UNIX(*)-Interfaces herruehrt. Wenigstens Linux akzeptiert seit einer
Weile auch CLOEXEC als Flag-Argument fuer open und socket (und
mutmasslich auch alle anderen deskriptorerzeugenden Systemaufrufe ---
fuer epoll weiss ich das aus dem Kopf, habe aber ausser in open(2) und
socket(2) nirgends nachgelesen).

> Man kann das mit einem geeignet platzieren Mutex zwar umschiffen,
> schafft dann aber a) Abh�ngigkeiten zwischen Programmteilen, die
> *NICHTS* miteinander zu tun haben sollten, und b) ben�tigt man
> direkten Quellcode-Zugang zu jedem einzelnen Aufruf von socket(),
> accept(), fork() und exec(), was bei Verwendung von Libraries oft
> nicht gegeben ist.

Nicht unbedingt: Wenigstens ELF unterstuetzt dass 'ueberladen'
beliebiger Bibliotheksfunktionen wenn dynamisch gelinkt
wurde. Persoenlich bin ich auch noch keinem der 'graesslichen
Probleme' begegnet, die Leute 'dynamischem Linken' generell
zuschreiben: Im Zweifelsfall waere es ein Problem fuer den
Systemadministrator, eine geeignete Ausfuehrungsumgebung fuer
bestimmte Software zusammenzubauen und mit chroot(2) gibt es auch das
geeignete 'Werkzeug' dafuer. Insofern ich fuer den Vertrieb bestimmte
'binary only'-Software entwickeln wuerde (anstatt zum Bereitstellen
von 'Dienstleisungen', die mein Arbeitgeber fuer Geld anbietet) wuerde
ich da eiskalt etwas in der Art von 'dieser Code wurde auf ....,
... und ... getestet. Er benoetigt ..., ... und ...' dokumentieren und
alles weitere fuer ein Problem von jemand anderen halten.

[Marcel Müller]

On 11.05.13 21.30, Rainer Weikusat wrote:
>> Fakt ist, dass saubere C++-Programme und fork() sich weitgehend
>> ausschlie�en.
>
> Das ist zunaechst mal eine Behauptung (es waere auch noch zu klaeren,
> was ein 'sauberes' Programm eigentlich sein soll). Auf die Frage nach
> einer Begruendung fuer diese kam beim letzten mal 'irgendwelches wilde
> Gerede' ueber 'Kernel-Ressourcen die der kernel nicht kopieren
> koennte und die "irgendwie" mit phtread-Synchronisationsobjekten
> zusammenhingen'.

Ganz einfach: jede C++-Klasse kann laut Spezifikation davon ausgehen,
dass sie Kopiervorg�nge ihrer selbst immer mit bekommt. Das ist eine
Garantie aus dem C++-Standard. fork() durchbricht diese Garantie. Damit
ist es keine C++-Laufzeitumgebung mehr. Und sobald die C++-Klasse etwas
verwaltet, was au�erhalb des Programms liegt (managed ressorces), geht
die Verwaltung dieser Objekte schief.
Beispielsweise w�rde ein C++-Objekt mit Referenzz�hler, das mit einem
speziellen Allocator im Shared Memory liegt und gerade einen Reference
Count von 1 hat, beim fork() die 1 behalten und dann sobald einer der
beiden Prozesse das Objekt nicht mehr braucht, gel�scht - schade aber auch.

> Wenn die einzige Loesung fuer 'das Kommunikationsproblem' 'mach einen
> Webservice draus' ist, dann nimmt es nicht wunder, dass IPC als
> ungemein komplizierter Overkill gilt ...

Es ist nicht die einzige L�sung. Es ist eine L�sung mit einer gut
testbaren API. Es gibt 100.000 andere. Da der OP nicht geschrieben hat,
worum es geht, kann man kaum eine sinnvolle Empfehlung geben.


Marcel

[Juergen Ilse]

Hallo,

Marcel Mï¿œller <news.5...@spamgourmet.org> wrote:
> On 11.05.13 21.30, Rainer Weikusat wrote:
>>> Fakt ist, dass saubere C++-Programme und fork() sich weitgehend

>>> ausschlieï¿œen.

>> Das ist zunaechst mal eine Behauptung (es waere auch noch zu klaeren,
>> was ein 'sauberes' Programm eigentlich sein soll). Auf die Frage nach
>> einer Begruendung fuer diese kam beim letzten mal 'irgendwelches wilde
>> Gerede' ueber 'Kernel-Ressourcen die der kernel nicht kopieren
>> koennte und die "irgendwie" mit phtread-Synchronisationsobjekten
>> zusammenhingen'.
> Ganz einfach: jede C++-Klasse kann laut Spezifikation davon ausgehen,

> dass sie Kopiervorgï¿œnge ihrer selbst immer mit bekommt. Das ist eine

> Garantie aus dem C++-Standard. fork() durchbricht diese Garantie. Damit
> ist es keine C++-Laufzeitumgebung mehr.

Innerhalb jedes Prozesses bleibt die Garantie eingehalten (da die Kopie
ja nur in einem anderen Prozess existiert).

> Und sobald die C++-Klasse etwas verwaltet, was auï¿œerhalb des Programms

> liegt (managed ressorces), geht die Verwaltung dieser Objekte schief.

... was aber an der Verwendung dieser "managed resources" liegt, die
sich genaugenommen so nicht unbedingt mit dem C++ Standard vertragen
(und die ueber die vom Sprachstandard garantierte Funktionalitaet
mindestens genausoweit hinausgeht wird fork()).

> Beispielsweise wï¿œrde ein C++-Objekt mit Referenzzï¿œhler, das mit einem

> speziellen Allocator im Shared Memory liegt und gerade einen Reference
> Count von 1 hat, beim fork() die 1 behalten und dann sobald einer der

> beiden Prozesse das Objekt nicht mehr braucht, gelï¿œscht - schade aber auch.

Liegt das Provlem hierbei bei fork() oder bei der Verwendung von
shared memory ohne ggfs. bei solchen Fehlermoeglichkeiten "manuell"
nachzubessern, indem man z.B. nach erfolgreichem fork() den Referenz-
count anpasst ... IMHO letzteres.

Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
--
Ein Domainname ist nur ein Name, nicht mehr und nicht weniger.
Wer mehr hineininterpretiert, hat das Domain-Name-System nicht
verstanden.

[Rainer Weikusat]

Marcel Müller <news.5...@spamgourmet.org> writes:
> On 11.05.13 21.30, Rainer Weikusat wrote:
>>> Fakt ist, dass saubere C++-Programme und fork() sich weitgehend

>>> ausschließen.

>>
>> Das ist zunaechst mal eine Behauptung (es waere auch noch zu klaeren,
>> was ein 'sauberes' Programm eigentlich sein soll). Auf die Frage nach
>> einer Begruendung fuer diese kam beim letzten mal 'irgendwelches wilde
>> Gerede' ueber 'Kernel-Ressourcen die der kernel nicht kopieren
>> koennte und die "irgendwie" mit phtread-Synchronisationsobjekten
>> zusammenhingen'.
>
> Ganz einfach: jede C++-Klasse kann laut Spezifikation davon ausgehen,

> dass sie Kopiervorgänge ihrer selbst immer mit bekommt.

Kann sie? Meines Wissens nach (und das koennte durchaus falsch sein)
ist

class A b(...), *c;

c = (A *)malloc(sizeof(b));
memcpy(c, &b, sizeof(b));

von casts die ich moeglicherweise vergessen habe, mal abgesehen,
gueltiges C++.

[Marcel Müller]

On 12.05.13 20.51, Rainer Weikusat wrote:
> class A b(...), *c;
>
> c = (A *)malloc(sizeof(b));

> memcpy(c,&b, sizeof(b));

>
> von casts die ich moeglicherweise vergessen habe, mal abgesehen,
> gueltiges C++.

Gültig, im Sinne von "der Compiler kann den Fehler nicht bemerken" ja.
Aber der Code hat undefiniertes Verhalten wenn A kein POD-Typ ist. Die
Nummer würde schon für A := std::string mächtig in die Hose gehen
(wahrscheinlich Programmabsturz im operator delete) - jedenfalls wenn
der String nicht singulär ist (also nicht leer oder NULL).


Marcel

[Rainer Weikusat]

Das das eine sinnvolle Operation ist, hatte ich nicht behauptet. Aber
ist es tatsaechlich 'undefiniertes Verhalten'? Und wie steht das mit
Dingen, der per Definition 'undefiniert' sind, soweit es C++ angeht,
also zB Interaktion mit irgendwelchen OS-spezifischen Interfaces?

[Rainer Weikusat]

Rainer Weikusat <rwei...@mssgmbh.com> writes:
>> On 12.05.13 20.51, Rainer Weikusat wrote:
>>> class A b(...), *c;
>>>
>>> c = (A *)malloc(sizeof(b));
>>> memcpy(c,&b, sizeof(b));
>>>
>>> von casts die ich moeglicherweise vergessen habe, mal abgesehen,
>>> gueltiges C++.
>>

>> G锟絣tig, im Sinne von "der Compiler kann den Fehler nicht bemerken"

>> ja. Aber der Code hat undefiniertes Verhalten wenn A kein POD-Typ

>> ist. Die Nummer w锟絩de schon f锟絩 A := std::string m锟絚htig in die Hose

>> gehen (wahrscheinlich Programmabsturz im operator delete) - jedenfalls

>> wenn der String nicht singul锟絩 ist (also nicht leer oder NULL).

>
> Das das eine sinnvolle Operation ist, hatte ich nicht behauptet. Aber
> ist es tatsaechlich 'undefiniertes Verhalten'? Und wie steht das mit
> Dingen, der per Definition 'undefiniert' sind, soweit es C++ angeht,
> also zB Interaktion mit irgendwelchen OS-spezifischen Interfaces?

Ergaenzung: Es gibt auch ggf weniger 'rabiate' Wege, einen
ueberladenen operator = zu umgehen. ZB koennte eine struct/ Klasse mit
ausschliesslich oeffentlichen Datenelementen einen haben aber man
koennte auch Datenelement fuer Datenelement von Hand kopieren. Ich
erinnere mich auch noch, dass es erlaubt ist, wenn eine Klasse einen
Kopierkonstrukter und keinen operator = hat oder umgekehrt. Das ist
auch (normalerweise) nicht sinnvoll aber nicht verboten.

[Stefan Reuther]

Rainer Weikusat wrote:

> Marcel M�ller <news.5...@spamgourmet.org> writes:
>>On 12.05.13 20.51, Rainer Weikusat wrote:
>>>class A b(...), *c;
>>>
>>>c = (A *)malloc(sizeof(b));
>>>memcpy(c,&b, sizeof(b));
>>>
>>>von casts die ich moeglicherweise vergessen habe, mal abgesehen,
>>>gueltiges C++.
>>

>>G�ltig, im Sinne von "der Compiler kann den Fehler nicht bemerken"

>>ja. Aber der Code hat undefiniertes Verhalten wenn A kein POD-Typ

>>ist. Die Nummer w�rde schon f�r A := std::string m�chtig in die Hose

>>gehen (wahrscheinlich Programmabsturz im operator delete) - jedenfalls

>>wenn der String nicht singul�r ist (also nicht leer oder NULL).

>
> Das das eine sinnvolle Operation ist, hatte ich nicht behauptet. Aber
> ist es tatsaechlich 'undefiniertes Verhalten'?

Der C++-Standard definiert diese Operation nur f�r POD-Datentypen,
sprich: Datentypen, die in C genauso "funktionieren" w�rden (�3.9(2) ff
im 1998er Standard). std::string f�llt dabei zum Beispiel raus, weil es
einen Konstruktor hat.

Das Problem entsteht bei std::string in der Praxis im Destruktor des
kopierten Objekts durch ein doppel-delete. Dieses spezielle Problem kann
man zwar prinzipiell in den Griff bekommen (z.B. indem man das Original-
Objekt ohne Destruktoraufruf wegr�umt, wie das z.B. implizit passieren
w�rde, wenn man realloc benutzt, was ja intern gerne malloc/memcpy/free
macht).

Allerdings gibt es noch weitere Stellen, wo der Compiler (und nicht nur
wie bei std::string die Bibliothek) die Zusicherung nutzt, dass ein
Objekt nur �ber Konstruktor und Destruktor kommt und geht: der Borland-
Compiler baut z.B. bei virtueller Vererbung unsichtbare Zeiger in das
Objekt ein, die auf das Basisklassen-Teilobjekt zeigen. memcpy macht
solche Objekte einfach kaputt.

> Und wie steht das mit Dingen, der per Definition 'undefiniert' sind,
> soweit es C++ angeht, also zB Interaktion mit irgendwelchen
> OS-spezifischen Interfaces?

Die sind eben, aus Sicht des C++-Standards, undefiniert. Sie m�ssten
z.B. von einem POSIX-C++-Binding definiert werden, was es meines Wissens
nach nicht gibt. Also bleibt nur die Hoffnung, dass sich die Macher der
OS-Interfaces und der C++-Compiler an den "Geist" des Standards halten
und daf�r sorgen, dass ein in C definiertes Interface auch m�glichst
�hnlich in C++ aufrufen l�sst.

Praktisch steigt, je weiter man von POSIX wegkommt, die Wahrscheinlich-
keit, auf Header zu sto�en, denen man noch ein 'extern "C"' verpassen
muss, oder die eine Membervariable namens 'class' definieren.

Und wenn man �ber den Tellerrand schaut, gibt es auch Betriebssystem-
Schnittstellen, deren Interaktion mit C++ komplizierteste Raketentechnik
ist, wie Microsoft's __try/__except in C.


Stefan

[Gerald Breuer]

Am 10.05.2013 17:31, schrieb Heinz-Mario Frï¿œhbeis:

> DANN ANTWORTE MIR NICHT! Verstehst du das nicht? *EOD*

Ich frag mich echt wie krank die Leute hier in der Birne sind sich
ï¿œber solche Verstï¿œndigungsprobleme aufzuregen. Mann, es geht hier
um Freizeitgestaltung in einer Newsgroup und nicht um was lebens-
wichtiges.