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

Elzen · Le 12/11/2010, à 16:40

Tout simplement ^^

Bah c'était facile, en fait, il suffisait de savoir faire du C…

Pylade a écrit :

3. Tu devrais prévoir le cas où une allocation échouerait…

J'veux bien, on fait ça comment ?

Edit : et merci aussi à grim7reaper pour l'explication plus complète et pour l'option que je ne connaissais pas

Dernière modification par ArkSeth (Le 12/11/2010, à 16:41)

grim7reaper · Le 12/11/2010, à 16:44

malloc & cie renvoie NULL en cas de problème (donc d'échec de l'allocation).

Il suffit donc de tester tes variables après l'appel à malloc, si elles valent NULL c'est qu'il y eu un problème sinon c'est OK.
Bon par contre, en cas d'échec si tu veux être propre faut libérer ce que tu as réussi à allouer avant l'échec.

Dernière modification par grim7reaper (Le 12/11/2010, à 17:07)

Elzen · Le 12/11/2010, à 16:49

Mm, je vois… d'un autre côté, c'est pas pour faire propre, c'est pour que ça tourne. Sur un vrai projet, on s'en occuperait sûrement, juste sur un TP où on est en retard et où de toute façon le prof a dit qu'on se foutait du gaspillage de place mémoire et compagnie, j'pense que c'est pas trop grave…
Enfin, c'est corrigé, et je transmet vos remarques à mon co-TPiste. Merci

Pylades · Le 12/11/2010, à 16:58

Bon, je suis sympa, j'ai un peu corrigé ton code. Note la suppression des casts qui alourdissent inutilement le code, ainsi que la suppression des espaces inutiles lorsqu'elles sont seules sur une ligne, un meilleur emploi de sizeof et des test pour les allocations.
Bon, c'est fait un peu à l'arrache, mais ça devrait être bon.
Au passage, je n'aime pas ta norme de codage.

Matrix *createTrieMat(int row) {
    Matrix *m;
    int i, j;
    char ok = 1;

    m = malloc (sizeof *m);
    if (m) {
        m->mat = malloc (row * sizeof *m->mat);
        m->term = malloc (row * sizeof *m->term);

        if (m->mat && m->term) {
            for (i = 0; i < row; i++) {
                m->mat[i] = malloc (SIZE_COL * sizeof **m->mat);
                if (!m->mat[i]) {
                    ok = 0;
                    break;
                }
                m->term[i] = 0;

                for (j = 0; j < SIZE_COL; j++) {
                    m->mat[i][j] = NIL;
                }
            }

            if (!ok) {
                for (j = 0; j < i; j++) {
                    free (m->mat[j]);
                }
            }

            m->last = 0;
            m->size = row;
        }
        else {
            ok = 0;
        }

        if (!ok) {
            free (m->mat);
            free (m->term);
            free (m);
            m = NULL;
        }
    }

    return m;
}

Dernière modification par Pylade (Le 12/11/2010, à 17:09)

grim7reaper · Le 12/11/2010, à 17:00

Dis plutôt que tu étais heureux de trouver une excuse pour faire du C au lieu de bosser tes exams

Dernière modification par grim7reaper (Le 12/11/2010, à 17:04)

Pylades · Le 12/11/2010, à 17:01

Il y a peut-être de ça…

grim7reaper · Le 12/11/2010, à 17:06

