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

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

Ça me rapelle le prof qui disait qu’une fonction/procédure ne devait jamais afficher ni demander de texte >_<.

L'mien dit la même chose, et avec raison. Et je suis d'accord : dans un main ça me gêne pas, mais pour une classe "interne", ça me choque. edit: 'fin pas pour l'affichage, mais pour attendre une entrée..

@grim': soit j'ai oublié, soit je suis passé totalement à côté de ça dans mes cours!
Et le compilo, il peut pas voir la "bourde" et remplacer ça par une liste d'initialisation ?
ça expliquerait pourquoi je suis passé à côté..

edit: les vectors c'est bon, mangez-en!

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

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

Putain g++ de base (sans options )sapu vraiment ! oO’
J’utilisais une variable int non initialisée, et g++ ne me disait rien du tout oO’ !

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

Elzen · Le 28/07/2011, à 19:37

J'suis d'accord pour le truc : un constructeur n'a pas à forcer le texte à venir de l'entrée standard, ou de n'importe quoi d'autre. Un constructeur, il dit qu'il a besoin d'un texte, et c'est le code appelant qui doit le lui fournir en décidant lui-même d'où il vient.

Afficher du texte, ça dépend, par contre : il peut y avoir de la sortie texte en cours de route quand le programme est en mode « bavard » (du genre indiquer les différentes étapes, ou autres). Mais le texte que la procédure/fonction doit produire (et non pas celui qu'elle produit accessoirement au cours son fonctionnement) doit être renvoyé, et si affichage sur la sortie standard il doit y avoir, c'est encore au code appelant de s'en charger.

Et bien entendu, il faut fournir chaque fois que c'est possible la possibilité de rendre muette la sortie « bavardage ».

tshirtman · Le 28/07/2011, à 19:46

helly a écrit :

Ça me rapelle le prof qui disait qu’une fonction/procédure ne devait jamais afficher ni demander de texte >_<.

Par ce que main est pas une fonction, peut être -_-…

et faire une fonction dédié à la récupération d'une donnée et à son traitement, c'est grave? si on a 10x à la faire, on est obligé de copier coller le code?

Comme toutes les rêgles, ce n'est valable que dans un cadre cohérent, pour moi, ce genre de règle ne marche que pour les très petits projets…

(et interdiction de se faire une encapsulation à printf spécifique pour logger aussi? >_<)

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

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

Tu remplace fonction/procédure par méthode, et tu aura compris la règle.

'fin afficher on s'en fout j'pense. C'est surtout genre une classe (pas forcément une classe d'ailleurs) sprite qui se met à faire un getchar... ben... : O_O

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

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

helly a écrit :

grim7reaper a écrit :
Piouf, long post is long (même si j'ai déjà fait pire )
Compris, même tout compris !

Bon, au moins j'ai pas détaillé pour rien

helly a écrit :

Mais je sais pas pourquoi, je trouve ça vraiment moche .

C'est une question de goût (et puis franchement, y'a des trucs carrément plus moche en C++ : les templates )
Et puis bon, moche ou pas ça reste la bonne façon de procéder donc bon…

helly a écrit :

Après, pour le coup du tab[], étrange, ça compilait et exécutait très bien !

Quelque chose me dit que c'est un UB (Undefined Behavior), partant de là ça peut faire n'importe quoi : planter, tourner gentiment, invoquer Satan, se comporter bizarrement, installer Windows, etc.

helly a écrit :

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 !

Oui c'est justifié pour au moins une raison : t'as pas a gérer la mémoire à la main pour ton tableau (bien que dans le cas présent, la gestion soit légère je te l'accorde).
Après je suis d'accord que c'est un peu bizarre d'utiliser std::vector pour une taille fixe et c'est bien pour ça que std::array existe.
Mais comme je le disais, actuellement c'est soit du Boost, soit du TR1, soit du tu-le-codes donc autant utiliser std::vector

helly a écrit :

Et qu’as tu contre l’emploi de cin dans un constructeur ?
C’est un avis personnel ou c’est justifié ?

C'est un avis personnel justifié
Plus sérieusement, en général une fonction a un rôle précis.
Dans le cas d'un constructeur c'est l'initialisation de l'objet, point barre.

Si tu commences a foutre de l'interaction utilisateur là‑dedans ça va être le bordel parce que les E/S avec un humain c'est un truc sacrément pète-couille quand même (faut bien sécuriser le truc, vérifier les données entrées, etc) et ça demande donc du code en plus.
Et si tu fais tout ça bien, ton constructeur va être bloated, moins lisible et moins simple à maintenir, source de bug et de prise de têtes (en plus d'être potentiellement moins performant).
Parce que là tu lis un int à un moment (cran), mais tu fais aucune vérif'. Si tu commences à ajouter de la saisie sécurisée dans ton constructeur ça va devenir moins lisible.
Ok, peut-être que dans ton cas précis tu t'en fiches itout, mais mon conseil reste d'ordre général.

helly a écrit :

Ça me rapelle le prof qui disait qu’une fonction/procédure ne devait jamais afficher ni demander de texte >_<.

Ça peut se justifier dans certains cas, mais en tant que règle absolu c'est stupide -__-

The Uploader a écrit :

Et le compilo, il peut pas voir la "bourde" et remplacer ça par une liste d'initialisation ?

Non, car c'est pas une bourde au sens propre du terme (c'est autorisé par le langage quoi).
Et puis selon la manière dont le code est écrit c'est pas forcément possible de substituer (le code d'helly est un exemple : le nom n'est connu que dans le corps du constructeur).

helly a écrit :

Putain g++ de base (sans options )sapu vraiment ! oO’
J’utilisais une variable int non initialisée, et g++ ne me disait rien du tout oO’ !

Bah je l'appelle pas « gcc le laxiste » pour rien :]

ArkSeth a écrit :

Afficher du texte, ça dépend, par contre

Oui, mais moi j'ai bien précisé que je parlait d'entrée (j'ai mentionné std::cin, pas std::cout), les sorties c'est autres choses.
Sinon je plussoie la globalité de ton post

tshirtman a écrit :

si on a 10x à la faire, on est obligé de copier coller le code?

Non, tu fais une macro et tu laisses le préprocesseur se charger de la duplication de code
->[]

@↓↓↓ : des sorties ça peut se concevoir (à des fins de log par exemple), par contre des sorties non (Cf. ce post).

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

Pylades · Le 28/07/2011, à 19:56

Bon, je ne sais pas si c’est personnel ou pas, mais je trouve ça hideux, des I/O dans un constructeur…

Et je viens de me prendre un bug chiant sur la tronche.

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

Dans le cas d'un constructeur c'est l'initialisation de l'objet, point barre.

Et c'est déjà bien assez! (quand je vois le code de mon constructeur Gauge::Game j'me dis qu'il est quand même un peu bloated..)

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

helly · Le 28/07/2011, à 20:01

Si tu commences a foutre de l'interaction utilisateur là‑dedans ça va être le bordel parce que les E/S avec un humain c'est un truc sacrément pète-couille quand même (faut bien sécuriser le truc, vérifier les données entrées, etc) et ça demande donc du code en plus.
Et si tu fais tout ça bien, ton constructeur va être bloated, moins lisible et moins simple à maintenir, source de bug et de prise de têtes (en plus d'être potentiellement moins performant).
Parce que là tu lis un int à un moment (cran), mais tu fais aucune vérif'. Si tu commences à ajouter de la saisie sécurisée dans ton constructeur ça va devenir moins lisible.
Ok, peut-être que dans ton cas précis tu t'en fiches itout, mais mon conseil reste d'ordre général.

Nan mais c’est pas con, il faut que je vois, dans le bouquin de Stroustrup c’est expliqué comment faire des méthodes avec un nombre variable d’arguments (genre fprintf).
Ça fait partie des trucs que je vais ajouter dans les machins à optimiser .

grim7reaper · Le 28/07/2011, à 20:03

@The Uploader : Ouais c'est tout à fait ce que je voulais dire : la construction d'un objet peut déjà être une tâche suffisamment complexe (selon l'objet), alors pas besoin d'ajouter de la saisie (et tout le code que ça implique niveau sécu/validation) par là‑dessus.

@helly : jpense que t'as pas besoin d'en arriver là.
Tu demandes le nombre de rotors, tu fais un joli std::vector avec ce que l'utilisateur entre et tu passes une référence constante de ce std::vector à ton constructeur et basta ! C'est dans la poche
Genre un truc comme ça (code totalement approximatif et réalisé de tête donc très certainement foireux mais c'est pour donner l'idée générale) :

std::cout << "combien de rotors?";
//lecture sécu'/valid' de nb_rotors
std::vector<std::pair<std::string, int> > params(nb_rotors);
std::pair<std::string, int> info;
for(int cpt = 0; cpt < nb_rotors; cpt++)
{
    std::cout<<"nom fichier du rotor "<<(cpt+1)<<'/'<<(nb_rotors)<<" :";
    std::cin >> info.first;
    std::cout<<"cran de base ? ";
    // lecture secu'/valid' de info.second
    params.push_back(info);
}
Enigma machine(params);

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

tshirtman · Le 28/07/2011, à 20:18

The Uploader a écrit :

Tu remplace fonction/procédure par méthode, et tu aura compris la règle.
'fin afficher on s'en fout j'pense. C'est surtout genre une classe (pas forcément une classe d'ailleurs) sprite qui se met à faire un getchar... ben... : O_O

public class MyKeyboardManager(blah blah blag){
    /* supposez un peu partout du code c++ que je sais pas écrire*/
    public string read_line(blah blah){
        string line;
        do{
            c = getchar();
            line << c;
        } while (c != EOL);
       return string;

/* insérer d'autres méthodes plus ou moins utiles, voir révolutionnaires */
}

c'est probablement largement invalide, mais je ne vois pas ce qui t'interdit de faire une classe de ce genre si tu veux gérer le clavier toi même. Comme le dit grim, la plupart du temps, un règle t'interdisant de faire des IO ailleurs que dans le main est stupide.

The Uploader · Le 28/07/2011, à 20:31

nan mais entre un sprite (excepté piloté par l'I/O clavier/souris, hein!) et une classe pour gérer le clavier y'a clairement une différence fondamentale de rôle. -_-

genre je vais pas mettre un getchar dans une classe métier..

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

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

@Grim : je garde sous le coude, merci .

tshirtman · Le 28/07/2011, à 20:45

The Uploader a écrit :

nan mais entre un sprite (excepté piloté par l'I/O clavier/souris, hein!) et une classe pour gérer le clavier y'a clairement une différence fondamentale de rôle. -_-
genre je vais pas mettre un getchar dans une classe métier..

Ah mais ouais, t'es le premier a parler de sprite là, la règle énoncée plus haut est beaucoup trop générale…

Pour une classe sprite qui serait géré par l'IO, je pense que ce serait quand même mieux de faire une classe spécifique pour l'IO, qui enverait des signaux à une seconde classe gérant la boucle de jeu, qui elle répercuterait les effets sur la classe de sprite (ou plutôt sur l'entité la possédant), et encore je pense que c'est l'une des organisations les plus basiques…

The Uploader · Le 28/07/2011, à 20:51

Ouais, ça me fait penser à peu près à ce que j'ai fait pour gauge... ^^ sauf que c'est pour tout type d'évènements pour lequel les subscribers sont abonnés.

Pylades · Le 28/07/2011, à 20:54

Bon, j’ai trouvé mon putain de bug. Par hasard. Ce crétin de GCC, qui me fait chier pour des constructions valides pour les conditions n’a en revanche pas été capable de me signifier que j’avais décalé ma fermeture de parenthèse, ce qui donnait une construction totalement aberrante. J’y ai perdu une heure. Et si je n’étais pas tombé dessus par hasard j’y serais encore…

Bon, le point positif c’est que j’ai trouvé une meilleure façon de faire mon optimisation.

grim7reaper · Le 28/07/2011, à 21:18

Of life and death

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

Elzen · Le 28/07/2011, à 21:26

Tiens, d'ailleurs, j'vais peut-être dire une bêtise, mais vu qu'on parle de constructeur, il me vient un doute…

Un constructeur est-il censé être un truc qui crée l'objet et qui l'initialise, ou bien un truc qui initialise un objet vide pré-créé ?
En gros et en C, sur le principe, est-ce que ce serait plutôt ça :

Object* construct(void) {
    Object* obj = malloc(sizeof(obj));
    …
    return obj;
}

int main(void) {
    Object obj = *construct();
    …
}

ou bien ça

void construct(Object* obj) {
    …
}

int main(void) {
    Object obj;
    construct(&obj);
    …
}

d'après vous ?

Dans la pratique, ça ne change pas forcément grand chose, mais j'aimerais bien connaître la théorie.

En Python, ça a plus ou moins l'air d'être la 2e solution au niveau du code de la classe elle-même (la méthode __init__() prend un paramètre self qui désigne l'objet qu'elle est censée initialiser, donc cet objet doit pré-exister), je suppose donc que l'appel à Machin() est un genre de raccourcis qui crée l'objet, appelle cette méthode et le renvoie.
Je suppose aussi que c'est à ça que doit servir le mot-clef « new » utilisé par tous les autres langages ayant vaguement la capacité de gérer plus ou moins l'objet que j'ai rencontré jusque là…

Mais dans ce cas, pourquoi en Java (j'ai pas testé dans d'autres langages utilisant « new ») ne peut-on pas rappeler le constructeur sur un objet déjà créé ? (Par contre, en Python, on peut rappeler __init__() sur l'objet si on veut)

Bon, c'est sûr qu'en Java, il n'y a quasiment pas de destructeurs explicites, donc le problème ne se pose peut-être pas, mais dans les autres langages à « new », peut-on réappeler le constructeur, par exemple sur un objet préalablement détruit, pour recycler l'espace mémoire au lieu d'en recréer un nouveau ?

Dernière modification par ArkSeth (Le 28/07/2011, à 21:28)

The Uploader · Le 28/07/2011, à 21:30

grim7reaper a écrit :

Of life and death

Fuck!

Oh well, il ne lui manquait rien à ce clone, à force. ça reste un très bon clone!

Pylades · Le 28/07/2011, à 21:59

@ ArkSeth : en Python, quand __init__ est appelé, l’objet est déjà valide, et c’est pour ça qu’on dit qu’__init__ n’est pas vraiment un constructeur. Donc si on suit ce raisonnement, c’est la première solution la bonne.

D’ailleurs, dans Libstropt j’utilise la première méthode (mais bon, je n’ai jamais eu la prétention de faire du bon code objet ^^).

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

Je vais parler de ce que je connais, donc le C++
Pour les autres langages, je laisse les gens compétents en la matière s'en charger.

ArkSeth a écrit :

Un constructeur est-il censé être un truc qui crée l'objet et qui l'initialise, ou bien un truc qui initialise un objet vide pré-créé ?

Il réalise seulement l'initialisation (cela dit c'est un peu plus complexe que ça car l'objet sur lequel il bosse est pas forcément « vide », mais entre tes deux propositions, c'est la 2 qui colle le plus).

ArkSeth a écrit :

Je suppose aussi que c'est à ça que doit servir le mot-clef « new » utilisé par tous les autres langages ayant vaguement la capacité de gérer plus ou moins l'objet que j'ai rencontré jusque là…

Oui, new alloue la mémoire puis il appelle le constructeur.

ArkSeth a écrit :

Mais dans ce cas, pourquoi en Java (j'ai pas testé dans d'autres langages utilisant « new ») ne peut-on pas rappeler le constructeur sur un objet déjà créé ? (Par contre, en Python, on peut rappeler __init__() sur l'objet si on veut)

En C++ on ne peut pas non plus.
La raison c'est que les constructeurs n'ont pas de nom !

C++ International Standard a écrit :

A constructor is used to initialize objects of its class type. Because constructors do not have names, they are never found during name lookup; however an explicit type conversion using the functional notation (5.2.3) will cause a constructor to be called to initialize an object. [ Note: for initialization of objects of class type see 12.6. — end note ]

Quand on fait un code comme ça (pour reprendre le code d'helly)

rotors[cpt] = Rotor(nom,cran);

On réalise le « explicit type conversion using the functional notation » qui va appeler le constructeur, mais ce n'est pas nous qui l'appelons directement.
Un code comme

A a;
a.A();

ou

rotors[cpt] = Rotor::Rotor(nom,cran);

Ne compileras pas. On ne peut pas appeler le constructeur, c'est juste impossible (ce n'est pas une fonction comme les autres).

ArkSeth a écrit :

peut-on réappeler le constructeur, par exemple sur un objet préalablement détruit, pour recycler l'espace mémoire au lieu d'en recréer un nouveau ?

Impossible d'appeler le constructeur donc non.
Cela dit, c'est possible dans un cas : utilisation du placement new (pratique très rare, on utilise le new traditionnel dans 99,42% des cas).

@The Uploader : Ça fait un moment qu'il se meurt, Cf. cet appel.
Ce que j'aime bien dans Warmux par rapport à Hedgewars c'est que c'est plus qu'un simple clone, il se démarque quand même de Worms sur plusieurs points (alors qu'Hegewars c'est du pur c/c de Worms).
Et puis il tourne sans accelération 3D !

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

The Uploader · Le 28/07/2011, à 22:25

Ouais Worms j'ai pas tellement accroché. Par contre Warmux m'a tout de suite conquis. Sûrement parce qu'il n'est pas un simple clone.

Après, vu le nombre de joueurs, ça sera sûrement repris un jour.

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

Bah justement pas sûr (pourquoi attendre qu'il meurt pour le reprendre, autant contribuer tout de suite)

Apparemment Hedgewars a draîné pas mal de monde.

yeKcim a écrit :

Pendant longtemps Wormux est resté le seul Worms-like libre. Maintenant Hedgewars est devenu une référence du style avec des graphismes particulièrement réussis, des effets tels que le zoom grâce à l'utilisation d'OpenGL, de nombreuses fonctionnalités, une évolution très rapide, incroyablement rapide même.
Chaque fois que nous parlons de Wormux quelque part aujourd'hui, nous trouvons des fanboys de Hedgewars pour crier un très constructif "Wormux est nul, jouez à Hedgewars !".
[…]
Wormux étant de moins en moins sollicité face à Hedgewars.

Bah oui les graphismes sont mieux donc le jeu est forcément mieux -__-, ça colle assez bien aux jeux vidéos qui cartonnent actuellement : des graphismes béton pour faire passer un jeu en mousse (pas de scénar, pas d'originalité, …).
Après heureusement y'a les gens comme moi pour qui les effets graphiques ne font pas tout, mais faut avouer qu'on semble pas être une majorité…
Je joue toujours à NetHack (ce jeu est juste énorme !), et là tu comprends tout de suite que la qualité graphique est loin d'être mon critère numéro 1 :]

Wikipedia a écrit :

NetHack is largely based on discovering secrets and tricks during gameplay. It can take years for one to become well-versed in them, and even experienced players routinely discover new ones. A number of NetHack fansites and discussion forums offer lists of game secrets known as "spoilers".[28] Fans of NetHack consider an ascension without having read spoilers very prestigious; the achievement is so difficult that some question whether it has been or can be accomplished.

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

Pylades · Le 28/07/2011, à 22:37

Bah je n’ai même pas remarqué que Hedgewars a de meilleurs graphismes que Wormux, en fait… Mais je ne sais pas pourquoi, Hedgewars m’a moins plu…

M’enfin bon, vu la fréquence à laquelle j’y joue, ça ne change pas grand chose.

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

Ho putain, merci archive.org \o/
Il avait disparu et je m'en voulais de pas avoir fait une copie sur mon DD

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1476 Le 28/07/2011, à 19:22

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

#1477 Le 28/07/2011, à 19:30

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

#1478 Le 28/07/2011, à 19:37

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

#1479 Le 28/07/2011, à 19:46

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

#1480 Le 28/07/2011, à 19:52

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

#1481 Le 28/07/2011, à 19:54

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

#1482 Le 28/07/2011, à 19:56

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

#1483 Le 28/07/2011, à 19:58

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

#1484 Le 28/07/2011, à 20:01

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

#1485 Le 28/07/2011, à 20:03

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

#1486 Le 28/07/2011, à 20:18

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

#1487 Le 28/07/2011, à 20:31

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

#1488 Le 28/07/2011, à 20:36

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

#1489 Le 28/07/2011, à 20:45

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

#1490 Le 28/07/2011, à 20:51

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

#1491 Le 28/07/2011, à 20:54

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

#1492 Le 28/07/2011, à 21:18

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

#1493 Le 28/07/2011, à 21:26

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

#1494 Le 28/07/2011, à 21:30

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

#1495 Le 28/07/2011, à 21:59

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

#1496 Le 28/07/2011, à 22:17

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

#1497 Le 28/07/2011, à 22:25

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

#1498 Le 28/07/2011, à 22:31

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

#1499 Le 28/07/2011, à 22:37

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

#1500 Le 28/07/2011, à 22:41

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

Pied de page des forums