Passage C->C++ : Différences de performances et de résultat

Salut les gens, je savais pas trop ou poster ca, mais votre débat me fait penser à ce qui m'arrive en ce moment :

J'ai developpé un petit logiciel de traitement d'image, en C.
Le traitement était trés long, mais le taux de réussite d'environ 80%

Je l'ai passé en Cpp (sans changer mes fonctions C) pour des raisons externes, et cela à eu pour conséquence tout à fait innatendue de rendre mon traitement 4 fois plus rapide environ, mais avec un taux de réussite moindre ! (environ 50%)

Alors bon première réaction = "l'informatique est définitivement pas une science exacte", mais deuxième réaction = "Bah ouais définitivement ca me dégoute :("

Avez vous deja connu ce genre de situation ?

(Vraiment, fonctions en tout point similaires, je n'ai fait que passer mes .c en .cpp, à quelques warnings prés)

Un taux de réussite à 50%, il y a forcement des bugs dans ton application...

Non.
L'objectif du traitement est de détecter dans un deuxieme temps quelque chose de précis sur l'image (je ne peux pas en parler plus précisément désolé), et c'est de ce taux de réussite la que je parle (sachant que la banque de données d'image dont je dispose possede les cas les plus difficiles, 80% est un trés bon résultat).

La n'est pas le sujet de toute facon.

Je suis vraiment intrigué par cet écart impressionant entre les deux versions, et bon, c'est pas la première fois que l'informatique est non détérministe, donc j'aimerais savoir si quelqu'un à déjà connu ca.

J'ai beaucoup de mal a croire que le langage soit un facteur significatif dans ton histoire: tu as vraisemblablement change d'algo en meme temps et c'est ca qui explique ta chute dans le taux de reussite.

Citation:

---

Envoyé par Jean-Marc.Bourguet

J'ai beaucoup de mal a croire que le langage soit un facteur significatif dans ton histoire: tu as vraisemblablement change d'algo en meme temps et c'est ca qui explique ta chute dans le taux de reussite.

---

et dans l'augmentation de la vitesse..

Il est impossible (même avec des traitements de chaînes de caractères) de diminuer un temps de calcul de 75% en passant de C à C++....

@skip78 :

soit tu n'as pas fait que "Vraiment, fonctions en tout point similaires, je n'ai fait que passer mes .c en .cpp, à quelques warnings prés", soit tu avais des structures et constructions aberrantes en C... (je soupçonne une "simili-construction C++" en C..., ou plus précisément un programme C fait par quelqu'un qui ne possède que les paradigmes objets, ou alors qui est débutant)

Citation:

---

Envoyé par skip78

(Vraiment, fonctions en tout point similaires, je n'ai fait que passer mes .c en .cpp, à quelques warnings prés)

---

Est-ce que tes routines de traitement d'images appellent des fonctions mathématiques ?( je suppose évidemment que oui surtout si c'est du traitement d'image )
Cela dépend de la manière dont sont implémentées ces fonctions selon le langage en C ou en C++ l'implémentation au niveau bibliothèque de code.
Si tu veux plus t'en rendre compte je te conseille de t'initier à l'assembleur et de tracer en assembleur pour voir comment le code a été compilé selon la version..
il se peut que dans un cas les bibliothèques fassent appellent à une émulation logicielle des fonctions mathématiques ( sin,cos....) et dans l'autre par des calculs avec des instructions assembleur implicites i386/i387.
Pour faire plus clair dans une version le compilo il voit sin( telle_valeur) il fait l'édition des liens avec une routine de code qui émule sin().
Dans l'autre cas il compile directement en code assembleur l'instruction i386 correspondante..
Tout cela tu le verras si tu traces directement dans le code assembleur..
Il y aussi les astuces de mise sur le registre de pile avec des push et pop assembleur comment le compilateur fait cela.


une suggestion de lecture que je ressorts à chaque fois :mouarf:
http://msdn.microsoft.com/en-us/libr...69(VS.60).aspx

Citation:

---

Envoyé par souviron34

et dans l'augmentation de la vitesse.

---

Il est vraisemblable qu'elle soit due a cela aussi.

Citation:

---

Il est impossible (même avec des traitements de chaînes de caractères) de diminuer un temps de calcul de 75% en passant de C à C++....

---

Je n'utiliserais pas le mot "impossible". J'imagine assez bien un tel rapport pour des operations particulieres, suite a de l'inlining autorise par une implementation a base de template plutot que l'utilisation de pointeurs sur fonctions (genre un tri avec une fonction de comparaison sur un type de base, avec qsort() fait une indirection a chaque comparaison, std::sort() peut inliner facilement). Mais les cas doivent etre relativement rares.

Citation:

---

Envoyé par Jean-Marc.Bourguet

Je n'utiliserais pas le mot "impossible".

---

admettons, je ne me battrais pas là-dessus ;)