Et en plus ton code compile pas (erreur de syntaxe dans un for et je crois qu'il manque une accolade fermante)

for (j = 0; j < i) {
    free (m->mat[j]);
}

Dernière modification par grim7reaper (Le 12/11/2010, à 17:07)

Pylades · Le 12/11/2010, à 17:10

Ouais, bon, j'avais bien dit que c'était un peu fait à la Rache.
C'est corrigé.

Elzen · Le 12/11/2010, à 17:11

Ce n'est pas ma norme de codage à moi personnellement (en fait, je n'ai quasiment pas touché le clavier, l'essentiel du boulot que j'ai fait dessus, c'était au tableau avec quatre couleurs,plus de la relecture).

Ceci dit, je garde le code sous la main, merci (Même si je trouve que des parenthèses à sizeof, c'est plus lisible. Puis je sors d'un exposé d'anglais sur le hacking, alors j'vais quand même paraphraser ESR : faut pas trop s'acharner à tout optimiser, ton temps de cerveau est plus important que le temps de la machine).

Sinon, question (encore plus) simple : le TP est constitué de trois .h et de trois .c, le dernier de chaque faisant un #include des deux autres. Quand j'essaye de compiler les deux autres en question, gcc râle à cause de l'absence du main, qui n'a pourtant rien à foutre là puisqu'il n'a besoin d'aller que dans le dernier. Mon collègue (qui a aussi créé le makefile) a fait quoi comme bêtises, encore ? ^^

grim7reaper · Le 12/11/2010, à 17:11

@Pylade :

@ArkSeth : Faudrait voir le Makefile, mais en général il ne se plaint pas de l'absence de main à la compilation (gcc -c) mais à l'édition des liens (quand il veux rassembler tout les .o pour faire l'exécutable final).
Pour juste compiler (transformer le .c en .o) il faut utiliser

gcc -c fichier.c

C'est peut-être de là que viens le souci ?

Dernière modification par grim7reaper (Le 12/11/2010, à 17:16)

Pylades · Le 12/11/2010, à 17:18

ArkSeth a écrit :

[…]
Ceci dit, je garde le code sous la main, merci (Même si je trouve que des parenthèses à sizeof, c'est plus lisible. Puis je sors d'un exposé d'anglais sur le hacking, alors j'vais quand même paraphraser ESR : faut pas trop s'acharner à tout optimiser, ton temps de cerveau est plus important que le temps de la machine).

De rien.
Sinon, trouverais-tu ça plus lisible de mettre systématiquement des parenthèse à + ?
Et puis là il n'est pas question d'optimisation (ça c'est le compilateur qui s'en charge), mais de coder proprement.
Et fais gaffe, j'ai édité mon message…

ArkSeth a écrit :

Sinon, question (encore plus) simple : le TP est constitué de trois .h et de trois .c, le dernier de chaque faisant un #include des deux autres. Quand j'essaye de compiler les deux autres en question, gcc râle à cause de l'absence du main, qui n'a pourtant rien à foutre là puisqu'il n'a besoin d'aller que dans le dernier. Mon collègue (qui a aussi créé le makefile) a fait quoi comme bêtises, encore ? ^^

Là, il va falloir que tu sois plus clair et que tu m'expliques les dépendances de chaque fichier…

Elzen · Le 12/11/2010, à 17:25

C'est bon, j'ai reprit le makefile (j'm'épate moi-même) et y a plus de soucis.

C'est pas si compliqué que ça, le C, en fait, en trois-quatre séances à regarder mon binôme coder, j'ai retrouvé un niveau supérieur à celui que j'avais à l'époque de ma licence et probablement au dessus de la moyenne de ma promo de cette année.

Pylades · Le 12/11/2010, à 17:45

Sinon, il y a un truc à faire, c'est de relire les anciens TdCCT, en particulier les passages où j'ai droit à mon heure de gloire par grim7reaper (:P). J'ai beaucoup appris de ses pavés ; et je pense que ça pourrait t'aider aussi.

Elzen · Le 12/11/2010, à 17:48

Hmm, j'y penserai…

Mais j'ai cet énorme défaut (enfin, du point de vue hacker) d'être assez réfractaire à l'auto-formation. Les gens qui savent et qui t'expliquent, c'est quand même tellement plus convivial et plus efficace…

Pylades · Le 12/11/2010, à 18:03

Ben oui, il sait et il explique bien.
Mais c'est vrai qu'avoir quelqu'un en face de toi (communication IRL) ça doit être mieux. Surtout quand on a apporté un laptop pour illustrer. ^^

tshirtman · Le 12/11/2010, à 19:33

oui, le C est un langage simple, c'est son principale avantage, avec sa rapidité, ce que je reproche au C++, entre autre, est de n'avoir pas su conserver cette simplicité d'apprentissage…

grim7reaper · Le 12/11/2010, à 21:21

ArkSeth a écrit :

j'ai retrouvé un niveau supérieur à celui que j'avais à l'époque de ma licence et probablement au dessus de la moyenne de ma promo de cette année.

Je crois que Pylade aussi à un niveau de C au dessus de la moyenne de sa promo

Pylade a écrit :

Ben oui, il sait et il explique bien.
Mais c'est vrai qu'avoir quelqu'un en face de toi (communication IRL) ça doit être mieux. Surtout quand on a apporté un laptop pour illustrer. ^^

Merci, je suis content de voir que mes pavés sont compréhensibles et peuvent servir . J'explique peut-être bien, mais je manque parfois cruellement de tact (ou de pédagogie, peut-être les deux ^^).
Mais c'est vrai que rien ne remplace un face à face avec machine à portée de main.

Pylades · Le 12/11/2010, à 22:11

grim7reaper a écrit :

ArkSeth a écrit :
[…] j'ai retrouvé un niveau supérieur à celui que j'avais à l'époque de ma licence et probablement au dessus de la moyenne de ma promo de cette année.
Je crois que Pylade aussi à un niveau de C au dessus de la moyenne de sa promo
[…]

Ouais, je confirme.
J'ai peut-être même bien le meilleur niveau (faudrait que je mène une enquête).

Sinon, le tact, ça ne sert à rien. ^^ Si un code est moche, il faut le dire : ce n'est pas en le taisant que l'on améliorera les choses.

grim7reaper · Le 12/11/2010, à 22:15

Oui c'est sûr, après il y a la façon de le dire ^_^

Pylades · Le 12/11/2010, à 22:28

Bof, il suffit d'être direct. Après, si l'autre le prend mal, tant pis pour lui ; ce n'est pas lui qui est là pour t'aider.

grim7reaper · Le 12/11/2010, à 22:36

Ouais c'est vrai, de toute façon ce comportement est en mémoire ROM donc jpeux pas le changer

Dernière modification par grim7reaper (Le 12/11/2010, à 23:12)

gnuuat · Le 13/11/2010, à 00:47

grim7reaper a écrit :

gnuuat a écrit :
gnuuat a écrit :
#include <iostream>
#include <cstdlib>

class Answer
{
public:
  void tell(int anAnswer) const
  {
    std::cout << anAnswer << std::endl;
  }

  void segfault(int anAnswer)
  {
    this->answer = anAnswer;
    std::cout << this->answer << std::endl;
  }

private:
  int answer;
};

int main()
{
  Answer *answer;
  answer->tell(42);
  answer->segfault(23);
  return (EXIT_SUCCESS);
}
No challengers?
et c'est quoi le challenge ?
Je ne fait plus de remarque sur ton code vu que tu nous vas encore nous faire un caca nerveux comme l'autre fois parce que je ne comprend pas ton humour

Rôôô mais non, si j'expose du code publiquement, c'est pour avoir des retours me permettant de m'améliorer c'est d'autant plus vrai avec le C++, vu que je n'ai qu'un mois d'expérience dans ce domaine là.
Le challenge, c'est expliquer pourqoi tell ne segfault pas (et n'a aucune raison de segfaulter) alors que segfault si (je donnerai la réponse si le challenge n'est pas relevé).

En attendant, faut que je bosse le rush Pokedex -_- (vendredi 18h42 -> dimanche 10h42, veuillez recoder Pokemon en C++ avec Qt, youhou /o\).

gnuuat · Le 13/11/2010, à 01:04

Cf.

#!/usr/bin/env python

class Tesseract:
    """Tesseract : representation en 4D du cube (provenant d'une dimension 3D)"""

    def __init__(self, x1 = 0, x2 = 0, x3 = 0, x4 = 0):
        _x1 = x1
        _x2 = x2
        _x3 = x3
        _x4 = x4

if __name__ == '__main__':
    tesseract = Tesseract(42, 23, 1337, 4423)

grim7reaper · Le 13/11/2010, à 01:04

gnuuat a écrit :

Rôôô mais non, si j'expose du code publiquement, c'est pour avoir des retours me permettant de m'améliorer c'est d'autant plus vrai avec le C++, vu que je n'ai qu'un mois d'expérience dans ce domaine là.

Je n'ai guère plus d'un mois d'expérience en C++ moi aussi donc bon…

Le challenge, c'est expliquer pourqoi tell ne segfault pas (et n'a aucune raison de segfaulter) alors que segfault si (je donnerai la réponse si le challenge n'est pas relevé).

Facile, un appel de méthode c'est comme (oui, je fais une approximation) un appel de fonction normal donc ta fonction est déclaré, elle à un corps, tu l'appelles et tout va bien. Aucune raison que ça plante, les méthodes ne sont pas stockés dans les objets (bonjour la perte de place) donc tu sautes à l'adresse de ta fonction et basta.
Segfault accède en écriture (oui c'est important, une lecture simple ne planteras pas ou du moins pas forcément) à un attribut membre donc stocké dans l'objet, donc on lit et surtout on écrit dans une zone qui ne nous est pas réservé => SIGSEGV.

Bon, c'est grosso modo le fonctionnement. J'ai fais des approximations techniques discutables mais le principe est là. J'ai la flemme ce soir car mon manque de sommeil commence à me rattraper (risque de me coûter les 10 points…)

Sinon, dans les remarques (ici, rien de technique juste de l'esthétique) :
- this est inutile ;
- std::endl aussi car pour les flux standards qui flush sur le '\n', std::endl est équivalent à '\n' (par contre pour les fichiers c'est différent, et en règle générale il vaut mieux utiliser '\n' pour éviter de flusher à chaque fois et perdre l'intérêt de la bufferisation).

En attendant, faut que je bosse le rush Pokedex -_- (vendredi 18h42 -> dimanche 10h42, veuillez recoder Pokemon en C++ avec Qt, youhou /o\).

Tu dois recoder Pokémon ou un Pokédex ?
Le challenge n'est pas le même.

Dernière modification par grim7reaper (Le 13/11/2010, à 01:10)

Pylades · Le 13/11/2010, à 01:06

Ben pour répondre il faudrait connaître le C++… C'est quoi this ? C'est un peu comme self en python ?

Bon, ben grillé. ^^

Dernière modification par Pylade (Le 13/11/2010, à 01:07)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1251 Le 12/11/2010, à 16:40

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

#1252 Le 12/11/2010, à 16:44

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

#1253 Le 12/11/2010, à 16:49

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

#1254 Le 12/11/2010, à 16:58

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

#1255 Le 12/11/2010, à 17:00

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

#1256 Le 12/11/2010, à 17:01

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

#1257 Le 12/11/2010, à 17:06

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

#1258 Le 12/11/2010, à 17:10

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

#1259 Le 12/11/2010, à 17:11

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

#1260 Le 12/11/2010, à 17:11

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

#1261 Le 12/11/2010, à 17:18

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

#1262 Le 12/11/2010, à 17:25

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

#1263 Le 12/11/2010, à 17:45

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

#1264 Le 12/11/2010, à 17:48

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

#1265 Le 12/11/2010, à 18:03

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

#1266 Le 12/11/2010, à 19:33

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

#1267 Le 12/11/2010, à 21:21

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

#1268 Le 12/11/2010, à 22:11

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

#1269 Le 12/11/2010, à 22:15

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

#1270 Le 12/11/2010, à 22:28

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

#1271 Le 12/11/2010, à 22:36

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

#1272 Le 13/11/2010, à 00:47

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

#1273 Le 13/11/2010, à 01:04

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

#1274 Le 13/11/2010, à 01:04

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

#1275 Le 13/11/2010, à 01:06

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

Pied de page des forums