Mon topic à moi... - Page 1

Hello, maintenant que c'est les vacances, je vais pouvoir commencer a programmer un peux plus sérieusement. Or, je pense que j'aurais plein de questions donc je crée mon topic

1ère question :

Pour créer une nouvelle fonction, j'utilise :

void newfunc ( short x, short y, ..........)
{
...........
}

Maintenant, imaginons que je veule faire une fonction, mais sans paramètre,
comment je dois déclarer cette dernière ?

Car
void newfunc(void)
{
...........
}

&

void newfunc
{
...........
}

ne marche pas.

void newfunc(void)
{
...........
}

devrait marcher...

Suis je bête :

void newfunc()
{
.....
}

le void n'est pas absolument nécessaire, mais il est plus précis de le mettre...

Puis je comprendre pourquoi ceci ne marche pas ?

SCR_RECT Screen = {{0, 0, 159, 99}};
DrawClipRect (MakeWinRect (0,8,159,99),Screen,A_NORMAL||B_DOUBLE);

Screen est mal définit ?

squale92 : c'est pas tout à fait pareil. Sans le void le compilateur considère que la fonction peut prendre un nombre d'arguments quelconque : zéro ou 10 ou 150 ...

oué, c pr ça que je dis qu'il est plus précis de le mettre, et c'est aussi pr ça que je dis qu'il n'est pas absolument nécessaire de le mettre

Quelqu'un peut répondre, je trouve ça vraiment bizarre.

WIN_RECT *MakeWinRect (short x0, short y0, short x1, short y1);


Builds a structure for representing rectangular area.

MakeWinRect accepts coordinates of two corners (x0, y0) and (x1, y1) of an rectangular area, and returns the pointer to the structure of type WIN_RECT in which these coordinates are embeded. This function may be useful in combination with a rich set of TIOS functions which expect a structure of type WIN_RECT as explicite argument, like WinOpen, WinLine, etc.

Note: This function returns a static pointer, which will be rewritten with each call. So, you must not use it inside functions which needs more than one parameter of type WIN_RECT like WinFillLines2 etc.

Je ne vois pas le rapport avec SCR_RECT

essaie : DrawClipRect(MakeWinRect(0,8,159,99), (&(SCR_RECT){{0, 0, 159, 99}}) , A_NORMAL | B_DOUBLE);

TachMan> Merci, je pense que sa devrait marcher.

Au lieu de MakeWinRect(0,8,159,99), utilise plutôt &(WIN_RECT){0,8,159,99}, ça donne du code plus efficace (et ça marche même pour des variables dans la version la plus récente de TIGCC).

Merci Kevin.

Comment faire pour créer un tableau de string dans la ram.
Je m'explique mal, je veux dire par là que la variable representant mon tableau doit être déclarer comme externe au programme car elle prend beaucoup trop de place.
Faut il utiliser malloc ?

Oui.

Thibaut a écrit un truc très interessant :
Sans le void le compilateur considère que la fonction peut prendre un nombre d'arguments quelconque : zéro ou 10 ou 150 ...

Mais c'est génial ça ! Comment on fait pr les utiliser les arguments, après ?

bah il faut déclarer le type d'arguments j'imagine ... comme pour toutes les fonctions qui en nécéssite.
tu ne pourras pas faire main(2, i, str) par ex, sans avoir dit ce qu'était 2, i , et str dans la liste des arguments.
Enfin peut-être me tompe-je ?!

il faut que tu utilise les fonctions de stdarg.h je crois
=> tu devra utiliser quelque chose du style de ce que printf utilise.

A savoir, quelque chose qui t'indique à la fois le nombre d'arguments, et leurs types...
(dans printf, c'est une chaîne de caractères)

Le mieux c'est de coder la fonction en assembleur, parceque je ne sais pas comment fonctionne stdarg.h mais ça doit être le bodel en C

le peu que j'en ai lu, ça paraissait bordélique

Une simple question :
Pourquoi

#define SAVE_SCREEN

est équivalent à :

LCD_BUFFER ecran;
LCD_save(Ecran);
LCD_restore(Ecran);

et nom à ça :

void *Ecran = malloc(3840);
LCD_save(Ecran);
LCD_restore(Ecran);

Les programmes ferait 3840 octets de moins en archive et prendrais exactement (je pense) la même taille en ram à l'execution.

Si chaque programme compiler avec Tigcc et utilisant #define SAVE_SCREEN de ma calculatrice utiliserait l'autre méthode, ça ferais des ko de gagné, non ?

De même : 4 octets de différence entre off(); et asm("trap #4")

Sinon quelqu'un a t-il une fonction C ou ASM pour sauver et restaurer l'écran avec les gris activés ?

Il faut que je déclare un pointeur globale, donc avant void _main(void) et avant toutes mes fonctions, je fais :

void *Screen = malloc(3840);

Tigcc me donne l'erreur "Initializer element is not constant".
Comment faire pour corriger ce problème ?

Il faut déclarer void *screen; puis faire screen = malloc(LCD_SIZE);
car malloc renvoie un pointeur que tu stockes dans screen.

"Initializer element is not constant"
tigcc est explicite : malloc() est une fonction et non une constante !
En dehors de toute fonction, tu ne peux pas éxécuter de code...

Comme BiHi te l'explique, met:

void * screen=NULL;

void _main(void) {

screen=malloc(3840);

}

Ok, merci a tout les deux, c'est sympa et maitenant, à table !

Bon, en fait, ça va toujours pas, je veux que Screen soit une variable globale, pas dans _main.

Donc je répète : comment déclarer un screen pour qu'il soit variable globale

Dans l'exemple cite, il est declare comme var globale.

Watcha a écrit :
Une simple question :
Pourquoi

#define SAVE_SCREEN

est équivalent à :

LCD_BUFFER ecran;
LCD_save(Ecran);
LCD_restore(Ecran);

et nom à ça :

void *Ecran = malloc(3840);
LCD_save(Ecran);
LCD_restore(Ecran);

Les programmes ferait 3840 octets de moins en archive et prendrais exactement (je pense) la même taille en ram à l'execution.

Si chaque programme compiler avec Tigcc et utilisant #define SAVE_SCREEN de ma calculatrice utiliserait l'autre méthode, ça ferais des ko de gagné, non ?

De même : 4 octets de différence entre off(); et asm("trap #4")
Sinon quelqu'un a t-il une fonction C ou ASM pour sauver et restaurer l'écran avec les gris activés ?

Bon déjà faut pas oiublier les free ou HeapFree après malloc ou HeapAlloc ...

Ensuite, pour l'histoire du off, ben c'est normal ...
Si tu mets off, ce sera traduit par quelque chose du style :
move.l $c8,a0
move.l off*4(a0),a0
jsr (a0)
(bien sûr, ça change avec OPTIMIZE_ROM_CALLS)
En gros, cela appelle le ROM_CALL off d'AMS.

Tandis que asm("trap #4") sera traduit en trap #4 en assembleur, et il se trouve que sur la TI l'extinction de la calculatrice est gérée par le trap #4 ...

Mais peut-être que off fait plus de choses que trap #4, du style générer un évènement pour les applications Flash ou autre ...

Je me trompe ?

Il me semble que la fonction off de TIGCC fait un simple trap #4

Non, elle appelle un simple ROM_CALL qui lui ne contient que 0x4e444e75, c'est-à-dire trap #4;rts.