6Fermer8
deleted2Le 23/08/2014 à 21:22
GT Turbo -> Lol grin Evidemment, j'adore toujours autant le 68k, mais on peut aussi faire du C de manière élégante, dans les règles de l'art, simplement, la manière de penser et d'aborder les problèmes est différente. Mais tant qu'on recherche pas l'impossible, on peut rester dans le beau. smile
Zeph (./4) :
- Ta fonction fait en réalité deux choses : elle cherche l'indice d'un élément dans ton tableau, puis une fois qu'elle a cet indice elle supprime l'élément en question. J'aurais tendance à séparer ces deux étapes en deux fonctions différentes, étant donné qu'il est assez probable que tu puisses réutiliser l'une ou l'autre (et même surement les deux)

Bien vu. Je suis au début du codage de ce que je fais, donc a priori, la nécessité que tu décris devrait arriver à un moment où l'autre. smile
Zeph (./4) :
- Selon le nombre d'itérations en moyenne dans la boucle, conserver "*element_count" dans une variable "int" locale pour éviter de déréférencer plusieurs fois pourrait être intéressant

Alors ça je me demandais justment. *element_count n'étant pas déclaré volatile, n'est-il pas considéré comme constant par le compilateur ? aucune fonction n'est appelée dans la boucle.
Zeph (./4) :
- Je ne suis pas sûr qu'il soit garanti que "realloc" ne retourne jamais NULL quand on demande une taille de bloc plus petite (ça ne serait pas très logique, mais ça mérite peut-être d'être vérifié)

realloc peut retourner NULL, tout à fait. Le standard ne garantit rien, même quand on rétrécit un espace. Donc une implémentation de <realloc()> comme <malloc(newsize), memcpy(new, old, size), free(old)> serait parfaitement valide, et pourrait échouer. Cependant, je code pour PedroM et AMS, où ça ne peut pas échouer.
Zerosquare (./2) :
memmove() est optimisée, tu as tout intérêt à l'utiliser quand tu le peux.

En fait, étrangement, l'appel à memmove prend 50 octets de plus que le for ! Et l'itération a de très fortes chances d'être très rapide, pas plus de 10 boucles. Et sur TI, je privilégie en général la place, tandis que le domaine d'utilisation de ce code ne demande pas de vitesse. J'ai donc gardé la version <for>


Brunni -> point de vue très intéressant, j'y répodn un peu plus tard ! C'est en effet un choix, expliquable, qui se pose dès qu'on décide de gérer la mémoire à la main. J'y reviens sous peu. smile