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

tshirtman · Le 07/08/2011, à 09:10

oh, je dis pas que c'est de ta faute .

Et sinon, si, je pense que dans tous les cas, il faut que la procédure d'affichage prenne grosso modo le même temps si possible, c'est mieux d'avoir des fps régulier…

The Uploader · Le 07/08/2011, à 09:14

euh ça c'est avec la clock (tick event), mais pour l'instant j'ai que la souris, et elle est pas concernée.. (si le jeu rame, la sours n'est pas censée ramer avec, surtout que normalement je m'en occupe pas. Là c'est "ma" faute : j'ai mis "show_cursor=false" pour en remplacer le sprite ^^)

Dernière modification par The Uploader (Le 07/08/2011, à 09:15)

grim7reaper · Le 07/08/2011, à 09:17

Hello World!

The Uploader a écrit :

Puis j'vais pas blitter le background et tout redessinner alors que j'ai qu'un seul sprite qui a demandé à être redéssiné, c'nul!

Bah de toutes façons, y’a pas 42 solutions : soit tu fais comme ça, soit tu blittes un bout du background de la taille du sprite à son ancienne position et tu blittes le sprite à sa nouvelle.

Je sais que la solution 2 est censée correspondre à undraw/draw mais c’est peut‑être mal foutu, au pire fait le à la main et regarde si ça change quelque chose.

tshirtman · Le 07/08/2011, à 10:30

Peut être que undraw se passe à la nouvelle position, ce qui expliquerait les trainés

The Uploader · Le 07/08/2011, à 10:42

ben nan, j'ai essayé de faire un Sprite.undraw/Sprites.UpdateGroupe.undraw avant et/ou après, bref a peu près dans tous les sens. ^^

Dernière modification par The Uploader (Le 07/08/2011, à 10:47)

grim7reaper · Le 07/08/2011, à 10:47

Bah essaye de le faire à la main, t’as rien à perdre (si ce n’est du temps au cas où ça ne change rien).

grim7reaper · Le 07/08/2011, à 14:32

@helly : bon voilà le résultat de mon code review sur ta dernière version d’Enigma.

Général
Je préfère mettre les parties public, puis les parties protected et enfin ce qui est private au lieu de private suivi de public comme tu le fais.
La raison c’est que si quelqu’un veut regarder mon code, il voit d’abord ce qui le concerne (qui est publique, donc l’interface) avant de voir toute la mécanique interne qui ne l’intéresse pas forcément.
C’est juste un conseil, rien de technique là-dedans donc tu en tiens compte si tu veux.

Sinon ça pourrait être sympa de mettre tout ton code dans un namespace Enigma.
Enfin, une remarque que je veux te faire depuis le début mais que j’oublie à chaque fois : n’utilise pas de caractères non‑ASCII dans tes chaînes de caractères (genre les insécables fines et autres conneries). Ce n’est pas portable (le rendu n’est pas garanti).

Makefile
Le -lc inutile, ça fonctionne très bien sans et je ne vois pas vraiment son intérêt.

Reflecteur.h
Tu as mis le commentaire sur le pourquoi 256, mais on ne voit pas apparaître le 256 dans ce fichier (vu qu’il est dans rotor.h). Je pense qu’il vaut mieux virer ce commentaire de reflecteur.h.

Rotor.h
Ici tu utilises la spécifications des exceptions (quand tu mets throw après le prototype de ton constructeur).
Dans l’absolu c’est pas mauvais, mais faut faire gaffe quand tu l’utilises : il faut l’utiliser seulement quand tu maîtrises tout le code appelé et que tu peux prévoir son déroulement (Cf. ici).
Bon là c’est le cas donc ça va.

