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

The Uploader · Le 27/07/2011, à 22:36

.... :]

tshirtman · Le 27/07/2011, à 22:46

>>> import glib
>>> help(glib)

Help on package glib:

NAME
    glib

FILE
    /usr/lib/python2.7/dist-packages/glib/__init__.py

MODULE DOCS
    http://docs.python.org/library/glib

DESCRIPTION
    # -*- Mode: Python; py-indent-offset: 4 -*-
    # pygobject - Python bindings for the GObject library
    # Copyright (C) 2006-2008 Johan Dahlin
    #
    #   glib/__init__.py: initialisation file for glib module
    #
    # This library is free software; you can redistribute it and/or
    # modify it under the terms of the GNU Lesser General Public
    # License as published by the Free Software Foundation; either
    # version 2.1 of the License, or (at your option) any later version.

je crois que ça viens du package python-gobject

tshirtman · Le 27/07/2011, à 23:23

The Uploader a écrit :

OMG Debian Maintainers
.... :]

Ouais, mais les mecs d'openssl-dev ont pas du tout réagit quand il a posé la question… alors franchement, la responsabilité est partagé… certes il a fait une boulette, mais avant de la faire, il a demandé si s'en était une, et on lui a dit que non, pas de soucis avec ça… ils ont sans doute lu trop vite la question… mais c'est pas comme si c'était leur boulot…

(les liens qu'il fournit sont édifiant aussi bien pour les dev d'openssl que pour debian…)

Pylades · Le 27/07/2011, à 23:43

tshirtman a écrit :

[…]
je crois que ça viens du package python-gobject

Oui, c’est le module gobject, et tous ceux qui en dépendent, qui est bidon avec Ubuntu…

cm-t · Le 28/07/2011, à 00:04

'Nuit;

cm-t · Le 28/07/2011, à 00:07

'Nuit;

nesthib · Le 28/07/2011, à 02:10

plop

Sir Na Kraïou · Le 28/07/2011, à 02:30

Кຼزດ · Le 28/07/2011, à 03:05

samυncle · Le 28/07/2011, à 03:24

-.-

Pylades · Le 28/07/2011, à 03:41

Compteur du TdCCT · Le 28/07/2011, à 06:43

Scores totaux, depuis le début :

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

Répartition Posts/heure

Compteur du TdCCT · Le 28/07/2011, à 06:44

Scores de la période en cours :

1) 270    nesthib
2) 246    Πυλάδης
3) 207    na kraïou
4) 184    Кຼزດ
5) 181    cm-t
6) 152    samuncle
7) 92    tshirtman
8) 70    HP
9) 67    grim7reaper
10) 41    The Uploader
11) 30    Atem18
12) 10    nathéo
12) 10    golgoth42
12) 10    ꙳♒⏅⚓ ЅаίԼίՈԶ ⚓⏅♒꙳
15) 9    helly
16) 5    Rolinh
17) 1    kamui57

helly · Le 28/07/2011, à 09:36

grim7reaper a écrit :

helly a écrit :
Elle est belle mon enigma .
Mouais, dans le peu de code que t'as posté y'a déjà quelques trucs qui m'ont fait tiquer hein.
Elle sera vraiment belle une fois qu'on aura fait les finitions ;-)

J’ai déjà dit qu’il y avait pour le moment aucune optimisation !

grim7reaper · Le 28/07/2011, à 09:41

Je sais, d'ailleurs c'est pour ça que j'ai dit :

/me a écrit :

Ouais, ça je te ferais des remarques après ta première release

Mais là c'est pas vraiment des trucs d'optimisations qui m'ont fait tiquer, juste des trucs pas très « C++ ».

helly · Le 28/07/2011, à 09:53

Oui, très possible aussi .
Bon, je la fini, j’essaye de corriger ce que je peux de mon côté, et je balance le code .

helly · Le 28/07/2011, à 11:07

Bon, voilà, maintenant elle marche et fait tout ce que je lui demande.
Maintenant je vais nettoyer tout ça, je pense passer le code ce soir.

helly · Le 28/07/2011, à 16:57

Bon, suite à optimisation, j’ai un problème !
Maintenant, dans enigma, je sépare bien le tableau de rotors, et le reflecteur (qui est un rotor particulier donc que je n’inclus pas dans le tableau, je lui fais une variable particulière, en vue après de lui faire une propre classe dérivée de la classe Rotor).
Donc maintenant dans enigma.h

private:               int nb_rotors;
                Rotor rotors[], reflecteur;

Et le constructeur ne fait rien de plus au niveau de la variable niveau rotors[], mais j’ai ajouté à la fin :

std::cout<<"nom du fichier reflecteur : ";
    std::cin >> nom;
    reflecteur = Rotor(nom,0);

Et là, c’est le drame, en fait un problème auquel j’avais déjà été confronté mais que je n’avais pas réussi à résoudre (proprement) :

enigma.c++: In constructor ‘Enigma::Enigma()’:
enigma.c++:21:16: erreur: no matching function for call to ‘Rotor::Rotor()’
enigma.c++:21:16: note: candidates are:
rotor.h:35:17: note: Rotor::Rotor(std::string, int)
rotor.h:35:17: note:   candidate expects 2 arguments, 0 provided
rotor.h:28:7: note: Rotor::Rotor(const Rotor&)
rotor.h:28:7: note:   candidate expects 1 argument, 0 provided

C’est en fait un problème au niveau de l’initialisation de reflecteur, visiblement cette affectation ne lui plaît pas…
Comment faire ?

(sinon côté code, pour l’instant j’ai juste commenté, mis les TODO, et là je suis entrain de bloquer sur le règlement du premeier TODO :].
Bon, si ça peut re-servir pour mémoire, le constructeur entier (dont je ne veux pas encore de reflection du genre « c’est pas assez c++ » )

Enigma::Enigma()
{
    std::string nom;
    int cran;
    std::cout << "combien de rotors?";
    std::cin >> nb_rotors;
    for(int cpt = 0; cpt < nb_rotors; cpt++)
    {
        std::cout<<"nom fichier du rotor "<<(cpt+1)<<'/'<<(nb_rotors)<<" :";
        std::cin >> nom;
        std::cout<<"cran de base ? ";
        std::cin >> cran;
        rotors[cpt] = Rotor(nom,cran);
    }

    std::cout<<"nom du fichier reflecteur : ";
    std::cin >> nom;
    reflecteur = Rotor(nom,0);

}

Sinon évidemment comme je disais plus haut, j’ai un moyen de règler ça : je fais un niveau prototype de constructeur pour Rotor :

public :
                 Rotor() = {}

Et j’ajoute une méthode pour ensuite affecter les bonnes valeurs

public :
               void Initialiser(std::string non, int cran)

Mais bon, je doute que çe soit la meilleure solution :].

Dernière modification par helly (Le 28/07/2011, à 17:02)

grim7reaper · Le 28/07/2011, à 17:31

