Le problème n'est pas un problème de "parse", mais un problème d'algorithme de parse.
Il peut être renommé en comment "parser une ligne, ou j'ai 2 champ sans espace au début, 2 champs sans espace à la fin, et un champ avec espace au milieu ?"
L'une des solutions se trouve dans le titre de mon commentaire....
tu récupère les premiers champs , puis les derniers.
Et le nom de la rue ... c'est le reste :)
Ou alors tu recup les premiers champs, puis tu compte le nombre d'espace que tu as dans le nom de ta rue, et tu enleve les deux derniers champs que tu met dans la ville et le CP.
ou alors ...
Ensuite, je vais faire mon chieur (mais c'est le but de poser des questions : progresser :) ), mais les constantes dans les programmes sur des longueurs de chaine , ou des décisions arbitraires c'est
-> pas beau (es-tu sur de ne jamais avoir de fichier mal formé ? de champ ou de ligne dépassant ?)
-> pas cohérent (tu prend une ligne de 256 octets, et tu cherche 5 champs qui peuvent faire chacun 256 octets...)
-> redondant et pas claire.
-> pas optimum. (imagine que tu dois traiter les adresses des 7 milliards d'êtres humains (ou tout chiffre volontairement important) Faut il mieux consomment 1.25Ko/adresse (>8Go au total) ou moins de 256 octets en moyenne (<1.6Go au total)) ? .
Si tu pense qu'il est "safe" de hardcoder ces limites, tu les mets avec un
#define MAXOCTETLINE 256#define MAXOCTETCHAMP 256
(et j'ai envie de dire idem avec le nom de fichier ...)
Comme ça, si tu as besoin d'en changer tu ne le fais qu'une fois et tu ne risques pas d'en oublier quelque part...
En plus c'est quand meme plus parlant de voir MAXOCTETCHAMP que 256...
Mais il est bien plus propre de ne pas faire de suppositions sur ces limites, et de les attribuer de façon dynamique.
Le peu d'optimisation que tu aurais pu avoir avec des longueur hardcodé, tu l'a perdu car tu fais un malloc.
Ensuite, aucune vérification d'erreur :'(
tu fais quoi si un malloc te renvoie null?
Pour résumer :
-> faire soit même l'algorithme de sélection des champs plutôt que de laisser fscanf tout faire
-> Commencer, dès les premiers programmes, à bien gérer les erreurs . C'est une habitude qui se prend, et crois moi, ça évite de nombreux casse tête
-> Commencer dans un second temps, à prendre les bonnes longueurs pour les données. Ni trop, ni pas assez. Ca permet de trouver plus facilement des erreurs de boundary check (electric fence, valgrind, etc...), limite la conso mémoire, ou simplement que le programme marche sur toutes les données, et pas perdre du temps à comprendre "pourquoi j'ai une adresse tronquée ?"
Même chose : c'est un mode de fonctionnement qui se prend dès le début. Tu crois que ça te fait coder plus lentement, mais vu le temps que tu peux gagner en débug après...
Avoir des longueurs hardcodé peut être tout à fait viable si c'est un choix assumé, mais assez rarement pour des données fournies par l'utilisateur sans contrôle... et encore plus rarement lorsque cet utilisateur est un prof ;)
PS : Question subsidiaire. Que faire si le champ ville contient aussi des espaces? Est-ce jouable ?
# backward....
Posté par briaeros007 . En réponse au message Un petit problème avec mon programme C. Évalué à 1.
Ploup,
Le problème n'est pas un problème de "parse", mais un problème d'algorithme de parse.
Il peut être renommé en comment "parser une ligne, ou j'ai 2 champ sans espace au début, 2 champs sans espace à la fin, et un champ avec espace au milieu ?"
L'une des solutions se trouve dans le titre de mon commentaire....
tu récupère les premiers champs , puis les derniers.
Et le nom de la rue ... c'est le reste :)
Ou alors tu recup les premiers champs, puis tu compte le nombre d'espace que tu as dans le nom de ta rue, et tu enleve les deux derniers champs que tu met dans la ville et le CP.
ou alors ...
Ensuite, je vais faire mon chieur (mais c'est le but de poser des questions : progresser :) ), mais les constantes dans les programmes sur des longueurs de chaine , ou des décisions arbitraires c'est
-> pas beau (es-tu sur de ne jamais avoir de fichier mal formé ? de champ ou de ligne dépassant ?)
-> pas cohérent (tu prend une ligne de 256 octets, et tu cherche 5 champs qui peuvent faire chacun 256 octets...)
-> redondant et pas claire.
-> pas optimum. (imagine que tu dois traiter les adresses des 7 milliards d'êtres humains (ou tout chiffre volontairement important) Faut il mieux consomment 1.25Ko/adresse (>8Go au total) ou moins de 256 octets en moyenne (<1.6Go au total)) ? .
Si tu pense qu'il est "safe" de hardcoder ces limites, tu les mets avec un
(et j'ai envie de dire idem avec le nom de fichier ...)
Comme ça, si tu as besoin d'en changer tu ne le fais qu'une fois et tu ne risques pas d'en oublier quelque part...
En plus c'est quand meme plus parlant de voir MAXOCTETCHAMP que 256...
Mais il est bien plus propre de ne pas faire de suppositions sur ces limites, et de les attribuer de façon dynamique.
Le peu d'optimisation que tu aurais pu avoir avec des longueur hardcodé, tu l'a perdu car tu fais un malloc.
Ensuite, aucune vérification d'erreur :'(
tu fais quoi si un malloc te renvoie null?
Pour résumer :
-> faire soit même l'algorithme de sélection des champs plutôt que de laisser fscanf tout faire
-> Commencer, dès les premiers programmes, à bien gérer les erreurs . C'est une habitude qui se prend, et crois moi, ça évite de nombreux casse tête
-> Commencer dans un second temps, à prendre les bonnes longueurs pour les données. Ni trop, ni pas assez. Ca permet de trouver plus facilement des erreurs de boundary check (electric fence, valgrind, etc...), limite la conso mémoire, ou simplement que le programme marche sur toutes les données, et pas perdre du temps à comprendre "pourquoi j'ai une adresse tronquée ?"
Même chose : c'est un mode de fonctionnement qui se prend dès le début. Tu crois que ça te fait coder plus lentement, mais vu le temps que tu peux gagner en débug après...
Avoir des longueurs hardcodé peut être tout à fait viable si c'est un choix assumé, mais assez rarement pour des données fournies par l'utilisateur sans contrôle... et encore plus rarement lorsque cet utilisateur est un prof ;)
PS : Question subsidiaire. Que faire si le champ ville contient aussi des espaces? Est-ce jouable ?