Posté le 03/11/2016 à 19:18 Membre depuis le 18/06/2001, -26239 message
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
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !
Posté le 03/11/2016 à 20:05Edité par RHJPP le 03/11/2016 à 20:30 Membre depuis le 04/05/2005, 4416 messages
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.
avatar
Posté le 03/11/2016 à 20:21Edité par O_o le 04/09/2017 à 22:56 Membre depuis le 01/04/2002, 22005 messages
-
Posté le 03/11/2016 à 20:50 Membre depuis le 18/06/2001, -26239 message
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 couic
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !
Posté le 03/11/2016 à 20:58 Membre depuis le 04/05/2005, 4416 messages
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.
avatar
Posté le 03/11/2016 à 21:07Edité par Folco le 03/11/2016 à 21:09 Membre depuis le 18/06/2001, -26239 message
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. sad

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 tsss
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !
Posté le 03/11/2016 à 21:09 Membre depuis le 10/06/2001, 2213 messages
Elles détectent rien du tout. Ni le type des arguments, ni leur nombre.
Posté le 03/11/2016 à 21:09 Membre depuis le 04/05/2005, 4416 messages
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.
avatar
Posté le 03/11/2016 à 21:19 Membre depuis le 18/06/2001, -26239 message
Ok, merci. Je pensais que 0 était passé pour un type scalaire, NULL pour un pointeur. Mon mauvais, et merci encore. smile
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !
Posté le 03/11/2016 à 22:40 Membre depuis le 24/04/2009, 2514 messages
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 grin
Posté le 04/11/2016 à 04:19 Membre depuis le 10/06/2001, 40014 messages
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.
avatarMes news pour calculatrices TI: Ti-Gen (fr/en), MobiFiles (de)
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité
Posté le 04/11/2016 à 06:16 Membre depuis le 18/06/2001, -26239 message
Kevin -> maintenant, oui cheeky Effectivement, 30% de place en moins. Mais faut que je continue à éviter de regarder grin
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !
Posté le 04/11/2016 à 13:39 Membre depuis le 30/06/2001, 70810 messages
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.
avatarProud to be CAKE©®™
The cake is a lie! - Love your weighted companion cube

->986-Studio's Wonder Project!<-
yN a cassé ma signature :o
Posté le 04/11/2016 à 14:32 Membre depuis le 10/06/2001, 40014 messages
Folco (./12) :
Kevin -> maintenant, oui cheeky Effectivement, 30% de place en moins. Mais faut que je continue à éviter de regarder grin
Bah, les exemples que tu as postés, normalement il n'y a pas ça en optimisé.
avatarMes news pour calculatrices TI: Ti-Gen (fr/en), MobiFiles (de)
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité