[Seattle] Partage de données avec une application c++

Bonjour les gens,

Nous avons un programme en c++ qui doit réaliser un calcul à partir de données que nous lui passons depuis Delphi, et qui doit nous renvoyer un résultat.

Solution actuelle : Le soft en Delphi enregistre un fichier de données et lance le programme c++ qui sait où prendre les données en entrée. La sortie est redirigée dans un fichier qui est lu par le soft en Delphi.

Ça fonctionne mais je me demandais s'il n'y aurait pas une manière plus directe de faire ça pour éviter les fichiers intermédiaires. Nous avons tenté l'intégration sous forme de fichier .obj mais à partir de toutes les infos glanées sur le net, il semble que seuls les programmes écrits en c sont possibles et non en c++ (enfin, c'est ce que j'ai cru comprendre).

Juste par curiosité, quelqu'un ici a déjà fait ce genre de combinaison ?

Papy !

il suffit que ton application C++ déclare une fonction non objet du style

Code:

---

1 2	char * traitement(char * data);

---

sous Delphi tu n'as plus qu'à faire

Code:

---

1 2 3

{$L code_cpp.obj} function traitement(data: PChar): PChar; external; // attention au AnsiChar/WideChar !

---

et le tour est joué.

si nécessaire tu peux ajouter un freedata(p: PChar) pour libérer la valeur retournée.

la même chose peut se faire avec une DLL

Code:

---

1 2	function traitement(data: PChar): PChar; external 'code_cpp.dll';

---

et si les données ne sont pas textuelles

Code:

---

1 2 3 4

function traitement(src: Pointer; src_size: Integer; return: PPointer; return_size: PInteger): Boolean; external 'code_cpp.dll'; // ou encore, car ça ne change rien au niveau du code C++ function traitement(src: Pointer; src_size: Integer; var return: Pointer; var return_size: Integer): Boolean; external 'code_cpp.dll';

---

inclure un .obj était ma première idée mais ça ne veut pas fonctionner.
Le .obj est généré à partir de

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

#ifndef _EXCENTRICITY_H_ #define _EXCENTRICITY_H_   #include <string> #include <list>     namespace MonNamespace { int maFonction(int inInteger); };   #endif

---

et

Code:

---

1 2 3 4 5 6 7 8 9 10

#include <iostream> #include <fstream> #include <stdexcept> #include "excentricity.h"   double MonNamespace::maFonction(std::string const & monTexte){ double result; result = 10.2; return result; };

---

Sous Delphi

Code:

---

1 2 3

{$L 'excentricity.obj'}   function _maFonction(inInteger: Integer): Integer; external;

---

Résultat à la compilation

Citation:

---

[dcc32 Erreur] Unit9.pas(11): E2065 Déclaration forward ou external non satisfaite : '_maFonction'
[dcc32 Erreur] Unit9.pas(30): E2065 Déclaration forward ou external non satisfaite : '__ZNSt8ios_base4InitD1Ev'
[dcc32 Erreur] Unit9.pas(30): E2065 Déclaration forward ou external non satisfaite : '__ZNSt8ios_base4InitC1Ev'
[dcc32 Erreur] Unit9.pas(30): E2065 Déclaration forward ou external non satisfaite : '_atexit'
[dcc32 Erreur fatale] AppelOBJ.dpr(6): F2063 Impossible de compiler l'unité utilisée 'Unit9.pas'

---

N'étant pas spécialiste cpp , j'ai du mal à voir la source de l'erreur

Je précise qu'il ne s'agit là qu'un test préliminaire à l'intégration d'un module plus "large"

je ne suis pas non plus expert C++, mais selon les options de compilation il peut y avoir des décorations ... tient je ne sais pas si la directive "name" fonctionne sur un external lié...à tester function test; external name '?test@@ZAXXZ';.

pour les autres erreurs elles viennent de .obj dont dépend le premier qui n'ont pas été liées par un $L...et si le code fait appel au runtime C++ ça peut devenir compliqué :)

la DLL reste alors plus simple avec toujours la question de la décoration éventuellement.

L'ajout de name n'a rien donné.
J'ai trouvé un article disant qu'un obj créé avec C++ Builder serait 100 % compatible.
Je vais voir avec un collègue qui connait le langage mieux que moi pour tester ça.
Et sinon, ça se finira avec une dll si il faut vraiment éviter les fichiers intermédiaires.

Merci de ton aide

Citation:

---

Envoyé par Papy214

L'ajout de name n'a rien donné.
J'ai trouvé un article disant qu'un obj créé avec C++ Builder serait 100 % compatible.
Je vais voir avec un collègue qui connait le langage mieux que moi pour tester ça.
Et sinon, ça se finira avec une dll si il faut vraiment éviter les fichiers intermédiaires.

Merci de ton aide

---

il faut savoir qu'il existe 2 formats OBJ : COFF et OMF...à partir de XE2, Delphi supporte les deux formats, avant cela il ne supportait que le format OMF obtenu notamment avec C++Builder :)

mais il n'en reste pas moins que si le code C fait appel à des fonctions internes du C, il faudra les lui fournir, un peu comme un DCU Delphi qui va réclamer les DCU des unités qu'il utilise.