..:: Topic des Codeurs Couche-Tard [0] ::..

helly · Le 29/05/2010, à 09:32

@grim : merci
Mais ce qui est étonnant c'est que la deuxième version je l'ai trouvé dans le bouquin de Stroustrup

Compteur du TdCCT · Le 29/05/2010, à 09:42

Scores totaux, depuis le début :

1) 375    samuncle
2) 297    nesthib
3) 259    Pylade
4) 253+5  grim7reaper
5) 214    mathieuI
6) 178    cm-t
7) 126    helly
8) 96    ǤƦƯƝƬ
9) 85    gnuuat
10) 72    tshirtman
11) 70    petifrancais
12) 37    ilagas
13) 27    Ouranos999
14) 25    GentooUser
14) 25    pierguiard
16) 19    Le Rouge
17) 18    Ph3nix_
18) 14    Kanor
19) 12    stratoboy
19) 12    kouskous
21) 10    CROWD
21) 10    keny
23) 7    Lagierl
23) 7    sailing
25) 6    Toineo
25) 6    Mornagest
25) 6    Zeibux
28) 5    xapantu
29) 4    danychou56
29) 4    Neros
29) 4    Biaise
32) 3    Р'tite G☢gole :mad:
33) 1    ceric
33) 1    pfriedK
33) 1    geenux

chart?chs=675x280&cht=p3&chco=ff0000,ffff00,008000,000080,8000ff&chf=bg,s,808080&chl=00h%20-%2000h59|01h%20-%2001h59|02h%20-%2002h59|03h%20-%2003h59|09h%20-%2009h59|10h%20-%2010h59|17h%20-%2017h59|19h%20-%2019h59|20h%20-%2020h59&chd=t:5,3,2,1,3,5,1,1,3&chtt=R%C3%A9partition%20des%20posts&chts=cccccc,12

Compteur du TdCCT · Le 29/05/2010, à 09:42

Scores de la période en cours :

1) 375    samuncle
2) 297    nesthib
3) 259    Pylade
4) 253    grim7reaper
5) 214    mathieuI
6) 178    cm-t
7) 126    helly
8) 96    ǤƦƯƝƬ
9) 85    gnuuat
10) 72    tshirtman
11) 70    petifrancais
12) 37    ilagas
13) 27    Ouranos999
14) 25    GentooUser
14) 25    pierguiard
16) 19    Le Rouge
17) 18    Ph3nix_
18) 14    Kanor
19) 12    stratoboy
19) 12    kouskous
21) 10    CROWD
21) 10    keny
23) 7    Lagierl
23) 7    sailing
25) 6    Toineo
25) 6    Mornagest
25) 6    Zeibux
28) 5    xapantu
29) 4    danychou56
29) 4    Neros
29) 4    Biaise
32) 3    Р'tite G☢gole :mad:
33) 1    ceric
33) 1    pfriedK
33) 1    geenux

grim7reaper · Le 29/05/2010, à 11:20

Hello World !

helly a écrit :

@grim : merci
Mais ce qui est étonnant c'est que la deuxième version je l'ai trouvé dans le bouquin de Stroustrup

Bah ce n'est pas mauvais en soit, surtout pour un objet point qui est généralement composé de 2 int (x et y) et ne contient aucun pointeurs (donc pas de problème avec le constructeur de recopie).
Certains estiment que jusqu'à 8 ou 12 octets le passage par valeur n'est pas mauvais (mais bon ce n'est jamais que l'habitude de certains, pas de consensus à ce niveau pour autant que je sache).

D'autres considèrent qu'il est mieux de passer tout les types non-primitifs par référence au cas où un jour une classe est modifiée est possède pleins d'attributs (donc les objets deviennent gros), il n'y a pas à modifier le code pour remplacer les passage par valeurs en passage par références.