Cependant, je te conseil d’éviter l’utilisation de la spécifications d’exceptions. Personnellement je ne l’utilise que pour signaler l’absence d’exceptions (donc en mettant throw() après les fonctions concernées).
Dans les autres cas je trouve que ça n’apporte rien, si ce n’est des emmerdes…
Autant en Java je peux comprendre (t’as une erreur à la compil’ si tu lances une exception non-prévue), autant en C++ ça n’apporte rien (si tu lances une exception non-prévue ça appelle std::unexpected (comme expliqué ici) et généralement ça crash (vu que par défaut ça appelle std::terminate).
D’ailleurs, il semblerait que les cadors du C++ me donnent raison car ce système va être déprécié en C++0x (partie « Deprecated Exception Specifications, Added noexcept ») et throw() (que je considère comme seul usage valable de ce mécanisme) va être conservé mais on le signalera par le mot‑clef noexcept.

Enigma.h
Il y a toujours la déclaration de la fonction membre Afficher qui n’existe pas. Il faudrait que tu penses à l’enlever.

Erreurs.h
Bon là, y’a pas mal de trucs à revoir ^^"

Déjà, je te conseille de revoir ta hiérarchie d’exception.
Tu ne dérives pas de std::exception pour Err_Rotor comme je te l’avais conseillé. Tu as une bonne raison pour ça ?
Tu peux t’inspirer de cet exemple.

Ensuite, dans Err_Rotor tu as un attribut de type std::string. C’est très fortement déconseillé.
std::string peut lancer une exception lors de sa construction (genre plus de mémoire pour allouer la chaîne et hop il t’envoie une std::bad_alloc dans la face). Et à ton avis, il se passe quoi quand tu lances une exception pendant que tu lances une exception ?
Bah un truc pas cool du tout => Tu as donc deux exceptions à gérer, laquelle tu choisis ?
La problème est insoluble donc la norme nous dit que ça invoque std::terminate et ça crash violemment.
Bon je dramatise un peu là, en fait c’est vraiment insoluble quand une exception est lancée lors du stack unwinding, ce qui n'est pas ton cas ici (du moins il me semble), donc ça reste peut‑être gérable mais c’est vraiment pas conseillé quand même.

Tiens, lit ça (ce n’est pas long). Ça devrait de donner une idée de ce qui est bien et pas bien dans ce domaine.
Tu remarqueras que les points 1 et 3 correspondent à mes deux remarques ;-).

Rotor.c++
Bon déjà je vois que tu mets toujours ton std::ios::in quand tu construis un std::iftream. Je l’ai déjà dit précédemment, mais c’est peut‑être passé inaperçu, c’est inutile car c’est déjà le mode d’ouverture par défaut (regarde là).

Ensuite, après l’ouverture tu fais ce test :

if (!fichier || fichier.eof())

tester eof est inutile car il ne peut être positionné qu’après avoir effectué au moins une opération de lecture.
Si tu n’as pas lu avant, tu ne peux pas savoir si le fichier est vide de cette manière. À la limite tu peux tester la taille du fichier pour voir si elle est nulle, mais là faut sortir POSIX car, pour ce que j’en sais, ce n’est pas faisable en C++ standard.

Pour les exceptions, tu peux remplacer tous tes trucs du genre :

Err_Fichier err(nom);
throw err;

par

throw Err_Fichier(nom);

Au passage, mettre un return après un throw est totalement inutile (c’est comme si tu mettais deux return à la suite…).
Suite à cette dernière remarque tu comprends que ça :

if (fichier.eof())
{
    Err_Fichier err(nom);
    throw err;
    fichier.close();
    return;
}

c’est foireux, car tu ne fermeras jamais le fichier. Il faut le réecrire comme ça :

if (fichier.eof())
{
    fichier.close();
    throw Err_Fichier(nom);
}

Enfin, ta boucle de lecture dans le constructeur est foireuse.
Tu testes eof, puis tu lis et enfin tu traites.
C’est mauvais pour deux raisons :
- comme dit précédemment, eof est inconnu avant de lire au moins une fois dans le fichier, donc s’il est vide à la base ça sent mauvais à la première itération (tu passes le test car eof n’est pas positionné et tu fais getline sur un fichier vide…) ;
- tu ne fais aucun test pour savoir si getline s’est bien passée et si le flux est toujours dans un état cohérent.

