techniques optimisations ? - Page 2

./28 : oui on a compris

djflex (./20) :
Ok je vais essayer avec x & 15 == 0 (ou !(x&15) en fait, c'est pas plus rapide ?)

Comme ça a été dit par Kevin, le code généré sera le même, donc la vitesse équivalente.
En revanche, moi je trouve que c'est plus lisible d'écrire x & 15 == 0, car c'est bien ce que tu cherches à savoir : si le reste de la division est nul.
J'utilise l'opérateur ! sur des variables ou des expressions booléennes seulement. Genre if(!dead).

AMHA quelqu'un qui écrit ==0 en C est un programmeur Java qui fait du C le dimanche.

Pourquoi

Parce que ça ne sert à rien d'écrire ça en C, l'opérateur ! sert à ça.

Non.

Ou quelqu'un qui code proprement ?
Pour moi quelqu'un qui n'écrit pas "==0" en C est quelqu'un qui code tout seul chez lui le dimanche Toi qui es mainteneur, je ne comprends pas comment tu peux ne pas conseiller d'utiliser un code le plus lisible et proche de ce qu'on veut possible (cf ./32 ).
Pour revenir au monde industriel que j'ai à cœur (la vie réelle, quoi), toute boîte qui se respecte et qui a envie de maintenir son code sur le long terme interdit ce genre de pratique par des rêgles de codage strictes. Pour citer celle que je dois respecter en ce moment (pour de l'aéronautique, au risque de me répéter), toute condition de test "if" doit être explicite. Et c'est salutaire quand on doit reprendre le code d'un autre.

edit : cross, réponse au ./33

Sasume (./32) :
x & 15 == 0,

Pas d'accord. Et les parenthèses ? La priorité de % n'est pas la même que & !

./37:

PpHd (./38) :

Sasume (./32) :
x & 15 == 0,

Pas d'accord. Et les parenthèses ? La priorité de % n'est pas la même que & !

Problème qu'on n'a pas avec !, parce qu'il faut toujours les parenthèses.

Et personnellement j'aime le code court, je préfère aussi 1[(short*)p] à ((short*)p)[1] parce que ça économise une paire de parenthèses.

Kevin Kofler (./39) :
1[(short*)p]

J'avais déjà vu ça dans ton code... Je suis prêt à parier que la majorité des programmeurs C (en incluant les bons) ne saurait même pas dire en première lecture ce que fait ce code... Et c'est exactement l'inverse d'un code propre, c'est pousser la norme du langage dans l'absurde. En toute logique, de mon point de vue, ce bout de code ne devrait même pas être valide.

./37> je sais pas pourquoi tu continues de te fatiguer a repeter la meme chose... depuis le temps que ca dure, si un jour il doit descendre de son petit nuage ca sera tres probablement pas ici en lisant des posts

