Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
[std::map] Exporter les données d'une map
Bonjour à tous.
Je dois partager (via mémoire partagée) un std::map entre plusieurs processus. Je ne sais pas vraiment comment m'y prendre puisque toutes les données de la map doivent être encapsulées dans ladite mémoire.
J'ai cherché dans la doc du type std::map, mais je n'ai rien trouvé de semblable à std::string::data(). Pourriez-vous m'aiguiller svp ?
Si vous mappez de la mémoire, vous n'exportez la structure, vous la partagez.
Avec se mécanisme, vous couplez très fortement vos applicatifs qui devront tous être généré par même compilateur ave les mêmes options de compilation et respecter un mécanisme d'exclusion mutuelle lors des écritures.
Bonjour, l'usine à gaz.
Sur quel OS et avec quel primitive faite vous le mapping de mémoire partagée ?
Pour pouvoir mettre une map en mémoire partagée, il faut effectivement utiliser les même compilateur et les mêmes options de chaque côté. C'est une contrainte tout à fait acceptable dans certains cas d'utilisation.
Il faut alors pour y parvenir non seulement y placer la map elle-même, mais aussi que si la map alloue de la mémoire en interne (ce qu'elle va faire), elle l'alloue elle aussi dans de la mémoire partagée. Il faut donc modifier la manière dont la map alloue de la mémoire. Ce qui se fait grâce au paramètre template Allocator de std::map. On lui fourni un allocateur qui alloue en mémoire partagée. Et dans certains cas, ça marche. Pas dans d'autres, suite à des limites d'implémentation des différentes STL.
Que faire alors ? Boost.interprocess vient à la rescousse en fournissant (entre autre) des map compatibles avec un allocateur mémoire en mémoire partagée. Lire http://www.boost.org/doc/libs/1_39_0...ners_explained pour plus de détails.
Bonjour, et merci de vos réponses.
Je me suis plongé depuis quelques jours déjà sur l'implémentation d'un allocator. Il fonctionne parfaitement. En revanche, ma std::map fait des demandes d'allocations de plages mémoires d'un unique octet, mais semble écrire sur plus d'un (cela oblige l'allocator à retourner des NULL et ainsi l'application à se terminer).
Savez-vous pourquoi cette satanée map ne fait des demandes que pour un octet ???
Concernant les remarques que vous avez faites, je les trouve pertinentes. J'avais prévu dès le début de créer une bibliothèque partagée. Ainsi, chaque instance accède à la même zone mémoire. Ensuite, plusieurs applications utilisant ladite bibliothèque peut être compilée avec un compilo différent.
Quant aux sémaphores, je ne les ai pas encore mis en place (je teste avec un unique process là), mais c'est à venir. Sous Linux, leur implémentation est aisée (un petit shmctl et hop !).
Ce qui m'inquiète, c'est que l'on me demande un portage Windows :/
Mince, j'ai écrit trop vite. L'erreur venait de ma part (et d'un nom de type ambigüe de la part de la stl).
La std::map fait une demande d'allocation en fournissant le nombre d'objets (de type typename T, l'allocator étant un template), je pensais que la demande était faite en nombre d'octets.
Ma sharedmap fonctionne donc
Merci.
Les semaphores ne sont pas plus compliqués sous windows. Regarde CreateSemaphore.
Par contre, pourquoi n'utilises tu pas la bibliothèque de boost qui défini déjà tout ça de manière portable ?
Avec une ressource telle qu'une map, je conseillerais plus un Mutex (qui ont partageables sous Windows) qu'un sémaphore...
Parce que je code pour une boîte. Et le copyright imposé par boost est quelque peu gênant, surtout pour un projet militaire :/Envoyé par JolyLoic
Gênant en quoi ?
Difficile d'imaginer moins contraignant que la license de boost...
C'est souvent non pas un problème de licence mais d'évaluation en terme de sécurité. En gros, tu ne peux utiliser que des COTS avec le label Approuvés Par Les Geeks Agents Secrets.Gênant en quoi ?
Difficile d'imaginer moins contraignant que la license de boost...
Imagine un missile utilisé par l'armée avec sur le coté écritGênant en quoi ?
Difficile d'imaginer moins contraignant que la license de boost...
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT. IN NO EVENT
SHALL THE COPYRIGHT HOLDERS OR ANYONE DISTRIBUTING THE SOFTWARE BE LIABLE
FOR ANY DAMAGES OR OTHER LIABILITY, WHETHER IN CONTRACT, TORT OR OTHERWISE,
ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
DEALINGS IN THE SOFTWARE.
(je bosse pas sur des missiles, mais je trouvais l'exemple plus rigolo)
Salut,Ben, c'est déjà plus ou moins le cas...Imagine un missile utilisé par l'armée avec sur le coté écrit
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT. IN NO EVENT
SHALL THE COPYRIGHT HOLDERS OR ANYONE DISTRIBUTING THE SOFTWARE BE LIABLE
FOR ANY DAMAGES OR OTHER LIABILITY, WHETHER IN CONTRACT, TORT OR OTHERWISE,
ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
DEALINGS IN THE SOFTWARE.
(je bosse pas sur des missiles, mais je trouvais l'exemple plus rigolo)
Tu n'es jamais sur qu'un missile atteindra sa cible et tuera bel et bien le type que tu cherche à avoir et non une dizaines d'innocents
Et en plus, ce passage est illégal en France. Il manque la phrase "TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW"...
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager