Flanker: il veut pas de reloc car il veut faire du code flash XIP sous pedrom ^^


GC: la réentrance, sur TI, on en a un peu rien à péter si on fait pas de récursivité ^^
c'est pas comme si elle était multithread la bébête

Rah le C, c'est définitivment bon

Je vais pouvoir plus bosser sur les concepts que les registres, sur les algos que sur les pointeurs de pile, et sur l'organisation de mon programme plutôt que sur les cycles.

Mais l'assembleur reste super sympa à coder, et j'imagine parfois inévitable sur une machine comme ça.

Folco (./270) :
Je vais pouvoir plus bosser sur les concepts que les registres, sur les algos que sur les pointeurs de pile, et sur l'organisation de mon programme plutôt que sur les cycles.

eh oui Et encore, le C ça reste bien lourdingue (gestion des strings par exemple )

Folco (./270) :
Mais l'assembleur reste super sympa à coder, et j'imagine parfois inévitable sur une machine comme ça.

En fait des que tu veux toucher à un truc un peu poussé comme le graphisme ou un interpréteur (pour un hypothétique langage X), l'assembleur est très recommandé ouais ^^

Folco : enfin tu découvres la Vraie Religion : le C \o/
(#triprovoc#)

(ceci dit une petite routine asm par ci par là quand le compilo s'en sort pas tout seul, faut pas s'en priver)

Tiens, je t'aurais plutôt pensé javintégriste toi

Tiens, autre chose.

C'est propre ce genre de truc :
while (i = i >> 1) {...}

ie faire l'affectation dans la condition ?

Bah si ça t'évite un code sensiblement plus long, oui c'est un bon choix ("propre" ça ne veut pas dire grand chose à ce niveau).

Par contre il me semble que GCC râle si tu n'ajoutes pas une paire de parenthèse autour. Il fait ça pour être sûr que tu veux bien utiliser une affectation, et que ce n'est pas un "while (i == i >> 1)" avec une faute de frappe.

Non. La boucle for sert un peu à ça (et pourquoi tu n'écris pas >>= ?)

edit (cross) : oui effectivement il faut doubler les parenthèses (et heureusement qu'il y a ce warning d'ailleurs ^^')

mais euh for( ; i; i >>= 1) n'est pas vraiment sensiblement plus long (bon après c'est vrai que le terme de « propre » n'est pas le mieux choisi, disons qu'avec le for ça me semble bien plus lisible)

Ça ne fait pas la même chose, il veut effectuer le décalage et tester la condition de boucle sur le résultat, alors que ton for commence par tester la valeur actuelle avant de la décaler.

Son truc est seulement équivalent à for (; (i >>= 1); ) c'est à dire while ((i >>= 1)) ^^

Ah... ah oui mince autant pour moi (mais bon c'est tordu )

du coup il me semble que c'est équivalent à for (i >>= 1; i; i >>= 1) non ? (qui est certes un peu redondant et un peu plus long, mais me semble néanmoins plus clair, enfin ce que j'en dis...)

Zephyr (./277) :
Ça ne fait pas la même chose, il veut effectuer le décalage et tester la condition de boucle sur le résultat, alors que ton for commence par tester la valeur actuelle avant de la décaler.

Ah merci, je commançais à me demander ^^

Zephyr (./277) :
c'est à dire while ((i >>= 1))

Voilà, c'est bien ça que je veux. Ca me fait gagner une constante dans une opération, c'est parfait.

Merci encore (et encore (etc...)) pour vos avis.

Faut faire attention aux écritures 'compressées'. Si on peut éviter de faire une affectation et un test en même temps dans une boucle, ça sera toujours mieux.

, je trouve toujours pas ce truc très lisible (si je relis le topic dans 6 mois je risque de refaire la même erreur d'interprétation )

Moi, je suis pour ce genre d'écritures, pourquoi écrire quelque chose de long quand on peut faire plus court? (Mais évidemment, i = i >> 1 est moche pour la même raison, comme déjà évoqué, >>= sert à ça.)

Kevin Kofler (./282) :
pourquoi écrire quelque chose de long quand on peut faire plus court?

Ouais, par exemple pourquoi donner des noms de plus de deux lettres aux fonctions, à moins d'en avoir plus de 26² ?
c'est débile comme argument, surtout que si tu aimes la concision faut pas programmer en C
Je préfère faire concis en général, mais il y a des limites quoi ^^

Sally (./283) :
Ouais, par exemple pourquoi donner des noms de plus de deux lettres aux fonctions, à moins d'en avoir plus de 26² ?

C'est bien pour ça que la macro appelée en général Q_89_92 ou C_89_92 dans les programmes de Zeljko et de la TICT s'appelle juste Q dans Backgammon.

Oui mais toi on t'a déjà dit 100 fois que tu ne savais pas coder proprement, entre tes macro "Q" et tes "indice[tableau]", pas la peine de le rappeler une fois de plus

2[(short*)p] est plus court que ((short*)p)[2] (et ça ne marche pas sans ces parenthèses supplémentaires), je n'y peux rien.

et tellement plus moche

Sally (./278) :
Ah... ah oui mince autant pour moi (mais bon c'est tordu )

du coup il me semble que c'est équivalent à for (i >>= 1; i; i >>= 1) non ? (qui est certes un peu redondant et un peu plus long, mais me semble néanmoins plus clair, enfin ce que j'en dis...)

Oué mais la version claire ce serait:
for (; i > 1; i /= 2)
Avec i non signé, bien sûr. Mais ça reste assez horrible à lire globalement, surtout que i désigne habituellement un index et devrait donc évoluer linéairement. Sinon >>= 1 peut être mieux pour mettre l'emphase sur le côté logique de l'opération.

Ben non ta version est décalée d'un cran (même si contrairement à celle que j'avais mise au début elle fait le bon nombre d'itérations)

Arf oué... quelle horreur en fait Dans ce cas je pense que je ferais quand même:

i >>= 1; 
while (i != 0) { 
    // Traitement 
    i >>= 1; 
}

Par question de clarté (la preuve on est tous tombés dans le panneau à part Zéphyr). Les for sont facilement illisibles en C si elles n'ont pas leur forme standard. J'ai d'ailleurs un collègue de classe qui ADORE faire des boucles for sans corps, je te laisse imaginer le truc...

J'aime bien les while (*++p); moi aussi.

Pas terrible je trouve. while (*p++) passe encore puisque c'est habituel (mais c'est encore moins compréhensible, à priori on ne sait pas si ça incrémente ce qu'il y a à l'adresse p ou p lui même après avoir lu ce qu'il y a à cette adresse) tout comme while (i--) mais perso je me limite vraiment à ça, et uniquement dans le traitement de chaînes de caractères ou de blocs mémoire en général...
Sinon tu peux aussi faire if (f = fopen(...)), mais sinon l'affectation dans les conditions en général c'est crade.

./293 Plus illisible que ça tu meurs. Au moins ça permet d'éviter une reprise de son code et de faire de la maintenance. C'est les seuls points positifs que j'arrive à trouver !
Coder aujourd'hui comme des crados des optimisations que le compilateur assume très bien, c'est totalement stupide. Prévilégiez la maintenance du code aux optimisations !

Malheuresement le C est trop permissif.
Avoir ce genre de paradigme est 100% mieux je trouve:

 
while (eof(s) == false) { 
  char c = getCurrent(s); 
  // Traitement 
  next(s); 
} 

Beurk, == false. On se demande pourquoi l'opérateur ! a été inventé.

Une abération de plus après == ça change pas grand chose. Tout comme le sont les >>=, i+=*p++>>k (ça existe ce genre de code).

Ta boucle peut s'écrire: for (;!eof(s);next(s)) { …

Même sur PC, Kevin est pour l'optimisation taille.