/* Topic des codeurs couche-tard [2] */

grim7reaper · Le 16/12/2010, à 22:22

Rolinh a écrit :

Et, hum, pourquoi scanf ?
EDIT: pour avoir pensé à utiliser scanf et ensuite, soit je n'ai pas compris soit... pourquoi vouloir récupérer avec scanf? C'est quoi la manœuvre voulue exactement?

J'ai envie de dire « et pourquoi pas ? ».
Ce n'est pas parce que 90% des gens l'utilisent trop et mal (comme les goto et les variables globales) que c'est à bannir de tout code.

Dans le cas présent (lecture d'un texte formaté), l'emploi d'une fonction de lecture formaté (tel que scanf) ne me semble pas aberrant.

Édit : HdP page 99 \o/

Dernière modification par grim7reaper (Le 16/12/2010, à 22:24)

Elzen · Le 16/12/2010, à 22:26

helly a écrit :

C'est un prof qui dit dans sa page perso « utiliser des LL » et qui se ramène avec son gros pc apple .

Mon PC Apple (oopah, d'ailleurs, c'était un processeur ppc, donc pas compatible x86) a tourné pendant une grande partie de sa vie (disons, de sa vie en ma possession, c'est vrai que je l'avais eu d'occase) uniquement sous Debian, et avec pour seul accroc dans son vrms le pilote privatif pour le Wifi, hein

grim7reaper a écrit :

Le « var machin type » sera plus simple à récupérer que le « type machin ».
Pour le premier, je pense que ça doit pouvoir se faire plutôt bien avec scanf (à voir), pour le second c'est plus problématique vu que le premier token (le type) n'est pas fixe…

Le « var machin type » m'apparaît plus simple aussi, mais comme je bosse pas seul et que j'ai oublié de demander l'avis de mon binôme, je suis pas encore sûr de faire comme ça (par contre et sans trop me vanter, comme mon binôme est aussi le seul gars de la promo à qui il arrive de temps en temps d'avoir raison quand on est pas d'accord sur un problème de codage ou de conception, j'suis sûr qu'on va faire un bon truc )
Au pire, le type n'est pas fixe, mais il n'y en a qu'un nombre limités, si ça peut aider (pour l'instant, on part sur entier, réel, complexe et booléen).
Je sais pas trop me servir du scanf et je trouve le man pas franchement clair, ça s'utilise comment, au juste ?

grim7reaper a écrit :

Qu'est-ce qui ne fonctionne pas avec atof/atoi/etc (d'ailleurs, j'en profite pour signaler que ces fonctions ne gèrent pas vraiment les erreurs, au contraite de leurs sœur strtod/strtol/etc) ?
C'est le fonctionnement d'une union que tu veux qu'on t'explique ?

calc.y: In function 'yyparse':
calc.y:10: warning: format '%f' expects type 'double', but argument 3 has type 'YYSTYPE'
calc.y:27: warning: passing argument 1 of 'atoi' makes pointer from integer without a cast
/usr/include/stdlib.h:148: note: expected 'const char *' but argument is of type 'YYSTYPE'
calc.y:28: warning: passing argument 1 of 'atof' makes pointer from integer without a cast
/usr/include/stdlib.h:145: note: expected 'const char *' but argument is of type 'YYSTYPE'

(ou à peu près même chose avec char* si je fais un #define YYSTYPE char*)
En gros et apparemment, tous les variables internes à yacc sont du même et unique type, même si on peut définir ce type comme on veut. Donc à moins de reconvertir les chaînes de caractères en valeurs numériques pour faire les calculs, puis de remettre en chaînes de caractères pour repasser à l'opération suivante (je doute que ce soit très efficace), 'va falloir utiliser une union.
Et j'ai jamais rencontré ces bêtes-là jusque-là, donc ouais, c'est ce que je voudrais que vous m'expliquiez, svp ^^

Dernière modification par ArkSeth (Le 16/12/2010, à 22:30)

helly · Le 16/12/2010, à 22:27

kupo a écrit :

Mon PC Apple (oopah, d'ailleurs, c'était un processeur ppc, donc pas compatible x86) a tourné pendant une grande partie de sa vie (disons, de sa vie en ma possession, c'est vrai que je l'avais eu d'occase) uniquement sous Debian, et avec pour seul accroc dans son vrms le pilote privatif pour le Wifi, hein

M'enfout, ça fait pas sérieux  !
Jverrai sa réaction, demain je me ramène avec mon tshirt « arrogant linux elitist »
Bon, jvais plancher sur le code, BN.
Sinon c'est bien : vrms tourne pas pour arch, que pour les distros debian et dérivées. Ça déculpabilise assez .

@Pylade ou monsieur grim : si vous pouvez ouvrir un TdCCT 3 svp… jfais ça pour vous laisser le premier post, si demain il est pas encore ouvert, jserai sans pitié !

Dernière modification par helly (Le 16/12/2010, à 22:31)

Elzen · Le 16/12/2010, à 22:33

helly a écrit :

M'enfout, ça fait pas sérieux  !

Il me semble avoir lu que Torvalds utilisait du matos Apple.
Après, ch'uis pas persuadé que Torvalds lui-même fasse sérieux.

helly a écrit :

Sinon c'est bien : vrms tourne pas pour arch, que pour les distros debian et dérivées.

T'as qu'à l'porter

Revan26914 · Le 16/12/2010, à 22:35

grim7reaper a écrit :

Ce n'est pas parce que 90% des gens l'utilisent trop et mal (comme les goto et les variables globales) que c'est à bannir de tout code.

La différence c'est que goto et les variables globales sont utiles. scanf(3) tu peux t'en passer. De plus, scanf(3) c'est dangereux entre autre parce que tu n'as pas de type check lors de la compilation. Sur un bon compilo, au pire tu as auras un warning en cas d'erreur de type.

compte supprimé · Le 16/12/2010, à 22:41

Bn;

Pylades · Le 16/12/2010, à 22:42

@helly : on peut utiliser des LL et aimer le matos kitch, hein…

grim7reaper a écrit :

[…]
Le « var machin type » sera plus simple à récupérer que le « type machin ».
Pour le premier, je pense que ça doit pouvoir se faire plutôt bien avec scanf (à voir), pour le second c'est plus problématique vu que le premier token (le type) n'est pas fixe…
[…]

Si tu as un nombre suffisamment restreint de types, tu peux utiliser plusieurs fscanf, mais après c'est merdique pour les perfs.
En tous cas, pour ce genre des choses, fscanf est tout indiqué.

Rolinh a écrit :

Pour info: atoi est deprecated
[…]

Je pense que tu confonds avec itoa, fonction qui n'a jamais fait partie du standard même si implémentée par de nombreux compilateurs. Son usage est donc à proscrire. Il est d'ailleurs bien plus efficace et pratique d'utiliser sprintf à la place.

Pour atoi, c'est juste un peu plus « à la Rache » que d'utiliser strtol, mais je ne vois vraiment pas ce qui pourrait justifier une dépréciation…

ArkSeth a écrit :

helly a écrit :
M'enfout, ça fait pas sérieux  !
Il me semble avoir lu que Torvalds utilisait du matos Apple.
Après, ch'uis pas persuadé que Torvalds lui-même fasse sérieux.

Torvalds ne fait pas sérieux, c'est justement pour ça que j'ai une de ses citations comme signature.

ArkSeth a écrit :

helly a écrit :
Sinon c'est bien : vrms tourne pas pour arch, que pour les distros debian et dérivées.
T'as qu'à l'porter

Ou le réécrire from scratch, ça serait probablement plus rapide…

Revan26914 a écrit :

[…] scanf(3) tu peux t'en passer. […]

Tu peux aussi te passer de compilateur et coder en assembleur…

Revan26914 a écrit :

[…] De plus, scanf(3) c'est dangereux entre autre parce que tu n'as pas de type check lors de la compilation. Sur un bon compilo, au pire tu as auras un warning en cas d'erreur de type.

Ouais, c'est ce qu'il disait, dans 90 % des cas c'est mal utilisé… mais ça n'est pas mauvais pour autant.

Dernière modification par Pylade (Le 16/12/2010, à 22:51)

grim7reaper · Le 16/12/2010, à 22:45

ArkSeth a écrit :

Le « var machin type » m'apparaît plus simple aussi, mais comme je bosse pas seul et que j'ai oublié de demander l'avis de mon binôme, je suis pas encore sûr de faire comme ça (par contre et sans trop me vanter, comme mon binôme est aussi le seul gars de la promo à qui il arrive de temps en temps à avoir raison quand on est pas d'accord sur un problème de codage ou de conception, j'suis sûr qu'on va faire un bon truc )
Au pire, le type n'est pas fixe, mais il n'y en a qu'un nombre limités, si ça peut aider (pour l'instant, on part sur entier, réel, complexe et booléen).
Je sais pas trop me servir du scanf et je trouve le man pas franchement clair, ça s'utilise comment, au juste ?

Ouais, la page de man n'est pas des plus user-friendly .
Cependant, je ne suis pas si sûr de moi pour scanf dans ce cas, il faut que je fasse quelques tests avant.

grim7reaper a écrit :

calc.y: In function 'yyparse':
calc.y:10: warning: format '%f' expects type 'double', but argument 3 has type 'YYSTYPE'
calc.y:27: warning: passing argument 1 of 'atoi' makes pointer from integer without a cast
/usr/include/stdlib.h:148: note: expected 'const char *' but argument is of type 'YYSTYPE'
calc.y:28: warning: passing argument 1 of 'atof' makes pointer from integer without a cast
/usr/include/stdlib.h:145: note: expected 'const char *' but argument is of type 'YYSTYPE'
(ou à peu près même chose avec char* si je fais un #define YYSTYPE char*)
En gros et apparemment, tous les variables internes à yacc sont du même et unique type, même si on peut définir ce type comme on veut. Donc à moins de reconvertir les chaînes de caractères en valeurs numériques pour faire les calculs, puis de remettre en chaînes de caractères pour repasser à l'opération suivante (je doute que ce soit très efficace), 'va falloir utiliser une union.
Et j'ai jamais rencontré ces bêtes-là jusque-là, donc ouais, c'est ce que je voudrais que vous m'expliquiez, svp ^^

Ouais, là effectivement je sens l'union venir.
Bon une union c'est comme une méta-variable, en fait plusieurs variables partage la même adresse en mémoire mais à un instant t tu ne peux stocker qu'une valeur dedans.
Un exemple de code

typedef union
{ 
       double d;
       int i;
} int_et_double;
[…]
int_et_double foo;

foo.d = 7.3
fprintf("%f\n", food.d);
foo.i = 42; /* Ecrase le 7.3 */
fprintf("%d\n", food.i);

C'est à toi de mettre la bonne valeur dans le bon champ et d'accéder au bon champ quand il faut.

helly a écrit :

Sinon c'est bien : vrms tourne pas pour arch, que pour les distros debian et dérivées. Ça déculpabilise assez .

Ouais, ça viens du format des paquets.

@Revan26914 : bah si tu à un minimum de contrôle de type (il regarde si le format correspond à ta variable quand même).

format '%f' expects type 'float *', but argument 2 has type 'int *'

Il suffit de savoir régler son compilo…
Et oui, scanf je peux m'en passer. Comme printf, comme for, comme if comme tout ce qui est de plus haut niveau que de l'assembleur RISC en fait (ouais, parce que même le CISC tu as des trucs dont tu peux aisement te passer).
Ce genre de remarque est relativement inutile…

@Pylade : alors, Python ou C pour le concours ?

Dernière modification par grim7reaper (Le 16/12/2010, à 22:45)

Revan26914 · Le 16/12/2010, à 22:49

Pylade a écrit :

Pour atoi, c'est juste un peu plus "à la Rache" que d'utiliser strtol, mais je ne vois vraiment pas ce qui pourrait justifier une dépréciation…

Pour la gestion des erreurs.

Pylades · Le 16/12/2010, à 22:52

Oui, ça fait plus « à la Rache », mais c'est tout.

Et j'ai édité mon message plus haut.

Dernière modification par Pylade (Le 16/12/2010, à 23:04)

Pylades · Le 16/12/2010, à 22:58

http://forum.ubuntu-fr.org/viewtopic.php?pid=3903595

grim7reaper · Le 16/12/2010, à 23:00

Arf tu m'a grillé.
J'ai demandé la suppression du mien du coup

(je remet le lien du tien pour le bot)
http://forum.ubuntu-fr.org/viewtopic.php?pid=3903595

Dernière modification par grim7reaper (Le 16/12/2010, à 23:00)

Elzen · Le 16/12/2010, à 23:03

grim7reaper a écrit :

Ouais, la page de man n'est pas des plus user-friendly .
Cependant, je ne suis pas si sûr de moi pour scanf dans ce cas, il faut que je fasse quelques tests avant.

Ouais, bah, si toi t'as besoin de faire des tests, je crois que moi je vais juste attendre patiemment ^^"

grim7reaper a écrit :

C'est à toi de mettre la bonne valeur dans le bon champ et d'accéder au bon champ quand il faut.

Ouais, donc en gros, c'est un genre de structure, mais avec un seul champ « actif » à la fois, on dirait… ça a l'air moins terrible que ce que je croyais ^^

Pylades · Le 16/12/2010, à 23:05

grim7reaper a écrit :

Arf tu m'a grillé.
J'ai demandé la suppression du mien du coup
(je remet le lien du tien pour le bot)
http://forum.ubuntu-fr.org/viewtopic.php?pid=3903595

Je peux te laisser l'honneur si tu veux (mais cite mon message, j'ai modifié quelques trucs)…

Pylades · Le 16/12/2010, à 23:07

http://forum.ubuntu-fr.org/viewtopic.php?pid=3903595

nesthib · Le 17/12/2010, à 01:34

plop

nesthib · Le 17/12/2010, à 03:37

oups non pas du tout mais je n'ai pas trop le temps de lire le TdCCT en ce moment alors je n'ai pas vu qu'il était fermé en postant ><
mea culpa

Dernière modification par nesthib (Le 17/12/2010, à 09:50)

helly · Le 17/12/2010, à 07:45

http://forum.ubuntu-fr.org/viewtopic.php?id=434134

Dernière modification par helly (Le 17/12/2010, à 16:41)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#2476 Le 16/12/2010, à 22:22

Re : /* Topic des codeurs couche-tard [2] */

#2477 Le 16/12/2010, à 22:26

Re : /* Topic des codeurs couche-tard [2] */

#2478 Le 16/12/2010, à 22:27

Re : /* Topic des codeurs couche-tard [2] */

#2479 Le 16/12/2010, à 22:33

Re : /* Topic des codeurs couche-tard [2] */

#2480 Le 16/12/2010, à 22:35

Re : /* Topic des codeurs couche-tard [2] */

#2481 Le 16/12/2010, à 22:41

Re : /* Topic des codeurs couche-tard [2] */

#2482 Le 16/12/2010, à 22:42

Re : /* Topic des codeurs couche-tard [2] */

#2483 Le 16/12/2010, à 22:45

Re : /* Topic des codeurs couche-tard [2] */

#2484 Le 16/12/2010, à 22:49

Re : /* Topic des codeurs couche-tard [2] */

#2485 Le 16/12/2010, à 22:52

Re : /* Topic des codeurs couche-tard [2] */

#2486 Le 16/12/2010, à 22:58

Re : /* Topic des codeurs couche-tard [2] */

#2487 Le 16/12/2010, à 23:00

Re : /* Topic des codeurs couche-tard [2] */

#2488 Le 16/12/2010, à 23:03

Re : /* Topic des codeurs couche-tard [2] */

#2489 Le 16/12/2010, à 23:05

Re : /* Topic des codeurs couche-tard [2] */

#2490 Le 16/12/2010, à 23:07

Re : /* Topic des codeurs couche-tard [2] */

#2491 Le 17/12/2010, à 01:34

Re : /* Topic des codeurs couche-tard [2] */

#2492 Le 17/12/2010, à 03:37

Re : /* Topic des codeurs couche-tard [2] */

#2493 Le 17/12/2010, à 07:45

Re : /* Topic des codeurs couche-tard [2] */

Pied de page des forums