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

Pylades · Le 02/01/2011, à 00:53

Steap a écrit :

Il me semble que "i" est plus grand que "brackets".
D'ailleurs valgrind me sort :
==1939== Invalid read of size 4
==1939==    at 0x804897C: main (bf.c:118)
==1939==  Address 0x4190fb4 is not stack'd, malloc'd or (recently) free'd
La ligne 118 est
i = closing[i]

Ah, mais, oui, bien sûr ! Ce que je peux être tête en l'air, parfois…
Cependant je pense qu'il peut y avoir autre chose, mais ça serait déjà bien d'éliminer ça…

Merci beaucoup !

Steap a écrit :

Je suis en 32 bits :
$ uname -m
i686

Mauvaise hypothèse, alors (ou alors le code 32 et 64 bits ont des portions identiques au même endroit, ce qui est également possible)…

Édit : en patchant mon code pour résoudre ce problème (malheureusement en sacrifiant beaucoup de mémoire), le comportement est à nouveau celui attendu. Cool.
Cependant, Valgrind me rapporte plus de 2 000 erreurs (dans quatre contextes), il y a encore des choses à vérifier…

Dernière modification par Pylade (Le 02/01/2011, à 01:06)

grim7reaper · Le 02/01/2011, à 01:07

glob, retard rattrapé.

Chui mort donc BN World !

Dernière modification par grim7reaper (Le 02/01/2011, à 01:07)

Pylades · Le 02/01/2011, à 01:12

'lut !
T'as lu mon édit ?

Sinon, BN pour moi aussi.

compte supprimé · Le 02/01/2011, à 01:16

Bn;

Pylades · Le 02/01/2011, à 02:07

Bon, il est maintenant parfaitement en ordre. Étonnamment, il n'est plus rapide que d'assez peu, même s'il consomme bien plus de mémoire.

Flemme de le comparer à celui de Grim, je vous donne un lien demain.

gnuuat · Le 02/01/2011, à 02:27

Pylade a écrit :

NAN !
Mais pourquoi ? Pourquoi faire si compliqué ? Pourquoi ces espaces ?

(Et en plus, c'est absolument terrible, car tu ne gères pas les erreurs et tu ne retournes rien, donc c'est proprement scandaleux.)

Les espaces, c'est pour l'indentation, cochon !

#include <cstdlib>
#include <unistd.h>

void putChar(char c)
{
  unsigned int writed;

  writed = write(STDOUT_FILENO, &c, sizeof(c));
  if (writed != sizeof(c))
    throw ("Failed to write a character!");
}

Et puis je trouve pas ça si compliqué .

samυncle · Le 02/01/2011, à 03:14

\\Ouranos// · Le 02/01/2011, à 03:17

Кຼزດ · Le 02/01/2011, à 04:02

nesthib · Le 02/01/2011, à 04:45

plop

Compteur du TdCCT · Le 02/01/2011, à 08:42

Scores totaux, depuis le début :

1) 2211    nesthib
2) 2071    samuncle
3) 1777    Pylade
4) 1425    Кຼزດ
5) 1053+5  grim7reaper /* ./viewtopic.php?pid=3486252#p3486252 */
6) 1048    cm-t
7) 774    \\Ouranos//
8) 743    helly
9) 732    Р☢w ! ✰ :mad: ✰ (эй !)
10) 537    gnuuat
11) 522    Lagierl
12) 350    tshirtman
13) 196    Askelon
14) 185    Kanor
15) 172    nathéo
16) 121    ǤƦƯƝƬ
17) 93    petifrancais
17) 93    The Uploader
19) 81    Rolinh
20) 78    edge_one
20) 78    pierguiard
22) 70    gulp
23) 59    kamui57
24) 37    ilagas
25) 32    Le Rouge
26) 30    keny
27) 25    GentooUser
27) 25    Morgiver
29) 24    ไ୦บเઢ'
29) 24    Steap
31) 22    xapantu
32) 20    CROWD
32) 20    d10g3n
34) 18    Ph3nix_
35) 15    timsy
36) 14    kouskous
37) 12    stratoboy
37) 12    sailing
37) 12    sakul
40) 11    alexises
40) 11    Crocoii
42) 10    Toineo
42) 10    NutMotion
42) 10    pseudovingtcinqcaracteres
42) 10    pfriedZ
46) 8    Mornagest
47) 7    Vista
48) 6    Zeibux
48) 6    ubuntlin
48) 6    asma.geek
51) 5    tendances-tdct
51) 5    kinouchou
53) 4    danychou56
53) 4    Neros
53) 4    Biaise
53) 4    totoflute
53) 4    pinballyoda ㋛
58) 3    Revan26914
59) 2    SoJaS
59) 2    ceric
61) 1    geenux

