je suis en train de faire un petit programme client et serveur qui echange
des messages. Dans cetains messages il y a deux valeur separer par des deux
points.
ex:
valeurun:valeurdeux
j'aimerais savoir si sscanf permet de gerer le separateur : ou faut il
utiliser une autre fonction? j'ai utilise sscanf("%s:%s", var1, var2); mais
ca ne marche pas.
memcpy() ne met pas de 0 final. strncat() le fait. Le jour où j'ai découvert ça (en parcourant c.l.c, i y a 4 ou 5 ans), ma vie a changé !
Il suffit souvent de memcopier un octet de plus pour avoir un zéro...
Emmanuel Delahaye
Harpo wrote on 27/04/05 :
<...>le problème vient du fait que 25 ans après ces fontions soient des standarts et qu'il y ait encore des gens qui les utilisent.
Question de formation, uniquement. Je me bat pour faire monter le niveau. Certains partent en courant, d'autres se moquent, d'autres, (les plus nombreux, j'espère), en tire quelque chose.
Je ne connais pas tous ces bouquins, mais je crois que je suis d'accord.
TU devrais!
Ecrire du bon code n'est pas excessivement lié au langage mais surtout à la volonté d'en écrire, le C permet cela et il est facile voire agréable de s'astreindre à écrire du code lisible.
Exactement. Le C, comme beaucoup de langages, permet le meilleur comme le pire. Le problème n'est pas le langage, mais celui qui s'en sert. Un langage n'est qu'un outil (tranchant).
La solidité, la lisibilité, la maintenabilité, la réusabilité tiennent sans doute en partie au langage
pas du tout (enfin, un peu quand même, sans pointeurs de fonctions, je suis perdu, ou je passe en assembleur !)
mais surtout au design et le C permet de faire des choses claires si on veut faire un peu d'effort.
Absolument. Ca ne demande qu'un peu de méthode, de rigueur, et, soit beaucoup d'expérience pour les autodidactes comme moi, soit une bonne formation. D'après ce que je vois, la formation n'est pas bonne (enfin, ici, et sur d'autres forums, on ne voit que les problèmes...).
Ceci dit, il y a des langages qui permettent de le faire plus facilement et limitent C à une niche écologique en dehors de laquelle il ne serait pas avisé de l'utiliser.
Sais pas. On peut tout construire en C, y compris des fonctions de très haut niveau... Certains ont franchi le pas et ont bati des interpréteurs objets avec le C (Python, Ruby etc.)
Sinon, GTK est un bon exemple de ce que peut faire une bonnne bibliothèque écrite en C pour construire des programme GUI (portabkes en plus, ce qui ne gâche rien)...
Ok, Python et Ruby savent aussi faire ça...
-- Emmanuel The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html The C-library: http://www.dinkumware.com/refxc.html
"Clearly your code does not meet the original spec." "You are sentenced to 30 lashes with a wet noodle." -- Jerry Coffin in a.l.c.c++
Harpo wrote on 27/04/05 :
<...>le problème vient du fait que 25
ans après ces fontions soient des standarts et qu'il y ait encore des
gens qui les utilisent.
Question de formation, uniquement. Je me bat pour faire monter le
niveau. Certains partent en courant, d'autres se moquent, d'autres,
(les plus nombreux, j'espère), en tire quelque chose.
Je ne connais pas tous ces bouquins, mais je crois que je suis d'accord.
TU devrais!
Ecrire du bon code n'est pas excessivement lié au langage mais surtout à
la volonté d'en écrire, le C permet cela et il est facile voire
agréable de s'astreindre à écrire du code lisible.
Exactement. Le C, comme beaucoup de langages, permet le meilleur comme
le pire. Le problème n'est pas le langage, mais celui qui s'en sert. Un
langage n'est qu'un outil (tranchant).
La solidité, la lisibilité, la maintenabilité, la réusabilité tiennent
sans doute en partie au langage
pas du tout (enfin, un peu quand même, sans pointeurs de fonctions, je
suis perdu, ou je passe en assembleur !)
mais surtout au design et le C permet
de faire des choses claires si on veut faire un peu d'effort.
Absolument. Ca ne demande qu'un peu de méthode, de rigueur, et, soit
beaucoup d'expérience pour les autodidactes comme moi, soit une bonne
formation. D'après ce que je vois, la formation n'est pas bonne (enfin,
ici, et sur d'autres forums, on ne voit que les problèmes...).
Ceci dit, il y a des langages qui permettent de le faire plus facilement
et limitent C à une niche écologique en dehors de laquelle il ne serait
pas avisé de l'utiliser.
Sais pas. On peut tout construire en C, y compris des fonctions de très
haut niveau... Certains ont franchi le pas et ont bati des
interpréteurs objets avec le C (Python, Ruby etc.)
Sinon, GTK est un bon exemple de ce que peut faire une bonnne
bibliothèque écrite en C pour construire des programme GUI (portabkes
en plus, ce qui ne gâche rien)...
Ok, Python et Ruby savent aussi faire ça...
--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html
"Clearly your code does not meet the original spec."
"You are sentenced to 30 lashes with a wet noodle."
-- Jerry Coffin in a.l.c.c++
<...>le problème vient du fait que 25 ans après ces fontions soient des standarts et qu'il y ait encore des gens qui les utilisent.
Question de formation, uniquement. Je me bat pour faire monter le niveau. Certains partent en courant, d'autres se moquent, d'autres, (les plus nombreux, j'espère), en tire quelque chose.
Je ne connais pas tous ces bouquins, mais je crois que je suis d'accord.
TU devrais!
Ecrire du bon code n'est pas excessivement lié au langage mais surtout à la volonté d'en écrire, le C permet cela et il est facile voire agréable de s'astreindre à écrire du code lisible.
Exactement. Le C, comme beaucoup de langages, permet le meilleur comme le pire. Le problème n'est pas le langage, mais celui qui s'en sert. Un langage n'est qu'un outil (tranchant).
La solidité, la lisibilité, la maintenabilité, la réusabilité tiennent sans doute en partie au langage
pas du tout (enfin, un peu quand même, sans pointeurs de fonctions, je suis perdu, ou je passe en assembleur !)
mais surtout au design et le C permet de faire des choses claires si on veut faire un peu d'effort.
Absolument. Ca ne demande qu'un peu de méthode, de rigueur, et, soit beaucoup d'expérience pour les autodidactes comme moi, soit une bonne formation. D'après ce que je vois, la formation n'est pas bonne (enfin, ici, et sur d'autres forums, on ne voit que les problèmes...).
Ceci dit, il y a des langages qui permettent de le faire plus facilement et limitent C à une niche écologique en dehors de laquelle il ne serait pas avisé de l'utiliser.
Sais pas. On peut tout construire en C, y compris des fonctions de très haut niveau... Certains ont franchi le pas et ont bati des interpréteurs objets avec le C (Python, Ruby etc.)
Sinon, GTK est un bon exemple de ce que peut faire une bonnne bibliothèque écrite en C pour construire des programme GUI (portabkes en plus, ce qui ne gâche rien)...
Ok, Python et Ruby savent aussi faire ça...
-- Emmanuel The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html The C-library: http://www.dinkumware.com/refxc.html
"Clearly your code does not meet the original spec." "You are sentenced to 30 lashes with a wet noodle." -- Jerry Coffin in a.l.c.c++
Emmanuel Delahaye
Charlie Gordon wrote on 27/04/05 :
Essayez avec vos propres projets, ou ceux dont vous avez les sources sous la main, c'est rare que strncpy ou strncat n'y soit pas utilisé de façon erronée.
Je te laisse regarder...
http://mapage.noos.fr/emdel/clib.htm
-- Emmanuel The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html The C-library: http://www.dinkumware.com/refxc.html
"There are 10 types of people in the world today; those that understand binary, and those that dont."
Charlie Gordon wrote on 27/04/05 :
Essayez avec vos propres projets, ou ceux dont vous avez les sources sous la
main, c'est rare que strncpy ou strncat n'y soit pas utilisé de façon
erronée.
Je te laisse regarder...
http://mapage.noos.fr/emdel/clib.htm
--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html
"There are 10 types of people in the world today;
those that understand binary, and those that dont."
Essayez avec vos propres projets, ou ceux dont vous avez les sources sous la main, c'est rare que strncpy ou strncat n'y soit pas utilisé de façon erronée.
Je te laisse regarder...
http://mapage.noos.fr/emdel/clib.htm
-- Emmanuel The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html The C-library: http://www.dinkumware.com/refxc.html
"There are 10 types of people in the world today; those that understand binary, and those that dont."
Emmanuel Delahaye
cedric wrote on 27/04/05 :
Emmanuel Delahaye wrote:
memcpy() ne met pas de 0 final. strncat() le fait. Le jour où j'ai découvert ça (en parcourant c.l.c, i y a 4 ou 5 ans), ma vie a changé !
Il suffit souvent de memcopier un octet de plus pour avoir un zéro...
Pas quand tu fais une extraction de sous-chaine...
-- Emmanuel The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html The C-library: http://www.dinkumware.com/refxc.html
"Mal nommer les choses c'est ajouter du malheur au monde." -- Albert Camus.
cedric wrote on 27/04/05 :
Emmanuel Delahaye wrote:
memcpy() ne met pas de 0 final. strncat() le fait. Le jour où j'ai
découvert ça (en parcourant c.l.c, i y a 4 ou 5 ans), ma vie a changé !
Il suffit souvent de memcopier un octet de plus pour avoir un zéro...
Pas quand tu fais une extraction de sous-chaine...
--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html
"Mal nommer les choses c'est ajouter du malheur au
monde." -- Albert Camus.
memcpy() ne met pas de 0 final. strncat() le fait. Le jour où j'ai découvert ça (en parcourant c.l.c, i y a 4 ou 5 ans), ma vie a changé !
Il suffit souvent de memcopier un octet de plus pour avoir un zéro...
Pas quand tu fais une extraction de sous-chaine...
-- Emmanuel The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html The C-library: http://www.dinkumware.com/refxc.html
"Mal nommer les choses c'est ajouter du malheur au monde." -- Albert Camus.
Richard Delorme
Tu as raison, mais il faut être pragmatique : quand un OP demande comment utiliser scanf() pour faire un split() de chaines, je ne suis pas de ceux qui proposent le format %[^:] , je préconise d'utiliser strchr() et d'éviter scanf().
Où est cette solution qui préconise strchr ? Celle que j'ai vu, est signé Yves Roman, et n'est pas complètement satisfaisante : écrit dans la chaine de départ, ne vérifie pas grand chose, lente (parcours 2 fois la chaine), longue (7 lignes contre 1 pour le sscanf), etc.
-- Richard
Tu as raison, mais il faut être pragmatique : quand un OP demande comment
utiliser scanf() pour faire un split() de chaines, je ne suis pas de ceux qui
proposent le format %[^:] , je préconise d'utiliser strchr() et d'éviter
scanf().
Où est cette solution qui préconise strchr ?
Celle que j'ai vu, est signé Yves Roman, et n'est pas complètement
satisfaisante : écrit dans la chaine de départ, ne vérifie pas grand
chose, lente (parcours 2 fois la chaine), longue (7 lignes contre 1 pour
le sscanf), etc.
Tu as raison, mais il faut être pragmatique : quand un OP demande comment utiliser scanf() pour faire un split() de chaines, je ne suis pas de ceux qui proposent le format %[^:] , je préconise d'utiliser strchr() et d'éviter scanf().
Où est cette solution qui préconise strchr ? Celle que j'ai vu, est signé Yves Roman, et n'est pas complètement satisfaisante : écrit dans la chaine de départ, ne vérifie pas grand chose, lente (parcours 2 fois la chaine), longue (7 lignes contre 1 pour le sscanf), etc.
-- Richard
Emmanuel Delahaye
Richard Delorme wrote on 27/04/05 :
Tu as raison, mais il faut être pragmatique : quand un OP demande comment utiliser scanf() pour faire un split() de chaines, je ne suis pas de ceux qui proposent le format %[^:] , je préconise d'utiliser strchr() et d'éviter scanf().
Où est cette solution qui préconise strchr ? Celle que j'ai vu, est signé Yves Roman, et n'est pas complètement satisfaisante : écrit dans la chaine de départ, ne vérifie pas grand chose, lente (parcours 2 fois la chaine), longue (7 lignes contre 1 pour le sscanf), etc.
-- Emmanuel The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html The C-library: http://www.dinkumware.com/refxc.html
"C is a sharp tool"
Richard Delorme wrote on 27/04/05 :
Tu as raison, mais il faut être pragmatique : quand un OP demande comment
utiliser scanf() pour faire un split() de chaines, je ne suis pas de ceux
qui proposent le format %[^:] , je préconise d'utiliser strchr() et d'éviter
scanf().
Où est cette solution qui préconise strchr ?
Celle que j'ai vu, est signé Yves Roman, et n'est pas complètement
satisfaisante : écrit dans la chaine de départ, ne vérifie pas grand
chose, lente (parcours 2 fois la chaine), longue (7 lignes contre 1 pour
le sscanf), etc.
Tu as raison, mais il faut être pragmatique : quand un OP demande comment utiliser scanf() pour faire un split() de chaines, je ne suis pas de ceux qui proposent le format %[^:] , je préconise d'utiliser strchr() et d'éviter scanf().
Où est cette solution qui préconise strchr ? Celle que j'ai vu, est signé Yves Roman, et n'est pas complètement satisfaisante : écrit dans la chaine de départ, ne vérifie pas grand chose, lente (parcours 2 fois la chaine), longue (7 lignes contre 1 pour le sscanf), etc.
-- Emmanuel The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html The C-library: http://www.dinkumware.com/refxc.html
"C is a sharp tool"
Harpo
Emmanuel Delahaye wrote:
Harpo wrote on 27/04/05 :
Il faut se dire qu'il faut se débrouiller avec, ce sont des fonctions que l'on doit connaître lorsqu'on les utilise souvent, j'utilise plus facilement memcpy lorsque je le peux.
memcpy() ne met pas de 0 final. strncat() le fait. Le jour où j'ai découvert ça (en parcourant c.l.c, i y a 4 ou 5 ans), ma vie a changé
Je comprends, une telle catharsis ne peut guère se manifester que dans une confrontation à la dimension tragi-comique du 'so-called real world'. Ensisagée dans sa dimension programmatique, elle nous fait dépasser une vision simplement pragmatique dont elle est issue mais à laquelle elle ne peut cependant pas par sa nature intrinsèque être limitée.
Bref, pour moi c'est simple, j'utilise memcpy() quand je connais la longueur et s'il faut que je mette le zero final, je mets le zero final, s'il faut que je mette un n je mets un n, s'il faut faire plaisir je fais plaisir. Ce concept de string avec zero final n'est pas con mais il ne s'agit que d'un choix d'implémentation.
Cela faisait un petit bout de temps que je programmais quand j'ai découvert ce truc pratiqué sur les unix, sans avoir eu sur moi un effet cathartique je me suis dit qu'il allait falloir que je m'y fasse, avant pour moi une donnée c'était une adresse et une longueur et éventuellement un alignement, éventuellement aussi peut-être une sémantique sur-jacente mais ces trucs d'utilisateurs sont souvent difficiles à comprendre.
Emmanuel Delahaye wrote:
Harpo wrote on 27/04/05 :
Il faut se dire qu'il faut se débrouiller avec, ce sont des fonctions
que l'on doit connaître lorsqu'on les utilise souvent, j'utilise plus
facilement memcpy lorsque je le peux.
memcpy() ne met pas de 0 final. strncat() le fait. Le jour où j'ai
découvert ça (en parcourant c.l.c, i y a 4 ou 5 ans), ma vie a changé
Je comprends, une telle catharsis ne peut guère se manifester que dans
une confrontation à la dimension tragi-comique du 'so-called real
world'.
Ensisagée dans sa dimension programmatique, elle nous fait dépasser une
vision simplement pragmatique dont elle est issue mais à laquelle elle
ne peut cependant pas par sa nature intrinsèque être limitée.
Bref, pour moi c'est simple, j'utilise memcpy() quand je connais la
longueur et s'il faut que je mette le zero final, je mets le zero
final, s'il faut que je mette un n je mets un n, s'il faut faire
plaisir je fais plaisir.
Ce concept de string avec zero final n'est pas con mais il ne s'agit que
d'un choix d'implémentation.
Cela faisait un petit bout de temps que je programmais quand j'ai
découvert ce truc pratiqué sur les unix, sans avoir eu sur moi un effet
cathartique je me suis dit qu'il allait falloir que je m'y fasse, avant
pour moi une donnée c'était une adresse et une longueur et
éventuellement un alignement, éventuellement aussi peut-être une
sémantique sur-jacente mais ces trucs d'utilisateurs sont souvent
difficiles à comprendre.
Il faut se dire qu'il faut se débrouiller avec, ce sont des fonctions que l'on doit connaître lorsqu'on les utilise souvent, j'utilise plus facilement memcpy lorsque je le peux.
memcpy() ne met pas de 0 final. strncat() le fait. Le jour où j'ai découvert ça (en parcourant c.l.c, i y a 4 ou 5 ans), ma vie a changé
Je comprends, une telle catharsis ne peut guère se manifester que dans une confrontation à la dimension tragi-comique du 'so-called real world'. Ensisagée dans sa dimension programmatique, elle nous fait dépasser une vision simplement pragmatique dont elle est issue mais à laquelle elle ne peut cependant pas par sa nature intrinsèque être limitée.
Bref, pour moi c'est simple, j'utilise memcpy() quand je connais la longueur et s'il faut que je mette le zero final, je mets le zero final, s'il faut que je mette un n je mets un n, s'il faut faire plaisir je fais plaisir. Ce concept de string avec zero final n'est pas con mais il ne s'agit que d'un choix d'implémentation.
Cela faisait un petit bout de temps que je programmais quand j'ai découvert ce truc pratiqué sur les unix, sans avoir eu sur moi un effet cathartique je me suis dit qu'il allait falloir que je m'y fasse, avant pour moi une donnée c'était une adresse et une longueur et éventuellement un alignement, éventuellement aussi peut-être une sémantique sur-jacente mais ces trucs d'utilisateurs sont souvent difficiles à comprendre.
Harpo
Emmanuel Delahaye wrote:
Non, tu t'emballes trop. Il y a un certain courant anti scanf()
Nous aurons sa peau :
Emmanuel Delahaye wrote:
Non, tu t'emballes trop. Il y a un certain courant anti scanf()
Non, tu t'emballes trop. Il y a un certain courant anti scanf()
Nous aurons sa peau :
Richard Delorme
Richard Delorme wrote on 27/04/05 :
Tu as raison, mais il faut être pragmatique : quand un OP demande comment utiliser scanf() pour faire un split() de chaines, je ne suis pas de ceux qui proposent le format %[^:] , je préconise d'utiliser strchr() et d'éviter scanf().
Où est cette solution qui préconise strchr ? Celle que j'ai vu, est signé Yves Roman, et n'est pas complètement satisfaisante : écrit dans la chaine de départ, ne vérifie pas grand chose, lente (parcours 2 fois la chaine), longue (7 lignes contre 1 pour le sscanf), etc.
pas génial non plus... sauf si c'est pour montrer que sscanf est mieux.
-- Richard
Richard Delorme wrote on 27/04/05 :
Tu as raison, mais il faut être pragmatique : quand un OP demande
comment
utiliser scanf() pour faire un split() de chaines, je ne suis pas de
ceux qui proposent le format %[^:] , je préconise d'utiliser strchr()
et d'éviter
scanf().
Où est cette solution qui préconise strchr ?
Celle que j'ai vu, est signé Yves Roman, et n'est pas complètement
satisfaisante : écrit dans la chaine de départ, ne vérifie pas grand
chose, lente (parcours 2 fois la chaine), longue (7 lignes contre 1 pour
le sscanf), etc.
Tu as raison, mais il faut être pragmatique : quand un OP demande comment utiliser scanf() pour faire un split() de chaines, je ne suis pas de ceux qui proposent le format %[^:] , je préconise d'utiliser strchr() et d'éviter scanf().
Où est cette solution qui préconise strchr ? Celle que j'ai vu, est signé Yves Roman, et n'est pas complètement satisfaisante : écrit dans la chaine de départ, ne vérifie pas grand chose, lente (parcours 2 fois la chaine), longue (7 lignes contre 1 pour le sscanf), etc.
pas génial non plus... sauf si c'est pour montrer que sscanf est mieux.
-- Richard
Emmanuel Delahaye
Richard Delorme wrote on 28/04/05 :
Où est cette solution qui préconise strchr ? Celle que j'ai vu, est signé Yves Roman, et n'est pas complètement satisfaisante : écrit dans la chaine de départ, ne vérifie pas grand chose, lente (parcours 2 fois la chaine), longue (7 lignes contre 1 pour le sscanf), etc.
pas génial non plus... sauf si c'est pour montrer que sscanf est mieux.
J'ai pas dit que c'était bien, mieux ou quoi. Tu voulais une solution, je t'en donne une toute fraîche. Si tu trouves qu'elle n'est pas bonne, il falloir être un moins vague que "pas génial non plus"
-- Emmanuel The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html The C-library: http://www.dinkumware.com/refxc.html
"Mal nommer les choses c'est ajouter du malheur au monde." -- Albert Camus.
Richard Delorme wrote on 28/04/05 :
Où est cette solution qui préconise strchr ?
Celle que j'ai vu, est signé Yves Roman, et n'est pas complètement
satisfaisante : écrit dans la chaine de départ, ne vérifie pas grand
chose, lente (parcours 2 fois la chaine), longue (7 lignes contre 1 pour
le sscanf), etc.
pas génial non plus... sauf si c'est pour montrer que sscanf est mieux.
J'ai pas dit que c'était bien, mieux ou quoi. Tu voulais une solution,
je t'en donne une toute fraîche. Si tu trouves qu'elle n'est pas bonne,
il falloir être un moins vague que "pas génial non plus"
--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html
"Mal nommer les choses c'est ajouter du malheur au
monde." -- Albert Camus.
Où est cette solution qui préconise strchr ? Celle que j'ai vu, est signé Yves Roman, et n'est pas complètement satisfaisante : écrit dans la chaine de départ, ne vérifie pas grand chose, lente (parcours 2 fois la chaine), longue (7 lignes contre 1 pour le sscanf), etc.
pas génial non plus... sauf si c'est pour montrer que sscanf est mieux.
J'ai pas dit que c'était bien, mieux ou quoi. Tu voulais une solution, je t'en donne une toute fraîche. Si tu trouves qu'elle n'est pas bonne, il falloir être un moins vague que "pas génial non plus"
-- Emmanuel The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html The C-library: http://www.dinkumware.com/refxc.html
"Mal nommer les choses c'est ajouter du malheur au monde." -- Albert Camus.
