Appel de fonction à arguments variables - Page 1

Je dois appeller une fonction avec des paramètres, et récuperer son éventuelle valeur de retour.

Supposons que je n'ai à ma disposition qu'un pointeur vers la fonction, et une chaine qui symbolise son type. Pour simplifier, on supposera qu'une fonction ne peut accepter (autant pour sa valeur de retour que pour les paramètres) que 4 types : "void", "unsigned char *", "signed long", et "double", respectivement codés "0", "1", "2" et "3".

Une fonction de cette forme : void print_xy(unsigned char *str, signed long x, signed long y);
Aura donc cette chaine associée : "0122" (0 pour le void, puis le type des paramètres à la suite, donc 112")

On retourne donc au problème, je n'ai que ces deux informations (pointeur et chaine) à ma disposition, et je voudrais appeller la fonction ("str", "x" et "y" sont bien sûr définis). En gros, je suppose qu'il faut passer les arguments "à la main", puisqu'on ne connait pas le prototype de la fonction à la compilation, puis appeller effectivement la fonction, et récuperer sa valeur de retour si il y en a une. C'est possible ?

C'est peut-etre une feature propre a gcc (sux) mais pour un projet qui correspondait un peu a ce que tu demande j'avais un pointeur de type :

typedef void *(*t_genfuncvs)();

qui me permettait de pointer sur les fonctions de tout type, en passant tous les arguments que je voulais (enfin 4 max pour etre sur que ca fasse pas de merde)

heu, oui mais là les arguments sont dans une liste (en gros), donc je peux pas appeller une fonction directement (si c'est bien comme ça que ça doit marcher ?)

en gros, fonc(arg[0],arg[1],arg[2]), impossible, je sais pas cb y'a d'args :/

Je remets ici : libffi (foreign function interface) permet de construire dynamiquement des appels de fonction.

Je n'ai pas trouvé de documentation allant avec, mais le fichier d'en-tête est très simple, ça peut s'utiliser au rtfh.

merci, je vais voir ça dès que j'ai le temps

re, j'ai pas regardé en détail, juste d/l le .tar.gz, et ça m'a l'air énorme... rien que le test.c fait 16ko... cette lib c'est pas un truc énorme qui fait un tas d'autres trucs ? parceque ça me semble beaucoup pour des simples arguments variables, enfin j'ai pê mal regardé... :/

(en plus comme j'adore, y'a 500 fichiers dans l'archive, les 9/10emes dont je ne comprends même pas l'utilité... y'a du boulot en perspective )

normalement y'en a juste un à #includer
Si j'ai le temps je testerai ça.

Hmm visiblement y'a pas grand chose à #includer, il manque des fichiers. Par exemple ffi.h n'existe pas, y'a un ffi.h.in qui doit être géneré par un script, sauf que install.sh sous win ça marche pas des masses... :/

(j'ai tjrs pas le courage de comprendre ffitest.c )

Essaye avec cygwin

./configure && make

'.' n'est pas reconnu en tant que commande interne
ou externe, un programme exécutable ou un fichier de commandes.
C:\>

Utilise une knoppix et basta !

Mwé enfin hmm... bon déjà j'en ai pas, flemme de d/l (#mac# ), mais surtout je trouve ça dommage qu'il n'y ait rien prévu pr utiliser ça sous Windows...

Va te plaindre a microsoft ou installe cygwin/mingwin.

C'est pas vraiment à Microsoft que je vais me plaindre si faut vraiment le faire, c'est pas à Windows de s'adapter à Unix pour pallier les oublis des développeurs
Enfin bref, on verra si une bonne ame sur IRC peut me sortir le .h.

C'est pas à Windows de s'adapter à Unix pour pallier les oublis des développeurs

Qu'est-ce que ca leur couterait de mettre les outils standards unix (/bin) et un support complet de posix ?
Rien ! S'ils ne veulent pas le faire, ils ont surement des raisons, surement commerciales (garder son format proprietaire pour empecher les clients de migrer ailleurs).
Par ailleurs, il n'y a aucun outil par default de developpement sous Windows. Tu voudrais qu'ils utilisent quoi ?

J'en sais rien, mais mettre un .h pour permettre aux gens sous win de l'utiliser, c'est si difficile que ça ?

Oui car le .h depend de ton systeme
C'est le boulot du configure de le remplir correctement. Mais normalement, si tu es motive, tu dois pouvoir traduire a la main le le fichier .h.in en .h.

Oui, v être obligé de faire ça... Ou de trouver une autre lib, d'ici deux semaines faudra bien que je tranche pour une ou l'autre de ces solutions :/

PpHd> bah t'as plus que ça à faire, t'as aussi les Makefile.am à transformer en Makefile.in puis Makefile

Cygwin te prendrait 30 secondes à installer

>>PpHd> bah t'as plus que ça à faire, t'as aussi les Makefile.am à transformer en Makefile.in puis Makefile
Normalement il a deja les Makefile.in, mais ca ne lui sert car je suppose qu'il a meme pas de programme make

>Cygwin te prendrait 30 secondes à installer
Oue. Mais cygwin reste quand meme une belle daube

Qu'est-ce que tu reproches à Cygwin ?

PpHd :
Rien ! S'ils ne veulent pas le faire, ils ont surement des raisons, surement commerciales (garder son format proprietaire pour empecher les clients de migrer ailleurs).

Euh, ils font eux-mêmes les Services for Unix pour permettre à leurs clients de migrer, justement... (mais dans le bon sens, évidemment ) Si lesdit clients choisissent d'utiliser une API spécifique Win32, c'est leur pb...

Vertyos :
Oui, v être obligé de faire ça... Ou de trouver une autre lib, d'ici deux semaines faudra bien que je tranche pour une ou l'autre de ces solutions :/

Tu peux pas développer sur ton Mac (où y'a tous les outils qui vont bien) ?

si mais ça fait chier, j'ai tous les outils qu'il me faut sous win, j'ai moyennement envie de passer sous osx juste parceque qqun a pas prévu le nécessaire... :/
en fait j'ai posté le topic à la place de qqun d'autre, c'est pas à moi de m'occuper de ça, mais par principe je trouve ça dommage de pas avoir fait le peu d'effort nécessaire pour que ça puisse être utilisable par tout le monde.

mais honnêtement y a pas moyen de faire sans ça ? parce que c'est crade, platform-dependent et tout et tout... (et source d'emmerdes, la preuve ^^)

je sais pas, franchement après avoir regardé, ça me semble vraiment compliqué pour "juste" passer des arguments un à un à une fonction... ça m'étonne qu'il n'y ait pas plus simple, mais bon si il faut, il faut :/ (je plains juste celui qui va avoir à s'occuper de ça )

non enfin parce que je soupçonne que :
- d'une part, on ne peut construire les arguments que pour la partie vararg de la fonction (donc si t'as une fonction qui prend exactement 4 arguments, ben tu vas pas pouvoir l'appeler comme ça, parce que le compilo aura pu mettre des args dans des registres et y a aucun moyen de le savoir dynamiquement, ou alors ça devient hyper-compliqué [infos de débug, toussa])
- d'autre part, si c'est pour la partie vararg d'une fonction, ben si c'est toi qui l'as écrite, tu peux la réécrire sans problème pour qu'elle utilise un tableau (c'est plus propre, totalement portable, etc...)

Donc je vois une utilité que si tu utilises une lib closed-source, écrite suffisamment mal pour qu'il y ait une fonction vararg qui n'ait pas d'alternative sans vararg, et dont tu ne peux vraiment pas te passer. Dans tous les autres cas, j'aurais tendance à penser que c'est une erreur de faire comme ça...

>Qu'est-ce que tu reproches à Cygwin ?
Hyper Lent et buggue
Mais faut dire que sans fork valable, ca explique pas mal de chose.

>Si lesdit clients choisissent d'utiliser une API spécifique Win32, c'est leur pb...
Ils peuvent developper en utilisant l'API Unix sous Windows, de facon native ? Depuis quand ?

> Hyper Lent et buggue
bof, moi j'ai pas encore rencontré de prog qui foire sous cygwin... par contre lent pour les fork(), oui (c'est vraiment le seul défaut je trouve -- ah si aussi le fait que le manager de packages n'est pas dispo en ligne de commande...)

> Mais faut dire que sans fork valable, ca explique pas mal de chose.
gnî ? c quoi un fork valable ? (à part au niveau vitesse)

> Ils peuvent developper en utilisant l'API Unix sous Windows, de facon native ? Depuis quand ?
Ben l'API Unix *n'est pas* l'API native de Windows, ça fonctionne pas pareil... De même que l'API Wine n'est pas l'API native de Linux. Mais y a qd même des possibilités d'émulation de l'une par l'autre (quoique, j'ai jamais essayé wine sous cygwin )