FarewellLe 23/08/2014 à 21:22
GT Turbo -> Lol 
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. 
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.
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.
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.
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.
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. 
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.
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.