Un léger avantage sur le passage par valeur, c'est que tu peux faire des modifications locales sur ta variable (vu que c'est de la copie, l'objet original est inchangé), avec les références si tu modifie ton paramètre tu modifie l'original (d'où l'ajout d'une couche de const dans l'exemple un pour éviter ça).

gnuuat · Le 29/05/2010, à 16:14

ma solution ./viewtopic.php?pid=3511497#p3511497 ne semble pas fonctionner sous ma Debian O_o .
Déjà, la makefile n'arrive pas à compiler, et quand je compile manuellement, je tombe sur un Mmap error :s

grim7reaper · Le 29/05/2010, à 17:36

Pas très étonnant, ton Makefile est un peu space. Tu utilises $HOSTTYPE pour choisir le compilo, chez moi cette variable contient i686 donc déjà aucun compilo ne sera choisi .

Ensuite, dans ton code tu utilises MAP_FILE (dans rd.c), désolé mais chez moi c'est inconnu au bataillon en tant que flag pour mmap (d'ailleurs mon man et POSIX ne la connaissent pas plus).

\\Ouranos// · Le 29/05/2010, à 22:35

Tiens, une question : en C, y'a des gens qui font des tableaux dynamiques comme ça ?

int i = 4;
int table[i];

Est-ce que vous considérez que c'est acceptable dans un code ?

Dernière modification par Ouranos999 (Le 29/05/2010, à 22:36)

grim7reaper · Le 29/05/2010, à 22:50

Ouranos999 a écrit :

Tiens, une question : en C, y'a des gens qui font des tableaux dynamiques comme ça ?
int i = 4;
int table[i];
Est-ce que vous considérez que c'est acceptable dans un code ?

Bah déjà ce n'est pas un tableau dynamique dans le sens où sa taille est définie à la compilation (et il n'est pas alloué sur le tas).

Après acceptable, sans rentrer dans des questions de goûts, c'est permis en C99 mais certainement pas en C89 ou C90.
Personnellement, je ne vois pas bien l'intérêt d'un tel ajout au standard.

nesthib · Le 29/05/2010, à 23:24

GMT+3

grim7reaper · Le 29/05/2010, à 23:47

http://pix.toile-libre.org/upload/origi … 173193.png
245 700 cellules (390x630) : généré en 0,107 seconde et résolu en 0,064 seconde

Il ne me reste plus qu'un algo de résolution a faire (là c'est du backtracking, le suivant c'est du dead-end filling). Si j'ai la motiv', je me le fais ce soir. Mais avant, il faut que je fasse une petite optimisation qui va me faire économiser 1/3 de mémoire sur mon algo de génération le plus rapide (mais le plus gourmand en mémoire justement).

gnuuat · Le 29/05/2010, à 23:58

@ grim7reaper : je vois ça plus tard dans la journée.
Sous ma FreeBSD, HOSTTYPE donne FreeBSD (uname -s)...

Pylades · Le 30/05/2010, à 00:26

grim7reaper a écrit :

http://pix.toile-libre.org/upload/origi … 173193.png
245 700 cellules (390x630) : généré en 0,107 seconde et résolu en 0,064 seconde
Il ne me reste plus qu'un algo de résolution a faire (là c'est du backtracking, le suivant c'est du dead-end filling). Si j'ai la motiv', je me le fais ce soir. Mais avant, il faut que je fasse une petite optimisation qui va me faire économiser 1/3 de mémoire sur mon algo de génération le plus rapide (mais le plus gourmand en mémoire justement).

T’es un dieu.
Nan, mais vous savez quoi ? La grande faucheuse est un dieu.

cm-t · Le 30/05/2010, à 00:27

Nuit

Кຼزດ · Le 30/05/2010, à 00:37

nenuit

Dernière modification par mathieuI (Le 30/05/2010, à 01:13)

grim7reaper · Le 30/05/2010, à 00:54

Pylade a écrit :

