Externaliser une classe C++ en C.

Version imprimable

11/06/2018, 10h28
tej64

Externaliser une classe C++ en C.

Bonjour,

Je dois utiliser une DLL C++ dans mon programme C.
J'ai trouvé sur internet comment rendre mes fonctions C++ compréhensibles en C avec les "extern c" etc ...

En revanche, impossible de faire cela sur une classe C++.
Par exemple, une fonction utilise un objet, lorsque je la rend "extern c" et que je l'importe dans mon programme C avec du GetProcAdress, ça plante au lancement de l'exécutable.

Auriez-vous des indications pour faire cela ? Dois-je m'affranchir des classes et objets pour arriver à mes fins ?
Merci d'avance, bonne journée.

tej
11/06/2018, 10h36
Bousk

C'est pas la même chose ? https://www.developpez.net/forums/d1...me-cpp-vers-c/
11/06/2018, 10h39
tej64

Oui, j'aurais du mettre l'autre sujet en résolu car j'ai avancé sur le sujet, je sais que c'est faisable car j'ai réussi à interfacer pas mal de fonctions de C++ vers C.
Là je souhaite attaquer la conversion des classes et objets de C++ vers C.

Si vous avez des idées là dessus je suis preneur.
11/06/2018, 10h50
Bousk

Les idées sont toujours les mêmes : oui c'est bien entendu faisable, et les sources de SFML sont toujours disponibles pour voir de quelle manière.
class n'existe pas en C, donc il faut interfacer des struct. Les fonctions membres n'existent pas, il faut interfacer des fonctions libres. C'est similaire à ce qui se fait avec FILE*.

https://github.com/SFML/CSFML/blob/m...etwork/Types.h
https://github.com/SFML/CSFML/blob/m...rk/TcpSocket.h
https://github.com/SFML/CSFML/blob/m.../TcpSocket.cpp
11/06/2018, 11h16
tej64

Merci pour ta réponse.

Si j'utilise la librairie SFML et une fonction de cette dernière dans une fonction libre en C++. Que je rend la fonction "extern c" et que j'en fais une DLL C++, elle ne marchera pas quand je l'appelerai de mon programme C ?
12/06/2018, 19h15
koala01
Salut,

Citation:

Envoyé par tej64

Merci pour ta réponse.
Si j'utilise la librairie SFML et une fonction de cette dernière dans une fonction libre en C++. Que je rend la fonction "extern c" et que j'en fais une DLL C++, elle ne marchera pas quand je l'appelerai de mon programme C ?

Normalement, la convention de nommage de n'importe quelle fonction déclarée extern "C" respecte les les conventions propres au C.

Le seul truc, c'est que si le compilateur C++ supporte une certaine partie de la syntaxe de C, l'inverse n'est absolument pas vrai : un compilateur C ne comprend... que C.

C'est la raison pour laquelle des mots clés comme class template ou namespace que l'on retrouve en C++ ne sont pas compris par le compilateur C.

Par contre, ce qui est chouette, c'est que toutes ces informations n'existent plus une fois que tu as compilé ta DLL (*). Si bien que, si ta dll exporte des symboles susceptibles d'être reconnu lors de l'édition de liens d'une application C, cette application pourra les utiliser sans "aucun problème" ;)

Donc oui: pour autant que tu veilles à
- respecter la syntaxe C dans les fichiers d'en-tête que tu vas utiliser pour ton application développée en C
- déclarer les éléments qui seront utilisés par ton application développée en C comme étant extern "C"
- créer des fonction libres (prenant un pointeur sur une structure C connue par ton compilateur) pour servir de "façade"
- respecter les règles spécifiques au C (pas de surcharge de fonctions, entre autres) pour tes éléments extern C
- j'oublie sans doute un ou l'autre conseil :P
ta DLL, compilée à l'aide d'un compilateur C++ devrait effectivement pouvoir servir pour une application développée en C.