Le bon "algo" c’est : tu lis, tu testes si tout c’est bien passé et si oui là tu peux traiter ce que tu as lu (si non, bah tu fait ce que tu veux pour gérer le problème, selon le type du problème).

Reflecteur.c++
Grosso modo même remarques que pour rotor.c++

Enigma.c++
Dans le constructeur, ton try/catch ne sert à rien.
Tu attrapes Err_Rotor pour la relancer sans faire aucun traitement O_o"
Bah à ce compte là, ne l’attrapes pas et laisse la passer. Ça te sert à quoi de l’attraper si c’est pour faire ça ?
Bon, je ne reviens pas sur les return après les throw, j’en ai parlé juste avant.

Ha, et ton constructeur peut crasher violemment sans que tu comprennes aussi.
Là tu as mal utilisé la specification d’exceptions (quand je disais que c’était source d’emmerdes et qu’il faut l’utiliser avec des pincettes, c’est pas une blague ).
Je m’explique.
Tu dis au compilateur que ton constructeur ne peux lancer qu’une exception de type Err_Rotor. Sauf que dans le constructeur tu fais appel à la fonction membre reserve de std::vector. Or cette fonction membre peut (comme chaque fonction qui fait de l’allocation mémoire il me semble) émettre une std::bad_alloc.
Et là c’est le drame , car tu ne l’attrapes pas (ton catch ne s’occupe que des Err_Rotor) et donc ton constructeur peut lancer une std::bad_alloc (mais toi tu as dit le contraire au compilo ).
Dans ce cas de figure, la norme nous dit que std::unexpected est invoqué (mais tout ça c’est déjà expliqué dans ce lien que j’ai déjà donné plus haut).
Donc il vaudrait mieux virer ta spécification d’exceptions ici.

Erreur.c++
Bon bah comme je l’ai déjà plus ou moins dit précédemment tes exceptions sont à revoir.
Ta fonction membre toString est inutile et surtout « dangereuse » car elle joue avec de l’allocation mémoire (concaténation pour l’une, std::ostringstream pour l’autre) donc tu risques de lancer une std::bad_alloc dans ton exception.
Si tu veux un message d’erreur, il y a la méthode what pour ça (à condition bien sûr que tu dérives de std::exception, mais ça j’en ai parlé avant).

main.c++
Ta lecture du nombre de rotors n’est pas très user‑friendly : ça termine le programme dès que l’on se trompe
De plus, elle réagit moyennement bien sur un ^D. Du genre comme ça :

nom du fichier du réflecteur ? :combien de rotors mettre dans la machine ? :nombre non acceptable

Je te conseille de t’inspirer de ma fonction de lecture d’unsigned : elle gère les EOF et elle est plus user‑friendly vu qu’elle redemande tant que la personne se plante (ça évite de relancer le programme à chaque erreur…)

Aussi, vu que cran dans la classe Rotor est un unsigned int, pourquoi ta paire <nom, cran> c’est
du <std::string, int> au lieu de <std::string, unsigned int> ?

Bon voilà, je crois que j’ai fait le tour.
Long post is long…

PS : s’il y en a qui se demande pourquoi je parle parfois de fonctions membres au lieu de méthodes c’est parce qu’il y a une nuance.
Je cite :

Luc Hermitte a écrit :