grim7reaper a écrit :
http://pix.toile-libre.org/upload/origi … 173193.png
245 700 cellules (390x630) : généré en 0,107 seconde et résolu en 0,064 seconde
Il ne me reste plus qu'un algo de résolution a faire (là c'est du backtracking, le suivant c'est du dead-end filling). Si j'ai la motiv', je me le fais ce soir. Mais avant, il faut que je fasse une petite optimisation qui va me faire économiser 1/3 de mémoire sur mon algo de génération le plus rapide (mais le plus gourmand en mémoire justement).
T’es un dieu.
Nan, mais vous savez quoi ? La grande faucheuse est un dieu.

Voyons, ça me fait plaisir mais c'est bien trop d'honneur.

C'est surtout que j'ai utilisé les algos les plus rapides que j'avais mais qui consomme plus que les autres en mémoire : ~3.0 Mio pour la génération (peut passer à 2 seulement si je fais ma modif) et ~678.2Kio pour la résolution. Bon, ça reste raisonnable quand on voit la taille des labyrinthes car j'ai optimisé l'empreinte mémoire de manière agressive .
J'ai des algos un peu plus gourmands en CPU mais plus économe en mémoire, tout dépend de ce que l'on veux. J'en ai même un qui pourrait générer des labyrinthes dont la taille est limité uniquement par ton espace disque ^^.

Si tu es intéressé, je pense publier le code dès qu'il sera terminé et documenté, dans les jours à venir si tout se passe sans problème (bon il y aura peut-être quelques morceaux de code pas très esthétiques dû à l'approche d'une deadline mais dans l'ensemble ça devrait être lisible).

nesthib · Le 30/05/2010, à 01:02

Zzz

GMT+3

Pylades · Le 30/05/2010, à 01:08

grim7reaper a écrit :

Voyons, ça me fait plaisir mais c'est bien trop d'honneur.

T’es quand-même vachement balèze.
Bon, je me doute que les algos, ce n’est pas toi qui les as inventés, mais il fallait quand-même les implémenter suffisamment bien pour avoir un aussi bon résultat…

Bon, je n’ai pas trouvé de bon tutoriel pour apprendre le C++, donc je vais me rabattre pour cette nuit sur ma lutte avec Valgrind…

grim7reaper · Le 30/05/2010, à 01:17

Oui c'est sûr que les algos ne sont pas de moi ^^ (encore qu'il y en a un que j'ai dû modifier afin d'ajouter une contrainte, sinon il ne fonctionnait pas), mais c'est vrai que l'implémentation et les choix des structures de données sont cruciaux.

Pour ton Valgrind si tu as besoin, cette nuit je suis là (environ jusqu'à 7h30, pas couché avant 8h30 de toute façon). Et en plus en plein dans le C (labyrinthe pour projet, arbres pour TP à rendre, tas binaire pour TP a préparer), tandis que demain je serais plutôt dans les révisions, au menu : partiel d'électronique, anglais, espagnol et japonais.

Dernière modification par grim7reaper (Le 30/05/2010, à 02:15)

Pylades · Le 30/05/2010, à 01:52

Ouch ! Bonne chance alors.

Bon, ligne qui causait mon invalid write identifiée.
Je suis sûr à 99,94 % environ que c’est elle, mais elle me semble correcte. Mais bon, à priori elle ne l’est pas. En même temps, c’est un peu risqué de bosser avec un char***, mais je pouvais difficilement faire autrement… Ou alors il me faudra créer une fonction redondante, et ça me ferait chier.

samυncle · Le 30/05/2010, à 02:07

Pylades · Le 30/05/2010, à 02:11

Bon, j’ai maintenant une idée plus précise de ce qui merde. Je vais te montrer un truc, peux-tu me dire ce que tu en penses ?

struct opt {
  const char** l_act;
};

/* ptr est un pointeur sur struct opt passé en argument
 * je souhaite faire un realloc de l_act, donc je dois récupérer un pointeur vers l_act
 */

const char*** real;
real=&ptr->l_act;

/* normalement, ça devrait me donner un pointeur correct vers ce putain de l_act ;
 * mais je crois avoir compris que mes soucis venaient de là…
 */

Édit : putain, je viens de comprendre en me relisant ! Quel con !
Je devais être fatigué quand j’ai pondu ça…

Dernière modification par Pylade (Le 30/05/2010, à 02:14)

Compteur du TdCCT · Le 30/05/2010, à 08:42

Scores totaux, depuis le début :

1) 385    samuncle
2) 307    nesthib
3) 269    Pylade
4) 263+5  grim7reaper
5) 220    mathieuI
6) 183    cm-t
7) 126    helly
8) 96    ǤƦƯƝƬ
9) 89    gnuuat
10) 72    tshirtman
11) 70    petifrancais
12) 37    ilagas
13) 30    Ouranos999
14) 25    GentooUser
14) 25    pierguiard
16) 19    Le Rouge
17) 18    Ph3nix_
18) 14    Kanor
19) 12    stratoboy
19) 12    kouskous
21) 10    CROWD
21) 10    keny
23) 7    Lagierl
23) 7    sailing
25) 6    Toineo
25) 6    Mornagest
25) 6    Zeibux
28) 5    xapantu
29) 4    danychou56
29) 4    Neros
29) 4    Biaise
32) 3    Р'tite G☢gole :mad:
33) 1    ceric
33) 1    pfriedK
33) 1    geenux

