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.
Oui (c'est le commutateur qui génère les avertissements), mais comme c'est devenu un avertissement par défaut avec -Wall (et maintenant -W aussi), l'option intéressante et à connaître ÀMHA c'est -Wno-trigraphs, pour faire cesser le verbiage quand il y a des trigraphes dans ton code et que tu le sais parfaitement.
À utiliser avec modération, évidemment.
Antoine
En <news:mn.ec987d541f51b1c6.15512@YOURBRAnoos.fr>, Emmanuel Delahaye
va escriure:
Au fait -Wtrigraphs, c'est interessant ?
Oui (c'est le commutateur qui génère les avertissements), mais comme c'est
devenu un avertissement par défaut avec -Wall (et maintenant -W aussi),
l'option intéressante et à connaître ÀMHA c'est -Wno-trigraphs, pour faire
cesser le verbiage quand il y a des trigraphes dans ton code et que tu le
sais parfaitement.
Oui (c'est le commutateur qui génère les avertissements), mais comme c'est devenu un avertissement par défaut avec -Wall (et maintenant -W aussi), l'option intéressante et à connaître ÀMHA c'est -Wno-trigraphs, pour faire cesser le verbiage quand il y a des trigraphes dans ton code et que tu le sais parfaitement.
À utiliser avec modération, évidemment.
Antoine
Antoine Leca
En <news:d4tp71$1pi$, Charlie Gordon va escriure:
les digraphes que les experts du C99 ont cru bon de rajouter :-((.
Les digraphes viennent de C++, et en particulier de l'inventeur du langage, un certain Bjarne Stroustrup.
Qui comme Danois est gêné de trouver des Æ ou autres ø quand il imprimait des sources C ou C++ sur une imprimante qui traîne à portée de la main.
Les digraphes sont en fait beaucoup moins gênants que les trigraphes, le seul vrai problème c'est le traitement des délimiteurs d'entêtes dans une ligne #include qui peut devenir arbitrairement compliquée.
Antoine
En <news:d4tp71$1pi$1@reader1.imaginet.fr>, Charlie Gordon va escriure:
les digraphes que les experts du C99 ont cru bon de rajouter :-((.
Les digraphes viennent de C++, et en particulier de l'inventeur du langage,
un certain Bjarne Stroustrup.
Qui comme Danois est gêné de trouver des Æ ou autres ø quand il imprimait
des sources C ou C++ sur une imprimante qui traîne à portée de la main.
Les digraphes sont en fait beaucoup moins gênants que les trigraphes, le
seul vrai problème c'est le traitement des délimiteurs d'entêtes dans une
ligne #include qui peut devenir arbitrairement compliquée.
les digraphes que les experts du C99 ont cru bon de rajouter :-((.
Les digraphes viennent de C++, et en particulier de l'inventeur du langage, un certain Bjarne Stroustrup.
Qui comme Danois est gêné de trouver des Æ ou autres ø quand il imprimait des sources C ou C++ sur une imprimante qui traîne à portée de la main.
Les digraphes sont en fait beaucoup moins gênants que les trigraphes, le seul vrai problème c'est le traitement des délimiteurs d'entêtes dans une ligne #include qui peut devenir arbitrairement compliquée.
Antoine
Emmanuel Delahaye
Antoine Leca wrote on 04/05/05 :
En <news:, Emmanuel Delahaye va escriure:
"Emmanuel Delahaye" wrote in message news:
September the 11th... ?
ISO 8601, normalisation des dates ?
Bravo Emmanuel. Heureusement qu'il y en a un qui suit!
Merci Google...
-- 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"
Antoine Leca wrote on 04/05/05 :
En <news:mn.ed6b7d54fb066a18.15512@YOURBRAnoos.fr>, Emmanuel Delahaye
va escriure:
"Emmanuel Delahaye" <emdel@YOURBRAnoos.fr> wrote in message
news:mn.ecc37d54ba8b107c.15512@YOURBRAnoos.fr...
September the 11th... ?
ISO 8601, normalisation des dates ?
Bravo Emmanuel. Heureusement qu'il y en a un qui suit!
Merci Google...
--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html
Bravo Emmanuel. Heureusement qu'il y en a un qui suit!
Merci Google...
-- 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
Charlie Gordon wrote:
Le problème, c'est que le coût des bugs croit exponentiellement avec le temps qu'on met à les trouver :
1: bug corrigé au moment de la frappe, par réflexe du programmeur bien formé, attentif et éveillé :
Bien formé, attentif et éveillé : il faut donc 3 programmeurs.
10: bug corrigé car détecté par le compilateur (helas trop souvent le compilateur n'est pas configuré pour signaler les cas suspects ou le programmeur ignore les warnings : solution -Wall -W -Werror).
C'est une question de connaissances et de méthodes que tout le monde est prêt à accepter.
Je suis globalement d'accord avec le reste.
Si les tests ne servaient à rien, on mettrait directement en fonction sur un TGV les programmes dès qu'ils sont compilés, mais il faudra me payer cher pour que je prenne un ticket.
Je ne dis pas que les tests ne servent à rien, loin de là ! Mais il est illusoire de s'imaginer qu'ils permettent de trouver tous les bugs.
Là encore, je suis d'accord, mais si les tests ne trouvent pas tous les bugs (ça se saurait), ils peuvent permettre d'en éliminer une grande partie
Or le management de projets informatiques semble le croire,
Vous avez bien dit "semble", je ne pense pas que quelqu'un de sérieux aille au-delà de faire semblant.
alors que les personnels qui produisent et conduisent les tests en question sont bien souvent encore moins qualifiés ou motivés que ceux qui produisent l'architecture ou le code des systèmes.
C'est bien dommage, je n'y connais pas grand chose mais je pense qu'élaborer des stratégies de test doit être intéressant. Il existe aussi des produits qui analysent le code (je ne connais guère que leur existence) et peuvent servir à des tests unitaires.
Quand ça se voit trop, l'argument massue est le manque de moyens, et on obtient alors d'augmenter le nombre d'intervenants, ce qui est une approche simpliste et souvent fatale du problème.
Je ne sais plus qui a dit qu'aux problèmes complexes il existait toujours des solutions simples qui ne marchaient jamais.
Je ne connais pas l'embarqué mais j'imagine qu'on doit prévoir les bugs et qu'il y a toujours un fallback dans ce cas. Par exemple dans le cas d'Ariane 5, on l'a fait exploser en dernier recours, c'est quand même mieux que de la voir s'écraser sur le WTC. Evidemment, dans le cas d'un Airbus avec 500 personnes à bord, on peut essayer de trouver mieux... j'sais pas ... demander s'il n'y a pas un pilote dans l'avion...
Charlie Gordon wrote:
Le problème, c'est que le coût des bugs croit exponentiellement avec
le temps qu'on met à les trouver :
1: bug corrigé au moment de la frappe, par réflexe du programmeur bien
formé, attentif et éveillé :
Bien formé, attentif et éveillé : il faut donc 3 programmeurs.
10: bug corrigé car détecté par le compilateur (helas trop souvent le
compilateur n'est pas configuré pour signaler les cas suspects ou le
programmeur ignore les warnings : solution -Wall -W -Werror).
C'est une question de connaissances et de méthodes que tout le monde est
prêt à accepter.
Je suis globalement d'accord avec le reste.
Si les tests ne servaient à rien, on mettrait directement en fonction
sur un TGV les programmes dès qu'ils sont compilés, mais il faudra me
payer cher pour que je prenne un ticket.
Je ne dis pas que les tests ne servent à rien, loin de là ! Mais il
est
illusoire de s'imaginer qu'ils permettent de trouver tous les bugs.
Là encore, je suis d'accord, mais si les tests ne trouvent pas tous les
bugs (ça se saurait), ils peuvent permettre d'en éliminer une grande
partie
Or le management de projets informatiques semble le croire,
Vous avez bien dit "semble", je ne pense pas que quelqu'un de sérieux
aille au-delà de faire semblant.
alors que
les personnels qui produisent et conduisent les tests en question sont
bien souvent encore moins qualifiés ou motivés que ceux qui produisent
l'architecture ou le code des
systèmes.
C'est bien dommage, je n'y connais pas grand chose mais je pense
qu'élaborer des stratégies de test doit être intéressant. Il existe
aussi des produits qui analysent le code (je ne connais guère que leur
existence) et peuvent servir à des tests unitaires.
Quand ça se voit trop, l'argument massue est le manque de
moyens, et on obtient alors d'augmenter le nombre d'intervenants, ce
qui est une approche simpliste et souvent fatale du problème.
Je ne sais plus qui a dit qu'aux problèmes complexes il existait
toujours des solutions simples qui ne marchaient jamais.
Je ne connais pas l'embarqué mais j'imagine qu'on doit prévoir les bugs
et qu'il y a toujours un fallback dans ce cas. Par exemple dans le cas
d'Ariane 5, on l'a fait exploser en dernier recours, c'est quand même
mieux que de la voir s'écraser sur le WTC.
Evidemment, dans le cas d'un Airbus avec 500 personnes à bord, on peut
essayer de trouver mieux... j'sais pas ... demander s'il n'y a pas un
pilote dans l'avion...
Le problème, c'est que le coût des bugs croit exponentiellement avec le temps qu'on met à les trouver :
1: bug corrigé au moment de la frappe, par réflexe du programmeur bien formé, attentif et éveillé :
Bien formé, attentif et éveillé : il faut donc 3 programmeurs.
10: bug corrigé car détecté par le compilateur (helas trop souvent le compilateur n'est pas configuré pour signaler les cas suspects ou le programmeur ignore les warnings : solution -Wall -W -Werror).
C'est une question de connaissances et de méthodes que tout le monde est prêt à accepter.
Je suis globalement d'accord avec le reste.
Si les tests ne servaient à rien, on mettrait directement en fonction sur un TGV les programmes dès qu'ils sont compilés, mais il faudra me payer cher pour que je prenne un ticket.
Je ne dis pas que les tests ne servent à rien, loin de là ! Mais il est illusoire de s'imaginer qu'ils permettent de trouver tous les bugs.
Là encore, je suis d'accord, mais si les tests ne trouvent pas tous les bugs (ça se saurait), ils peuvent permettre d'en éliminer une grande partie
Or le management de projets informatiques semble le croire,
Vous avez bien dit "semble", je ne pense pas que quelqu'un de sérieux aille au-delà de faire semblant.
alors que les personnels qui produisent et conduisent les tests en question sont bien souvent encore moins qualifiés ou motivés que ceux qui produisent l'architecture ou le code des systèmes.
C'est bien dommage, je n'y connais pas grand chose mais je pense qu'élaborer des stratégies de test doit être intéressant. Il existe aussi des produits qui analysent le code (je ne connais guère que leur existence) et peuvent servir à des tests unitaires.
Quand ça se voit trop, l'argument massue est le manque de moyens, et on obtient alors d'augmenter le nombre d'intervenants, ce qui est une approche simpliste et souvent fatale du problème.
Je ne sais plus qui a dit qu'aux problèmes complexes il existait toujours des solutions simples qui ne marchaient jamais.
Je ne connais pas l'embarqué mais j'imagine qu'on doit prévoir les bugs et qu'il y a toujours un fallback dans ce cas. Par exemple dans le cas d'Ariane 5, on l'a fait exploser en dernier recours, c'est quand même mieux que de la voir s'écraser sur le WTC. Evidemment, dans le cas d'un Airbus avec 500 personnes à bord, on peut essayer de trouver mieux... j'sais pas ... demander s'il n'y a pas un pilote dans l'avion...
Antoine Leca
En <news:4271195b$0$1255$, Harpo va escriure:
Si les tests ne servaient à rien, on mettrait directement en fonction sur un TGV les programmes dès qu'ils sont compilés, mais il faudra me payer cher pour que je prenne un ticket.
C'est pas comme cela avec les versions x.0 de Micro$oft (et en général de toutes les boîtes informatiques qui gagnent beaucoup d'argent, comme par exemple mon fournisseur préféré de logiciel de @#*!): on met directement en fonctionnement les programmes dès qu'ils sont compilés, ET il faut payer très cher pour avoir un ticket ?
J'avais cru.
Antoine
En <news:4271195b$0$1255$8fcfb975@news.wanadoo.fr>, Harpo va escriure:
Si les tests ne servaient à rien, on mettrait directement en fonction
sur un TGV les programmes dès qu'ils sont compilés, mais il faudra me
payer cher pour que je prenne un ticket.
C'est pas comme cela avec les versions x.0 de Micro$oft (et en général de
toutes les boîtes informatiques qui gagnent beaucoup d'argent, comme par
exemple mon fournisseur préféré de logiciel de @#*!): on met directement en
fonctionnement les programmes dès qu'ils sont compilés, ET il faut payer
très cher pour avoir un ticket ?
Si les tests ne servaient à rien, on mettrait directement en fonction sur un TGV les programmes dès qu'ils sont compilés, mais il faudra me payer cher pour que je prenne un ticket.
C'est pas comme cela avec les versions x.0 de Micro$oft (et en général de toutes les boîtes informatiques qui gagnent beaucoup d'argent, comme par exemple mon fournisseur préféré de logiciel de @#*!): on met directement en fonctionnement les programmes dès qu'ils sont compilés, ET il faut payer très cher pour avoir un ticket ?
J'avais cru.
Antoine
Antoine Leca
En <news:427b9eba$0$11695$, Harpo va escriure:
il y a toujours un fallback dans ce cas. Par exemple dans le cas d'Ariane 5, on l'a fait exploser en dernier recours, c'est quand même mieux que de la voir s'écraser sur le WTC.
Je ne connais pas le cas de la sûreté d'Ariane, mais je suppose qu'il n'y a pas UN mais PLUSIEURS systèmes, indépendants et tout et tout, pour faire sauter la fusée quand quelque chose n'est vraiment plus « nominal ».
Et que ces systèmes-là ont subi plus de tests que les autres. Par exemple, je suppose que personne n'a eu l'idée « d'augmenter les possibilités du sous-système d'auto-destruction en passant d'un micro 16 à 32 bits »; ou plus exactement, que l'on a gentiment expliqué à celui qui a émis l'idée que « non, non merci, on a répliqué exactement le module qui marche sur Ariane 3/4 ».
Antoine
En <news:427b9eba$0$11695$8fcfb975@news.wanadoo.fr>, Harpo va escriure:
il y a toujours un fallback dans ce cas. Par exemple dans
le cas d'Ariane 5, on l'a fait exploser en dernier recours, c'est
quand même mieux que de la voir s'écraser sur le WTC.
Je ne connais pas le cas de la sûreté d'Ariane, mais je suppose qu'il n'y a
pas UN mais PLUSIEURS systèmes, indépendants et tout et tout, pour faire
sauter la fusée quand quelque chose n'est vraiment plus « nominal ».
Et que ces systèmes-là ont subi plus de tests que les autres.
Par exemple, je suppose que personne n'a eu l'idée « d'augmenter les
possibilités du sous-système d'auto-destruction en passant d'un micro 16 à
32 bits »; ou plus exactement, que l'on a gentiment expliqué à celui qui a
émis l'idée que « non, non merci, on a répliqué exactement le module qui
marche sur Ariane 3/4 ».
il y a toujours un fallback dans ce cas. Par exemple dans le cas d'Ariane 5, on l'a fait exploser en dernier recours, c'est quand même mieux que de la voir s'écraser sur le WTC.
Je ne connais pas le cas de la sûreté d'Ariane, mais je suppose qu'il n'y a pas UN mais PLUSIEURS systèmes, indépendants et tout et tout, pour faire sauter la fusée quand quelque chose n'est vraiment plus « nominal ».
Et que ces systèmes-là ont subi plus de tests que les autres. Par exemple, je suppose que personne n'a eu l'idée « d'augmenter les possibilités du sous-système d'auto-destruction en passant d'un micro 16 à 32 bits »; ou plus exactement, que l'on a gentiment expliqué à celui qui a émis l'idée que « non, non merci, on a répliqué exactement le module qui marche sur Ariane 3/4 ».
Antoine
JBJ
En <news:427b9eba$0$11695$, Harpo va escriure:
il y a toujours un fallback dans ce cas. Par exemple dans le cas d'Ariane 5, on l'a fait exploser en dernier recours, c'est quand même mieux que de la voir s'écraser sur le WTC.
Je ne connais pas le cas de la sûreté d'Ariane, mais je suppose qu'il n'y a pas UN mais PLUSIEURS systèmes, indépendants et tout et tout, pour faire sauter la fusée quand quelque chose n'est vraiment plus « nominal ».
Et que ces systèmes-là ont subi plus de tests que les autres. Par exemple, je suppose que personne n'a eu l'idée « d'augmenter les possibilités du sous-système d'auto-destruction en passant d'un micro 16 à 32 bits »; ou plus exactement, que l'on a gentiment expliqué à celui qui a émis l'idée que « non, non merci, on a répliqué exactement le module qui marche sur Ariane 3/4 ».
En <news:427b9eba$0$11695$8fcfb975@news.wanadoo.fr>, Harpo va escriure:
il y a toujours un fallback dans ce cas. Par exemple dans
le cas d'Ariane 5, on l'a fait exploser en dernier recours, c'est
quand même mieux que de la voir s'écraser sur le WTC.
Je ne connais pas le cas de la sûreté d'Ariane, mais je suppose qu'il n'y
a pas UN mais PLUSIEURS systèmes, indépendants et tout et tout, pour faire
sauter la fusée quand quelque chose n'est vraiment plus « nominal ».
Et que ces systèmes-là ont subi plus de tests que les autres.
Par exemple, je suppose que personne n'a eu l'idée « d'augmenter les
possibilités du sous-système d'auto-destruction en passant d'un micro 16 à
32 bits »; ou plus exactement, que l'on a gentiment expliqué à celui qui a
émis l'idée que « non, non merci, on a répliqué exactement le module qui
marche sur Ariane 3/4 ».
il y a toujours un fallback dans ce cas. Par exemple dans le cas d'Ariane 5, on l'a fait exploser en dernier recours, c'est quand même mieux que de la voir s'écraser sur le WTC.
Je ne connais pas le cas de la sûreté d'Ariane, mais je suppose qu'il n'y a pas UN mais PLUSIEURS systèmes, indépendants et tout et tout, pour faire sauter la fusée quand quelque chose n'est vraiment plus « nominal ».
Et que ces systèmes-là ont subi plus de tests que les autres. Par exemple, je suppose que personne n'a eu l'idée « d'augmenter les possibilités du sous-système d'auto-destruction en passant d'un micro 16 à 32 bits »; ou plus exactement, que l'on a gentiment expliqué à celui qui a émis l'idée que « non, non merci, on a répliqué exactement le module qui marche sur Ariane 3/4 ».
Et que ces systèmes-là ont subi plus de tests que les autres. Par exemple, je suppose que personne n'a eu l'idée « d'augmenter les possibilités du sous-système d'auto-destruction en passant d'un micro 16 à 32 bits »;
Ça c'est pas toujours une bonne idée, voir : [ les rapports sur l'échec du vol 501 ]
Je voulais dire, ne rien changer, même pas le système sur lequel cela tourne. Pas question d'augmenter les performances d'un tel module, donc.
Ariane 501 a « correctement » explosée à la suite du bogue sur la conduite de vol, je ne vois pas bien en quoi les références proposées s'appliquent. Surtout que le vrai problème, c'est que le bogue est venu initialement d'un système qui lui n'avait pas été testé avec la séquence de données réelles (autrement dit, la fusée «devait» dévier dans 100% des cas).
Maintenant, si c'est pour faire remarquer que les logiciels conçus pour gérer les pannes aléatoires (cas d'Ariane) ne doivent pas être exemptés de savoir traiter *correctement* les pannes systématiques (défaillance qui est la cause de l'explosion), alors là oui, d'accord. Et c'est d'autant plus vrai pour les systèmes de sûreté, comme je voulais le souligner.
Antoine
En <news:YX1fe.55679$Of5.34696@nntpserver.swip.net>, JBJ va escriure:
Et que ces systèmes-là ont subi plus de tests que les autres.
Par exemple, je suppose que personne n'a eu l'idée « d'augmenter les
possibilités du sous-système d'auto-destruction en passant d'un
micro 16 à 32 bits »;
Ça c'est pas toujours une bonne idée, voir :
[ les rapports sur l'échec du vol 501 ]
Je voulais dire, ne rien changer, même pas le système sur lequel cela
tourne. Pas question d'augmenter les performances d'un tel module, donc.
Ariane 501 a « correctement » explosée à la suite du bogue sur la conduite
de vol, je ne vois pas bien en quoi les références proposées s'appliquent.
Surtout que le vrai problème, c'est que le bogue est venu initialement d'un
système qui lui n'avait pas été testé avec la séquence de données réelles
(autrement dit, la fusée «devait» dévier dans 100% des cas).
Maintenant, si c'est pour faire remarquer que les logiciels conçus pour
gérer les pannes aléatoires (cas d'Ariane) ne doivent pas être exemptés de
savoir traiter *correctement* les pannes systématiques (défaillance qui est
la cause de l'explosion), alors là oui, d'accord.
Et c'est d'autant plus vrai pour les systèmes de sûreté, comme je voulais le
souligner.
Et que ces systèmes-là ont subi plus de tests que les autres. Par exemple, je suppose que personne n'a eu l'idée « d'augmenter les possibilités du sous-système d'auto-destruction en passant d'un micro 16 à 32 bits »;
Ça c'est pas toujours une bonne idée, voir : [ les rapports sur l'échec du vol 501 ]
Je voulais dire, ne rien changer, même pas le système sur lequel cela tourne. Pas question d'augmenter les performances d'un tel module, donc.
Ariane 501 a « correctement » explosée à la suite du bogue sur la conduite de vol, je ne vois pas bien en quoi les références proposées s'appliquent. Surtout que le vrai problème, c'est que le bogue est venu initialement d'un système qui lui n'avait pas été testé avec la séquence de données réelles (autrement dit, la fusée «devait» dévier dans 100% des cas).
Maintenant, si c'est pour faire remarquer que les logiciels conçus pour gérer les pannes aléatoires (cas d'Ariane) ne doivent pas être exemptés de savoir traiter *correctement* les pannes systématiques (défaillance qui est la cause de l'explosion), alors là oui, d'accord. Et c'est d'autant plus vrai pour les systèmes de sûreté, comme je voulais le souligner.