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

Elzen · Le 11/01/2011, à 21:50

D'un autre côté, la taille des fichiers est assez limitée ^^ (j'crois même que le nombre de lignes est censé être fixe dans l'énoncé, mais j'ai la flemme de relire et j'essaye de faire un truc un peu portable)

Donc je vais prendre la version 3, pour une fois que j'ai une bonne idée, j'en profite

Edit : HDP 42 \o/

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

Rolinh · Le 11/01/2011, à 21:50

Pylade a écrit :

C'est mieux ainsi…
(Et je ne vois pas la déclaration de i…

Tu as parfaitement raison
Et oui, j'ai oublié le i.

Elzen · Le 11/01/2011, à 22:16

C'est fait, mais j'veux bien qu'on m'explique un truc…

Mon code, c'est ça :

int read_words_in_file(int* nbwords, char*** words, char* wordsfile) {
    long size, llen, len;
    char* text;
    int i;
    
    FILE* file = fopen(wordsfile, "r");
    fseek(file, 0, SEEK_END);
    size = ftell(file);
    fseek(file, 0, SEEK_SET);
    
    text = malloc(size * sizeof(char));
    
    len = 0;
    (*nbwords) = 0;
    while (len < size) {
        fgets(text+len, size, file);
        llen = strlen(text+len);
        (*nbwords)++;
        len += llen;
        text[len-1] = '\0';
    }
    
    (*words) = malloc((*nbwords) * sizeof(char*));
    
    len = 0;
    for (i=0; i<(*nbwords); i++) {
        (*words)[i] = text+len;
        len += strlen(text+len)+1;
    }
    
    fclose(file);
    return size;
}

(Oui, je sais, sizeof(char) c'est pas la peine, mais j'trouve ça plus lisible )

Ce que je n'arrive pas à comprendre, c'est que si je déplace le fclose(file); à la sortie de la première boucle plutôt que tout à la fin (c'est là que je l'avais mis au début, vu qu'on a plus besoin du fichier après), il me sort un segfault

(Sinon, vu qu'il n'y a pas de code généré par flex, yacc et compagnie dans ce truc-ci, j'ai rajouté -Wextra dans mon Makefile ^^)

helly · Le 11/01/2011, à 22:17

QUARANTE DEUUUUUUUUUUUUUUUUUUUUUX !
Horreur !
Pour le tp de cet aprèm, c'était sous eclipse, pas moyen de trouver un pc en dualboot avec eclipse d'installé sur leur GNU/Linux !
Jl'avais pas non plus installé sur mon pc, et avec leur débit, j'avais pas assez de 2 h pour l'installer (sans rire, c'était vrai ! Il me demandait environ 3 h) alors forcé de faire du éclipse sous Windows 2000
Nan mais les gus là oO, jsuis en dépression, vous voulez m'achever c'est ça ?

edit : bon, ça y est, j'ai installé sur mon pc, mais ça reste eclipse…
Va faloir que je vois comment faire avec vim.

Dernière modification par helly (Le 11/01/2011, à 22:25)

grim7reaper · Le 11/01/2011, à 22:26

ArkSeth a écrit :

Ce que je n'arrive pas à comprendre, c'est que si je déplace le fclose(file); à la sortie de la première boucle plutôt que tout à la fin (c'est là que je l'avais mis au début, vu qu'on a plus besoin du fichier après), il me sort un segfault

Un truc de ce genre ça sente la corruption mémoire à plein nez : tu dois faire des accès pas très catho à certains endroits.
Sûrement de peu, genre des off-by-one (Valgrind semble m'approuver).
Reste à voir pourquoi.

Sinon, si j'étais toi je mettrais le troisième paramètre en const vu que tu ne comptes pas le modifier.

(*nbwords) = 0;

Parenthèses inutiles.

@helly : pourquoi Eclipse (pour Java ça pourrait presque se justifier, mais là…) ?

Dernière modification par grim7reaper (Le 11/01/2011, à 22:36)

Pylades · Le 11/01/2011, à 22:26

ArkSeth a écrit :

[…]
(Oui, je sais, sizeof(char) c'est pas la peine, mais j'trouve ça plus lisible )
[…]

truc * sizeof (char) serait donc plus lisible que truc. Ouais, ça se défend…

Au passage, tant qu'à avoir tes tailles en long, autant les passez en size_t, c'est un saine habitude à prendre.
(Tu comprendras si un jour tu actives -Wconversion. ^^)

Sinon, fseek peut échouer, il faut tester le retour, mais ça je ne t'en veut pas, je ne le fait pas moi-même. En revanche, je ne pas tester le retour de fopen, ça c'est impardonnable.

Et désolé, mais je ne comprends pas la cause de ton bug…

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

helly · Le 11/01/2011, à 22:28

grim a écrit :

@helly : pourquoi Eclipse (pour Java ça pourrait presque se justifier, mais là…) ?

Javascript.
Jsais pas encore comment faire ça sans eclipse vu qu'il y a une magouille à faire avec tomcat que je ne sais pas faire sans eclipse.

Кຼزດ · Le 11/01/2011, à 22:29

helly a écrit :

grim a écrit :
@helly : pourquoi Eclipse (pour Java ça pourrait presque se justifier, mais là…) ?
Javascript.
Jsais pas encore comment faire ça sans eclipse vu qu'il y a une magouille à faire avec tomcat que je ne sais pas faire sans eclipse.

Yaaaaaaaaaaaaaaaaaargh

Pylades · Le 11/01/2011, à 22:35

grim7reaper a écrit :

[…]
Pylade a écrit :
grim7reaper a écrit :
@Rolinh : quand je vois des exit dans un code, je sors mon revolver…
T'es si catégorique que ça ? T'as des arguments ?
Non bien sûr, il y a des cas où c'est justifié bien entendu.
C'est juste que le voir utiliser à tort et à travers ça me rend violent ^^.
Pour les arguments, bah c'est juste crade de quitter comme ça quand tu joues avec les *alloc : exit ne libère pas la mémoire allouée avant de quitter (Ok avec Linux, Windows, BSD & cie, no problem ils nettoient après ton passage mais ce n'est pas une raison).

Ah, OK. Là dessus nous sommes complétement d'accord. ^^

tshirtman · Le 11/01/2011, à 22:48

@koin: +1 ^^

The Uploader · Le 11/01/2011, à 22:50

Кຼزດ a écrit :

helly a écrit :
grim a écrit :
@helly : pourquoi Eclipse (pour Java ça pourrait presque se justifier, mais là…) ?
Javascript.
Jsais pas encore comment faire ça sans eclipse vu qu'il y a une magouille à faire avec tomcat que je ne sais pas faire sans eclipse.
Yaaaaaaaaaaaaaaaaaargh

yAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARGH!

euh attends.. :

réponse a écrit :

introspection a écrit :
Pourquoi FlashDevelop (pour un cours sur Flash ça pourrait se justifier, mais là....) ?
Jsais pas encore traduire de l'ActionScript de cours à vitesse 1:1. Obligé de magouiller FlashDevelop dans une VM Windows XP et de lui trouver ses .NET Framework et son JRE, et ses .dll vieilles et oubliées pour qu'il fonctionne.

DOUBLE yAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARGH!

Dernière modification par The Uploader (Le 11/01/2011, à 22:56)

Elzen · Le 11/01/2011, à 22:51

grim7reaper a écrit :

Un truc de ce genre ça sente la corruption mémoire à plein nez : tu dois faire des accès pas très catho à certains endroits.
Sûrement de peu, genre des off-by-one (Valgrind semble m'approuver).
Reste à voir pourquoi.

À part quelques tests sur les paramètres, appeler cette fonction est le premier truc que je fais dans le programme, donc j'suis à peu près sûr que ça vient de cette fonction-là.

grim7reaper a écrit :

Sinon, si j'étais toi je mettrais le troisième paramètre en const vu que tu ne comptes pas le modifier.

Done.

grim7reaper a écrit :

Sinon tu mets trop de parenthèses inutiles je trouve (mais c'est totalement subjectif).

J'ai fait un peu de Lisp, donc j'trouve pas
(D'une manière générale, je préfère mettre trop de parenthèses que pas assez (d'ailleurs même en français j'en mets trop (la preuve ^^))).

Pylade a écrit :

Au passage, tant qu'à avoir tes tailles en long, autant les passez en size_t, c'est un saine habitude à prendre.
(Tu comprendras si un jour tu actives -Wconversion. ^^)

Quand j'vous dis que je débute
Effectivement, -Wconversion me sort quelques warnings en plus
Déjà, j'avais mis des long pour faire plaisir à -Wextra, ils pourraient se mettre d'accord, quand même ^^"
J'vais essayer de corriger, pour la forme.

Pylade a écrit :

Sinon, fseek peut échouer, il faut tester le retour, mais ça je ne t'en veut pas, je ne le fait pas moi-même. En revanche, je ne pas tester le retour de fopen, ça c'est impardonnable.

Bah d'un autre côté, le programme est fait pour lire des fichiers qui seront générés par un autre exécutable situé juste à côté (et sera accompagné d'un script shell qui appelera les deux l'un après l'autre), donc à mon humble avis, si le type qui teste arrive à avoir des fichiers pas lisibles, il mérite de se prendre une segfault dans la tronche
J'suppose que si je corrige, le truc doit renvoyer une taille de 0 ou -1, et dans ce cas, le main qui appelle la fonction quitte avec un message d'erreur…

Pylade a écrit :

Et désolé, mais je ne comprends pas la cause de ton bug…

Pendant mon premier séjour à la fac, mon expérience personnelle me faisait penser que les segfaults incompréhensibles qui apparaissent et disparaissent juste en déplaçant une ligne de code apparemment anodine étaient un truc obligé en C ^^"

grim7reaper · Le 11/01/2011, à 22:54

@ArkSeth : erreur classique

text = malloc(size * sizeof(char));

buffer trop petit, si tu à N caractères, il te faut un buffer de N+1 cases ('\0' terminal, ajouté de manière automatique par fgets).
Du coup, là tu écrivais un '\0' à la suite de ton buffer et tu écrasais un truc qui fallait pas…

Dernière modification par grim7reaper (Le 11/01/2011, à 22:54)

helly · Le 11/01/2011, à 22:56

tshirtman a écrit :

@koin: +1 ^^

Si vous pensez que je choisi…
edit : ↓ idem.

Dernière modification par helly (Le 11/01/2011, à 23:06)

compte supprimé · Le 11/01/2011, à 23:05

Bn;

EDIT : Page 42 \o/

Dernière modification par Lagierl (Le 11/01/2011, à 23:05)

Elzen · Le 11/01/2011, à 23:06

ArkSeth a écrit :

Effectivement, -Wconversion me sort quelques warnings en plus
Déjà, j'avais mis des long pour faire plaisir à -Wextra, ils pourraient se mettre d'accord, quand même ^^"
J'vais essayer de corriger, pour la forme.

Ou pas : le projet est à rendre rapidement, j'ai des partiels pas sympa à réviser, et ça me sort trop de warnings partout.
Déjà, j'suis passé au -Wextra… je rajouterai le -Wconversion plus tard ^^

grim7reaper a écrit :

Du coup, là tu écrivais un '\0' à la suite de ton buffer et tu écrasais un truc qui fallait pas…

Ah ouais, pas bête ^^

tshirtman · Le 11/01/2011, à 23:09

à part pour le DS de java, ou j'avais pas le temps de me faire un environnement, j'ai quasi pas utilisé éclipse, et toujours utilisé vim…

(ok, et le premier TP gui de .net, fallait bien voir comment marche ces widgets, et s'aider du designer pour commencer).

sinon je viens d'ajouter une détection de collision pixel perfect dans un petit projet que je fais, à chaque frame, ça plombe bien les performances >_< (entre une image de 75*75 et une autre de 1000*480) je ne parcours que les pixels contenus dans la plus petite bien sur… j'ai décidé d'incrémenter de 2 en deux, du coup, c'est plus que du semi, perfect, mais c'est amplement suffisant… je vais même peut être passer à 4…

edit: même à 8, le résultat est plus qu'acceptable, et mes perfs sont sacrément plus sympas ^^, on va en rester là pour l'instant

Dernière modification par tshirtman (Le 11/01/2011, à 23:14)

grim7reaper · Le 11/01/2011, à 23:13

Normalement on ne teste pas tout les pixels d'une image.
On dégrossi avec les bounding box et s'il y a collision on ne teste que la zone de chevauchement en pixel-perfect (mais c'est peut-être ce que tu fais déjà, je ne suis pas sûr d'avoir bien interprété ton message). Du moins c'est comme ça que je ferai.

Dernière modification par grim7reaper (Le 11/01/2011, à 23:14)

tshirtman · Le 11/01/2011, à 23:21

oui, c'est ce que je fais, j'ai ma petite image, je regarde ou elle est positionnée sur la grande, et je parcours tous les pixels sur celle là, en regardant si les pixels sont non transparent sur les deux images.

grim7reaper · Le 11/01/2011, à 23:29

De toute façon, travailler sur les pixels c'est toujours lent (en SDL du moins).
Faut rapatrier la surface en RAM si elle est en VRAM, la bloquer, faire ce que tu as à faire, la débloquer et la renvoyer en VRAM (si elle y était).
Forcément, c'est pas gratuit ce genre de truc.

tshirtman · Le 11/01/2011, à 23:35

faudrait une opération pour tester un masque sur une surface directement en vram…

grim7reaper · Le 11/01/2011, à 23:40

OpenGL (ou d'autres bibliothèques du genre) propose peut-être des trucs comme ça, je ne sais pas.

Dr Le Rouge · Le 12/01/2011, à 00:12

42 ?

grim7reaper · Le 12/01/2011, à 00:16

Tiens, vla le mec qui code en Pascal

:!pakman · Le 12/01/2011, à 00:16

Le Rouge a écrit :

42 ?

A cette question, je répondrais par... 42, bien sûr ! (c'est beau la récursivité)
bn tt le monde

Dernière modification par :!pakman (Le 12/01/2011, à 00:17)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1026 Le 11/01/2011, à 21:50

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

#1027 Le 11/01/2011, à 21:50

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

#1028 Le 11/01/2011, à 22:16

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

#1029 Le 11/01/2011, à 22:17

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

#1030 Le 11/01/2011, à 22:26

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

#1031 Le 11/01/2011, à 22:26

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

#1032 Le 11/01/2011, à 22:28

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

#1033 Le 11/01/2011, à 22:29

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

#1034 Le 11/01/2011, à 22:35

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

#1035 Le 11/01/2011, à 22:48

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

#1036 Le 11/01/2011, à 22:50

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

#1037 Le 11/01/2011, à 22:51

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

#1038 Le 11/01/2011, à 22:54

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

#1039 Le 11/01/2011, à 22:56

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

#1040 Le 11/01/2011, à 23:05

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

#1041 Le 11/01/2011, à 23:06

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

#1042 Le 11/01/2011, à 23:09

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

#1043 Le 11/01/2011, à 23:13

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

#1044 Le 11/01/2011, à 23:21

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

#1045 Le 11/01/2011, à 23:29

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

#1046 Le 11/01/2011, à 23:35

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

#1047 Le 11/01/2011, à 23:40

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

#1048 Le 12/01/2011, à 00:12

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

#1049 Le 12/01/2011, à 00:16

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

#1050 Le 12/01/2011, à 00:16

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

Pied de page des forums