chart?chs=675x280&cht=p3&chco=ff0000,ffff00,008000,000080,8000ff&chf=bg,s,808080&chl=00h%20-%2000h59|01h%20-%2001h59|02h%20-%2002h59|03h%20-%2003h59|10h%20-%2010h59|12h%20-%2012h59|17h%20-%2017h59|18h%20-%2018h59|23h%20-%2023h59&chd=t:3,4,4,2,3,1,1,1,2&chtt=R%C3%A9partition%20des%20posts&chts=cccccc,12

Compteur du TdCCT · Le 30/05/2010, à 08:42

Scores de la période en cours :

1) 385    samuncle
2) 307    nesthib
3) 269    Pylade
4) 263    grim7reaper
5) 220    mathieuI
6) 183    cm-t
7) 126    helly
8) 96    ǤƦƯƝƬ
9) 89    gnuuat
10) 72    tshirtman
11) 70    petifrancais
12) 37    ilagas
13) 30    Ouranos999
14) 25    GentooUser
14) 25    pierguiard
16) 19    Le Rouge
17) 18    Ph3nix_
18) 14    Kanor
19) 12    stratoboy
19) 12    kouskous
21) 10    CROWD
21) 10    keny
23) 7    Lagierl
23) 7    sailing
25) 6    Toineo
25) 6    Mornagest
25) 6    Zeibux
28) 5    xapantu
29) 4    danychou56
29) 4    Neros
29) 4    Biaise
32) 3    Р'tite G☢gole :mad:
33) 1    ceric
33) 1    pfriedK
33) 1    geenux

Pylades · Le 30/05/2010, à 09:30

@grim7reaper ou gnuuat, ou toute autre personne qui touche bien au C : quand on écrit une chaîne littérale dans le code, il me semble que le compilateur la convertie en static const char*. J’utilise abondamment cette fonctionnalité dans mon code. Mais voilà, je déclare mes pointeurs comme const char*, sans préciser la classe de stockage (donc auto par défaut). Mais est-ce utile de déclarer la classe de stockage de l’objet pointé ? Est-ce acceptable au moins ?

Voilà je m’interroge…
Sinon, il ne me reste plus qu’à gérer correctement les échecs de malloc (SIGSEGV ), et à ajouter les dernière fonctionnalités. Je devrais peut-être commencer à apprendre Doxygen…

Sinon, c’est normal ce truc (optenu avec -v) ?

==3033== WARNING: new redirection conflicts with existing -- ignoring it
--3033--     new: 0x04017070 (strlen              ) R-> 0x04c26210 strlen

