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

Pylades · Le 05/05/2010, à 21:01

Vous pouvez pas virer ces :: qui font penser à cette engeance de langage du titre du topic ?

/me retourne à Ritchie & Kernighan.

grim7reaper · Le 05/05/2010, à 21:04

Bon, bah je ne dépasserais pas nesthib ce soir .
Et oui chers amis, une fois n'est pas coutume, mais ce soir je vais déserter le TDCCT (et même le PC O_o").

@Pylade : ha ok, j'avais oublier que tu bossais en TTY maintenant. Tu y as pris goûts ? Tu y es souvent ?

@helly : Bon courage, tu ne le regretteras pas .

Edit : Le dernier post de Pylade me fait penser qu'il faut que je chope le K&R, c'est la bible du C quand même c'est pas sérieux de ne pas l'avoir .

/me est déjà parti...

Dernière modification par grim7reaper (Le 05/05/2010, à 21:05)

Кຼزດ · Le 05/05/2010, à 21:04

Pylade a écrit :

Vous pouvez pas virer ces :: qui font penser à cette engeance de langage du titre du topic ?

Ah, tu parles d'un vrai langage moderne ?

Pylades · Le 05/05/2010, à 21:36

grim7reaper a écrit :

@Pylade : ha ok, j'avais oublier que tu bossais en TTY maintenant. Tu y as pris goûts ? Tu y es souvent ?

C’est pas super confortable sur certains points (surtout pour gérer les configurations de clavier , mais quand on bosse il n’y en a pas besoin), mais c’est pratique pour bosser. Et puis comme je n’ai pas réussit à régler la coloration syntaxique de vim comme je le voulais, j’ai gardé celle par défaut, et je trouve qu’elle rend mieux en TTY. Mais bon, je n’y suis que pour coder et débugger, pour le reste j’utilise un terminal graphique.

grim7reaper a écrit :

Edit : Le dernier post de Pylade me fait penser qu'il faut que je chope le K&R, c'est la bible du C quand même c'est pas sérieux de ne pas l'avoir .

Je ne sais pas si ce sont traducteurs (Jean-François Groff et Éric Mottier), ou si c’est moi qui était trop jeune et innocent à l’époque, mais . Bon c’est peut-être aussi le fait que ça soit un bouquin plus âgé que moi (c’est la 2e édition), ça doit jouer aussi.

Nan, pas les cailloux !

cm-t · Le 05/05/2010, à 22:53

CFCF XELEX ZYGDE VEMSQ SKXTZ VMGYX ELENL FCENG CTCES GPWHY G

Dernière modification par cm-t (Le 05/05/2010, à 23:03)

helly · Le 05/05/2010, à 23:14

<p>BN</p>

gnuuat · Le 05/05/2010, à 23:18

cm-t a écrit :

CFCF XELEX ZYGDE VEMSQ SKXTZ VMGYX ELENL FCENG CTCES GPWHY G

T'as pas oublié le W aut tout début ?

#include <stdlib.h>
#include <unistd.h>

#define MSG "BN!\n"

int             main(void)
  {
    infinite_loop:
      write(STDOUT_FILENO, MSG, strlen(MSG));
      goto infinite_loop;
    return (EXIT_SUCCESS);
  }