Non, bien au contraire. Méthode est un terme impropre au C++. On va le retrouver dans d'autres langages ou dans la spéc d'UML. D'ailleurs dans cette dernière, une méthode correspond à la mise en oeuvre d'une opération. Vu sous cet angle, cela signifierait qu'une méthode est retranscrite en C++ par une fonction membre virtuelle; l'opération étant une fonction membre virtuelle pure. Parler de méthode en C++ est courant, mais il s'agit d'un abus de langage -- un peu comme de parler de polymorphisme pour désigner le polymorphisme d'inclusion (cf la taximonie détaillée par en:Luca_Cardelli).
Pour bien faire, il faudrait au contraire remplacer toutes les occurrences de méthode par fonction membre -- enfin, si on veut être respectueux jusqu'au bout de la terminologie C++.

Édit : tiens je me demande même si je n’ai pas fait un post un peu record niveau longueur là :]
Sachant que ce n’est pas un post de réponse et donc que je ne quote personne c'est d'autant plus beau ^^
Bon, je sais qu’il y a plus long sur le forum mais pour un post technique c'est pas mal je pense.

Dernière modification par grim7reaper (Le 07/08/2011, à 14:36)

tshirtman · Le 07/08/2011, à 18:32

hg clone http://hg.python.org/cpython

pour voir comment ils font leur gestion du temps… un truc que je trouve un peu bordélique en C…

#include "Python.h"

#ifdef __APPLE__
#if defined(HAVE_GETTIMEOFDAY) && defined(HAVE_FTIME)
  /*
   * _PyTime_gettimeofday falls back to ftime when getttimeofday fails because the latter
   * might fail on some platforms. This fallback is unwanted on MacOSX because
   * that makes it impossible to use a binary build on OSX 10.4 on earlier
   * releases of the OS. Therefore claim we don't support ftime.
   */
# undef HAVE_FTIME
#endif
#endif

#ifdef HAVE_FTIME
#include <sys/timeb.h>
#if !defined(MS_WINDOWS) && !defined(PYOS_OS2)
extern int ftime(struct timeb *);
#endif /* MS_WINDOWS */
#endif /* HAVE_FTIME */

void
_PyTime_gettimeofday(_PyTime_timeval *tp)
{
    /* There are three ways to get the time:
      (1) gettimeofday() -- resolution in microseconds
      (2) ftime() -- resolution in milliseconds
      (3) time() -- resolution in seconds
      In all cases the return value in a timeval struct.
      Since on some systems (e.g. SCO ODT 3.0) gettimeofday() may
      fail, so we fall back on ftime() or time().
      Note: clock resolution does not imply clock accuracy! */
#ifdef HAVE_GETTIMEOFDAY
#ifdef GETTIMEOFDAY_NO_TZ
    if (gettimeofday(tp) == 0)
        return;
#else /* !GETTIMEOFDAY_NO_TZ */
    if (gettimeofday(tp, (struct timezone *)NULL) == 0)
        return;
#endif /* !GETTIMEOFDAY_NO_TZ */
#endif /* !HAVE_GETTIMEOFDAY */
#if defined(HAVE_FTIME)
    {
        struct timeb t;
        ftime(&t);
        tp->tv_sec = t.time;
        tp->tv_usec = t.millitm * 1000;
    }
#else /* !HAVE_FTIME */
    tp->tv_sec = time(NULL);
    tp->tv_usec = 0;
#endif /* !HAVE_FTIME */
    return;
}

void
_PyTime_Init()
{
    /* Do nothing.  Needed to force linking. */
}

gettimeofday dans le meilleurs des cas donc… (en supposant que j'ai pris le bon fichier ^^)

edit: note que j'aurais pu faire http://hg.python.org/cpython/file/ >_<

Dernière modification par tshirtman (Le 07/08/2011, à 18:35)

grim7reaper · Le 07/08/2011, à 18:41

T’as besoin de ça pour faire quoi ?

tshirtman · Le 07/08/2011, à 18:47

ben dans du code C, avoir une vrai gestion des FPS et du temps depuis la dernière frame, histoire de mettre à jour correctement ce qui à besoin de l'être, plutot que toujours passer une constante …, comme en googlant j'ai trouvé pleins d'indications contradictoires, et des histoires d'horloges ayant le droit de tourner à l'envers (si on a un serveur ntp, on peut reculer dans le temps entre deux mises à jours…), j'avais envie de savoir comment python faisait pour nous présenter un truc pas chiant, qui indique le temps depuis le lancement du programme… j'ai hésité a regarder le code de pygame aussi, mais y'avais des chances pour qu'il s'appuie sur celui de python…

Dernière modification par tshirtman (Le 07/08/2011, à 18:48)

grim7reaper · Le 07/08/2011, à 19:00

Ok.

Si tu veux, j’ai de la précision niveau nanosecondes mais je ne pense pas qu’il soit nécessaire d’aller jusque là pour de la gestion de FPS :]