Et le mieux de tout, c'est que tu devrais même, du coup, pouvoir envisager de l'utiliser en java ou en C# par exemple :D
13/06/2018, 09h07
tej64
Citation:
Par contre, ce qui est chouette, c'est que toutes ces informations n'existent plus une fois que tu as compilé ta DLL (*). Si bien que, si ta dll exporte des symboles susceptibles d'être reconnu lors de l'édition de liens d'une application C, cette application pourra les utiliser sans "aucun problème" ;)

Donc oui: pour autant que tu veilles à

respecter la syntaxe C dans les fichiers d'en-tête que tu vas utiliser pour ton application développée en C
déclarer les éléments qui seront utilisés par ton application développée en C comme étant extern "C"
créer des fonction libres (prenant un pointeur sur une structure C connue par ton compilateur) pour servir de "façade"
respecter les règles spécifiques au C (pas de surcharge de fonctions, entre autres) pour tes éléments extern C
j'oublie sans doute un ou l'autre conseil :P

ta DLL, compilée à l'aide d'un compilateur C++ devrait effectivement pouvoir servir pour une application développée en C.

Et le mieux de tout, c'est que tu devrais même, du coup, pouvoir envisager de l'utiliser en java ou en C# par exemple :D
Bonjour, et un grand merci pour ta réponse !
C'est beaucoup plus clair tout d'un coup :D

Si je comprends bien, le fait que je développe avec syntaxe C++ dans ma DLL C++, cela n'a pas d'importance une fois compilé, il mangera mes vector<string> et compagnie.
Je dois par contre créer un point d'entrée de cette DLL en "extern c" afin que, depuis mon main.c, je puisse l'appeler.
Ce qui m'intéresse dans la fonction Update de ma DLL, c'est de pouvoir récupérer le vector<float> que ma fonction remplit, il faut donc que je puisse pointer ce vecteur depuis mon fichier C en créant une nouvelle fonction C qui va récupérer ce vecteur.

Mon fichier C charge dynamiquement ma DLL C++ (les pointeurs de fonctions ne sont pas nuls) et je peux appeler les fonctions chargés avec du GetProcAdress.
Me reste plus qu'à récupérer la sortie de ces fonctions (vector<string> et vector<float>) ... une autre paire de manches mais je m'approche vraiment du résultat !

Encore merci pour ta réponse ! ;)
13/06/2018, 11h48
dalfab

Citation:

Envoyé par tej64

Si je comprends bien, le fait que je développe avec syntaxe C++ dans ma DLL C++, cela n'a pas d'importance une fois compilé, il mangera mes vector<string> et compagnie.

Le C ne peut pas comprendre un objet vector ni un objet string aucun des deux ne respecte les préconisations indiquées par Koala01

Citation:

Envoyé par tej64

Je dois par contre créer un point d'entrée de cette DLL en "extern c" afin que, depuis mon main.c, je puisse l'appeler.

Le C ne peut normalement appeler que des fonctions "extern C".

Citation:

Envoyé par tej64

Ce qui m'intéresse dans la fonction Update de ma DLL, c'est de pouvoir récupérer le vector<float> que ma fonction remplit, il faut donc que je puisse pointer ce vecteur depuis mon fichier C en créant une nouvelle fonction C qui va récupérer ce vecteur.

En aucun cas un code C ne pourra utiliser le vector<float>. Le code C++ peut par exemple transmettre les valeurs de vector<float>::data() et vector<float>::size() sous la forme de const float* et size_t pour permettre au code C de lire les données.
13/06/2018, 15h03
koala01

Citation:

Envoyé par dalfab

vector<float>::size() sous la forme de const float* et size_t pour permettre au code C de lire les données.

