strtok et "champs" vides

Bonjour,
Je dois découper une chaîne de caractères selon un caractère de séparation, pour cela j'utilise strtok. Tout fonctionne tant que les valeurs entre les séparateurs sont bien renseignées. Mais j'ai des cas où certaines valeurs manquent, et les séparateurs sont alors collés.
Exemple

Code:

---

1 2	10;12;15;6 8;6;;7

---

Le problème c'est que j'ai l'impression que strtok va alors lire la valeur suivant les séparateurs collés, et donc "sauter" la valeur absente. Ce qui du coup me décale tout car je me base sur l'ordre d'apparition des valeurs pour déterminer leur rôle.

Est-ce que vous auriez une idée pour être informé quand même lorsqu'il y a un vide entre 2 séparateurs ?
Merci d'avance.

C'est effectivement une limitation de strtok()

essaye avec strsep() si il existe dans ta libc

Citation:

---

La fonction strsep() a été introduite en remplacement de strtok(), qui ne peut pas traiter les champs vides. Néanmoins strtok() est conforme au C ANSI et est donc plus portable.

---

Je n'ai pas d'erreur d'include pour <string.h>, par contre j'ai une erreur de link avec le symbole "strsep", bizarre :/

Citation:

---

Je n'ai pas d'erreur d'include pour <string.h>

---

Bien sûr. Il s'agit d'un fichier standard donc présent quel que soit le compilateur que tu utilises. Tu voulais dire peut-être que t'as pas d'erreur de compilation mais seulement d'édition des liens ? Normal, la déclaration d'une fonction n'est pas obligatoire en C. Seulement, lorsqu'une fonction n'est pas déclarée, le compilateur suppose qu'il s'agit d'une fonction qui retourne un int. Si la fonction existe dans un des fichiers sources de tes projets mais ne retourne pas un int, le compilateur génèrera une erreur ("déclaration != définition"). Sinon, la fonction sera cherchée pendant l'édition des liens et si elle n'est pas trouvée, l'éditeur des liens génèrera une erreur.

Citation:

---

par contre j'ai une erreur de link avec le symbole "strsep"

---

C'est que cette fonction n'est pas disponible dans l'implémentation que tu utilises ou que tu ne t'es pas lié avec le fichier objet qui la contient, mais c'est plus que certain qu'on est dans le premier cas. Mon intuition me le dit :D.

Si le format est le même pour chaque ligne (nb1;nb2;nb3;nb4), utilise sscanf. Par exemple (première approximation) :

Code:

---

n = sscanf(ligne, "%[0-9];%[0-9];%[0-9];%[0-9]", s1, s2, s3, s4);

---

Où s1, s2, s3, s4 sont des tableaux de char (char s1[51], etc.). Si tout se passe bien, n devra contenir 4 : le nombre de lectures formatées réussies. Utilise ensuite atoi ou strtol pour convertir les chaînes lues en entier. Ici, atoi est plus que suffisant.

Dans le code précédent, la taille des buffers s1, s2, s3, s4 n'est pas renseignée à sscanf => risque de débordement de tampon. Le bon code est donc :

Code:

---

n = sscanf(ligne, "%50[0-9];%50[0-9];%50[0-9];%50[0-9]", s1, s2, s3, s4);

---

Enfin, la véritable bonne solution c'est de se fabriquer un tokenizer adapté à ses besoins ou d'utiliser des fonctions libres de droit en cherchant un peu sur le net.

Merci de ta réponse, l'inconvénient de ta solution est de fixer le nombre de valeurs par ligne, j'aurais préféré garder quelque chose plus flexible (actuellement je boucle avec strtok). Je sens que je vais devoir traiter la chaîne "à la main" donc.

C'est souvent plus pratique de boucler avec strchr, en détruisant la chaîne au passage (remplacement du token par un zéro) et en remplissant au passage un tableau de char* passé en paramètre. C'est portable, rapide, et ça gère les champs vides et/ou composites...

De plus, même si ce n'est plus (trop) un problème avec les compilateurs récents, il faut savoir que strtok n'était habituellement pas compatible avec le multithreading, car elle n'était pas réentrante... Ce qui n'est pas le cas d'une boucle avec strchr.

Merci ! Mais entre temps j'ai fait mon propre truc caractère par caractère. Ca servira peut être à quelqu'un qui cherchera la même chose que moi.

Citation:

---

Envoyé par Mac LAK

De plus, même si ce n'est plus (trop) un problème avec les compilateurs récents, il faut savoir que strtok n'était habituellement pas compatible avec le multithreading, car elle n'était pas réentrante... Ce qui n'est pas le cas d'une boucle avec strchr.

---

"Habituellement" étant un mot-clé ici. La version Microsoft, bien que toujours pas réentrante, restait compatible avec le multithreading, parce qu'elle utilisait du Thread-Local Storage...

Citation:

---

Envoyé par Médinoc

"Habituellement" étant un mot-clé ici. La version Microsoft, bien que toujours pas réentrante, restait compatible avec le multithreading, parce qu'elle utilisait du Thread-Local Storage...

---

Tout à fait. C'était juste pour souligner que, comme d'autres fonctions de la CLib, strtok est une fonction potentiellement "dangereuse" à utiliser... C'est comme "scanf", autre fonction difficile à bien utiliser (= sans risquer les gros bugs à l'exécution) : vaut mieux savoir qu'il y a des risques (et ne pas être surpris) que de croire aveuglément que la fonction est fiable, et devenir fou à chercher une erreur qui n'en est pas une... ;)