Répartition Posts/heure

Compteur du TdCCT · Le 02/01/2011, à 08:42

Scores de la période en cours :

1) 10    nesthib
1) 10    Кຼزດ
3) 6    samuncle
3) 6    \\Ouranos//
5) 5    gnuuat
5) 5    Pylade
7) 4    Lagierl
7) 4    grim7reaper
9) 3    Steap
10) 2    helly
10) 2    tshirtman

Pylades · Le 02/01/2011, à 11:18

gnuuat a écrit :

Pylade a écrit :
NAN !
Mais pourquoi ? Pourquoi faire si compliqué ? Pourquoi ces espaces ?

(Et en plus, c'est absolument terrible, car tu ne gères pas les erreurs et tu ne retournes rien, donc c'est proprement scandaleux.)
Les espaces, c'est pour l'indentation, cochon !
#include <cstdlib>
#include <unistd.h>

void putChar(char c)
{
  unsigned int writed;

  writed = write(STDOUT_FILENO, &c, sizeof(c));
  if (writed != sizeof(c))
    throw ("Failed to write a character!");
}
Et puis je trouve pas ça si compliqué .

Ouais, c'est déjà mieux. Mais bon, toujours est-il que sizeof(c), ça se remplace par 1U, quand on sait ce qu'on fait.

Ah, et comme promis, voici le lien vers ma nouvelle version qui n'apporte pas tant de perfs que ça…

Dernière modification par Pylade (Le 02/01/2011, à 11:21)

Steap · Le 02/01/2011, à 13:31

@Pylade :

gcc -O3 -std=c89 -pedantic -Wall -Wextra -Winit-self -Wfloat-equal -Wstrict-prototypes -Wold-style-definition -Wredundant-decls -Wwrite-strings -Wcast-qual -Wconversion -Wunreachable-code -Wformat=2 bf.c -c -o bf.o
bf.c: In function 'main':
bf.c:69: warning: passing argument 2 of 'move_pointer' with different width due to prototype
bf.c:77: warning: passing argument 2 of 'move_pointer' with different width due to prototype
bf.c:202: warning: will never be executed
bf.c:204: warning: will never be executed
bf.c:196: warning: will never be executed
bf.c:198: warning: will never be executed
gcc -s  bf.o -o bf

Pylades · Le 02/01/2011, à 13:37

Pour les deux premiers warning, bizarre, chez moi je ne les ai pas. J'ai rajouté un cast, peut-être que c'était ça qui ne lui plaisait pas.

Pour les quatre autres, c'est normal, c'est dû à l'optimisation -O3, très agressive, qui peut provoquer des faux positifs.

Elzen · Le 02/01/2011, à 16:50

Même pas drôle, personne n'a relevé, j'ai pas pu faire ma blague.

Pylade a écrit :

Ouais, c'est déjà mieux. Mais bon, toujours est-il que sizeof(c), ça se remplace par 1U, quand on sait ce qu'on fait.

Et pour le cas où on voudrait enregistrer sous une machine bizarre pour qui un char serait d'une taille différente ?

Genre je sais pas, moi : si jamais quelqu'un essayait de faire un compilo qui reconnaisse les caractères unicodes comme des caractères et pas des suites de caractères… ça n'existe pas, mais ça pourrait très bien

