Mon second programme en C - Page 12

je pense pas qu'il faille un "niveau" et proposer une bonne idée est une contribution aussi valable qu'un bout de C.

Ben les idées, c'set pas ce qui manque je suppose, vu le forum. Mais qui code ? qui a le temps et la motivation nécessaire ?

Ce qui manque, c'est probablement plus le temps (encore plus pour PpHd et Godzil que pour moi) que la motivation ou les idées

Godzil (./329) :
Non tu manque cruellement d'un bon editeur de fichier C qui te propose de la completion automatique, avec un tel editeur, impossible (ou presque) de faire ce genre d'erreurs

Ctrl+Espace
Il y a aussi Ctrl+m comme alternative, pour le cas où Ctrl+Espace est utilisé par autre chose.

Folco (./330) :
D'ailleurs, faut quel niveau en C pour contribuer ?

Pour les EDIs, aucun, étant donné que KTIGCC est en C++ et TIGCC IDE est en Delphi.
Soit dit au passage que si tu veux vraiment contribuer, tu devrais contribuer à TIGCC, pas GCC4TI. GCC4TI se contente essentiellement d'utiliser le code du projet TIGCC et de rajouter quelques patches de mauvaise qualité qui dégradent le tout.

Je crois pas que tu arrive a convaincre martial, mais bon comme tu veux ^^

Kevin Kofler (./334) :
Soit dit au passage que si tu veux vraiment contribuer, tu devrais contribuer à TIGCC, pas GCC4TI. GCC4TI se contente essentiellement d'utiliser le code du projet TIGCC et de rajouter quelques patches de mauvaise qualité qui dégradent le tout.

Ah bon ? Heureusement que tu es là pour rétablir la vérité

mort de rire

#kevichou#

[Kevin@TIGCC] $ ReceiveContrib(anything) > /dev/null

'spèce de geek

switch(random) {
case 0: il manque la doc;
case 1: le patch a pas les bonnes fins de ligne, je le veux pas
case 3: c'est quoi la licence?
case 4: j'ai pas le temps
case 5: c'est pas un bug c'est une feature
case 6: ce sera pour ktigcc 2/3/4
default: non
}

Je sais pas comment dire, mais le C me fait un peu peur à un niveau. Mon code de tout de suite :
En asm, je sais pas comment je me serais démerdé entre les structures de données et la valeur de retour du menu, mais je m'en serais certainement pas tiré avec un pavé very-like... J'ai dû très mal concevoir mon programme autour de ces données. En tout cas, l'avantage énorme, c'est qu'un tel pavé met 5 minutes à s'écrire. C'est réellement fou la différence avec l'assembleur à ce niveau !

Fais des tableaux, genre LineModePlane0 -> Modes[0][TOOL_LINE].

pourquoi tu fais pas des switch
là en théorie il va faire tous les tests de rang (bon en pratique il optimise sans doute, mais bon )
attends...

unsigned char flag; /* ou autre type */
switch (DrawMenu(&ModeMenuLP,DScreen)) {
  case 1: flag = A_NORMAL; break;
  case 2: flag = A_REVERSE; break;
  case 3: flag = A_XOR; break;
}
switch (MainData.Tool) {
  case TOOL_LINE: MainData.LineModePlane0 = flag;
  case TOOL_CIRCLE: etc.
}

Les switch ne résolvent pas le vrai problème, qui est qu'à part le if (key == KEY_MODE), le code se résume à une seule instruction C si les tableaux sont utilisés correctement! Toutes les distinctions du cas sont inutiles. (D'ailleurs, on peut écrire le même genre de code en assembleur, regarde le code de XtraKeys. )

Kevin -> Ah oui merci, j'ai pas pensé aux tableau à deux dimensions. En asm, tu vois la ram comme un long ruban d'octets, la perfection de la dimension 1 quoi.

Sally -> A part gagner quelques caractères à écrire, ça va apporter quoi ? A part sûrement perdre en lisibilité ? Puis pour les if, faut des valeurs constantes en temps de compilation, et je n'en dispose pas ici... (ou alors, juste dans un seul niveau de l'assemblage de if que j'ai).

Certes, il pourrait mieux s'y prendre au niveau des structures de données, mais même en gardant exactement la même sémantique, il n'a pas besoin de copier-coller 250 fois la même chose

Folco > perdre en lisibilité en divisant par 4 la taille de ta fonction ? on n'a pas la même notion de lisibilité je crois

Eh oh faut savoir, je dois pas coder comme un bourrin "tant que ça marche" ? Qui plus est, sortir une 0.91 RC2 bêta avec une optimisation de 24% en taille par rapport à la RC1, ça fait mieux que d'annoncer "j'ai gagné 18 octets", non ?

