Liste + Incrementation en C - Page 1

Par curiosité, peut-on optimiser ça en une ligne ?

tbl_rtt[int_rtr++]=1;
tbl_rtt[int_rtr]=1;

Bob 64 a écrit :
Par curiosité, peut-on optimiser ça en une ligne ?

tbl_rtt[int_rtr++]=1; tbl_rtt[int_rtr]=1;

Oui.
tbl_rtt[int_rtr++]=1;tbl_rtt[int_rtr]=1;

Ct pas exactement ce à koi je m'attendais

Qqun a une réponse intelligente ?

En changeant le type de données peut-être ?

tbl_rtt[int_rtr++]=1; tbl_rtt[int_rtr]=1;

Pour être sérieux : ((long *)tbl_rtt)[int_rtr++]= 0x00010001;

J'ai même pas eu besoin de chercher, c'est génial .

Merde zdrubal a eu la même idée que moi

ah oué ça affecte les 2 rangs en même temps... ok merci

après compilation ça prends plus, autant ou moins de place ?

2 octets de plus

ah ok c pas génial... faudra que j'essaie quand même, merci

Arf attend remarque, peut-être pas, je me suis basé sur la première ligne !! Il se peut que ça donne un code moins gros en fait. Ca dépend des optimisations de TIGCC.
Le meilleur moyen de savoir c'est de compiler et mater le code généré.

V voir ça tt de suite...

Résultat : 7773 octets partout, il n'y a aucune différence

C'est plus élégant

C plus "pro" c sûr... Mais ça rend la source moins compréhensible aussi...

Essaies {long *plong= (long *)&tbl_rtt[int_rtr++]; *plong= 0x00010001;}

4 octets de plus.

(ce qui ammene le prog à 7777 octets, beau chiffre )

Conclusion : reste à la première implémentation

vi

dommage 7777 c classe comme taille

vive les écritures indigestes !

J'ai découvert que pour ça, le C est encore mieux que le basic

oué, mais c'est au programmeur de savoir quoi utiliser...
si tu veux diffuser ton code, je connais pas gd monde qui va ne serait-ce que essayer de comprendre ça !

Non mais g laissé l'écriture "simple", vu que l'autre n'apporte rien.

Par contre si une écriture illisible me fait gagner ne serait-ce qu'un octet, je la laisse

arf...
essaye directement en ASM alors...
tu pourra spas optimiser plus

ASM... oué mais c un truc grand saut j'ai l'impression

disons que si c'est pr ton truc utilisé à partir du BASIC? l'optimisation n'est pas vraiménet nécessaire (étant donné la llenteur du BASIC)

Quel truc ?

Sinon l'optisation du basic, au contraire... En C même sans beaucoup optimiser on peut sortir quelque chose de potable (j'ai pas dit exellent, j'ai dit potable). Même plutot bien.
Alors qu'en basic c'est même pas la peine d'y penser, un jeu ne sera pas jouable avant d'avoir été optimisé à fond, ou presque. Mais bon ça fait travailler...

un truc en basic restera lent...
tandis qu'en C, il peut doubler de vitesse selon certains choix stratégiques

Un truc en basic restera lent...
> Comparé à un truc en C, oui. Mais comparé au même "truc" non-optimisé, il est bien plus rapide. Je vois souvent ici des programmeurs en C contents d'avoir gagné une frame ou 2 par seconde.
Personnellement je reprends parfois 3 ou 4 fois un programme à zéro pour l'avoir le plus rapide possible.

Il m'arrive aussi souvent de reprendre un prog de 0 pour le rendre plus rapide.
et même en C !!!
et quand je dis gagner 50% de vitesse, je ne plaisante pas