Tube en C++ (Windows)

**jmjmjm** · 08/08/2010, 21h38

Bonjour, j'ai deux application qui doivent s'échanger des données l'une tourne en C# et l'autre en C++ native.

Mon choix c'est porté vers les pipes, qu'en pensez vous??

Auriez vous un exemple de fonctionnement de pipe en C++ natif car je ne trouve rien sous Windows, pas mal d'exemple Linux (c'est d'ailleurs sous Linux que j'ai connu les pipes).

J'ai le handle du pipe créé en C#, je voudrais donc écouter ce handle sur le programme c++.

Merci d'avance

**ram-0000** · 08/08/2010, 23h28

L'API Microsoft de gestion des pipes est ici : http://msdn.microsoft.com/en-us/libr...(v=VS.85).aspx

**jmjmjm** · 09/08/2010, 00h22

merci pour la réponse, j'étais justement en train d'éplucher le MSDN mais je n'arrive pour le moment pas à recevoir les données envoyer par mon programme C++. J'arrive à faire un début de connexion, c'est déjà ca !!

Tu ne m'as pas dis ce que tu pensais du fait d'utiliser les pipes. Bonne solution?? Moyenne?? Pas le choix ??

**ram-0000** · 09/08/2010, 01h17

Envoyé par jmjmjm

Tu ne m'as pas dis ce que tu pensais du fait d'utiliser les pipes. Bonne solution?? Moyenne?? Pas le choix ??

Je n'en pense rien, ni bon, ni mauvais. C'est un moyen de communication interprocess comme un autre. Naturellement, je serais parti vers un socket mais un pipe c'est bon aussi.

**3DArchi** · 09/08/2010, 13h43

Comme le dit Ram, il y a plusieurs solutions pour faire communiquer différents processus. Toute une rubrique est présentée dans Interprocess Communication du MSDN.
Cependant, lors de l'échange de données, il faut faire attention au format d'échange entre les 2 langages (problème de représentation, d'alignements, d'endian etc.). La réponse dépend peut être de la façon dont tu sérialises tes données en C++ et en C#.

**jmjmjm** · 09/08/2010, 18h20

Merci pour la réponse, pour le moment j'essaye juste d'envoyer une chaine string mais ca passe pas. Je galère vraiment. Les exemple MSDN ne sont pas compatible :
- le client du C++ fonctionne avec le serveur C++ (normal)
- le client c# fonctionne avec le serveur c# (normal)

mais je n'arrive pas à faire marcher un client c++ avec un serveur c#.

Je ne trouve pas d'exemple sur le net de cas comme ca.

Quelles sont les autres solutions que tubes nommés (Socket, partage par fichier (pas top))

Merci

**white_tentacle** · 09/08/2010, 18h28

Shared memory, sinon. Mais si ta communication est à sens unique, un pipe c'est très bien. Je pense que le problème vient effectivement de la sérialisation des données : si tu dumpes tes structures de manière brute depuis le code c++ (ou les sérialise d'un moyen quelconque), il faut en revanche passer par le marshaller et interop pour les lire depuis le C#.

Je soupçonne les classes de gestion de pipe de .net de s'occupper elle même de la (dé)sérialisation et de le faire de manière différente de ton programme c++.

**jmjmjm** · 09/08/2010, 19h05

Ta réponse m'interpelle. Car moi j'utilise le pipe dans les deux sens tu peux le déclarer en in, out ou inout. Quesque shared memory?? Trouverais je des exemples facilement pour communiquer de c++ a c#. Désole dete poser cette question mais je suis dans le train et je ne peux pas facillement chercher sur Google.

Merci

**ram-0000** · 09/08/2010, 19h09

shared memory, c'est de la mémoire partagée.

C'est un autre procédé de communication interprocess qui permet d'échanger des données. Ceci dit, c'est plutôt prévu pour échanger une structure de données plutôt qu'une file de messages (ou alors, il va falloir faire tout le mécanisme de gestion de file de messages pour transformer et adapter ta mémoire partagée en une file de messages).

**Flob90** · 09/08/2010, 19h09

Si je me trompe pas un shared memory est comme son nom l'indique une zone mémoire partagé par différent processus, il convient donc de prendre les précautions utiles en programmation MT, pour ce genre de mémoire il doit y avoir des memory barriers qui permettent de locker la zone pendant un certain temps. (mais je sais pas si il y a quelque chose de portable à ce sujet, je croit pas)

**3DArchi** · 10/08/2010, 10h18

Salut,

Envoyé par Flob90

Si je me trompe pas un shared memory est comme son nom l'indique une zone mémoire partagé par différent processus, il convient donc de prendre les précautions utiles en programmation MT, pour ce genre de mémoire il doit y avoir des memory barriers qui permettent de locker la zone pendant un certain temps. (mais je sais pas si il y a quelque chose de portable à ce sujet, je croit pas)

Dans mon souvenir, le shared memory win32 s'appuie sur les file mapping. Les memory barrier n'apparaissent qu'avec vista il me semble.

**white_tentacle** · 10/08/2010, 10h56

Envoyé par jmjmjm

Ta réponse m'interpelle. Car moi j'utilise le pipe dans les deux sens tu peux le déclarer en in, out ou inout. Quesque shared memory?? Trouverais je des exemples facilement pour communiquer de c++ a c#. Désole dete poser cette question mais je suis dans le train et je ne peux pas facillement chercher sur Google.

J'étais persuadé que les pipes étaient à sens unique, au temps pour moi, donc.

Sinon, il te faut un named pipe pour la communication, parce que pour passer le handle, il te faut communiquer, et que du coup on se mort la queue

.

**Flob90** · 10/08/2010, 18h17

Envoyé par 3DArchi

Salut,

Dans mon souvenir, le shared memory win32 s'appuie sur les file mapping. Les memory barrier n'apparaissent qu'avec vista il me semble.

Merci pour l'info. Je me suis jamais penché sur le sujet, juste Alexandrescu qui en parle dans certains articles (sur le singleton et le developpement lock-free) comme une solutions plus fiables que les mutex (pour palier au problème du DCLP en particulier) mais il ne présente pas de code (rien de portable ni de standard).

**jmjmjm** · 13/08/2010, 00h42

Merci à tous, j'ai donc choisi et retenu la solution utilisant les named pipe, cela fonctionne très bien après pas mal de recherche, je dois par exemple transformer mes strings c# afin que le C++ puisse les lire à l'autre extrémité et vis versa. je vous parle même pas des foncions de fou que j'ai faite pour sérialiser / dé-sérialiser un objet mais maintenant que tout fonctionne ca me va..

A bientôt