Les soucis de "strtok()" - C - Programmation
Marsh Posté le 01-06-2006 à 19:23:40
Je n'aime pas strtok(), en conséquence de quoi j'ai créé dans ma bibliothèque perso une fonction de découpage de chaîne en une liste doublement chaînée de "mots", qui ne modifie pas la chaîne initiale.
C'est un peu plus long de traitement (micro-optimisation toussa ), mais plus souple je trouve, et du coup ce genre de traitement que tu décris en devient plus simple.
Marsh Posté le 01-06-2006 à 19:40:58
http://www.linux-kheops.com/doc/ma [...] tok.3.html
regarde du côté de strtok_r
C'est vrai que c'est tricky, mais c'est le genre de problème qui arrive très souvent quand on n'a pas le courage de lire la doc (et je parle en connaissane de cause ;-)
Marsh Posté le 01-06-2006 à 22:23:17
simple_stupid a écrit : http://www.linux-kheops.com/doc/ma [...] tok.3.html |
J'avais vu la doc. Elle parle d'environnement multi thread donc j'avais pas trop percuté, je ne travaille qu'en mono tâche. Mais le pb est répercuté aussi dans l'environnement "empilement de fonctions" et là, si je dois me demander avant d'utiliser "strtok" si je vais pas avoir un pb avec une fonction descendante, ça me fait plus ch...
J'ai noté "strtok_r". Il va juste falloir que j'apprenne à l'utiliser
Je me demande s'il y a d'autres fonctions qui posent des pb de ce style...
Marsh Posté le 02-06-2006 à 09:40:34
Toutes celles qui utilisent un buffer statique.
La seule qui me vient à l'esprit là c'est inet_ntoa()
Marsh Posté le 02-06-2006 à 14:01:18
dans la bibliotheque standard il y en a pas mal (tmpnam, asctime, ctime...), toutes sont signalées comme non réentrantes et certaines sont depreciées
Marsh Posté le 02-06-2006 à 18:42:52
Sve@r a écrit : J'ai eu un soucis aujourd'hui avec "strtok()". |
Force 9 sur l'Echelle de Goret.
http://mapage.noos.fr/emdel/goret.htm
Marsh Posté le 03-06-2006 à 11:19:22
simple_stupid a écrit : Toutes celles qui utilisent un buffer statique. |
skelter a écrit : dans la bibliotheque standard il y en a pas mal (tmpnam, asctime, ctime...), toutes sont signalées comme non réentrantes et certaines sont depreciées |
En fait, il ne suffit pas que la fonction renvoie un buffer statique. getenv() le fait aussi et cela interdit juste de faire un truc de ce style
Code :
|
Bon, je dis "juste" mais c'est déjà pas mal comme restriction. J'imagine le pauvre débutant qui fait ça et qui ne comprend pas pourquoi il obtient 2 fois la même chose, il a de quoi s'arracher les cheveux
Mais "strtok()" va plus loin. Elle utilise aussi un buffer statique mais elle s'en re sert lors de l'appel suivant. C'est ce genre de fonction dont je me demandais s'il y en avait d'autre...
Marsh Posté le 03-06-2006 à 11:46:55
Ok, je croyais que tu voulais dire "dont on ne peut pas interlacer les utilisations".
En fait, on s'en doute un peu avec strtok(), parce qu'elle mémorise la chaîne d'un appel sur l'autre. Je pense que le jour où on utilise une telle fonction, on peut s'en douter.
Marsh Posté le 01-06-2006 à 19:12:34
J'ai eu un soucis aujourd'hui avec "strtok()".
J'avais fait une fonction qui convertit une chaîne composée de nombres séparés par un caractère (style "10:20:30" ) en structure contenant chaque nombre dans un tableau. J'utilisais donc gaillardement "strtok" et remplissais ma structure dans une boucle. Jusque là, ok
J'ai eu ensuite à traiter un fichier contenant sur chaque ligne plusieurs de ces suites de nombres, séparés par une virgule, style "10:20:30,40:50:60". Je prends donc ma ligne, et là, je lance "strtok" pour découper mes suites. Et puis chaque suite je la passe à ma fonction qui, elle aussi, utilise "strtok" pour découper chaque nombre. Et là, gros pb. Les "strtok()" ne peuvent pas s'empiler et j'ai eu n'importe quoi.
J'imagine que la fonction doit contenir un pointeur static qui mémorise le dernier emplacement pour repartir du même endroit lors de l'appel suivant. Tant que les appels se suivent séquentiellement, tout va bien. Mais s'il faut les empiler, ça va plus !!!
Conclusion: strtok c'est un bel outil, mais il faut être très prudent avec...
---------------
Vous ne pouvez pas apporter la prospérité au pauvre en la retirant au riche.