Hum...
Jusqu'ici, je me disais que les goto, c'était peut être bien pour les boucles inifnies (au lieu d'un while (42)) mais... Dans le main, ça a pour conséquence de ne jamais rien retourner, ce qui contredit le prototype de la fonction, et surtout...
Ben une boucle infinie, c'est mal. Vaut mieux mettre une variable du genre "run", qu'on pourra mettre à RUN pour boucler et à STOP pour arrêter la boucle (gestion d'exceptions).

Peut être que le goto ne sert que dans des cas de gestion d'exceptions ?

Pylades · Le 05/05/2010, à 23:33

Bon, l’écriture du code est terminée dans les grandes lignes (je n’ajouterai plus de fonctionnalités), et un premier déboguage effectué.

Maintenant, il faut signaler les erreurs lorsqu’elle se produisent, peaufiner (j’ai encore supprimé un return), optimiser, et pousser les tests un peu plus loin. Au fait, vous ne connaîtriez pas un outil qui permettrait de demander au noyau de refuser une allocation de mémoire de temps en temps, histoire de voir si ces cas sont bien gérés ?

All heap blocks were freed -- no leaks are possible

Mwahahahah !

Bon, on va s’arrêter là pour aujourd’hui.

helly · Le 05/05/2010, à 23:39

Courage courage !!! débug bien , mois je vais dodo !

gnuuat · Le 05/05/2010, à 23:40

Pylade a écrit :

noyau de refuser une allocation de mémoire de temps en temps, histoire de voir si ces cas sont bien gérés ?

Fais toi un petit programme qui alloc en masse jusqu'à saturer la mémoire, et qui ensuite va tourner en fond en libérant et reprendre un peu de mémoire de temps en temps.
Ou alors, tu fais un code temporaire dans ton programme qui va rétrécir drastiquement la mémoire accordée à ton process, afin qu'il arrive vite à saturation, pour voir son comportement.
Mais si tu vérifies les malloc, devrait pas y avoir de problèmes.

Pylades · Le 05/05/2010, à 23:43

gnuuat a écrit :

Mais si tu vérifies les malloc, devrait pas y avoir de problèmes.

J’ai tellement fait de conneries pour arriver à pondre ça que je me dis qu’il vaut mieux vérifier.

Pylades · Le 06/05/2010, à 00:16

Plop à points et BN à tous.

nesthib · Le 06/05/2010, à 01:00

grim7reaper a écrit :

Bon, bah je ne dépasserais pas nesthib ce soir .

non… je suis plutôt occupé en ce moment mais je passe vous faire un bref coucou ! o/

Grünt · Le 06/05/2010, à 02:03

plopapoint.

Pylades · Le 06/05/2010, à 12:13

Nesthib, tu as encore oublié…

Pylades · Le 06/05/2010, à 14:57

Bon, j’ai fait un joli petit cleanup, et voici des petites statistiques :

3 fonctions void ;
11 fonctions non-void ;
13 return ;
3 break ;
1 continue ;
0 goto.

Comme vous pouvez le voir, j’ai mis fin à ma fâcheuse manie de mettre des return partout, mais sans pour autant tomber dans l’excès de break, continue, ou goto.
J’ai maintenant moins de return que de fonctions.

\o/

helly · Le 06/05/2010, à 15:01

En quoi est ce un mal d'avoir beaucoup de return ?

Seren · Le 06/05/2010, à 15:03

Pylade a écrit :

Maintenant, il faut signaler les erreurs lorsqu’elle se produisent, peaufiner (j’ai encore supprimé un return), optimiser, et pousser les tests un peu plus loin. Au fait, vous ne connaîtriez pas un outil qui permettrait de demander au noyau de refuser une allocation de mémoire de temps en temps, histoire de voir si ces cas sont bien gérés ?

Tu peux t'amuser à créer une fonction malloc, qui de façon aléatoire, 99% du temps te retourne un pointeur vers une zone allouée (donc qui appelle vraiment malloc) et 1% du temps 1 pointeur NULL...

Pylades · Le 06/05/2010, à 15:06

@helly : relis tout le TdCCT, à un moment je me fais engueuler pour excès de return, et un peu plus tard, je dis que j’aimerais bien modulariser mon projet, mais que je vais avoir du mal à cause des return, et grim7reaper me rétorque que je n’avais qu’à ne pas utiliser autant de return.

Bref, c’est plus propre ainsi.

@Seren : pourquoi pas, je vais voir ça.

Dernière modification par Pylade (Le 06/05/2010, à 15:08)

grim7reaper · Le 06/05/2010, à 15:33

\o\ \o| |o| |o/ /o/

Je connais enfin la source de mon mystico-bug, je vais enfin pouvoir investiguer dessus pour trouver une explication rationnelle.
En fait, le bug se produit pour certaines valeurs utilisées comme graines pour initialiser le générateur aléatoire via srand(). Reste à savoir pourquoi et surtout comment cela impacte le reste du programme (c'est peut-être tout con...ou pas). Maintenant j'ai au moins un point de départ pour le débug (je sens que je vais apprendre des nouveaux trucs si j'arrive à le résoudre).

Sinon, GG à mon responsable qui a su trouver la source. Il n'était pas sûr (c'était une hypothèse, que je viens de confirmer à l'instant) mais c'était la première idée qui lui est venu à l'esprit, avant même la corruption mémoire. Bon en même temps l'aléatoire et les générateurs qui vont avec c'est l'un de ses domaines donc il a plus d'expérience que moi dans le débug de programme se basant sur l'aléatoire.

@helly : regarde là et la discussion qui s'en suit pour l'usage des return.

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

Pylades · Le 06/05/2010, à 16:10

C’est cool, ça.
/me va tester ses échecs de malloc.

oracle_bot · Le 06/05/2010, à 18:18

Scores totaux, depuis le début:

1) 42002    chuck norris
2) 180    samuncle
3) 127    Pylade
4) 118    nesthib
4) 118    grim7reaper
6) 78    mathieuI
7) 70    helly
8) 63    ǤƦƯƝƬ
9) 55    cm-t
10) 37    ilagas
11) 22    pierguiard
11) 22    tshirtman
13) 20    gnuuat
14) 19    Ouranos999
14) 19    Le Rouge
16) 12    stratoboy
16) 12    kouskous
18) 10    CROWD
19) 7    Lagierl
19) 7    oracle_bot
21) 6    sailing
21) 6    Toineo
21) 6    Ph3nix_
24) 5    Mornagest
25) 4    danychou56
25) 4    Neros
25) 4    Biaise
28) 3    Р'tite G☢gole :mad:
29) 2    Kanor
30) 1    ceric
30) 1    pfriedK
30) 1    geenux