grim7reaper · Le 02/01/2011, à 17:03

Ça existe (je crois que sur certaines archi, peut-être une famille de DSP, le char fait 24 bits), mais ça ne change rien car le standard définit le type char comme faisant un byte (la taille du byte pouvant varier selon l'archi, mais en général c'est un octet) et sizeof(char) doit toujours renvoyer 1.

ISO/IEC 9899:TC3 a écrit :

6.5.3.4 The sizeof operator
[…]
3 When applied to an operand that has type char, unsigned char, or signed char,
(or a qualified version thereof) the result is 1.
[…]

Dernière modification par grim7reaper (Le 02/01/2011, à 17:05)

Steap · Le 02/01/2011, à 17:22

Et du coup, pourquoi on écrirait pas "sizeof(char)", ce qui serait tout à fait équivalent à "1", "1U", "4/4" mais aurait l'avantage d'être bien clair ?

helly · Le 02/01/2011, à 18:03

la taille du byte pouvant varier selon l'archi

Heiiiin ? 8 bits = 1 byte, c'est pas une norme ?

nany · Le 02/01/2011, à 18:23

Bonjour chez vous.

@helly : http://fr.wikipedia.org/wiki/Byte

Byte ≠ octet

grim7reaper · Le 02/01/2011, à 19:00

Pylade a écrit :

@grim7reaper : enfin, on a le droit de considérer qu'un interpréteur n'a pas forcément à être très portable, sinon on serait limité…

« Portable » n'est pas le bon mot, ce n'est pas ce que j'ai voulu dire.
Je voulais dire que la majorité des programmes brainfuck se base sur des cases d'au moins 1 octet, c'est donc un standard de fait (de toute façon, il n'y a pas vraiment de standard officiel alors…).
Donc si tu fais un interpréteur brainfuck qui n'est pas compatible avec le « parc logiciel » brainfuck (en utilisant des cases d'un bit), on peut considérer qu'il est « faux ».

Ah, et comme promis, voici le lien vers ma nouvelle version qui n'apporte pas tant de perfs que ça…

Bah chez moi si, les perf sont meilleures que ton ancienne version et pas qu'un peu (grosso modo même niveau que le mien en C++).

Dernière modification par grim7reaper (Le 02/01/2011, à 19:03)

Pylades · Le 02/01/2011, à 19:02

Steap a écrit :

Et du coup, pourquoi on écrirait pas "sizeof(char)", ce qui serait tout à fait équivalent à "1", "1U", "4/4" mais aurait l'avantage d'être bien clair ?

Ben, dans le contexte, un 1U me paraît tout aussi évocateur qu'un sizeof (char), mais c'est probablement parce que j'ai moi-même l'habitude de faire comme ça.

De toutes façons, tout cela n'est pas bien grave…

grim7reaper a écrit :