Citation:

---

Envoyé par Mat.M

...
il se peut que dans un cas les bibliothèques fassent appellent à une émulation logicielle des fonctions mathématiques ( sin,cos....) et dans l'autre par des calculs avec des instructions assembleur implicites i386/i387.
...

---

M'étonnerais fortement (ou alors par volonté délibérée de privilégier un langage) que les bibliothèques de maths soit si différentes que ça... avec le même compilo, la même machine, le même OS, le même IDE...


M'enfin, rien n'est hors de portée de M$ en ce qui concerne les coups tordus.. ;)

Citation:

---

Envoyé par Jean-Marc.Bourguet

J'ai beaucoup de mal a croire que le langage soit un facteur significatif dans ton histoire: tu as vraisemblablement change d'algo en meme temps et c'est ca qui explique ta chute dans le taux de reussite.

---

Moi aussi j'ai beaucoup, mais alors vraiment BEAUCOUP de mal à y croire, et c'est pour ca que je me permet de poster ceci ici, je savais que j'aurais pas mal de réactions, et je suis maintenant servi :)

Citation:

---

Envoyé par souviron34

soit tu n'as pas fait que "Vraiment, fonctions en tout point similaires, je n'ai fait que passer mes .c en .cpp, à quelques warnings prés", soit tu avais des structures et constructions aberrantes en C... (je soupçonne une "simili-construction C++" en C..., ou plus précisément un programme C fait par quelqu'un qui ne possède que les paradigmes objets, ou alors qui est débutant)

---

Bah j'ai pas grand interet à mentir n'est ce pas ;)
J'ai absolument rien changé.
Pour ce qui est des structures et constructions aberrantes en C, mdr
je vois pas comment je pourrais être aberrant à ce point, mais ca proviens peut être de là :

Mon interface graphique utilise GTK+, et pour retrouver tous mes arguments au fil des callbacks, et éviter les statics, j'ai tout foutu dans une structure globale.

C'est plutot commun en GTK, mais bon peut être que ca peut venir de la ?

De plus le GTK+ utilise une "pseudo structure objet", comme tu dis, mais bon c'est cencé fonctionner en C++.


Je tiens tout de même à préciser que le programme fonctionne à la perfection malgrès les écarts de résultats.

C'est ce qui me fait penser que mon code d'origine est pas si mauvais ...

Mais si quelqu'un peut m'affirmer à 100% que la différence de vitesse ne peut PAS être due au changement de language, c'est que c'est du au fait que mon passage en Cpp est mauvais non ?

Pourtant je vous le répète, je n'ai pas changé une ligne de code, j'ai juste un programme en C dans des fonctions .cpp
Cela ayant pour but d'inclure une lib en cpp.

Enfin voilou de mon coté je tente de repasser tout ca en C malgrès tout, dans l'hypothèse ou c'est effectivement la conception de mon programme qui est foireuse.

Citation:

---

Envoyé par skip78

mais ca proviens peut être de là :

Mon interface graphique utilise GTK+, et pour retrouver tous mes arguments au fil des callbacks, et éviter les statics, j'ai tout foutu dans une structure globale.

C'est plutot commun en GTK, mais bon peut être que ca peut venir de la ?

---

ben ça c'est classique... et à priori ça ne viendrait pas de là..

Et utilises-tu GTK+ dans les 2 langages ?

Sinon, pourquoi transformer tout un programme pour utiliser une biblothèque ?? une API spécifique aurait suffi...

Oui Gtk+ dans les deux.

Je viens de faire une série de tests, c'est vraiment étrange.

Pour certains panels d'image j'ai de meilleurs résultats en C, pour d'autres de meilleurs résultats en Cpp.

Bon sans trop pouvoir rentrer dans les détails, je ne travaille pas seul, et je reçois plusieurs librairies à tester. Au départ j'ai fait mon programme en C pour qu'il soit le plus portable possible, mais la plupart des libs sont en Cpp, donc bon vu que le C est supposé fonctionner en C++, je me suis dis pourquoi ne pas faire un copier collé tout con.