Pylades · Le 07/08/2011, à 19:23

@ Elzen : dans launcher/dockmenus.py : http://paste.tdct.org/index.php?x.
Ainsi, tu respectes XDG, une exception est levée quand $HOME n’existe pas au lieu de passer silencieusement « '~' » et tout fonctionne correctement. À voir peut-être l’intégration de la vérification que $XDG_CONFIG_HOME n’est pas vide.

Ah, et la référence en dur à .config/ se trouve trois fois dans stettings/workspace et deux fois dans tasklist/wsfilm (dont un /home/seth/.config/touhy/gtkrc/extras).

Dernière modification par Πυλάδης (Le 07/08/2011, à 21:24)

tshirtman · Le 07/08/2011, à 19:43

grim7reaper a écrit :

Ok.
Si tu veux, j’ai de la précision niveau nanosecondes mais je ne pense pas qu’il soit nécessaire d’aller jusque là pour de la gestion de FPS :]

oui, j'ai vu qu'on pouvait faire ça, mais la question reste la portabilité… il me semble que cette fonction n'est dispo que sous linux et ses amis…

grim7reaper · Le 07/08/2011, à 20:01

Non, ma solution est disponible sous tous les OS qui implémentent POSIX.1-2001.
Je ne sais pas où en est Windows là-dessus, je sais quil n’implémente qu’un bout de POSIX et je ne sais pas si ce bout inclu POSIX.1-2001.

Édit : bon en fait, comme à son habitude Windows chie sur les standards existants et fait son propre truc dans son coin ce qui donne QueryPerformanceCounter pour avoir l’équivalent (bon au pire ça se résout à coup de compilation conditionnelle, mais bon…).
C’est bien ce que j’avais cru voir dans les sources de SDL.

Bon cela dit, je pense que les nanosecondes pour du FPS c'est overkill. Autant rester sur gettimeofday.

Dernière modification par grim7reaper (Le 07/08/2011, à 20:11)

helly · Le 07/08/2011, à 21:57

@grim : merci pour les remarques, je regarde ça… demain !
Là j’vais jouer avec ma hache et mes poissons !

Sir Na Kraïou · Le 07/08/2011, à 23:17

Æ

HP · Le 08/08/2011, à 01:04

…

Dernière modification par HP (Le 09/08/2011, à 08:51)

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

koin sans code

samυncle · Le 08/08/2011, à 01:08

.

nesthib · Le 08/08/2011, à 01:14

plop

samυncle · Le 08/08/2011, à 03:03

.

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

Scores totaux, depuis le début :