Pylade a écrit :
@grim7reaper : enfin, on a le droit de considérer qu'un interpréteur n'a pas forcément à être très portable, sinon on serait limité…
« Portable » n'est pas le bon mot, ce n'est pas ce que j'ai voulu dire.
Je voulais dire que la majorité des programmes brainfuck se base sur des cases d'au moins 1 octet, c'est donc un standard de fait (de toute façon, il n'y a pas vraiment de standard officiel alors…).
Donc si tu fais un interpréteur brainfuck qui n'est pas compatible avec le « parc logiciel » brainfuck, on peut considérer qu'il est « faux ».

Hum, point de vue intéressant. Je ne dirais pas faux, puisque qu'il reste valable, mais plutôt inapproprié.

grim7reaper a écrit :

Pylade a écrit :
Ah, et comme promis, voici le lien vers ma nouvelle version qui n'apporte pas tant de perfs que ça…
Bah chez moi si, les perf sont meilleures que ton ancienne version et pas qu'un peu (grosso modo même niveau que le mien en C++).

Cool, ça.
Et en plus mon tampon est toujours infini et je détecte maintenant les erreurs d'appariement avant l'exécution. /me est décidément très balèze.

Dernière modification par Pylade (Le 02/01/2011, à 19:07)

grim7reaper · Le 02/01/2011, à 19:30

Pylade a écrit :

grim7reaper a écrit :
Pylade a écrit :
@grim7reaper : enfin, on a le droit de considérer qu'un interpréteur n'a pas forcément à être très portable, sinon on serait limité…
« Portable » n'est pas le bon mot, ce n'est pas ce que j'ai voulu dire.
Je voulais dire que la majorité des programmes brainfuck se base sur des cases d'au moins 1 octet, c'est donc un standard de fait (de toute façon, il n'y a pas vraiment de standard officiel alors…).
Donc si tu fais un interpréteur brainfuck qui n'est pas compatible avec le « parc logiciel » brainfuck, on peut considérer qu'il est « faux ».
Hum, point de vue intéressant. Je ne dirais pas faux, puisque qu'il reste valable, mais plutôt inapproprié.

Pourquoi inapproprié ?

Pylade a écrit :

Et en plus mon tampon est toujours infini

Il y a plus qu'a trouver un code qui en a l'utilité ^_^.

Pylade a écrit :

je détecte maintenant les erreurs d'appariement avant l'exécution.

Je crois qu'il n'y a que ta version qui ne le faisait pas encore

Pylades · Le 02/01/2011, à 19:39

grim7reaper a écrit :

Pourquoi inapproprié ?

Car ça serait un interpréteur incompatible avec les programmes qu'il est censé interpréter… ^^

grim7reaper a écrit :

Pylade a écrit :
Et en plus mon tampon est toujours infini
Il y a plus qu'a trouver un code qui en a l'utilité ^_^.

C'est pour le principe.

grim7reaper a écrit :

Pylade a écrit :
je détecte maintenant les erreurs d'appariement avant l'exécution.
Je crois qu'il n'y a que ta version qui ne le faisait pas encore

Ouais, mais maintenant elle a presque toutes les qualités.
D'ailleurs je rappelle qu'elle peut lire un code depuis une indirection.

Tu peux maintenant ajouter un lien sur ton site vers cette belle version.

grim7reaper · Le 02/01/2011, à 19:45

Pylade a écrit :

grim7reaper a écrit :
Pourquoi inapproprié ?
Car ça serait un interpréteur incompatible avec les programmes qu'il est censé interpréter… ^^

Oui, mais en quoi mon point de vue est inapproprié ?
Si tu veux écrire un interpréteur, en l'absence de standard reconnu, il faut bien que tu l'écrives pour qu'il soit compatible avec la majorité des programmes existant, non ?

Pylade a écrit :

Tu peux maintenant ajouter un lien sur ton site vers cette belle version.

Done.

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#676 Le 02/01/2011, à 00:53

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

#677 Le 02/01/2011, à 01:07

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

#678 Le 02/01/2011, à 01:12

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

#679 Le 02/01/2011, à 01:16

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

#680 Le 02/01/2011, à 02:07

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

#681 Le 02/01/2011, à 02:27

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

#682 Le 02/01/2011, à 03:14

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

#683 Le 02/01/2011, à 03:17

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

#684 Le 02/01/2011, à 04:02

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

#685 Le 02/01/2011, à 04:45

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

#686 Le 02/01/2011, à 08:42

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

#687 Le 02/01/2011, à 08:42

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

#688 Le 02/01/2011, à 11:18

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

#689 Le 02/01/2011, à 13:31

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

#690 Le 02/01/2011, à 13:37

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

#691 Le 02/01/2011, à 16:50

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

#692 Le 02/01/2011, à 17:03

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

#693 Le 02/01/2011, à 17:22

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

#694 Le 02/01/2011, à 18:03

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

#695 Le 02/01/2011, à 18:23

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

#696 Le 02/01/2011, à 19:00

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

#697 Le 02/01/2011, à 19:02

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

#698 Le 02/01/2011, à 19:30

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

#699 Le 02/01/2011, à 19:39

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

#700 Le 02/01/2011, à 19:45

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

Pied de page des forums