Non je voulais dire diviser par 4 la taille du CODE SOURCE de ta fonction, évidemment (sinon le résultat obtenu après compilation devrait pas être très différent avec ma proposition, surtout si l'optimisation est bien faite), de mon point de vue ça *améliore* la lisibilité (et la maintenabilité) par rapport à un pavé à base de copier/coller...

Tes TOOL_MACHIN ne sont pas des constantes

Si, c'est la seule chose dont je parlais qui est constante.

ah bon, mais tu sais quoi, 1, 2 et 3 sont aussi des constantes . Donc ma proposition en ./346 marche (j'ai pas tout écrit hein, mais la suite me semble évidente). Mais bien ŝur utiliser des tableaux est encore mieux.

Oui, mais quel avantage ? Perso je trouve ça plus chiant à lire ; par exemple, j'ai remplacé une dizaine de case qui s'étendaient sur 3 pages après un switch, parce que ça devenait chiant à lire (pourtant, il me semble indenter correctement, avec les règles de clarté que vous m'avez données).

Déjà un conseil, évite les affectations dans les conditions :

MenuResult = DrawMenu(&ModeMenu,DScreen);
if (MenuResult == 1) 

n'est-il pas beaucoup plus lisible que
if ((MenuResult = DrawMenu(&ModeMenu,DScreen)) == 1)
?
D'autant plus que la comparaison avec le second test est immédiate ainsi.

Ensuite, sauf si je me trompe fondamentalement sur la nature de ton code, ne serait-il pas équivalent de faire ça :

Font_Type_t Font_Type;

if (Key == KEY_MODE) 
{ 
    MenuResult = DrawMenu(&ModeMenu,DScreen);
    MenuResult2 = DrawMenu(&ModeMenuLP,DScreen);

    if (MenuResult2 == 1) 
    { 
        Font_Type = A_NORMAL;
    } 
    if (MenuResult2 == 2) 
    { 
        Font_Type = A_REVERSE; 
    } 
    if (MenuResult2 == 3) 
    { 
        Font_Type = = A_XOR; 
    } 

    if (MenuResult == 1) 
    { 
        if (MainData.Tool == TOOL_LINE)         MainData.LineModePlane0         = Font_Type; 
        if (MainData.Tool == TOOL_CIRCLE)       MainData.CircleModePlane0       = Font_Type; 
        if (MainData.Tool == TOOL_ELLIPSE)      MainData.EllipseModePlane0      = Font_Type; 
        if (MainData.Tool == TOOL_RECTANGLE)    MainData.RectangleModePlane0    = Font_Type; 
        if (MainData.Tool == TOOL_FRAME)        MainData.FrameModePlane0        = Font_Type;         
    } 
    if (MenuResult == 2) 
    { 
        if (MainData.Tool == TOOL_LINE)         MainData.LineModePlane1         = Font_Type; 
        if (MainData.Tool == TOOL_CIRCLE)       MainData.CircleModePlane1       = Font_Type; 
        if (MainData.Tool == TOOL_ELLIPSE)      MainData.EllipseModePlane1      = Font_Type; 
        if (MainData.Tool == TOOL_RECTANGLE)    MainData.RectangleModePlane1    = Font_Type; 
        if (MainData.Tool == TOOL_FRAME)        MainData.FrameModePlane1        = Font_Type; 
    
    } 
}

?

J'ai essayé de désimbriquer les conditions indépendantes les unes des autres pour factoriser le code, mais il est tard, j'ai pu me tromper Bref, l'idée est là.
Après, une autre idée, ça serait, à la place d'avoir des champs xxxPlane0 et xxxPlane1, d'avoir un tableau xxxPlane[PLANE_COUNT], et de faire un truc du genre :

Headers :

typedef enum Plane_Index_e
{
    PLANE_0,
    PLANE_1,
    PLANE_COUNT     /* Comme l'enum commence à 0 , PLANE_0 = 0, PLANE_1 = 1 et PLANE_COUNT = 2, ça tombe bien non ? */
}
Plane_Index_t;

typedef struct Type_De_Main_Data_s
{
    Font_Type_t LineModePlane[PLANE_COUNT];
    Font_Type_t CircleModePlane[PLANE_COUNT];
    Font_Type_t EllipseModePlane[PLANE_COUNT];
    Font_Type_t RectangleModePlane[PLANE_COUNT];
    Font_Type_t FrameModePlane[PLANE_COUNT];
}
Type_De_Main_Data_t;

code :

Type_De_Main_Data_t MainData;
Font_Type_t         Font_Type;
Plane_Index_t       Plane_Index;
Boolean_t           Update_Font_Type;

if (Key == KEY_MODE) 
{ 
    MenuResult = DrawMenu(&ModeMenu,DScreen);
    MenuResult2 = DrawMenu(&ModeMenuLP,DScreen);

    if (MenuResult2 == 1) 
    { 
        Font_Type = A_NORMAL;
    } 
    else if (MenuResult2 == 2) 
    { 
        Font_Type = A_REVERSE; 
    } 
    else if (MenuResult2 == 3) 
    { 
        Font_Type = = A_XOR; 
    } 
    else
    {
        Font_Type = -1; /* à remplacer par un code d'erreur nommé */
    }

    if (MenuResult == 1) 
    { 
        Plane_Index = PLANE_0;
        Update_Font_Type = TRUE;      
    } 
    else if (MenuResult == 2) 
    { 
        Plane_Index = PLANE_1;
        Update_Font_Type = TRUE;
    } 
    else
    {
        Update_Font_Type = FALSE;
    }

    if ((Font_Type != -1) && (Update_Font_Typ == TRUE))
    {
        if (MainData.Tool == TOOL_LINE)         MainData.LineModePlane      [Plane_Index] = Font_Type; 
        if (MainData.Tool == TOOL_CIRCLE)       MainData.CircleModePlane    [Plane_Index] = Font_Type; 
        if (MainData.Tool == TOOL_ELLIPSE)      MainData.EllipseModePlane   [Plane_Index] = Font_Type; 
        if (MainData.Tool == TOOL_RECTANGLE)    MainData.RectangleModePlane [Plane_Index] = Font_Type; 
        if (MainData.Tool == TOOL_FRAME)        MainData.FrameModePlane     [Plane_Index] = Font_Type; 
    }
}

Dernières considérations : tu peux aussi remplacer ces conditions par des switch (là j'ai gardé tes if).
Enfin, tu peux carrément faire un tableau indexé par tes MenuResult qui contient les constantes qui vont bien, et aller chercher la valeur à la main, genre :

Enfin pour de vrai, ce n'est pas possible de t'arranger pour que tes DrawMenu retournent directement La bonne valeur de Plane_Index et de Font_Type ?

(code non compilé/testé, juste pour l'exemple)
(méga cross)

Edit : et perso j'aurais aussi fait un tableau à deux dimensions comme Kevin le suggère

Les switches donnent aussi un code meilleur (plus petit et plus rapide) qu'une suite de if si tes valeurs sont suffisamment denses (c'est-à-dire plus proches de 1, 2, 3 que de -32768, 0, 32767 ).

l'avantage du switch tu veux dire ? bon c'est vrai que la syntaxe du switch est très pourrie en C, avec le break et tout, m'enfin recopier à chaque fois MainData.Tool ça me semble encore plus lourd, mais bon ça c'est une question de goût... (bon et puis l'absence de else me fait mal aux yeux même si je sais que c'est sûrement optimisé ) C'est peut-être aussi que tu n'as pas l'habitude du C, quand on voit un switch on sait immédiatement ce que ça fait, quand on voit une séquence de if, c'est moins évident a priori.

Mais je parlais surtout de la séparation en deux pour éviter de recopier ton code trois fois hein, le switch vs. if est un point secondaire
edit : voilà, comme dit Ximoon, j'ai eu la flemme de le faire en entier en ./346 c'est peut-être pour ça que tu ne voyais pas à quel point c'était plus lisible ^^

Note : dans le dernier exemple j'ai rajouté des codes de contrôle car je ne connais pas le range des données retournées par ta fonction DrawMenu, mais ces codes peuvent éventuellement sauter si tu maîtrises bien le tout. Si ce n'est pas le cas d'ailleurs, ton code précédent est potentiellement bugué

Kevin Kofler (./356) :
Les switches donnent aussi un code meilleur (plus petit et plus rapide) qu'une suite de if si tes valeurs sont suffisamment denses (c'est-à-dire plus proches de 1, 2, 3 que de -32768, 0, 32767 ).

Ok, merci du tip.

Ximoon (./355) :
Edit : et perso j'aurais aussi fait un tableau à deux dimensions comme Kevin le suggère

Je pense que je vais réorganiser mes données dans ce sens, là j'ai déclaré plein de shorts à la suite, sans savoir comment j'allais y lire et y accéder.

Ximoon (./355) :
Enfin pour de vrai, ce n'est pas possible de t'arranger pour que tes DrawMenu retournent directement La bonne valeur de Plane_Index et de Font_Type ?

non, DrawMenu() retourne l'élément sélectionné d'un menu affiché, ou 0. Ca peut servir à autre chose, au pire je pourrais faire un wrapper, mais autant tout faire au même endroit, ici-même. Et je t'ai induit en erreur dans la recomposition de mon code, c'est pas MenuResult2 = DrawMenu(&ModeMenuLP,DScreen), mais MenuResult2 = DrawMenu(&ModeMenuDP,DScreen); qu'il faut lire... Mais ça devrait pas changer grans chose, dans tous les cas, je m'y suis très mal pris.

Ah zut

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 )