Discussion :

[gege2061]

--- Sujet original : Interface graphique en C ---

Rectification, à présent j'ai quelque chose contre GTK+ : GTK+ semble utiliser à outrance des transtypages sur des pointeurs de fonction.
Autant pour les structures en C on peut comprendre, autant pour les pointeurs de fonction c'est la porte ouverte à tous les problèmes, et j'ai déjà vu ici un problème dû à ça.

--> Faire une croix dessus.


PS: De plus, pour les structures, j'aurais donné deux macros séparées pour l'upcast et le downcast, mais là, c'est l'amateur de "compatibilité C++" qui parle.

Tu pourrais expliquer un peu ? T'as un exemple ?

[Médinoc]

J'avais un exemple ici même à developpez.net, mais je ne le retrouve plus.

Il y avait une fonction appelant en boucle un callback qui devait retourner une valeur booléenne (true pour continuer la boucle).
Il a fallu que j'aille moi-même consulter l'aide sur un site Web pour le découvrir, alors que notre pauvre forumeur désemparé avait déclaré sa fonction comme retournant void.

Résultat, selon la dernière fonction appelée/dernière opération effectuée, la "fonction" retournait soit 0/FALSE en code normal, soit une valeur non-nulle (TRUE) quand il s'adonnait au printf()-debugging...
Ainsi, son code foirait "en Release" et pas "en Debug" (entre guillemets car je ne crois pas qu'il utilisait Visual), alors c'était vraiment PITA pour trouver l'origine du problème...

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Un autre problème est souvent rencontré sous Windows, lorsque certains utilisent encore un ancien prototype datant de Win16 pour une WindowProc:

Code Horrible et vieux :

Sélectionner tout - Visualiser dans une fenêtre à part

LONG FAR PASCAL MaMainProc(HWND hWnd, WORD wMsg, WORD wParam, LONG lParam)

©mon incompétent prof de Système du BTS.

Dans un vrai code, on a ceci:

Code Win32 OK :

Sélectionner tout - Visualiser dans une fenêtre à part

LRESULT CALLBACK ProcDeFenetre(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam);

Sachant que UINT fait 32 bits et que WPARAM et LPARAM correspondent respectivement à UINT_PTR et LONG_PTR, qui font tous les deux 32 ou 64 bits selon la plate-forme.
Quant on sait que du code lit le mot de poids fort du WPARAM, on va droit à la catastrophe.
---> Normalement, le compilateur devrait signaler une erreur là-dessus. Ce qu'il fait, quand il n'y a pas un petit malin (ou un vieux con) pour transtyper systématiquement le pointeur de fonction...

C'est pourquoi selon moi, un pointeur de fonction en C ne doit jamais, au grand jamais, être transtypé.

(en C++, il y a des cas spéciaux pour les pointeurs de fonctions membres non-statiques).

Là chose à retenir, c'est qu'en transtypant un pointeur de fonction, on transtype du même coup tous ses paramètres et sa valeur de retour. Et qu'il s'agit d'un transtypage "à la C" (C-Style cast), c'est-à-dire celui qui permet absolument tout et n'importe quoi (changement de type, de taille, et perte de const).

[Lunixinclar]

<GTK+>Si quelqu'un veut retourner un booleen et déclare sa fonction en void,
alors on peut en déduire qu'il faut faire une croix sur GTK parce que GTK+ semble
utiliser à outrance des transtypages sur des pointeurs de fonction.</GTK+>
L' année commence bien.

[Médinoc]

Si GTK+ n'exigeait pas ainsi des transtypages, le compilo aurait signalé l'erreur, point.

[Lunixinclar]

Oui! C'est à cause du méchant compilo et de son prof qui est complice!

[Médinoc]

Non, c'est la faut des auteurs d'une bibliothèque qui ont été trop fainéants pour définir plusieurs typedefs différents pour leur callbacks.

Tu te fous de ma gueule, mais on voit que tu n'as pas encore eu ce genre de problème. L'élément humain est le plus propice aux erreurs, et une erreur sur le type d'une fonction a des effets plus pervers que d'autres.
Aussi, un bon programmeur prend le minimum de risques...

Surtout pour une bibliothèque...