[C] retransmission d'une liste d'arguments variables - Page 1

yop,

Si une fonction a ce prototype : void fonction (int n, char* format, ...);
Comment peut-elle faire un printf(format, ...); ?
Autrement dit, comment repasser une liste d'arguments variables d'une fonction à une autre ?

J'ai brozé sur le ouaibe sans trouver, et pourtant ça me dit quelque chose cette manière de faire.
Une idée svp ?

elle peut pas.

les fonctions qui appelées doivent utiliser un va_list.

donc void la fonction vprintf(const char *format, va_list ap);

#include <stdarg.h>
void function(int n, char * format, ...) {
  va_list ap;
  va_start(ap,format);
  printf("[%02X] ",n);
  vprintf(format,ap);
  va_end(ap);
}

y'a donc aussi vsprintf, vsnprintf, vasprintf, vscanf, vsscanf, etc

Merci bien, c'est une possibilté, peut-être bien la seule d'ailleurs.
Etonnant, qu'il faille implémenter une fonction qui prenne une va_list en argument pour régler ce problème, plutôt que de prévoir un mécanisme côté appelant pour ce genre de chose...

bin vu que l'argument '...' n'a pas de nom, comment tu peux transmettre ça à l'appelé?

rappelle toi qu'en asm, tous les args de ce type de fonction sont pushés sur la pile par l'appelant de la première fonction, puis on fait call.

comment tu ferais pour passer ces "vieux" arguments à une sous-fonction? pas évident de trifouiller sp!

pour s'en sortir, le va_list est en fait un pointeur vers les arguments de la fonction à ptits points.

squalyl (./4) :
comment tu ferais pour passer ces "vieux" arguments à une sous-fonction? pas évident de trifouiller sp!

http://sourceforge.net/p/asoc/code/HEAD/tree/src/print.asm

oh bah on peut toujours faire des saletés, hein

J'ai eu besoin de ça un jour et j'étais tombé sur une lib qui devait permettre de le faire, sauf que bien sûr c'était spécifique à une plate forme (x86) et je n'ai jamais réussi à la faire fonctionner donc je n'ai pas retenu le nom. Le plus simple serait peut-être que tu trouves une autre solution ^^

Folco (./3) :
Merci bien, c'est une possibilté, peut-être bien la seule d'ailleurs.
Etonnant, qu'il faille implémenter une fonction qui prenne une va_list en argument pour régler ce problème, plutôt que de prévoir un mécanisme côté appelant pour ce genre de chose...

C'est comme cela que ça fonctionne en interne.

Si tu regarde la fonction printf, elle récupère la liste variable d'argument dans un va_list et appelle vprintf (ou vfprintf suivant les implémentations)

vprintf qui a pour prototype

int vprintf(const char *format, va_list ap);

C'est la seule solution propre. Tout ce que fait va_start est de mettre l'adresse du premier argument dans un pointeur qui est va_list.

va_list est un format opaque mais c'est juste un "pointeur" (Bon ca peux etre un peu plus complique suivant les ABIs, mais c'est le principe)

edit: bon squalyl exipliquait ca aussi bien en fait je n'avions point vu.

Merci bien à tous.

squalyl (./6) :
oh bah on peut toujours faire des saletés, hein

C'est pas sale, c'est pour logguer sans détruire un seul registre, et en utilisant toute la puissance de f/printf, très commode pour déboguer en asm. C'est mieux que de se rendre compte que ton bug vient du log qui a détruit le d0 dont tu avais besoin... Là, ça permet de rajouter les logs ici et là, à la volée, sans s'inquiéter de rien.

*normalement* si stdarg est bien implémenté sur l'architecture utilisé, l'overhead est plus que minime, rien ou presque n'est a copier, et la lib peux elle même faire des optimisation comme tu l'a fait dans AS suivant l'ABI

En fait, à la création de ta fonction, tu devrais toi aussi faire une version va_list et une version "..." qui est juste un wrapper de la version va_list.


Ce que je trouve plus emmerdant, c'est l'absence d'API standard (ou non-standard, d'ailleurs) pour créer de toutes pièces une va_list.

J'attends avec une impatience terrible le switch -std=c15 qui permettra ça, notamment par la surcharge de fonction (pas question que je fasse ça de manière non-trnasparente).
Surtout qu'il n'y a, je pense, rien qui n'empêche d'ajouter cette feature au C. Tout comme l'affectation d'une variable structure à une autre, et bien d'autres choses encore.

Link (./11) :
Ce que je trouve plus emmerdant, c'est l'absence d'API standard (ou non-standard, d'ailleurs) pour créer de toutes pièces une va_list.

Parceque ca n'a aucun interet?

et pitie non surtout pas de surcharge en C, et ce pour la simple raison que le language n'est pas prévu pour et que pour avoir de la surcharge ca veux dire casser quasiment toutes les ABI.

La surcharge est généralement une mauvaise idée...