1) 3995    nesthib
2) 3459    Πυλάδης
3) 3441    samuncle
4) 2531    Кຼزດ
5) 2011    cm-t
6) 1800+5  grim7reaper /* ./viewtopic.php?pid=3486252#p3486252 */
7) 1683    na kraïou
8) 884    helly
9) 877    \\Ouranos//
10) 769    tshirtman
11) 659    gnuuat
12) 565    Lagierl
13) 448    Rolinh
14) 434    The Uploader
15) 428    nathéo
16) 271    Kanor
17) 202    :!pakman
18) 196    Askelon
19) 121    ǤƦƯƝƬ
20) 105    HP
21) 103    kamui57
22) 93    petifrancais
23) 78    edge_one
23) 78    pierguiard
25) 70    gulp
26) 45    Le Rouge
27) 42    sakul
28) 38    xapantu
29) 37    ilagas
30) 30    keny
30) 30    Atem18
32) 26    gustare
32) 26    d10g3n
34) 25    GentooUser
34) 25    Morgiver
34) 25    pfranco
37) 24    ไ୦บเઢ'
37) 24    Steap
39) 20    CROWD
40) 18    Ph3nix_
41) 16    kouskous
42) 15    timsy
43) 12    stratoboy
43) 12    sailing
45) 11    alexises
45) 11    Crocoii
47) 10    Toineo
47) 10    NutMotion
47) 10    pseudovingtcinqcaracteres
47) 10    pfriedZ
47) 10    CasseTaTele
47) 10    Zeibux
47) 10    THS`
47) 10    golgoth42
47) 10    ꙳♒⏅⚓ ЅаίԼίՈԶ ⚓⏅♒꙳
47) 10    Ras'
57) 8    Mornagest
58) 7    Vista
59) 6    ubuntlin
59) 6    asma.geek
61) 5    tendances-tdct
61) 5    kinouchou
63) 4    danychou56
63) 4    Neros
63) 4    Biaise
63) 4    totoflute
63) 4    pinballyoda ㋛
63) 4    NLS le pingouin
63) 4    ceric
63) 4    Dice-Man
63) 4    Pylade
72) 3    Revan26914
72) 3    raspouillas
72) 3    sweetly
72) 3    DaveNull
76) 2    SoJaS
77) 1    geenux
77) 1    ArzhurBZH
77) 1    monsieurweller

Répartition Posts/heure

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

Scores de la période en cours :

1) 62    nesthib
2) 60    na kraïou
3) 58    Πυλάδης
4) 37    samuncle
5) 22    tshirtman
6) 16    HP
7) 10    Ras'
7) 10    pfranco
9) 9    Кຼزດ
10) 6    helly
11) 5    cm-t
11) 5    \\Ouranos//
13) 3    DaveNull
13) 3    The Uploader
15) 2    xapantu

Ras' · Le 08/08/2011, à 06:43

le compteur a écrit :

47) 10 Ras'

\o/

helly · Le 08/08/2011, à 10:05

Hey, vous savez quoi mettre dans le vimrc pour que, quand on ouvre un fichier, on se trouve totomatiquement en mode insertion ?

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1876 Le 07/08/2011, à 09:10

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

#1877 Le 07/08/2011, à 09:14

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

#1878 Le 07/08/2011, à 09:17

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

#1879 Le 07/08/2011, à 10:30

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

#1880 Le 07/08/2011, à 10:42

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

#1881 Le 07/08/2011, à 10:47

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

#1882 Le 07/08/2011, à 14:32

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

#1883 Le 07/08/2011, à 18:32

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

#1884 Le 07/08/2011, à 18:41

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

#1885 Le 07/08/2011, à 18:47

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

#1886 Le 07/08/2011, à 19:00

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

#1887 Le 07/08/2011, à 19:23

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

#1888 Le 07/08/2011, à 19:43

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

#1889 Le 07/08/2011, à 20:01

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

#1890 Le 07/08/2011, à 21:57

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

#1891 Le 07/08/2011, à 23:17

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

#1892 Le 08/08/2011, à 01:04

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

#1893 Le 08/08/2011, à 01:08

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

#1894 Le 08/08/2011, à 01:08

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

#1895 Le 08/08/2011, à 01:14

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

#1896 Le 08/08/2011, à 03:03

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

#1897 Le 08/08/2011, à 06:42

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

#1898 Le 08/08/2011, à 06:42

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

#1899 Le 08/08/2011, à 06:43

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

#1900 Le 08/08/2011, à 10:05

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

Pied de page des forums