Et il faut surtout s'assurer que toutes les modifications (principalement les ajouts et les suppressions d'éléments) apportées au niveau de ton std::vector soient prise en charge par des fonction extern "C" (ce qui risque d'être un peu plus dur :P)

En gros, ton applicatin C peut parcourir les éléments que contient ton tableau. Dans une certaine mesure, elle peut envisager de modifier ces éléments (passer un double de 3.1415 à 21.6, par exemple), mais tout ce qui aura pour résultat de modifier le nombre d'éléments de ton tableau ne pourra être pris en charge que par ta dll ;)

Dans le main.cpp il faut rajouter ceci :

Code:

1
2
3
4
5
6
7
 
typedef const char * const_str_ptr;
extern "C"
{
    const float *get_float_vector(int *size);
    const_str_ptr *get_string_vector(int *size);
}

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
 
const float *get_float_vector(int *size)
{
   const std::vector<float> &v = VecteurDeFloat;
 
   *size = v.size();
   return &v[0];
}
 
const_str_ptr* get_string_vector(int *size)
{
  const std::vector<std::string> &v = VecteurDeString;
  *size = v.size();
  const_str_ptr *rval = (const_str_ptr*)malloc(*size * sizeof(const_str_ptr));
  for (int i=0;i<*size;i++)
  {
      rval[i] = v[i].c_str();
  }
  return rval;
}

Pour qu'en C on puisse charger la DLL C++ et écrire :

Code:

1
2
3
 
PointeurConstFloatGetValueVector = (TypePointeurConstFloat)GetProcAddress(dllLib, "get_float_vector" );
PointeurConstStrPtrGetStringVector = (TypePointeurConstStrPtr)GetProcAddress(dllLib, "get_string_vector" );

Et on récupère en C, les vecteurs de float et de string comme suit (dans float_array et string_array) :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
 
     int taille;
     const float *float_array = PointeurConstFloatGetValueVector(&taille);
     int i;
     for (i=0;i<taille;i++)
      {
         printf("%d %f\n",i,int_array[i]);
      }
 
    const_str_ptr* string_array = PointeurConstStrPtrGetStringVector(&taille);
 
    for (i=0;i<taille;i++)
      {
         printf("%d %s\n",i,string_array[i]);
      }
 
 
    free(string_array);

Sujet résolu merci à bientôt !

1 pièce(s) jointe(s)

Citation:
Envoyé par tej64
Dans le main.cpp il faut rajouter ceci :
Code:

1 2 3 4 5 6 7 typedef const char * const_str_ptr; extern "C" { const float *get_float_vector(int *size); const_str_ptr *get_string_vector(int *size); }
Code:

1 2 3 4 5 6 7 8 const float *get_float_vector(int *size) { const std::vector<float> &v = VecteurDeFloat; *size = v.size(); return &v[0]; }
Et tu vas te retrouver avec une belle erreur de fragmentation à la première utilisation, à moins que VecteurDeFloat ne soit une variable globale, ce qui n'est jamais bon :P:furax::furieux:

Et si c'est effectivement une variable globale, tu peux te contenter d'un
Code:

1 2 3 4 5 6 const float *get_float_vector(int *size) { *size = VecteurDeFloat.size(); return VecteurDeFloatv[0]; }
qui aura exactement le même effet ;)
Citation:
Envoyé par tej64
Code:

1 2 3 4 5 6 7 8 9 10 11 const_str_ptr* get_string_vector(int *size) { const std::vector<std::string> &v = VecteurDeString; *size = v.size(); const_str_ptr *rval = (const_str_ptr*)malloc(*size * sizeof(const_str_ptr)); for (int i=0;i<*size;i++) { rval[i] = v[i].c_str(); } return rval; }
A priori, tu ne devrais jamais avoir besoin de récupérer un tableau (C style) de chaines de caractères C style :

Il faut en effet se rendre compte que, a priori, une classe en C++ devrait être pensée en termes de services rendus et non en termes d'éléments qu'elle contient. Surtout lorsque c'est pour l'exporter au travers d'une DLL, et à plus forte raison si cette DLL doit être utilisable en C.

Les données qui composent nos classe ne sont -- au final -- que des "détails d'implémentation" qui permettent à notre classe de rendre les services que l'on attend de sa part et dont l'utilisateur (de la classe) n'a absolument aucun besoin de connaitre l'existence.

En cela, les accesseurs (getXXX, getYYY), par exemple, peuvent éventuellement correspondre à des services que l'on est en droit d'attendre d'une de nos classes, mais les mutateurs (setXXX, setYYY) n'ont absolument rien à faire là ;)