(d'ailleurs, a propos des "!" ou "== 0", il faut signaler les macros "not", "or", "and", etc.. qui font partie d'un STANDARD (whoaa.. sisi ^^ (bon je sais plus lequel par contre )), et qui sont obligatoires en suivant les normes de certaines boites... (bon, apres, preference personnelle, a choisir, je prefere les operateurs normaux pour diverses raisons, mais bon pourquoi pas..))
en tout cas pour les "!", idem, je reserve ca aux booleens (que ca soit des types ou des conditions, ecrire (a > b) == 0, c'est moche, mais ecrire !(a - b), c'est moche aussi)
ah si, a l'exception des tests avec des flags, ou le resultat est cense etre booleen, meme si en pratique l'operation ne l'est pas. mais c'est plus une notation conceptuelle qu'autre chose, et, AMHA, c'est plus lisible.
(ceci dit, pour tester la nullite ou la non nullite des pointeurs, depuis un certain temps, j'utilise systematiquement == NULL ou != NULL (meme si "!" marche parfaitement aussi, mais le code final est quand meme nettement plus lisible avec les NULL explicites))
surtout que lorsque tu parcours du code, un tout petit "!", c'est quand meme super facile a louper

EDIT: cross...
./39> omg...

hum t'es sur que c'est pas plutot parceque ca te donne l'impression d'etre l33t d'ecrire ca que tu t'en sers? (non parceque franchement la... )

Problème qu'on n'a pas avec !, parce qu'il faut toujours les parenthèses.

bah... heu.. non.
! x & y est tout aussi valide que x & y == 0... argument bidon..

momotte (./41) :

hum t'es sur que c'est pas plutot parceque ca te donne l'impression d'etre l33t d'ecrire ca que tu t'en sers? (non parceque franchement la... )

Et après on s'étonne que j'ai tellement ralé avant de me lancer dans le code de son ld-tigcc

si les normes en question c'est MISRA et compagnie c'est parfois aussi que les codes du dimanche... Certaines ont été faites par des extrémistes, et en plus quand la boite adapte le style, genre on a pas le droit à un seul goto...

./44 > là où je suis, pas de goto, ce qui ne me choque pas le moins du monde (code plus facile à relire et à comprendre quand les blocs sont bien structurés), pas de break sauf pour les switch/case, là encore rien à dire même si parfois on préférerait, et enfin pas d'opérateur ternaire, sauf dans les macros. Sur ce point, je suis plus critique, mais au final on se débrouille très bien sans.

Exemple d'extrêmisme qui a traîné jusqu'à mes oreilles : redéfinir les constantes numériques... dans le genre : #define ONE (1)

lol

sauf que nous on est en embarqués, et on SAIT (testé) que le code serait plus performant avec des break et des gotos.

autre exemple: ils veulent nous faire misraîser des modules FS linux

Martial Demolins (./45) :
Oué bon tu peux parler, t'as vu tes sources de PreOS?

Oué. Superbe

Martial Demolins (./50) :
-> faut ':' au bout des labels

Pas en assembleur 68000: il suffit qu'il soit situé en début de ligne

Martial Demolins (./50) :
alors :
-> choisis des nom de labels plus explicites (next ?)
-> plus variés (je suis allé jusqu'à Next10 )
-> t'es toujours entre 36 conventions de nommage pour les labels et les variables -> faut ':' au bout des labels

1+2 Un label local est local à son contexe. Un next dans un contexe est très explicité.
3. La convention indique la classe de la ressource.
4. Non

momotte (./42) :

Problème qu'on n'a pas avec !, parce qu'il faut toujours les parenthèses.

bah... heu.. non.! x & y est tout aussi valide que x & y == 0... argument bidon..

"toujours" veut bien dire ce que ça veut dire:
x % 16 == 0 fait ce qu'on veut, mais pas x & 16 == 0.
Ni !x % 16, ni !x & 15 ne font ce qu'on veut.
Donc avec ! on a toujours le réflexe de mettre les parenthèses.

PpHd (./43) :
Et après on s'étonne que j'ai tellement ralé avant de me lancer dans le code de son ld-tigcc

Une grande partie du code a été écrite par Sebastian Reichelt. Et les integer[array], il n'y en a pas dans tous les sens dans ld-tigcc, je ne suis même pas sûr qu'il y en ait même un seul. Je réitère ma demande une ne fois de plus: indique-moi un exemple de code de ld-tigcc que tu juges illisible s'il te plaît. Parce que ld-tigcc est vraiment très bien commenté, avec des noms de variables parlants, des structures de données simples (tout est liste chaînée, et parcouru le plus souvent avec une macro foreach) etc.

Ximoon (./51) :
Pas en assembleur 68000: il suffit qu'il soit situé en début de ligne

Pas avec un assembleur antique et obsolète, tu veux dire. L'indentation obligatoire de tout ce qui n'est pas label, on dirait la première version du FORTRAN. C'est normal qu'un assembleur moderne comme GNU as ne fait pas ce genre de présuppositions, totalement casse-c***lles (quand j'ai commencé avec A68k, à chaque fois j'ai voulu mettre des instructions dans la colonne 1 et il m'a jeté, j'ai appris à mettre une espace (oui, une seule, et c'est déjà trop ) devant, mais maintenant j'utilise GNU as et je peux enfin écrire les instructions directement dans la colonne 1 ), même un xdef doit être au moins dans la colonne 2 dans A68k.

"toujours" veut bien dire ce que ça veut dire:
x % 16 == 0 fait ce qu'on veut, mais pas x & 16 == 0.
Ni !x % 16 == 0, ni !x & 15 ne font ce qu'on veut. Donc avec ! on a toujours le réflexe de mettre les parenthèses.

...
deja, tu dois plutot vouloir dire "!x % 16", pas "!x % 16 == 0", et ensuite, premierement, on peut tres bien vouloir ecrire !x & qqch, et deuxiemement, comme pour le "!", on a toujours le reflexe de mettre les parentheses pour le "x & truc == 0" aussi, exactement au meme titre que !x & 15.

les differences de comportement et d'utilisation entre "x & y == 0" et "!x & z" sont tout a fait similaires. dans les deux cas, si tu ne mets pas la parenthese, ca ne fait pas ce que tu veux, mais dans les deux cas aussi, tu peux quand meme vouloir faire ce que fait la version sans parentheses (et c'est a peu pres aussi peu probable (et peu lisible) dans un cas que dans l'autre (a moins que selon toi ca n'aie aucun sens de vouloir ecrire "(!x) & y", mais que ca en aie de vouloir ecrire "x & (y == 0)" ? ))
donc vraiment, si, argument bidon. pour changer...

Kevin Kofler (./53) :

Ximoon (./51) :
Pas en assembleur 68000: il suffit qu'il soit situé en début de ligne

Pas avec un assembleur antique et obsolète, tu veux dire. L'indentation obligatoire de tout ce qui n'est pas label, on dirait la première version du FORTRAN. C'est normal qu'un assembleur moderne comme GNU as ne fait pas ce genre de présuppositions, totalement casse-c***lles (quand j'ai commencé avec A68k, à chaque fois j'ai voulu mettre des instructions dans la colonne 1 et il m'a jeté, j'ai appris à mettre une espace (oui, une seule, et c'est déjà trop ) devant, mais maintenant j'utilise GNU as et je peux enfin écrire les instructions directement dans la colonne 1 ), même un xdef doit être au moins dans la colonne 2 dans A68k.

Et alors ? Je trouve ça très bien, et au moins, c'est la syntaxe officielle

c***lles

on dit "couilles"

COUILLE, subst. fém.
Trivial. Testicule : 1. Le cheval attendait, l'œil stupide. Avril passa le grand soufflet à Armand : − Soufflez-y sur les couilles qu'il se tienne tranquille... petit, tiens-y la jambe...

Kevin Kofler (./53) :
ndique-moi un exemple de code de ld-tigcc que tu juges illisible s'il te plaît. Parce que ld-tigcc est vraiment très bien commenté, avec des noms de variables parlants, des structures de données simples (tout est liste chaînée, et parcouru le plus souvent avec une macro foreach) etc.

Ce n'est pas tellement un code en particulier, mais plutôt qu'il y une grosse barrière pour assimiler l'architecture, les données, les liens entre les données. Et que passer cette barrière est nécessaire même pour faire des modifications très locales.

c'est quand même pas un programme trivial, un éditeur de liens...

C'est quoi ce dico. momotte?
Sinon juste pour troller : j'écrirais ==0 si je veux que le programme soit maintenu après moi, sinon je prendrais !(). (Mais c'est vrai que les unsigned, pour ma part je m'en tape, je suis pas sur TI) ) : Il faut bien se rendre indispensable à l'heure ou "on" bosse pareil/mieux pour 200€/mois.
Kevin : le fortran c'est marrant (sauf les goto) et dans certain cas plus rapide que le C. (ou en tous cas, dans certain cas le programme est plus clair pour la même vitesse d'execution, je sais qu'on peux toujours faire mieux en C, mais le code est quand même moins beau)

moi je mets ! si l'expression est booléenne, sinon, ==0

si ça génère le même code, tant mieux.