Reprise du message précédent :

 
Malheureusement, il n'y a pas d'astuce (ça se saurait).
 
Faut juste être complètement fou.

enfin de toutes manières c'est casse-gueule de passer des instances de classes à méthodes virtuelles par une mémoire partagée...

 
donc fodrait se démerder pour se faire une table de translation pour résoudre le vfptr du process créateur au vfptr du process courant.

genre au niveau process créateur, tu énuméres les classes possibles dans la mémoire partagée, tu as une table de couples nom classe/vfptr..
 
le process courant fait la même chose, et se construit une table de translation vfptr créateur->vfptr courant.
 
pour les appels de méthodes virtuelles, t'attrapes le vfptr de l'instance dans la mémoire partagée, tu retrouves le vfptr pour le process courant, tu te démerdes pour faire l'appel (gni)...
 
et pi tu te tires un balle et tu notes pour plus tard, qu'être un programmeur fou (et un petit peu matuvu) c'est mal.

 
Casse gueule, c'est le mot.
 
Deux programmeurs sont en haut d'une immeuble. Ils se lancent un pari : descendre le plus vite possible. Le premier, sain de corps et d'esprit se dirige rapidement vers les ascenseurs. Le deuxième ouvre la fenêtre et se jette. Il a intérêt à apprendre rapidement à voler...

 
Il y a comme un hic au niveau du (gni). Et d'autant plus que si tu avais dans l'idée de patcher ton objet, tu vas te poser des restrictions de locking pour le moins sévères.

patcher non, faire juste ça en local... dans la fonction appelante du process non créateur...

J'ai pas compris, c'est faisable ou c'est pas faisable ?
De toute façon, 2 process n'ont pas à se passer et bosser sur de mêmes instances de classes.
Dans le cas de ton toto, faudrait changer le private int toto en private volatile int toto...

Et puis faut gérer l'exclusion mutuelle...
Bref, en plus d'être une horeur en génie log, ça peut pas marcher, avec ou sans vtable.

bah...... en se faisant chier chier et en priant très fort pour avoir de cas particuliers tordus, ça peut passer...
 
par contre pourquoi le volatile pour la méthode toto() ?

 
Je ne vois pas bien ce que vous voulez dire et faire.

 
C'est faisable mais c'est vraiment pas simple, loin de là. Je ne suis même pas sûr qu'on trouve une solution quelque part dans google.
 
Pour le reste, 2 process peuvent très bien avoir à utiliser une instance commune d'une même classe (on peut toujours se débrouiller autrement mais là n'est pas la question). Si vous désirez des explications sur des implémentations à la mords-moi-le-com, je dois pouvoir vous trouver un lien.

J'ai du mal à en saisir l'intérêt.

 
Un intérêt est, par exemple, de masquer la communication des process pour se transmettre les données et d'avoir à reconstruire d'un coté ce qui existait déjà de l'autre.

 
je dirais un truc dans ce goût là:
 

 
un truc on ne peut plus dégueulasse, bancal et non portable qui soit.... (c'est un ordre d'idée m'en fous si c'est pas censé compiler bien évidemment, si les void* c'est mal, si le push 0 est pas popé)

en gros c'est un topic à mauvaises pratiques et autres choses suicidaires de la vie

 
Pour le principe d'avoir à coder, quelque part, l'appel à la fonction, tu es sûr la bonne piste. Il y a de l'idée mais tel quel, je pense que cela être plus que difficile d'implémenter la fonction TranslateVfptr parce qu'elle ne pourra pas facilement savoir qu'elle travaille sur la classe blabla au moment du runtime. En outre, le challenge était de pouvoir faire directement : pObjetBlabla->UneMethode(). Disons que le programmeur fou trouve la méthode pour le faire et une fois qu'il l'a réalisée, un programmeur pas fou peut l'utiliser sans même savoir comment elle fonctionne.
 
Astuce 5: le problème ne se résout pas dans le code du process appelant les méthodes
Astuce 6: le problème ne se résout pas non plus dans le code du process créant l'objet

 
Pas tout à fait. C'est un topic pour montrer qu'on peut toujours faire ce que d'autres proclament comme impossible, du moment qu'on ouvre un peu son esprit et qu'on essaye de penser autrement.

pour en revenir au loader de librairie, si le loader charge toute la lib en mémoire partagée, et qu'il force les allocations en mémoire partagée, la vtable ne pourrait-elle pas etre lisible et utilisable par les 2 processus ?
 
-edit-
si c'est la lib qui s'occupe de l'allocation de ses objets

Oui, sauf qu'il y a deux autres points posant problème:
- il va falloir résoudre toutes les dépendances de la lib et faire en sorte qu'elles aillent aussi en mémoire partagée (ça reste faisable)
- la plupart des implémentations d'unix n'acceptent pas qu'on exécute du code en mémoire partagée (petit souci...)