Et ça me dit ça,

==3090== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 4)

mais est-ce bien grave, ces quatre erreurs supprimées ?

Ah, et puis sinon, je me suis aperçu que ma taille de pointeur était de 8 octets… alors que je ne dispose que de 870 Mio de RAM !
Et-ce pour coller à mon architecture 64 bits, ou est-ce parce que les devs Ubuntu sont des gros flemmards et font tout sur 8 octets, même sur les machines à petite RAM, pour ne pas s’emmerder ?

Dernière modification par Pylade (Le 30/05/2010, à 09:47)

grim7reaper · Le 30/05/2010, à 12:09

Pylade a écrit :

@grim7reaper ou gnuuat, ou toute autre personne qui touche bien au C : quand on écrit une chaîne littérale dans le code, il me semble que le compilateur la convertie en static const char*.

Ouaip, je confirme et la norme aussi (j'ai balancé la citation dans les 10 premières pages du topic il me semble).

J’utilise abondamment cette fonctionnalité dans mon code. Mais voilà, je déclare mes pointeurs comme const char*, sans préciser la classe de stockage (donc auto par défaut). Mais est-ce utile de déclarer la classe de stockage de l’objet pointé ? Est-ce acceptable au moins ?

Non, tu peux avoir un pointeur auto qui pointe sur une variable static, aucun problème. On n'est plus vraiment dans du typage là.

Sinon, c’est normal ce truc (optenu avec -v) ?
==3033== WARNING: new redirection conflicts with existing -- ignoring it
--3033--     new: 0x04017070 (strlen              ) R-> 0x04c26210 strlen
Et ça me dit ça,
==3090== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 4)
mais est-ce bien grave, ces quatre erreurs supprimées ?

Je pense que c'est normal, ça doit se produire quand gcc remplace certaines fonctions de la GNU libc par ses propres fonctions internes. Tu ne peux pas y faire grand-chose.

Ah, et puis sinon, je me suis aperçu que ma taille de pointeur était de 8 octets… alors que je ne dispose que de 870 Mio de RAM !
Et-ce pour coller à mon architecture 64 bits, ou est-ce parce que les devs Ubuntu sont des gros flemmards et font tout sur 8 octets, même sur les machines à petite RAM, pour ne pas s’emmerder ?

C'est parce que ton architecture est en 64 bits (et surtout que tu utilise un OS 64 bits). Les devs d'Ubuntu n'y sont pour rien, tu as un OS 64 bits donc les définitions de types qui vont avec.

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#2001 Le 29/05/2010, à 09:32

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#2002 Le 29/05/2010, à 09:42

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#2003 Le 29/05/2010, à 09:42

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#2004 Le 29/05/2010, à 11:20

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#2005 Le 29/05/2010, à 16:14

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#2006 Le 29/05/2010, à 17:36

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#2007 Le 29/05/2010, à 22:35

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#2008 Le 29/05/2010, à 22:50

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#2009 Le 29/05/2010, à 23:24

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#2010 Le 29/05/2010, à 23:47

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#2011 Le 29/05/2010, à 23:58

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#2012 Le 30/05/2010, à 00:26

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#2013 Le 30/05/2010, à 00:27

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#2014 Le 30/05/2010, à 00:37

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#2015 Le 30/05/2010, à 00:54

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#2016 Le 30/05/2010, à 01:02

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#2017 Le 30/05/2010, à 01:08

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#2018 Le 30/05/2010, à 01:17

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#2019 Le 30/05/2010, à 01:52

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#2020 Le 30/05/2010, à 02:07

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#2021 Le 30/05/2010, à 02:11

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#2022 Le 30/05/2010, à 08:42

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#2023 Le 30/05/2010, à 08:42

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#2024 Le 30/05/2010, à 09:30

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#2025 Le 30/05/2010, à 12:09

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

Pied de page des forums