Bonjour,
 
Je souhaite implémenter le conteneur map dans une mémoire partagée, de manière à ce que le contenu du conteneur puisse etre exploité par plusieurs processus en lecture / écriture.
 
Mon pb: comment dois-je copier le conteneur dans la mémoire partagée ? J'ai un pb de lecture et d'écriture pour cet objet.
 
Note: je peux copier sans pb un tableau d'entiers, de structures, sans doute parce que les données sont stockées de manière contigue et sans référence à des adresses de mémoire. Mais pour un conteneur de la STL, problème !    
 
Je suis sous Linux Red Hat 7.2. J'utilise le c++ standard.    
 
kason  

Il te faut créer ton propre allocateur et le filer en dernier paramètre template à ton map.

Que devra contenir ce nouveau allocateur par rapport à l'allocateur par défaut ? En fait, je ne vois pas ce que je dois modifier dans la classe Allocator de base...

nan, enfin pas obligatoirement/seulement.
 
il faut utiliser l'opérateur new "in place", dont la syntaxe est la suivante:

avec ça new ne fait pas l'allocation mémoire, et se contente d'apeller le constructeur sur l'addresse mémoire qu'on lui donne.

Je voudrais en savoir plus sur la classe Allocator de la librairie STL.  
 
Permet-elle d'organiser la position et la structure des éléments du conteneur dans la mémoire (itérateurs, données, etc) ?

as tu seulement pipé un mot de mon post déjà?

Ceci dit schnapsmann, la difficulté, c'est pas tant d'allouer l'objet map, que de lui dire comment ensuite allouer les noeuds de son arbre red-black. Donc un allocateur pour shared-memory s'impose...
 
Mais je crois bien qu'il y a un outil qui s'appelle google qui pourrait nous en apprendre un peu plus sur les allocateurs de la STL...

oui bien sur, ceci dit le commencement c'est bien le new in place, et effectivement un allocateur redéfini est obligatoire

schnapsmann> vu qu'en interne std::map va faire des allocs, ça me parrait obligatoire.  
 
Y'a pas de classe Allocator utilisable comme tu sembles le penser, c'est juste une interface de manipulation pour la STL. Tu dois en implémenter une autre que celle fournie par défaut (std::allocator), donc tu le fais comme tu veux. Tu peux faire des allocations dans un fichier, sur un ordi distant via tcp/ip si ça te dit.
http://www.roguewave.com/support/d [...] /12-6.html

mmmmm.... et au niveau adressage ne risque-t-il pas y avoir de problème lorsque l'arbre sera parcouru ? (question pour moi)
 
mais si tu prends deux process différents (pas issu d'un fork), ça risque de pêter les plombs au niveau adressage (ou il alors il faudrait un adressage relatif au début de la mémoire partagée) ?

 
la cohérence des addresses dans la shm est assurée par le système, et les pointeurs restent valables d'un process à l'autre (sauf si tu t'amuses à stoquer un pointeur vers l'espace privé d'un process dans la shm)

Oui y'a d'autres contraintes liées au multitache et aux accès concurrents...

ça existe à cette adresse :
http://allocator.sourceforge.net/

 
Non. Rien ne vous garantit que n'importe quel os va toujours mapper le segment à la même adresse virtuelle dans chaque processus. En d'autres termes, la seule manière d'être à la fois safe et portable, c'est d'utiliser, d'une manière ou d'une autre, des adresses relatives à l'adresse du début du segment.
 

 
oui, au temps pour moi, c'est vrai uniquement avec des process clonés par fork qui s'attacheraient à la shm avant de forker comme le disait bjone; mais de toutes façons il vaut mieux utiliser des pointeurs relatifs.

 
Oui. D'ailleurs, dans la même veine, il faut faire plutôt attention à la shared en C++ pour les classes ayant une vtable car rien ne garantit non plus que l'adresse sera la même dans tous les processus.

Y'avait eu un topic là dessus.