WCFCF XELEX ZYGDE VEMSQ SKXTZ VMGYX ELENL FCENG CTCES GPWHY G

oracle_bot · Le 06/05/2010, à 18:18

scores de la période en cours:

1) 42002    chuck norris
2) 170    samuncle
3) 121    Pylade
4) 111    nesthib
5) 108    grim7reaper
6) 71    mathieuI
7) 70    helly
8) 56    ǤƦƯƝƬ
9) 55    cm-t
10) 37    ilagas
11) 22    pierguiard
12) 20    tshirtman
13) 19    Ouranos999
13) 19    Le Rouge
15) 15    gnuuat
16) 12    stratoboy
16) 12    kouskous
18) 10    CROWD
19) 7    Lagierl
19) 7    oracle_bot
21) 6    sailing
21) 6    Toineo
21) 6    Ph3nix_
24) 5    Mornagest
25) 4    danychou56
25) 4    Neros
25) 4    Biaise
28) 3    Р'tite G☢gole :mad:
29) 2    Kanor
30) 1    ceric
30) 1    pfriedK
30) 1    geenux

WCFCF XELEX ZYGDE VEMSQ SKXTZ VMGYX ELENL FCENG CTCES GPWHY G

helly · Le 06/05/2010, à 18:23

Zut j'ai loupé le 69

grim7reaper · Le 06/05/2010, à 18:35

Bah tu le feras le mois prochain.

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1126 Le 05/05/2010, à 21:01

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

#1127 Le 05/05/2010, à 21:04

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

#1128 Le 05/05/2010, à 21:04

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

#1129 Le 05/05/2010, à 21:36

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

#1130 Le 05/05/2010, à 22:53

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

#1131 Le 05/05/2010, à 23:14

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

#1132 Le 05/05/2010, à 23:18

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

#1133 Le 05/05/2010, à 23:33

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

#1134 Le 05/05/2010, à 23:39

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

#1135 Le 05/05/2010, à 23:40

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

#1136 Le 05/05/2010, à 23:43

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

#1137 Le 06/05/2010, à 00:16

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

#1138 Le 06/05/2010, à 01:00

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

#1139 Le 06/05/2010, à 02:03

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

#1140 Le 06/05/2010, à 12:13

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

#1141 Le 06/05/2010, à 14:57

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

#1142 Le 06/05/2010, à 15:01

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

#1143 Le 06/05/2010, à 15:03

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

#1144 Le 06/05/2010, à 15:06

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

#1145 Le 06/05/2010, à 15:33

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

#1146 Le 06/05/2010, à 16:10

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

#1147 Le 06/05/2010, à 18:18

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

#1148 Le 06/05/2010, à 18:18

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

#1149 Le 06/05/2010, à 18:23

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

#1150 Le 06/05/2010, à 18:35

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

Pied de page des forums