Bref, tu vois les idées.
C'est en sciant que Léonard devint scie, n'est-ce pas ?
(il est temps d'aller dormir
)
)
if (Key == KEY_MODE)
{
MenuResult = DrawMenu(&ModeMenu,DScreen);
switch (MenuResult)
{
case 1:
MenuResult2 = DrawMenu(&ModeMenuLP,DScreen);
break;
case 2:
MenuResult2 = DrawMenu(&ModeMenuDP,DScreen);
}
if ((MenuResult != 0) && (MenuResult2 != 0))
{
MainData.ToolsMode[MenuResult-1][MainData.Tool] = MenuResult2 - 1;
}
}
typedef struct Data_s
{
WIN_RECT Curs;
short ToolsMode[PLANE_COUNT][TOOLS_COUNT];
short Tool;
short Cursor;
short Flags;
short CircleRadius;
short EllipseAxe1;
short EllipseAxe2;
SCR_RECT Clip;
} Data_t;
Data_t MainData = //default values
{
{LCD_WIDTH/2,LCD_HEIGHT/2,LCD_WIDTH/2,LCD_HEIGHT/2},
{A_XOR,A_XOR,A_NORMAL,A_NORMAL,A_NORMAL,A_NORMAL,
A_NORMAL,A_NORMAL,A_NORMAL,A_NORMAL,A_NORMAL,A_NORMAL},
TOOL_DOT,CURSOR_0,FLAGS_DEFAULT,CIRCLE_RADIUS,ELLIPSE_AXE_1,ELLIPSE_AXE_2,{{0,0,239,127}}
};
{{A_XOR,A_XOR,A_NORMAL,A_NORMAL,A_NORMAL,A_NORMAL},
{A_NORMAL,A_NORMAL,A_NORMAL,A_NORMAL,A_NORMAL,A_NORMAL}}
{{A_XOR,A_XOR},{A_NORMAL,A_NORMAL},{A_NORMAL,A_NORMAL},
{A_NORMAL,A_NORMAL},{A_NORMAL,A_NORMAL},{A_NORMAL,A_NORMAL}}
). Cela dit, j'écrirais ton code comme ça:
à moins que j'ai fait une erreur en croyant faire ça ...
if (Key == KEY_MODE) {
MenuResult = DrawMenu(&ModeMenu,DScreen);
if (MenuResult) {
MenuResult2 = DrawMenu(--MenuResult ? &ModeMenuDP : &ModeMenuLP,DScreen);
if (MenuResult2)
MainData.ToolsMode[MenuResult][MainData.Tool] = MenuResult2 - 1;
}
}Folco (./365) :
Oui , PLANE_COUNT == 2 effectivement. Ca veut dire que mon tabealu doit prendre la première forme ?
Kevin Kofler (./366) :
Il faut au minimum 3 cas pour que le switch ait un intérêt.
.set pedrom__stdin, pedrom__0000 .set pedrom__stdout, pedrom__0000+4 .set pedrom__stderr, pedrom__0000+8 .set pedrom__printf, pedrom__0004 .set pedrom__vcbprintf, pedrom__0005 .set pedrom__clrscr, pedrom__0006 .set pedrom__fclose, pedrom__0007 .set pedrom__freopen, pedrom__0008 .set pedrom__fopen, pedrom__0009 .set pedrom__fseek, pedrom__000a .set pedrom__ftell, pedrom__000b .set pedrom__feof, pedrom__000c .set pedrom__fputc, pedrom__000d .set pedrom__fputs, pedrom__000e .set pedrom__fwrite, pedrom__000f .set pedrom__fgetc, pedrom__0010 .set pedrom__fread, pedrom__0011 .set pedrom__fgets, pedrom__0012 .set pedrom__ungetc, pedrom__0013 .set pedrom__fflush, pedrom__0014 .set pedrom__clearerr, pedrom__0015 .set pedrom__ferror, pedrom__0016 .set pedrom__rewind, pedrom__0017 .set pedrom__fprtinf, pedrom__0018 .set pedrom__tmpnam, pedrom__0019 .set pedrom__qsort, pedrom__001b .set pedrom__bsearch, pedrom__001e .set pedrom__remove, pedrom__001f .set pedrom__unlink, pedrom__001f .set pedrom__rename, pedrom__0020 .set pedrom__atoi, pedrom__0021 .set pedrom__atol, pedrom__0021 .set pedrom__rand, pedrom__0023 .set pedrom__srand, pedrom__0024 .set pedrom__calloc, pedrom__0025 .set pedrom__realloc, pedrom__0026 .set pedrom__atof, pedrom__0027 .set pedrom__sttputchar, pedrom__0028 | ??? .set pedrom__perror, pedrom__0029 .set pedrom__getenv, pedrom__002a .set pedrom__system, pedrom__002b .set pedrom__setvbuf, pedrom__002c .set pedrom__exit, pedrom__002d .set pedrom__atexit, pedrom__002e
Folco (./369) :
Au fait, comment fait-on pour faire un programme kernel ?
), -DUSE_KERNEL.Folco (./370) :
Le truc, c'est que j'ai pas la moindre idée de comment écrire la première ligne pour que ça crée les exports corrects pour le kernel.
void pedrom__getenv(char * "asm (%a2)";
Kevin Kofler (./372) :
const char *pedrom__getenv(const char * asm("a2"));
Kevin Kofler (./372) :
Et pouf la portabilité...
Folco (./373) :
Mais au fait, pourquoi un const pour l'argument ? Qu'est-ce qui te fait mettre ça ?
Kevin Kofler (./372) :Sauf si c'est pour un soft pedrom-only.
Et pouf la portabilité...
Prends l'habitude du const partout où c'est possible, ça t'empêchera de te taper des warnings et ce sera aussi très important si tu veux te mettre au C++ un jour.
alors qu'en C on peut tricher avec des castsXimoon (./378) :
Oui mais si t'as besoin de tricher c'est que tu t'es raté dans ton design
Folco (./376) :
Au sujet de la portabilité, je parlais de pcontrol, qui n'a visiblement pas sa place sous AMS. Je veux le refaire en C, c'est la fôôte à PpHd avec la nouvelle alpha de PedroM
Folco (./370) :
Je voudrais également porter ce header en C :
PpHd (./379) :
Ximoon (./378) :
Oui mais si t'as besoin de tricher c'est que tu t'es raté dans ton design
Faux. Il y a 1 cas du C où tu es obligé de tricher avec les const car il ne fait pas la conversion automatique.
(Mais un cas, j'ai bien dit un cas, pas deux).
PpHd (./379) :
Mais pourquoi, qu'ai-je fait ?
PpHd (./379) :
Regarde le répertoire 'example' de PedroM.
Attention : il n'est pas conseillé de copier les headers fournis dans ton header tigcc : tu vas tout casser sinon.
Utilise bien la directive -Iinclude !
Folco (./376) :Oui, ça permet de réaliser des appels du genre « maFonction("ma chaîne"); », car les constantes littérales sont … constantes.
Pour ce qui est des const, est-ce que c'est typiquement à employer dans les paramètres passés à une fonction ?
Ou aux tableaux de chaines de caractères ?C’est-à-dire ?
Parceque si j'assigne ça à une variale, je ne pourrai plus la modifiée...Effectivement, ce n’est pas à utiliser sur tes variables. C’est un mécanisme qui permet de protéger tes données. Utilise-le quand c’est nécessaire.
digression -> pourquoi spécialement en C++ ?En C++ tu manipuleras souvent des objets (un peu comme des structures en C), et quand tu passeras un objet en argument à une fonction celle-ci aura accès à tout un tas de fonctions qu’elle pourra appliquer sur l’objet, elle pourrait donc faire des bêtises et casser ton objet. Pour éviter ça, tu peux utiliser une copie de ton objet (comme ça, même si la fonction la modifie, tu t’en fous). Mais c’est un peu lourd de recopier des grosses structures de données à chaque appel de fonction, donc une autre solution c’est que la fonction qui utilise un objet en argument garantisse qu’elle ne modifiera pas l’objet (comme ça, pas de risque de faire des bêtises, et puis ça permet plus simplement de contrôler l’accès aux objets), en prenant en paramètre un objet constant.
Sasume (./382) :
C'est-à-dire ?
PpHd (./379) :
Regarde le répertoire 'example' de PedroM.
Attention : il n'est pas conseillé de copier les headers fournis dans ton header tigcc : tu vas tout casser sinon.
Utilise bien la directive -Iinclude !
Sasume (./382) :
essemblent à ça : const Cercle & fabriqueUnCercle(const Point & centre, const Longueur & rayon);Du coup, et c’est le bonheur du C++, la plupart des prototypes des fonctions r
Folco (./388) :
Ah ... Je ne donne aucun chemin... Je partais du principe que le chemin par défaut était celui du TPR, puisqu'un #include "header.h" fonctionne avec le header dans le répertoire du projet. C'est un tort ?
J'ai oublié de préciser : je fais ça sous Win.