hmmmm ? Je dois mal voir les tenants et aboutissants de la surcharge alors.
Comment casser une ABI, alors qu'il s'agirait de faire compiler du code qui, à ce jour, ne pourrait compiler ?
Il s'agirait juste de permettre des fonctions de même nom avec des signatures différentes, ce qui m'aurait épargné ce problème de printf pra exemple.

Godzil (./13) :
La surcharge est généralement une mauvaise idée...

La surcharge, ça peut se résumer à des gros #if au préprocessing, on en perd toute trace dès le stade de la compilation...

Enfin, je pense. Si c'est implémenté autrement, ça serait sympa de m'expliquer pourquoi.

surcharge? in my c compiler? vade retro, strousoupnas, touche pas à mon C!

la surcharge c'est un "plouf-plouf" du compilateur pour déterminer quelle fonction appeler selon le type de ses arguments. En C, sans classes ni héritage, ça n'a aucun intéret.

Ben... si ? Je ne vois ni le rapport avec classes et héritage, ni pouquoi ça serait plus ou moins utile sans.

[edit] je complète, même si ça m'énerve ces posts à la "machin c'est de la merde" surtout quand le sujet n'est pas maitrisé, vous pouvez quand même émettre un minimum de réserve dans vos jugements non ?

Bon, la surcharge ça n'a strictement rien à voir avec les classes, l'héritage ou je ne sais quoi d'autre. C'est simplement prendre en compte les types des paramètres en plus du nom d'une fonction dans sa signature. Et je ne vois pas non plus pourquoi ça irait casser les ABI...

Si le C proposait cette "mauvaise idée" qu'est la surcharge ça permettrait de n'avoir par exemple qu'une seule fonction "abs" qui prenne n'importe quel type numérique en paramètre au lieu de 50 noms différents "abs", "fabs", "fabsl", "fabsf" et autres fantaisies impossibles à retenir. Même chose pour les tonnes de doublons dans stdlib qui n'existent justement que parce que le C ne propose pas de surcharge.

squalyl ->

void Fatal (int err, const char* str)
{
    fprintf (stderr, str);
    exit(err);
}

void Fatal (int err, const char* str, unsigned long ul)
{
    fprintf(stderr, str, ul);
    exit(err);
}

etc....

C'est beaucoup plus propre que d'appeler (f)vprintf avec on ne sait pas quoi derrière.
Ca c'est dans mon cas, pour lequel j'ai créé le topic, mais c'est valable pour tout un tas d'autres cas que j'ai rencontrés. Et quant au rapport avec les classes et l'héritage, ben je vois pas trop en fait

(ah, et faudrait aussi rajouter les arguments pas défaut, pareil, ça coûte rien en C, ça)

ok, je voyais plus le cas où le nombre de paramètres est identique.

mais ton truc, on peut le faire avec une fonction à arguments variables, parce que dans les cas que tu cites, si les paramètres ne correspondent pas à la chaine de format, ça va s'envoyer en l'air

bref,

squalyl (./16) :
je trouve qu'en C, sans classes ni héritage, ça n'a aucun intéret.

et je devais mélanger avec le polymorphisme.

C'est la même chose (mais ton ./15 v2 est beaucoup mieux )

Oui ABI n'est pas le bon terme, signature lui est le bon.

Le C n'a pas de mangling a la C++ et la raison est assez simple, vous avez déjà regardé le mangling d'une fonction C++ ? C'est juste imbuvable, et c'est inutilisable en direct en assembleur.

Le C n'est PAS un langage de haut niveau, moins de fonctionnalité a la con sont présente dans le langage, mieux il se porte, c'est un langage fait pour faire du système, pas pour faire des "truc fantaisies" et le polymorphisme est quelque chose qui enlève une partie du contrôle qu'on peu avoir sur le langage. Et puis apres on ajoute quoi ? la surcharge des opérateurs ? Comme ça on peux faire du cin/cout en C ?

(tu cherches à montrer quoi, là ? ...)

pas compris non plus

Dit tout de suite que ce que j'ai écrit est incomprehensible et qu'il faudrait que j'aille dormir ?

farpaitement

(nan mais si tu prends le C et que t'ajoutes toutes les features du C++, ça fait juste du C++, pas du C amélioré )

On est d'accord

Godzil (./23) :
Dit tout de suite que ce que j'ai écrit est incomprehensible et qu'il faudrait que j'aille dormir ?

ben ya un peu de ça oui, moi je parle de surcharge de fonction, et toi tu pars dans tous les sens, parlant de mangling et d'abi, de signature et de bas niveau, choses qui n'ont rien à voir avec ça. J'y reviendrai ce tantôt.

Ben le mangling est indispensable pour la surcharge...

hmm, mangling à la pistache, ça a l'air d'un dessert

Godzil (./27) :
Ben le mangling est indispensable pour la surcharge...

Cf: http://en.wikipedia.org/wiki/Name_mangling

Et c'est bien ce qui me semblait, le mangling est considéré comme faisant partit de l'ABI.

__1cGstrcpy6Fpcpkc_0_

a tes souhaits

(je sais ce que c'est le mangling )