🚀 go-pugleaf

Charlie Gordon wrote:

> C'est vraiment d�geulasse de mettre des d�finitions dans un header. 

Non et oui.
Non : non.
Oui, j'aurais du l'appeler .c

> Cela ne manquera pas de t'�tre reproch� par le compilateur si tu ne te
> sers pas de ce
> tableau.

Maintenant, j'ai le truc : (void) rot13;

> De plus ce nom est un peu court, on ne reconnait pas 
> facilement une table de translation, rot13 fait plutot penser � une
> fonction... Utilise plutot un module s�par� pour la table rot13_table
> d�finie comme suit:

Ok, c'est ce que j'ai propos� comme meilleure solution � la fin du post,
tu r�ponds � la vol�e sans faire de backtracking ?

> 
> De plus tu devrais mettre dans ce rot13.c g�n�r� par programme une
> indication de l'architecture cible.

Tu as raison, surtout quand l'architecture cible peut ne pas �tre celle
du syst�me qui l'a g�n�r�e. Remarque tr�s �clair�e.

> 
>> // *INDENT-ON*
> 
> C'est quoi ce truc ?

Gr�ce � tes conseils �clair�s, j'ai d�cid� de changer la pr�sentation de
mes programmes en C, je garde juste les espaces apr�s et avant les
parenth�ses respectivement ouvrantes et fermantes mais j'ai fait
l'effort de supprimer les espaces devant les ';' et je traite les
accolades diff�remment.
J'ai pris un programme au hasard et j'ai voulu voir la diff�rence, je
suis un peu niaiseux mais pas au point de faire les modifs � la main,
j'ai utilis� indent (man indent is your friend).
Par le plus pur des hasards, ce programme utilisait des lookup tables
'tables de consultation ?', dont une que j'ai eu � peine � modifier
pour le besoin de la r�ponse. Chaque ligne du source de la table fait
16 * 5 = 80 caract�res, si ce programme 'indent' avait indent� ce
source (il me l'a d'ailleurs fait avant que je le corrige), il aurait
ajout� un d�calage de 4 (c'est la valeur qu'il me plait d'avoir pour
l'indentation), ce qui aurait fait 84 et aurait �t� un affront
inadmissible � nos anc�tres qui travaillaient sur des cartes perfor�es
de 80 colonnes.
Le programme indent, bien que ne connaissant qu'un minimum du C est
capables de lire les commentaires, moi aussi.
Ce sont des directives � ce programme pour dire qu'il faut s'arr�ter
d'indenter et recommencer � indenter.

> 
> Cette fonction ne modifie pas les tableaux arguments, qui ne sont pas
> du bon type, et devrait prendre la FILE* en argument aussi pour etre
> un peu generique. L'utilisation de size_t comme type de c est
> extr�mement surprenante, pourquoi des variables interm�diaires
> d'ailleurs ?

Ok pour les const, je n'ai pas pris l'habitude de les utiliser et cette
non-habitude est une mauvaise habitude.
Pour le FILE * tu chipotes, il est �vident qu'une telle fonction n'a en
g�n�ral pas pour vocation d'�crire son r�sultat sur stdout, dans
l'ainsi-nomm� monde r�el, elle aurait de toute mani�re une autre
signature. le putchar �tait l� pour montrer si �a marche ou pas.

Pour size_t, je vais y r�fl�chir...

Pour les  variables intermediaires, la raison est simple.
Elle ne se justifie pas dans ce cas et je n'en aurais pas utilis�
ailleurs que sur fclc.
Il arrive dans le monde r�el que des programmeurs �crivent des fonctions
moins triviales et qui font, surtout apr�s maintenance, des 10aines
voire des 100aines de lignes et plus.
Je pense que modifier directement l'argument n'est pas une bonne
habitude quand on �crit un fonction un peu grosse, on peut ensuite
avoir besoin de l'argument dans son �tat originel.
Dans cette fonction, cela ne s'applique pas, mais on est sur fclc, je
pense qu'il est mieux d'�crire comme �a au d�part.

> 
>>     (void) argc;  // Yep !
>>     for ( parg = argv; ( str = *(++parg) ) ; ) {
>>         tr( rot13, str );
>>         putchar( ' ' );
>>     }
> 
> Nope ! utilise plutot une boucle plus simple et plus lisible qui
> utilise argc et argv:
> 
>     int i;
> 
>     for (i = 1; i < argc; i++) {
>         tr(rot13_table, argv[i], stdout);
>         putchar(' ');
>     }

Les go�ts les couleurs toussa...
Et - ping pong - pourquoi i et ne pas d�cr�menter argc ?

> 
>>     putchar( '\n' );
>>     return( EXIT_SUCCESS ) ;
> 
> bouh les parenth�ses !

J'aime les parenth�ses, des fois j'en rajoute m�me expr�s ! Niark !
Dans ce cas j'ai une bonne raison d'en rajouter.
Mettons que sur un source, je change tous les return pax xreturn et
d�finisse :
( juste pour le plaisir de recevoir des flames )
#ifdef DEBUG
#ifdef _GNUC_
#define xreturn( rc ) \
( typeof( rc ) RC = rc; \
        fprintf( stderr, " function %s return %lx\n", _function_, (long)RC );\
        return RC ; \
) 
#else 
        ( return rc )
#endif _GNUC_
#else
        ( return rc )
#endif DEBUG

Enfin de m�moire un truc comme �a, pour _function_, je ne sais plus tr�s
bien.

>>
>> Une autre solution, meilleure, serait de compiler s�par�ment la table
>> et de la mettre dans une biblioth�que avec laquelle on linkerait le
>> programme rot13.
> 
> Ou simplement dans un module compil� avec, on a d�j� plusieurs modules
> dans ce petit programme :
> 
> cc -o rot13 rot13.c tr.c rot13_table.c

Non, non des biblioth�ques pour ces donn�es d'une grande importance
strat�gique et communement utilis�es par toutes les applis.