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

helly · Le 27/06/2010, à 22:09

Bêêêêêê N

Pylades · Le 27/06/2010, à 23:07

grim7reaper a écrit :

Moi j'utilise 80 comme pour le code.
Justification: aucune (enfin si : le coup du 80 revient souvent, doit y avoir un truc historique derrière).

Les cartes perforées standardisées faisaient 80 caractères (j’en ai, si tu veux je te les scanne ), donc du coup les premiers terminaux faisaient souvent 80 caractères de large, donc du coup on s’est astreint à ne pas faire des lignes de plus de 80 caractères. Mais certains préconisent un maximum de 79 caractères (sans doute pour certains éditeurs), comme c’est le cas dans la PEP 8, et d’autres encore 72, pour laisser la place à je ne sais plus quoi. Par ailleurs, Vim utilise quatre caractères quand la numérotation est activée, plus si le fichier fait plus de mille lignes.
La GPL est prévue pour un maximum de 72 caractères (enfin je crois parce que de temps en temps on croise des lignes de 73 caractères).
Je crois que je vais opter pour le choix qui a été fait pour la GPL.

grim7reaper · Le 27/06/2010, à 23:15

Ouais le fortran 77 se limitait aussi à la colonne 72 (après c'était des infos pour la carte ou je ne sais quoi), et il commençait à la colonne 7.

Je songe à passer à 72 caractères, mais il faudra que je passe à 2 espaces d'indentation sinon ça risque d'être contre-productif.

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

Pylades · Le 27/06/2010, à 23:28

Sinon, j’ai une question : pourquoi open, read, write et close ne sont pas déclarées dans stdio.h ?
Et est-ce que fopen et compagnie les utilisent ? Parce que là, je vais utiliser les deux (/me a décider de coder son interpréteur brainfuck en C ^^)… donc j’aimerais savoir si je fais des inclusions redondantes.

(Mais je sais, il ne faut pas être implicite, parce que si j’arrête d’utiliser les fonctions de stdio.h, je devrai ré-inclure les bons headers pour que cela fonctionne de nouveau.)

grim7reaper · Le 27/06/2010, à 23:45

Pylade a écrit :

Sinon, j’ai une question : pourquoi open, read, write et close ne sont pas déclarées dans stdio.h ?

Probablement parce que ce sont des fonctions POSIX (alors que fopen & cie sont des fonctions ANSI C donc plus portable).

Et est-ce que fopen et compagnie les utilisent ?

Je dirais que oui (mais je ne suis pas aller vérifier dans le code de la libc), mais ça doit dépendre des implémentations.

Parce que là, je vais utiliser les deux (/me a décider de coder son interpréteur brainfuck en C ^^)… donc j’aimerais savoir si je fais des inclusions redondantes.

Pourquoi mélanger les deux (il me semble que c'est même déconseillé, faudrait que je cherche des sources pour en être sûr) ?

En règle générale, on utilise les f*. Les autres étant généralement rencontré dans la prog système ou bas niveau.
Ce sont des généralités, il y a bien sûr des exceptions courantes (et ce ne sont pas non plus des règles immuables).

Dernière modification par grim7reaper (Le 27/06/2010, à 23:56)

Pylades · Le 28/06/2010, à 00:10

Ouais, je viens de voir que c’était du POSIX.

grim7reaper a écrit :

Pourquoi mélanger les deux (il me semble que c'est même déconseillé, faudrait que je cherche des sources pour en être sûr) ?

J’ai trouvé fread et fwrite (que je ne connaissais pas), et ça me convient parfaitement, je vais les utiliser.

\\Ouranos// · Le 28/06/2010, à 00:20

Intéréssant le débat sur les chars par ligne

@Pylade : Un lien vers de la doc pour fwrite et fread ?

grim7reaper · Le 28/06/2010, à 00:26

@\\Ouranos// :

man fwrite
man fread

Dans un terminal ou un moteur de recherche .

Alors ton interpréteur, ça en est où ?
Tu as corrigé tes derniers bug ?
Désolé, j'ai dû partir un peu violemment tout à l'heure, le serveur est down .

\\Ouranos// · Le 28/06/2010, à 00:40

grim7reaper a écrit :

@\\Ouranos// :
man fwrite
man fread
Dans un terminal ou un moteur de recherche .
Alors ton interpréteur, ça en est où ?
Tu as corrigé tes derniers bug ?
Désolé, j'ai dû partir un peu violemment tout à l'heure, le serveur est down .

Corrigé encore un, il m'en reste encore un peu :

`--> ./bfint.rb ./hello.bf
./bfint.rb:46: syntax error, unexpected kWHEN, expecting kEND
        when ']' then hash.invert
            ^
./bfint.rb:46: syntax error, unexpected kTHEN, expecting kEND
        when ']' then hash.invert
                     ^
./bfint.rb:52: syntax error, unexpected $end, expecting kEND
zsh: exit 1     ./bfint.rb ./hello.bf

J'ai vu ton message sur la rade du serveur Jabber.

Pylades · Le 28/06/2010, à 00:49

while(fread(&c, 1, 1, fd))
    i++;

Ça vous paraît correct pour lire la taille d’un fichier ?
Ou est-ce très moche ?

Sinon, vous paraît-il normal qu’un bout de <bits/stdio2.h> soit signalé comme code inatteignable ?

/me en mode galère avec la lecture de fichiers, cela faisait tellement longtemps que je n’en avais pas fait…

Kanor · Le 28/06/2010, à 00:51

/me trouve que 80 caractére c'est pas beaucoup alors 72

cm-t · Le 28/06/2010, à 01:06

'Nuit;

Pylades · Le 28/06/2010, à 01:09

Bordel, mais c’est fread qui merde !
J’ai fait quoi de travers ?

/me va dire « fuck » à la portabilité, et utiliser read, si ça continue…

grim7reaper · Le 28/06/2010, à 01:11

Pylade a écrit :

while(fread(&c, 1, 1, fd))
    i++;
Ça vous paraît correct pour lire la taille d’un fichier ?
Ou est-ce très moche ?

Très moche.
De mémoire on peut faire ça (ou quelque chose de similaire), c'est plus joli quand même .

        fseek(fd, 0, SEEK_END);
        size = ftell(fd);

Ou utiliser stat (Cf. man 3 stat).
Dans les 2 cas, tu va avoir des problèmes si tes fichiers ont une grande taille (environ plus de 3 Giga je crois) là tu peux taper dans le fseeko et ftello, et si ça dépasse encore bah faut utiliser une autre approche (mais bon c'est dans des cas rares, tu ne manipuleras pas de fichier texte de cette taille).
Enfin bon, dans le cas présent ça m'étonnerait qu'on te présente un fichier en bf qui dépasse le Go ^^ donc les astuce précédente seront amplement suffisante.

Sinon, vous paraît-il normal qu’un bout de <bits/stdio2.h> soit signalé comme code inatteignable ?

Faut pas s'en faire, c'est la lib standard donc les mecs savent ce qu'il font. Probablement un "faux-positif", ou alors c'est voulu.

\\Ouranos// · Le 28/06/2010, à 01:16

Bon, maintenant mon code fait une boucle infinie au lieu de sortir des erreurs.

Edit : Corrigé. Maintenant, encore des erreurs.

Dernière modification par \\Ouranos// (Le 28/06/2010, à 01:19)

grim7reaper · Le 28/06/2010, à 01:30

Toujours les hash ?

\\Ouranos// · Le 28/06/2010, à 01:34

grim7reaper a écrit :

Toujours les hash ?

Nop, ma méthode length est pas définie pour les tableaux.

Aaaaaaah, je vois comment contourner le problème.

Edit : Ah non.

Dernière modification par \\Ouranos// (Le 28/06/2010, à 01:36)

grim7reaper · Le 28/06/2010, à 01:47

\\Ouranos// a écrit :

grim7reaper a écrit :
Toujours les hash ?
Nop, ma méthode length est pas définie pour les tableaux.

Tu est sûr ?

La doc me donne au moins 2 méthodes : length et size (qui est alias sur length).

(Pour le serveur down tout s'explique => http://jabber.apinc.org/news/?p=90 )

Dernière modification par grim7reaper (Le 28/06/2010, à 01:55)

\\Ouranos// · Le 28/06/2010, à 01:53

grim7reaper a écrit :

\\Ouranos// a écrit :
grim7reaper a écrit :
Toujours les hash ?
Nop, ma méthode length est pas définie pour les tableaux.
Tu est sûr ?
La doc me donne au moins 2 méthodes : length et size (qui est alias sur length).

Résolu ici. Bizarre, il m'a suffi de mettre la taille des tableaux dans des variables et de les utiliser pour la comparaison à la place des keys.length et values.length, et ça marchait.

Maintenant, il me plante sur les case o-O

alexises · Le 28/06/2010, à 01:55

Si il y a des dev qt cpp ou cmake qui cherche un projet dans lequel participer j'ai quelquechose pour vous.

Pylades · Le 28/06/2010, à 01:57

grim7reaper a écrit :

De mémoire on peut faire ça (ou quelque chose de similaire), c'est plus joli quand même .
        fseek(fd, 0, SEEK_END);
        size = ftell(fd);
Ou utiliser stat (Cf. man 3 stat).
Dans les 2 cas, tu va avoir des problèmes si tes fichiers ont une grande taille (environ plus de 3 Giga je crois) là tu peux taper dans le fseeko et ftello, et si ça dépasse encore bah faut utiliser une autre approche (mais bon c'est dans des cas rares, tu ne manipuleras pas de fichier texte de cette taille).
Enfin bon, dans le cas présent ça m'étonnerait qu'on te présente un fichier en bf qui dépasse le Go ^^ donc les astuce précédente seront amplement suffisante.

Ouais, bon stat c’est bien gentil, mais c’est lourd, il me semble, et puis de toutes façons, c’est POSIX, donc on va s’en passer. ([mode=philo]Est-ce qu’un jour POSIX sera un standard universel ? Serait-ce appréciable seulement ?[/mode])
Pour la taille critique, c’est 4 Gio. Et ce n’est pas tant fseeko que ftello qu’il faudrait utiliser pour pallier à ce problème. En utilisant :

#define _FILE_OFFSET_BITS 64

ftello te renvoie alors un type sur 64 bits. Un fichier qui n’est pas représentable sur 64 bits, ça ne sera pas de si tôt, quand même. ^^

Au fait, normalement, fseeko peut échouer, mais si ton code est bien foutu ça n’arrive pas. Donc je n’ai vraiment pas envie de tester le retour. C’est mal ?

grim7reaper a écrit :

Pylade a écrit :
Sinon, vous paraît-il normal qu’un bout de <bits/stdio2.h> soit signalé comme code inatteignable ?
Faut pas s'en faire, c'est la lib standard donc les mecs savent ce qu'il font. Probablement un "faux-positif", ou alors c'est voulu.

Mouais, sauf que je pensais plutôt avoir merdé moi, étant donné que le problème disparaissait en commentant la ligne du fread…

\\Ouranos// · Le 28/06/2010, à 02:05

Bon, je règlerai ça demain. Bn.

grim7reaper · Le 28/06/2010, à 02:06

Pylade a écrit :

Ouais, bon stat c’est bien gentil, mais c’est lourd

C'est sur que si tu veux juste la taille c'est sortir le bazooka pour tuer une mouche . Mais sinon c'est une fonction très utile dans certains cas.

Au fait, normalement, fseeko peut échouer, mais si ton code est bien foutu ça n’arrive pas. Donc je n’ai vraiment pas envie de tester le retour. C’est mal ?

Non.
Je suppose que tu ne teste pas les retours de tout les scanf() et tout les printf() , donc non ce n'est pas grave. Faut tester seulement si l'opération est indispensable pour la suite (i.e si elle échoue ton programme se vautre).
C'est à toi d'évaluer les risques.
Dans ton cas, inutile d'utiliser les f*o (le mec qui te présente un source, de bf en plus, de plus de 4Go c'est un grand malade).
Je ne suis même pas sûr que gcc accepte des fichiers si gros en entrée en tant que source (faut déjà les pondre les 4Go de lignes de code ).

Pylades · Le 28/06/2010, à 02:09

Précision très importante : en fait ftell ne convient pas, parce que je souhaite ne compter que les caractères du brainfuck. Donc je dois tous les lire. Du coup je dois passer par fread, mais ça me renvoie un warning flippant. ><'

D’ailleurs, y a-t-il plus court que ça ?

while(fread(&c, 1, 1, fd))
  if (c == '+' || c == '-' || c == '>' || c == '<' || c == '.' || c == ',' || c == '[' || c == ']')
    i++;

Dernière modification par Pylade (Le 28/06/2010, à 02:09)

grim7reaper · Le 28/06/2010, à 02:20

Ha oui, dans ce cas tu n'as pas trop le choix.
Je ne pense pas qu'il y ai plus court (bon tu peux mettre une macro pour rendre le truc plus lisible, mais fondamentalement ça ne changeras rien).

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#626 Le 27/06/2010, à 22:09

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

#627 Le 27/06/2010, à 23:07

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

#628 Le 27/06/2010, à 23:15

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

#629 Le 27/06/2010, à 23:28

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

#630 Le 27/06/2010, à 23:45

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

#631 Le 28/06/2010, à 00:10

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

#632 Le 28/06/2010, à 00:20

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

#633 Le 28/06/2010, à 00:26

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

#634 Le 28/06/2010, à 00:40

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

#635 Le 28/06/2010, à 00:49

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

#636 Le 28/06/2010, à 00:51

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

#637 Le 28/06/2010, à 01:06

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

#638 Le 28/06/2010, à 01:09

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

#639 Le 28/06/2010, à 01:11

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

#640 Le 28/06/2010, à 01:16

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

#641 Le 28/06/2010, à 01:30

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

#642 Le 28/06/2010, à 01:34

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

#643 Le 28/06/2010, à 01:47

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

#644 Le 28/06/2010, à 01:53

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

#645 Le 28/06/2010, à 01:55

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

#646 Le 28/06/2010, à 01:57

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

#647 Le 28/06/2010, à 02:05

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

#648 Le 28/06/2010, à 02:06

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

#649 Le 28/06/2010, à 02:09

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

#650 Le 28/06/2010, à 02:20

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

Pied de page des forums