Ok, j'ai compris (c'était pas simple car t'as une autre erreur dans ton code que j'avais pas vu et donc mon raisonnement qui était juste me semblait faux (mais maintenant que j'ai repéré la seconde erreur ça colle))

En cours de rédaction…

Édit : Done
Bon bon bon, allons‑y

On retrouve un peu la problèmatique d'hier.
En fait le souci quand tu fais ça :

reflecteur = Rotor(nom,0);

Il me semble qu'il se passe plusieurs trucs :
- appel du constructeur par défaut (Rotor::Rotor()) pour initialiser reflecteur, et c'est là que ça coince ;-)
- appel du constructeur Rotor::Rotor(std::string, int) pour créer un objet temporaire
- appel de l'opérateur d'affectation pour copier l'objet temporaire dans reflecteur.
Bon déjà on voir que niveau perf' ça pue (tu crées deux objets inutiles).
Le souci, que l'on voit bien dans le message d'erreur, c'est que tu appelles le constructeur par défaut qui n'existe pas. Le compilo en génère un automatiquement SAUF si tu définis toi même au moins un constructeur (ce qui est le cas ici avec Rotor::Rotor(std::string, int)).

La solution que tu as trouvé était donc de définir le constructeur par défaut pour satisfaire le compilo.

Mon raisonnement semble OK mais il y a un problème : pourquoi le compilo ne gueule pas sur ton tableau ?
Bah ouais, hier je t'ai bien dit que quand tu déclarais un tableau le compilo l'initialisait en appelant le constructeur par défaut pour chaque case. Et comme ce constructeur n'existe pas tu aurais dû avoir un message d'erreur mais ce n'est pas le cas .
Mon explication serait‑elle foireuse ?

C'est à ce moment qu'intervient ta deuxième erreur. Quand tu fais ça

Rotor rotors[], reflecteur;

Tu déclares un tableau de taille zéro !
D'ailleurs si ton code compilait il planterait sûrement à l'exécution avec un SIGSEGV ou truc du genre.
Avec une telle déclaration, chez moi g++ dit :

warning : ISO C++ forbids zero-size array ‘rotors’ [-pedantic]

Et là tout s'explique, ton tableau a une taille nulle donc le constructeur par défaut n'est pas appelé (d'où l'absence de message d'erreur) donc mon explication précédente est valide

Passons maintenant à la solution de ton problème : les listes d'initialisations (faut utiliser les listes d'initialisation à chaque fois que c'est possible). En plus de résoudre ton soucis, c'est bien meilleurs pour les perf' (y'a pas tout plein d'objets temporaires pour rien).
Chez toi ça donnerais un truc dans ce genre

Enigma::Enigma() : reflecteur(nom, 0)
{
    // ton code.
}

Si tu connais pas les listes d'initialisation (ça m'étonnerais, mais on ne sait jamais), regarde un peu ici.

Bon bien sûr ça nécessite de chopper les nom de fichiers avant d'entrer dans le constructeur (et de lui passer en arguments), mais ça me semble plus propre de toutes façons : je trouve très moyen de mettre des cin dans un constructeur )

Au passage, vu que rotors est maintenant dynamique (tu demandes la taille à l'exécution) utilise un std::vector (ça t'éviteras les problèmes de constructeurs par défaut, comme expliqué ici).
Sinon y'a bien std::array (pour les tableaux à taille fixe comme ça semble être ton cas ici) mais c'est dans C++1x (enfin c'est dispo depuis le TR1 il me semble, mais bon peu importe) ou Boost donc on va peut‑être se contenter de std::vector :]

Dernière modification par grim7reaper (Le 28/07/2011, à 17:53)

helly · Le 28/07/2011, à 17:33

grim président o//.

The Uploader · Le 28/07/2011, à 17:36

helly a écrit :

Bon, si ça peut re-servir pour mémoire, le constructeur entier (dont je ne veux pas encore de reflection réflexions du genre « c’est pas assez c++ » )

C'est pourtant sympa la reflection.. :] </jeu de mots pourri>

Dernière modification par The Uploader (Le 28/07/2011, à 17:39)

grim7reaper · Le 28/07/2011, à 17:54

Piouf, long post is long (même si j'ai déjà fait pire )

Pylades · Le 28/07/2011, à 17:57

Heu, cool, j’essayais d’optimiser mon interpréteur brainfuck, pis je me suis rendu compte qu’un fonction devenait un peu obèse, alors j’ai essayé de factoriser un peu… puis j’ai tout défait, car ça demandait de variables et lectures en plus, donc pour ce qui est sensé être une optimisation ce n’est pas top. Résultat : une fonction de 104 lignes (celle qui est censée transformer un fichier ouvert en code lisible par mon interpréteur), et ça va encore grossir, vu que je n’ai pas fini d’écrire l’optimisation… ben je crois que j’ai quelques soucis de conception, dans cette fonction, en fait (elle faisait déjà plus de 90 lignes avant).

Ouais : super résultat, en plus… Non contente de consommer plus de RAM, cette optimisation n’accélère pas le bousin. Elle le ralentit même très légèrement, d’une valeur fixe pour le programme choisi, probablement à cause du surcoût lors de la bufferization.

Il faudrait que je sache profiler mon code pour repérer les parties lentes du traitement…

Re-édit : ouais bah à la lecture des sources brainfuck je comprends pourquoi. En fait, c’est rarissime que l’on aligne plusieurs « + » ou « - » dans une boucle. Donc en gros mon optimisation qui consistait en compter les « + » et « - » consécutifs pour tous les appliquer d’un coup avait un léger surcoût et ne servait jamais. Beuh.

Ah, et en plus j’avais un léger bug dans cette optimisation : rien de bien méchant, mais ça limitait son efficacité.

Dernière modification par Πυλάδης (Le 28/07/2011, à 18:52)

helly · Le 28/07/2011, à 19:09

grim7reaper a écrit :

Piouf, long post is long (même si j'ai déjà fait pire )

Compris, même tout compris !
Ouais, je connaissais le système des initialisateurs qu’on met à côté genre

 Rotor::Rotor():reflecteur(nom,cran)

Mais je sais pas pourquoi, je trouve ça vraiment moche .
Après, pour le coup du tab[], étrange, ça compilait et exécutait très bien ! (avant que je ne me lance dans l’optimisation avec le reflecteur), et dans ce cas, je ne sais pas vraiment si l’usage de vector est judicieuse, parceque Okay, au début on ne sait pas quelle taille va faire ce tableau, mais la taille en elle même reste fixe !
Bon, j’vais appliquer tout ça. Merci en tout cas .

Et qu’as tu contre l’emploi de cin dans un constructeur ?
C’est un avis personnel ou c’est justifié ?
Ça me rapelle le prof qui disait qu’une fonction/procédure ne devait jamais afficher ni demander de texte >_<.

Dernière modification par helly (Le 28/07/2011, à 19:12)

The Uploader · Le 28/07/2011, à 19:10

[Flash/MP4V][Collège de France] Sécurité informatique et sciences numériques

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1451 Le 27/07/2011, à 22:36

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

#1452 Le 27/07/2011, à 22:46

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

#1453 Le 27/07/2011, à 23:23

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

#1454 Le 27/07/2011, à 23:43

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

#1455 Le 28/07/2011, à 00:04

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

#1456 Le 28/07/2011, à 00:07

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

#1457 Le 28/07/2011, à 02:10

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

#1458 Le 28/07/2011, à 02:30

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

#1459 Le 28/07/2011, à 03:05

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

#1460 Le 28/07/2011, à 03:24

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

#1461 Le 28/07/2011, à 03:41

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

#1462 Le 28/07/2011, à 06:43

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

#1463 Le 28/07/2011, à 06:44

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

#1464 Le 28/07/2011, à 09:36

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

#1465 Le 28/07/2011, à 09:41

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

#1466 Le 28/07/2011, à 09:53

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

#1467 Le 28/07/2011, à 11:07

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

#1468 Le 28/07/2011, à 16:57

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

#1469 Le 28/07/2011, à 17:31

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

#1470 Le 28/07/2011, à 17:33

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

#1471 Le 28/07/2011, à 17:36

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

#1472 Le 28/07/2011, à 17:54

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

#1473 Le 28/07/2011, à 17:57

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

#1474 Le 28/07/2011, à 19:09

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

#1475 Le 28/07/2011, à 19:10

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

Pied de page des forums