Et la les ennuis ont commencés.

P.S. J'ai besoin d'aller chercher des variables et manipuler les fonctions des libs à tester, donc je suis obligé de les intégrer convenablement.

Cela étant dit c'est peut être la librairie sur laquelle je travaille actuellement qui à mal été transcrite du Cpp vers le C.
Même si l'opération semblait simplissime, y'avait du extern C un peu partout si je me souviens bien, donc c'est pas dit que y'ai une couille dans le potage.

Bref je sais toujours pas à quoi c'est du, et surtout je ne sais que choisir entre la version plus stable mais plus lente de C ou la version rapide et parfois plus précise C++.

Etant donné mes difficultés à comprendre la situation, je pense revenir en C, mais bon c'est tout de même bien dommage ...

En tout cas bonne soirée à tous, et bon courage si vous taffez :)

:dehors:

Citation:

---

Envoyé par skip78

Bon sans trop pouvoir rentrer dans les détails, je ne travaille pas seul, et je reçois plusieurs librairies à tester. Au départ j'ai fait mon programme en C pour qu'il soit le plus portable possible, mais la plupart des libs sont en Cpp, donc bon vu que le C est supposé fonctionner en C++, je me suis dis pourquoi ne pas faire un copier collé tout con.

---

Déjà cette supposition là est fausse. C et C++ partage une ensemble commun important qui couvre en fait une grande partie du C. Mais C n'est pas intégralement inclus dans le C++. De fait, même du code syntaxiquement correct dans les deux langages peut avoir un comportement légèrement différent entre les deux langages.

Maintenant est ce la source de la différence observé ? Difficile à dire à priori, mais cela me semble assez peu probable.

Citation:

---

Envoyé par skip78

Oui Gtk+ dans les deux.

Je viens de faire une série de tests, c'est vraiment étrange.

Pour certains panels d'image j'ai de meilleurs résultats en C, pour d'autres de meilleurs résultats en Cpp.

---

Cela change tout !! Tu n'avais précisé que tu utilisais Gtk+ ! 8O
En général les frameworks utilisent des threads internes une sorte de scheduler.
Si tu prends les sources de MFC donc une bibliothèque semblable à Gtk+ à l'initialisation du framework tu as des threads ou des events qui sont lancés ce qui fait que MFC peut-être parfois plus lent qu'un programme directement fait en win32.
Mais là n'est pas la seule explication ; si tu as un framework comme Gtk+ eh bien...tu as la gestion des exceptions par derrière ce qui risque de nuire aux performances du programme ( un peu comme le Garbage Collector en Java :mouarf: mais il y a déjà 50 pages de fil de discussion à ce sujet :aie: )
Alors comment peut s'expliquer une telle différence entre C et C++ ? Eh bien c'est qu'à l'édition des liens, lier Gtk+ peut se faire différemment... selon le langage.
Il ne faut pas perdre de vue que la compilation en C++ demande plus de mémoire que le C..

Je te conseillerais pour de meilleurs performances d'isoler les traitements et calculs de la gestion de l'interface utilisateur.
En d'autres termes si par exemple tu est sous Windows de faire une dll qu'importe que cela soit en C ou C++ pourvu que les classes soient simples pour les calculs et l'interface utilisateur avec Gtk

Citation:

---

Envoyé par skip78

Mais si quelqu'un peut m'affirmer à 100% que la différence de vitesse ne peut PAS être due au changement de language, c'est que c'est du au fait que mon passage en Cpp est mauvais non ?

Pourtant je vous le répète, je n'ai pas changé une ligne de code, j'ai juste un programme en C dans des fonctions .cpp
Cela ayant pour but d'inclure une lib en cpp.

---

Oui mais l'édition des liens est radicalement différentes entre sources C et sources CPP !
En c++ c'est infiniment plus complexe pour le compilateur cela va de soi qu'en C.
Le compilateur à partir du C++ pour faire des fichiers objets doit obéir à bien plus de règles qu'à partir du C.

Si tu as des différences de performances alors que tu n'as fait que des copier-coller des explications possibles seraient
-en C++ il y a un mécanisme de gestion des exceptions supplémentaires qui se met en route
en C il n'y a rien cela donne un beau "violation access" :mouarf:
-en C++ il y aussi des trucs comme le Run-time Type Information ( RTTI )
On peut le paramêtrer ou non...