Les choses sont encore plus compliquées lorsque notre classe maintient "une collection" (que ce soit un tableau, une liste ou quoi que ce soit d'autre) "d'éléments" (quel que puisse en être le type) pour pouvoir rendre certains services.

Il se peut, à ce moment là, que l'on attende de la part de notre classe qu'elle nous fournisse des services comme:

connaitre le nombre d'éléments que la collection contient (savoir si elle est vide :question:)
parcourir l'ensemble des éléments (à fin de modification et / ou d'interrogation uniquement)
ajouter un élément
supprimer un élément donné
accéder à un élément seron un critère donné
...

Mais nous ne devrions jamais vouloir accéder à la collection directement (un accesseur du genre de getMyVector n'ayant en définitive absolument aucun sens ;) )

Et les fonctions extern "C" ne devraient servir au développeur C qu'à faire appel aux différents services exposés par tes différentes classes

N'oublie pas que ta dll doit être une "boîte noire", un peu comme cet appareil :Pièce jointe 388445

On dispose de différents cadrans et voyants qui nous permettent de connaitre l'état de l'appareil (c'est un appareil CB, pour ceux qui se poseraient la question :D ) et de différents boutons qui nous permettent d'agir sur cet état, et dont les sérigraphies nous indiquent l'effet qu'ils auront.

Mais si je pourrais sans aucun problème t'expliquer à quoi servent ces boutons et ces voyants, je serais bien incapable de t'expliquer leur impact sur l'électronique qui compose l'appareil : en tant qu'utilisateur, tout ce que j'ai besoin de savoir m'est fourni par la... façade de l'appareil.

Ta DLL doit agir exactement de la même manière, malgré le fait que ce qu'elle manipule en interne ne soient en définitive que des données qui sont forcément abstraites :D

14/06/2018, 08h51
tej64

En fait mon programme C++ décode des trames arrivant sur différents ports UDP définis dans un fichier de configuration, à chaque mise à jour de mon objet Décodeur, une callback de décodage est appelé et le tableau DECODER->VarValue[] se remplit (car les variables arrivent sur des ports différents). Ce vecteur de float se remplit à pleins d'endroits différents, mais je dois le récupérer en C pour un certain besoin.
Franchement je ne vois pas comment récupérer ce tableau à part avec la méthode que j'ai fournie.

Donc oui ma DLL C++ est faite à base de classes et objets, et j'ai deux points d'entrées qui sont l'init (création des objets Decoder, PortUDP etc ...) et la fonction Update qui fait un receivePort de chaque objet.
Mon main.c doit charger la DLL et récupérer à chaque update mon vecteur Decoder->VarValue. Il me fallait donc un accesseur.

Certains ingénieurs de ma boite me conseillait de refaire mon décodeur en C, ce qui est une énorme connerie et une perte de temps. Il me suffisait d'utiliser mon décodeur déjà fonctionnel en C++ et de le compiler en DLL pour accéder aux données qui m'intéressent.

Autrement je suis d'accord avec toi, ce sont peut être des pratiques qui ne se font pas, mais comment récupérer ces vecteurs autrement que comme ça depuis mon main.C ?

En tout cas tout fonctionne correctement sans erreur, et j'ai mis le code pour aider certaines personnes qui seraient dans le même cas que moi.
Le sujet est résolu.

Citation:

Envoyé par tej64

Mon main.c doit charger la DLL et récupérer à chaque update mon vecteur Decoder->VarValue. Il me fallait donc un accesseur.

non, il te faut une fonction
Code:

1 2 3 4 5 extern "C"{ size_t count(); /* ou ou ou */ bool empty(); }
pour savoir si tu peux récupérer les données et une fonction
Code:

1 2 3 4 5 extern "C"{ double getValue(); /* OU OU , selon le cas */ double getValue(size_t index); }
pour récupérer les données une à une.

Les deux fonctions pouvant alors être utilisées sous une forme proche de
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 int main(){ /* ... */ while(! empty()){ double d = getValue(); /* ... */ } /* OU OU */ size_t c = count(); for(size_t i = 0; i<c;++i){ double d = getValue(i); \ }
Parce que tu ne dois en AUCUN CAS exposer à l'extérieur de ta dll la manière dont tes données sont stockées à l'intérieure de ta dll ;)

(note d'ailleurs que, même en C++, l'interface de ton décodeur doit en dire le moins possible sur la manière dont les doubles sont gérés en interne: les deux fonctions extern "C" dont j'ai parlé pourraient parfaitement avoir leur équivalent sous la forme de fonction membre de ton décodeur ;) )

Citation:

Certains ingénieurs de ma boite me conseillait de refaire mon décodeur en C, ce qui est une énorme connerie et une perte de temps.

Sans doute parce qu'ils sont plus à l'aise avec le C qu'avec le C++

Citation:

Il me suffisait d'utiliser mon décodeur déjà fonctionnel en C++ et de le compiler en DLL pour accéder aux données qui m'intéressent.

En effet, réinventer la roue est toujours une perte de temps ;)

Citation:

Autrement je suis d'accord avec toi, ce sont peut être des pratiques qui ne se font pas, mais comment récupérer ces vecteurs autrement que comme ça depuis mon main.C ?

Tu ne permet pas à l'utilisateur de ta dll de récupérer un tableau!!! Tu lui permet de récupérer... les éléments du tableaux, un à un. A charge pour lui de le faire correctement et de les stocker de la manière qui lui convient.

Ton job, en tant que développeur de la bibliothèque, c'est de t'assurer que l'utilisateur de ta bibliothèque dispose de tout "ce qu'il faut" pour pouvoir le faire correctement et facilement (et pour lui éviter la tentation d'utiliser ta biblitothèque de manière incorrecte :D )

19/09/2018, 15h18
bacelar

Remarque à 2 balles : l'usage de "GetProcAddress" est obsolète.
C'est bien plus simple d'utiliser un .h et la lib associée à la Dll.

P.S.: @koala01 a tout à fait raison et @tej64 va directement dans le mur.
19/09/2018, 15h23
tej64

En effet ta remarque vaut 2 balles.
Et pour mon besoin, cela fonctionne tout à fait, je te remercie mais je ne vais pas dans le mur.

Si t'as pas autre chose à foutre que de déterrer un sujet résolu, tu peux toujours aller voir y ailleurs si j'y suis.

Cordialement
19/09/2018, 19h03
bacelar

Il est peut-être "résolu" pour toi, mais je pense plus au pauvre esseulé qui cherche de vraies bonnes solutions et qui ne veut pas se prendre TON mur.

A+, centre du monde.
19/09/2018, 21h26
koala01

Citation:

Envoyé par tej64

En effet ta remarque vaut 2 balles.

Aucune remarque ne vaut vraiment plus de deux balles, si on considère le temps nécessaire à les rédiger ;)

Seulement, la plupart des remarques que pourront te faire les membre compétents qui passent sur ce forum (et crois moi: tu en croisera pas mal par ici ;) )seront jouées à la roulettes et rapporteront systématiquement 36 fois la mise ;)

En efficacité et/ou en facilité, si tu décides d'en tenir compte, ou en emmerdes, si tu décides de ne pas le faire. A toi de choisir le genre de gain que tu préfères. Nous, nous ne pouvons de toutes manières te forcer à rien ;)

Citation:

Envoyé par tej64

Et pour mon besoin, cela fonctionne tout à fait, je te remercie mais je ne vais pas dans le mur.

Oh là là... Si tu savais comme j'ai appris à me méfier de ce genre de phrase (la première partie surtout)!!!

Car l'expérience ma appris que "ca fonctionne", ca tourne régulièrement à "c'est la cata" dés que l'on essaye d'apporter la moindre modification

Si bien que, malgré le fait que je ne voudrais pas briser tes illusions, je t'avouerai avoir un très sérieux doute sur la deuxième partie de ton affirmation ;)

Citation:

Si t'as pas autre chose à foutre que de déterrer un sujet résolu, tu peux toujours aller voir y ailleurs si j'y suis.

De quoi te plains tu:question: ce sujet n'a que trois mois...

Si quelqu'un peut engueuler l'autre, ce serait plutôt moi, car tu n'as jamais pris la peine de répondre à mon intervention ;)