Les va_* me font suer - Page 1

pouet,

J'ai voulu passer d'un proto comme ça : bool guilib__AttachWidget(HANDLE layout, HANDLE widget); à ça : bool guilib__AttachWidget(HANDLE layout, HANDLE widget, ...);
Bref, un coup de stdarg c'est c'est bon.

J'ai donc ajouté ça en début et en fin de fonction :

    va_list(ap);
    va_start(ap, widget);
    // le corps de la fonction

    va_end(ap);

Et dans le corps, j'utilise ça :

    while (widget) {
        HANDLE handle = va_arg(ap, HANDLE);
        ...
    }

puis je manipule handle selon mes besoins.

J'ai une address error au runtime, vous voyez pourquoi ? J'ai l'impression de rater un truc évident, qui malheureusement ne me saute pas aux yeux (sachant que la fonction marchait très bien avant

Ta boucle while n'a pas de raison de s'arrêter.

    do {
        ...
        widget = va_arg(ap, HANDLE);
    } while (widget);

Ainsi, tu peux manipuler widget.

-

Merci RHJPP. Effectivement, ce que j'avais écrit n'était pas malin.
Mais bon, toujours address error, saylamayrde.

Donc je regarde l'assembleur généré. Et là, je me rappelle pourquoi le C sur TI, c'est mal. Florilège :

	lea _ROM_CALL_96:l,%a0
	move.w 10(%fp),%d0
	move.w %d0,-(%sp)
	jbsr (%a0)

(c'est un simple HeapDeref(handle))

	move.l %a0,%d0
	move.l %d0,-16(%fp)
	move.l -16(%fp),%a0

Une partie à trois version 68k

	move.w 2(%a0),%d0
	tst.w %d0

Pour convaincre les Z-Flags les plus récalcitrants

	move.w 10(%fp),%d0
	move.w %d0,-(%sp)
	jbsr guilib__0004
	addq.l #2,%sp

Parfois d0 est jaloux, faut pas qu'il se sente oublié

Bon j'arrête là, il reste les 3/4 de la fonction à parcourir

Tu mets bien un 0 comme dernier argument à ta fonction ? C'est ce que tu sembles avoir voulu utiliser pour marquer la fin de la liste.

Non. Je pensais que c'était fait tout seul par les macros. J'ai pas bien compris comment elles détectent la fin des arguments fournis, ou du moins le nombre d'arguments fournis.

edit : Mais malheureusement, ça vient de tomber en marche après que j'ai mis puis enlevé un asm("bra .");, et rien d'autre. Et je sais toujours pas comment il trouve la fin de la liste

Elles détectent rien du tout. Ni le type des arguments, ni leur nombre.

Il me semble qu'on ne peut pas détecter la fin de la liste si on ne met rien en place pour. Tu peux peut-être ajouter le 0 final avec une macro.

Ok, merci. Je pensais que 0 était passé pour un type scalaire, NULL pour un pointeur. Mon mauvais, et merci encore.

Sinon, tu peux faire du C++, et finir avec des parameter pack, à coups de std::enable_if, et de la récursion en compile-time pour te retrouver avec N fonctions générées par le compilateur, où N correspond au nombre maximum d'arguments que tu passeras à ta fonction dans le parameter pack.

Pas sûr qu'en embarqué ça passe par contre

As-tu bien compilé avec un flag d'optimisation (minimum -O, préférablement -O2 ou -Os)? Parce que ton code ASM ressemble fortement à du -O0.

Kevin -> maintenant, oui Effectivement, 30% de place en moins. Mais faut que je continue à éviter de regarder

Oui comme dit par les autres, les va_list n'ont aucun mecanisme par defaut pour determiner la fin de liste. Tu as deux possibilite, soit un marqueur identifiable (NULL/0 peux ne pas etre la bonne solution dans certains cas) soit comme printf, un des parametres obligatoires permet de connaitre le nombre d'element variables.

- Ca peux etre un basique
void foo(int count, ...);
Mais tu as le nombre mais pas le type, donc chaque element soit etre du meme type (ou alors utiliser des choses intelligente comme le polymorphisme possible en C avec les structures)

- a un truc plus complique comme ce que fait *printf:
int printf(const char *fmt, ...);
ou le parsing de fmt permet de savoir le type et le nombre de chacun des parametres.

Folco (./12) :
Kevin -> maintenant, oui Effectivement, 30% de place en moins. Mais faut que je continue à éviter de regarder

Bah, les exemples que tu as postés, normalement il n'y a pas ça en optimisé.