Citation:

---

Envoyé par skip78

Etant donné mes difficultés à comprendre la situation, je pense revenir en C, mais bon c'est tout de même bien dommage ...
En tout cas bonne soirée à tous, et bon courage si vous taffez :)

---

Tout dépend si tu veux avoir recours à la programmation objet c'est évident..
si tu sents le besoin d'avoir du code modulable et réutilisable vaut mieux faire du code C++.
Mais encore une fois je conseille vivement de séparer le code pour les calculs et le traitement de l'image pur du reste du projet et notamment de l'interface utilisateur.
Sinon tu devrais avoir recours à des techniques plus avancées comme la programmation multithreading.
Mais pour ce qui est des performances pures je suis sceptique je ne pense pas qu'il y en ait autant entre un code en C et un code en C++ c'est kif kif

Je veux bien comprendre des grosses différences de performances, par contre des résultats différents c'est étonnant. Utilises-tu un algorithme probabiliste?

Citation:

---

Envoyé par Mat.M

Il ne faut pas perdre de vue que la compilation en C++ demande plus de mémoire que le C..

---

C'est ce que je me disais avant cet incident :)
Mais là c'est le C++ qui est 4 fois plus rapide que le C ;)


Pour ce qui est de séparer l'interface Graphique du reste, c'est compliqué, voir impossible, car le rôle principal de mon apli (le rôle secondaire étant d'afficher les résultats) est d'aller chercher l'info dans la lib de traitement d'image étudiée et de changer les widgets en conséquence (affichage texte/graphique, gestion des filtres ...)

L'idée est donc bonne, mais je pense pas que ca soit jouable.



Sinon ca me fait plaisir de lire des commentaires tels que "Je suis quand même vraiment sceptique ..."

Vous savez je n'y crois toujours pas à ce truc, c'est juste dingue, mais c'est pourtant vrai.



Bon et puis j'ai tout repassé en C pour voir, c'est définitivement plus stable, mais biiiiiiiiien plus lent :(

Sick'

P.S. non pas d'algo probabiliste ;) juste des calculs de moyenne, de diférentielles, de dérivées directionelles...

Je pense que tu appelles certaines fonctions sans respecter leur préconditions, et que donc, les comportements "à la marge" sont différents entre C et C++. Voire, tu as assumé que certaines équivalences C/C++ étaient vraies, alors qu'elles ne le sont pas tout à fait (code de retour différents, comportements différents).

C++ quatre fois plus rapide que C, ça veut dire que le code C était mauvais (ie, qu'on peut beaucoup l'optimiser), ou que le code C++ ne fait plus un traitement que le code C faisait.

Tu parles de "tout repasser en C", mais si tu compiles ton code C avec g++, il devrait compiler et tu devrais avoir le même comportement qu'avec gcc.

Je me doute que tu ne peux pas poster les deux codes ici, mais néanmoins, pourrais-tu détailler un peu plus ce que tu entends par "passer de C à C++" (par exemple, remplacer les tableaux par des vector, etc...)

L'informatique, c'est en général déterministe, et quand ça ne l'est pas, c'est souvent un bug.

J'ai peut être sauté un post mais il me semble que tu n'a pas précisé le compilateur que tu as utilisé pour le C et le C++. Et les options que tu as activé pour l'un puis pour l'autre.

Citation:

---

Envoyé par skip78

P.S. J'ai besoin d'aller chercher des variables et manipuler les fonctions des libs à tester, donc je suis obligé de les intégrer convenablement.

---

ça, c'est uniquement un problème de commnication entre appels, et ça se fait via des API ... (du style jni pour Java). Pas besoin de tout réécrire...

Citation:

---

Envoyé par Mat.M

Je te conseillerais pour de meilleurs performances d'isoler les traitements et calculs de la gestion de l'interface utilisateur.

---

:king: +1000

Citation:

---

Envoyé par Mat.M

si tu sents le besoin d'avoir du code modulable et réutilisable vaut mieux faire du code C++.

---

beeeppp !!!!

Biais éhonté... ;)

Il n'y a aucune raison que ce ne soit pas en C...

Citation:

---

Envoyé par skip78

Bon et puis j'ai tout repassé en C pour voir, c'est définitivement plus stable, mais biiiiiiiiien plus lent :(

---

Définitivement un bug....

Citation:

---

Envoyé par white_tentacle

C++ quatre fois plus rapide que C, ça veut dire que le code C était mauvais (ie, qu'on peut beaucoup l'optimiser), ou que le code C++ ne fait plus un traitement que le code C faisait.
...
L'informatique, c'est en général déterministe, et quand ça ne l'est pas, c'est souvent un bug.

---

:king:

Citation:

---

Envoyé par white_tentacle

Je me doute que tu ne peux pas poster les deux codes ici, mais néanmoins, pourrais-tu détailler un peu plus ce que tu entends par "passer de C à C++" (par exemple, remplacer les tableaux par des vector, etc...)

---

Vraiment rien changé. Je l'ai déjà dit plus haut.
---------------------------------------------

Bon bah grace à vos messages et à ma réaction d'orgeuil, j'ai cérné le problème.

Ca n'est pas mon apli GTK+, ni mes filtres, qui sont en cause (non mais alors :yaisse2:)

C'est effectivement (j'y pensais hier soir, mais je n'avais pas effectué les tests) la lib que je teste qui à mal supportée la conversion en C.

En fait, pour être plus précis, je teste un .lib dont la quasi totalité des fonctions sont en C. Seul l'appel des premières fonctions se fait en C++.

Au départ, mon programme étant en C, je ne pouvais linker la lib à cause de ce court passage en C++. J'ai donc demandé à ce qu'on me file la lib en C.

Chose faite un peu plus tard => linkage réussi.

Et dans mon programme en C++, j'ai repris la première lib, celle ou l'appel est en C++.


Et la, en court circuitant les appels en question, j'obtiens des vitesses d'éxécution quasi similaires en C et en C++
(0.3 secs / img lors de la première execution et 0.21 secs / img aux traitements suivants (la difference s'expliquant bien entendu par les créations de widgets) en C++ vs 0.28 et 0.21 en C )

Cela étant dit, les .lib et .dll que je teste (C et C++) possedent effectivement 3 fonctions d'appel qui différent, mais 6500 lignes de code communes ....

Donc wtf ? :mouarf:


P.S. certains me parlaient de moyens d'integrer la lib .cpp dans mon programme en C ?

Je suis preneur dans les deux sens ;) (C vers C++ aussi)

Citation:

---

Cela étant dit, les .lib et .dll que je teste (C et C++) possedent effectivement 3 fonctions d'appel qui différent, mais 6500 lignes de code communes ....

Donc wtf ?

---

Sans code, difficile de dire quoi que ce soit. Deux options :
- le bug est dans le code différent --> facile à vérifier
- le bug est un comportement indéfini qui est différent en C et C++ --> là t'es dans la merde :).

J'imagine que tu peux réclamer le code source de la lib, les infos de debug. Isole une image ou le "code C" marche, le "code C++" marche pas, et joue avec le pas à pas du debugger.

Sinon, tape sur les doigts du fournisseur de ta lib, à priori, le bug serait chez lui.

Je pense que tu devrais dupliquer le code compilé, fonction par fonction
et a chaque appel de fonction en C++ vérifier que la fonction C avec les mêmes parametres donne le même résultat
lorsque tu es sur que la premiere fonction fonctionne, porte la deuxieme
etc etc

6500 lignes de code c'est pas trop lourd.

Citation:

---

Envoyé par skip78

P.S. certains me parlaient de moyens d'integrer la lib .cpp dans mon programme en C ?

Je suis preneur dans les deux sens ;) (C vers C++ aussi)

---

Il faudrait connaître les spécificités de C++ utilisées..

Dans le sens C vers C++, c'est direct pour tout ce qui est calcul, allocations, structures, globales, etc.. Ensuite, on peut transformer des tableaux en std::list.. Pour le reste, je ne suis que "débutant" en C++.

Dans le sens C++ vers C, il faudrait voir...

Citation:

---

Envoyé par screetch

Je pense que tu devrais dupliquer le code compilé, fonction par fonction
et a chaque appel de fonction en C++ vérifier que la fonction C avec les mêmes parametres donne le même résultat
lorsque tu es sur que la premiere fonction fonctionne, porte la deuxieme
etc etc

6500 lignes de code c'est pas trop lourd.

---

C'est ce que je fais principalement dans mon programme en fait :
Le principe de base de mon appli est de tester et corriger les libs soumises.

=> Une premiere fois j'appelle la fonction de traitement de la lib en question, qui me retourne un résultat, que j'affiche.

=> Si l'utilisateur le demande, il peut entrer pas à pas dans le traitement généré par la lib => pour cela, j'ai porté toutes les fonctions une par une.

Mais cela ne peux pas aider pour le C++ vs C car toutes les fonctions sont en C.

Encore une fois, seul l'appel change, c'est la que ca reste super surprenant.
Enfin bon, j'en parlerais au responsable dès qu'il sera dans le coin :evilred:

Par contre, pour que je puisse poursuivre, je vais rester en C, importer la lib C, qui (je viens de faire une simulation grande echelle) obtient définitivement de meilleurs résultats (82 vs 49 % même si sur certains dossiers, c'est invérsé ... lol) et puis me démerder pour importer les nouvelles libs C++ (je vais les porter en C je pense, bien relou, mais bon faut ce qu'il faut, et puis ca fait bien 1 an que j'ai pas touché au C++ :))
Enfin, au final ce qu'il me faudrait c'est pouvoir importer une lib C dans mon prog Cpp :)

Ah et puis pour la vitesse d'éxécution ... surprise :
Quand je passe pas par Visual (et que j'utilise directement le .exe) c'est 2 fois plus rapide que la version la plus rapide via le compilateur, et ca m'a l'air égal pour les 2 libs ...

Je fais les tests de suite.

edit : => 0.108 en cpp vs 0.112 en c sur un échantillon de 200 images. C'est kif kif :) => Vive la lib C

Citation:

---

Envoyé par skip78

Par contre, pour que je puisse poursuivre, je vais rester en C, importer la lib C, qui (je viens de faire une simulation grande echelle) obtient définitivement de meilleurs résultats (82 vs 49 % même si sur certains dossiers, c'est invérsé ... lol)

---

Fondamentalement, cela indique un bug majeur dans la librairie C++.

Et c'est sans doute pour ça qu'elle va plus vite : elle ne fait pas un truc essentiel que fait la librairie C.. :D

Bon bah en tout cas merci à tous d'avoir réagi, ca m'a permis d'avancer un peu ;)

Et donc par contre, la décision est prise, il faudrait que je puisse intégrer la lib en C à mon programme C++.

=> Comment faire ? :)

Je disposes d'un fichier .lib et d'un fichier .dll, et quand je tente de linker, le compilo me sort une erreur de link extern, exactement comme quand je crée un fichier .cpp dans mon programme en c et que j'essaies d'acceder à une fonction définie et écrite dans le fichier en question.

Citation:

---

Envoyé par skip78

Bon bah en tout cas merci à tous d'avoir réagi, ca m'a permis d'avancer un peu ;)

Et donc par contre, la décision est prise, il faudrait que je puisse intégrer la lib en C à mon programme C++.

=> Comment faire ? :)

Je disposes d'un fichier .lib et d'un fichier .dll, et quand je tente de linker, le compilo me sort une erreur de link extern, exactement comme quand je crée un fichier .cpp dans mon programme en c et que j'essaies d'acceder à une fonction définie et écrite dans le fichier en question.

---

Il ne manquerait pas un extern "C" autour de la declaration de la fonction C que tu appelles?

Bah, si :)
C'est justement quelque chose comme ca lol
Mais le problème c'est que je n'y connais rien.
Et puis la on part du principe que j'ai accès à la librairie en question.

Disons que je ne peux vraiment pas modifier la lib que je veux linker, et donc qu'elle est en .c
Comment la linker à mon programme en cpp ?

(l'erreur précise est la suivante :

Code:

---

1 2 3

1>image_processing.obj : error LNK2019: symbole externe non résolu "char * __cdecl MaFonction(unsigned char *,int,int,int)" (?MaFonction@@YAPADPAEHHH@Z) référencé dans la fonction "char * __cdecl FonctionD_Appel(struct _GtkWidget *)" (?FonctionD_Appel@@YAPADPAU_GtkWidget@@@Z) 1>C:\Users\mobiletag\Desktop\Projet\MonProjet\MonProjet_1.3\Debug\MonProjet_1.3.exe : fatal error LNK1120: 1 externes non résolus

---

extern "C"

Tu dois invoquer des comportements indéfinis à la pelle.
Utilise valgrind pour t'aider à en déboguer certains.