striiiiiiiiiiiiiiing - Page 33

Sasume (./959) :
Mais euh pourquoi mon conseil vous paraît-il bidon ?

Pas bidon, mais mauvais.
Un conseil bidon, ça serait plutôt du genre « va apprendre à traire les vaches, ensuite tu sauras coder en C++ »

Lire du code de l’extérieur permet d’apprendre ;

C'est l'open source, donc il y a de tout c'est vrai, mais soyons honnêtes. Le code est quand même très souvent de mauvaise qualité. Soit au niveau du design des API, soit au niveau de l'implémentation. Par mauvais je comprends aussi les choses comme le « code trop complexe » (c'est très fréquent dans les logiciels open source), et les sources difficiles à parcourir.
En gros, selon le logiciel que tu vas étudier, tu vas chopper de mauvaises pratiques, voir te figer dans un style de programmation, et tu risques de ne jamais acquérir ton propre style. (Qui viendra plutôt avec la liberté que tu t'accorderas… Je dis pas que tu chopperas pas de mauvaises habitudes, mais au moins ça sera les tiennes. Et les habitudes ça se change si il faut, avec un peu de volonté.)
Mais en sortant la phrase du contexte "open-source", je suis entièrement d'accord. Il faut lire des tas de choses et les recouper pour se faire sa propre idée. Tutos, explications, documnetations, …

Contribuer et subir de review de code permet d’apprendre ;

Pour contribuer il faut avoir de l'expérience. Comprendre le code que tu as lu, et trouver des choses à y corriger ou à y ajouter. Ça demande plus qu'un niveau de débutant (il faut des connaissances plus importantes que juste le langage de programmation), d'autant plus qu'on ne te laissera probablement pas contribuer comme ça.
J'ajouterais qu'on apprend mieux en faisant des trucs qui nous intéressent. Trouver un projet en rapport avec tes intérêts c'est une chose (pas forcément facile). Mais bosser dessus en est une autre. (Tu n'est pas vraiment libre de ce que tu codes… C'est la face cachée de l'open-source mais #chut#)

Bef, c’est donnant-donnant : tu rends service aux utilisateurs des logiciels et tu te formes.

Bof, produire du code de qualité médiocre et difficilement maintenable n'est probablement pas rendre service à qui que ce soit. Même pas à toi-même dans un certain sens, mais il faut bien commencer quelque part, et toi… ben ça t'apprend des choses.

Bon, c’est vrai que c’est peut-être un peu tôt. Enfin, faut bien commencer à un moment.

Y'a aucune obligation de contribuer à des projets open-source nulle part… Il ne « faut » pas commencer à un moment, tu fais ce que tu veux. Tu peux vouloir vendre ton code pour vivre aussi hein.

(Je m'arrête là avant de dériver du sujet.)
Enfin bref, non, c'est mal !

enfin avant de justifier kilométriquement y'a une raison plus simple: pourquoi contribuer à un truc qui m'intéresse pas, qui est pas mon bébé, plutot que de coder mon propre truc? surtout pour apprendre.

./960 > Tatata… Si tu codes proprement, ton code C++ peut être parfaitement lisible (plus que du C équivalent en tout cas). Mais j'admet que coder proprement en C++ est un défi qui frôle de près les frontières de l'impossible. Je veux dire, pour coder un programme entier proprement. Les bouts de code séparément c'est plus facile… et encore ^^

Heu nan mais je n’ai pas dit qu’il devait contribuer à des projets open-source hein, juste que ça me semble une bonne occasion de le faire.

Évidemment il faut choisir un projet bien codé (parmi ceux que je connais en C++ : KDE en général et KTorrent) et qui t’intéresse…

./963> Voilà, c'est ce que je voulais dire. Il faut admettre que les concepteurs du C++ ne se sont pas inquiétés en priorité que le code qu'on peut écrire soit lisible, mais qu'il soit puissant (cf. rien que les headers de la STL, ça vaut vraiment le coup d'oeil ).
Si on prend un langage tel que l'Ada par exemple, on a généralement une seule manière d'écrire une solution, et elle est souvent élégante. En C++ on peut écrire n'importe quoi en partant du style JS minifié (exemple) à quelque chose de joli. Si tu es pile entre les deux, alors c'est déjà très mauvais...
Mais ce n'est possible décemment que pour de petits programmes. Par exemple il est à peu près impossible de ne pas mélanger références et pointeurs, alors que normalement ces deux n'ont pas de raison de coexister.

Sasume (./964) :

Évidemment il faut choisir un projet bien codé (parmi ceux que je connais en C++ : KDE en général et KTorrent) et qui t’intéresse…

Oui mais ça lui impose un framework, ce qui n'est pas forcément le mieux pour débuter je pense.

Ce n'est pas forcément un problème. Il peut apprendre de ce framework et réutiliser les idées qui lui plaisent. A l'école on a fait des langages qu'on n'utilisera jamais dans l'industrie mais les idées sont bonnes, et on saurait les implémenter ailleurs au besoin. Là c'est un peu pareil.
Mais je ne pense pas qu'il ait besoin de ça, de toute façon. Il lui faudrait voir des design patterns pour comprendre l'intérêt de l'objet.

faut se méfier aussi

les design patterns, faut pas vouloir les utiliser "parce que c'est bien"

exemple, là j'ai utilisé le pattern visiteur avec le border accept(this,arg) et visit(this,arg) parce que l'ast que je parcours est composé d'une 50aine de types de noeuds différents.

mais si je fais un machin simple, vous croyez que je vais aller implémenter tout un bordel juste pour la beauté du truc?

Isoler des fonctionnalités dans une interface OK, mais si je vais jamais avoir besoin d'avoir plusieurs implémentations différentes, a quoi bon?

il arrive aussi d'en faire sans le savoir. un "Adapteur" est un simple wrapper, on en fait des dizaines, qui peuvent être méga dégueux même si ils suivent un DP...

bref, pour moi il suffit qu'un projet marche avec un schéma clair et un code compréhensible, et des possibilités d'évolutions, pour qu'il soit "propre".

mais c'est rarement le premier projet qui sort bien, le premier projet est moche, le suivant capitalise sur les erreurs passées, etc...

Folco (./949) :
Donc je n'ai qu'une envie, repartir au C, avec des trucs comme ça : typedef struct {int bidule, long chose, const char *machin, void (*méthode) (long trucmuche, int chouette)} Objet_chose;

On dirait GTK+…

Voilà, ça garde le concept d'objet que je trouve génial en soi, et ça évite de se perdre dans les méandres et complexités des différentes relations entre classes que je ne maitrise pas.

Tu as tout ces concepts quand-même, tu as juste un langage pas du tout fait pour (il est fait pour programmer en procédural) que tu bidouilles pour le faire sembler objet (des pointeurs de fonction dans une structure ).

De plus, ton code est moins efficace si tu mets les pointeurs vers les méthodes directement dans ta structure au lieu d'utiliser une vtable partagée. Le code machine que donnerait le C++ est plutôt de type:

// ISO C99 paragraphe 6.3.2.3 §8 (cf. n1256.pdf):
// un pointeur de fonction peut être converti en void (*)(void) et de retour
// mais pas nécessairement en void *!
typedef void (*funcptr)(void);

void Objet_chose_methode(long trucmuche, int chouette);
// ISO C99 paragraphe 6.3.2.1 §4 (cf. n1256.pdf):
// La prise d'adresse est implicite pour une fonction, on peut omettre le &
const funcptr Objet_chose_vtable[] = {(funcptr) Objet_chose_methode};

typedef struct {int bidule, long chose, const char *machin, const funcptr *vtable} Objet_chose;

Brunni (./956) :
Folco ton problème c'est que tu veux faire 2 choses en même temps:
* Apprendre le C++
* Apprendre la POOLes deux sont extrêmement complexes, d'où les conseils insistants de partir sur un langage qui te facilite la tâche au moins pour apprendre la POO, histoire de ne pas tout mélanger.

Un langage qui lui facilite la tâche comme le C++ + Qt?

Au fait, connaissant GoldenCrystal, le langage dont il parle est probablement un certain langage dont le nom se traduit en "do dièse"… Personnellement, je préfère encore le Java!

GoldenCrystal (./957) :
./953 > Il participait au concours du pire conseil à donner à un débutant. Je pense qu'il a gagné le premier prix.

Je ne trouve pas le conseil de Sasume si mal que ça. Beaucoup de développeurs de logiciels libres ont appris en contribuant à des projets existants. Personnellement, j'ai appris le C en travaillant sur A68k (qui n'est pas libre, mais les sources sont disponibles), et puis travailler sur GCC m'a appris énormément de choses sur le C. Pour le C++, c'était un peu différent (j'ai fait du C++ à l'université aux USA pendant un semestre et puis mon premier projet en C++ était un projet à moi (KTIGCC)).

Pour vraiment bien maîtriser le C et le C++, rien de mieux que de suivre les discussions sur la mailing list de GCC pendant un certain temps. Évidemment on ne comprend rien au début, mais au fil du temps on comprend de mieux en mieux et on apprend plein de choses sur les aspects les plus obscurs des standards.

Brunni (./960) :
Tout bêtement parce que le C(++) est un langage write-only Il n'est pas particulièrement fait pour être lisible et relu (même pour celui qui l'a écrit c'est généralement chaud qqes temps après, même bien commenté).

Alors là je ne suis pas d'accord du tout, j'ai en général besoin de peu ou pas de commentaires pour comprendre du C ou du C++, du moins s'il est écrit à peu près proprement. (Exemple à ne pas suivre: obj2ti de Julien Muchembled. Heureusement que ld-tigcc le remplace.) Il y a des projets difficiles à comprendre par leur nature et/ou leur ampleur (cf. GCC par exemple), mais c'est loin d'être le cas de tous les projets libres.

GoldenCrystal (./961) :
En gros, selon le logiciel que tu vas étudier, tu vas chopper de mauvaises pratiques, voir te figer dans un style de programmation, et tu risques de ne jamais acquérir ton propre style.

Alors là, je ne vois vraiment pas… Mon code C ne ressemble ni à celui de A68k (style totalement obsolète, déclarations K&R etc.), ni à celui de GCC (le formatage style GNU est à vomir: mélange d'espaces et de tabs qui casse si on n'utilise pas la même largeur de tab qu'eux, placement et indentation des accolades totalement bizarre, espaces entre nom de fonction et parenthèse ouvrante qui n'ont aucune justification logique etc.), et pourtant ce sont les projets avec lesquels j'ai commencé.

d'autant plus qu'on ne te laissera probablement pas contribuer comme ça.

Tu n'es pas obligé de contribuer au projet officiel, hein. Dans certains cas, il n'y a même plus de projet officiel, donc on peut reprendre le projet tranquillement. (C'était le cas pour A68k quand je m'y suis mis.) Et quand le projet officiel existe encore, ce qu'on peut faire, c'est développer son patch tranquillement, puis l'envoyer quand il est fini, après à eux de décider s'ils en veulent ou non. Et faire de bons patches, ou du moins des patches qui suivent les attentes du projet visé, ça s'apprend au fur et à mesure.

(Tu n'est pas vraiment libre de ce que tu codes… C'est la face cachée de l'open-source mais #chut#)

Si, tu es libre de forker. Tu risques de ne pas te faire aimer par le projet officiel, évidemment, mais en principe tu peux, et parfois tu n'as pas le choix. Certains projets te conseilleront même de forker si tu veux faire des changements qu'ils ne trouvent pas acceptables pour leur projet pour une raison ou pour une autre.

squalyl (./962) :
enfin avant de justifier kilométriquement y'a une raison plus simple: pourquoi contribuer à un truc qui m'intéresse pas, qui est pas mon bébé, plutot que de coder mon propre truc? surtout pour apprendre.

Justement, il contribuerait à un projet qui l'intéresse, évidemment. Et personnellement, je ne vois pas l'intérêt de refaire ce qui existe déjà.

Sasume (./964) :
Évidemment il faut choisir un projet bien codé (parmi ceux que je connais en C++ : KDE en général et KTorrent) et qui t’intéresse…

Attention quand-même aux apps pour KDE tierces, dont la qualité du code est très variable.

Nil (./966) :
Oui mais ça lui impose un framework, ce qui n'est pas forcément le mieux pour débuter je pense.

Je ne suis pas d'accord du tout, le Qt/KDE, c'est très bien pour débuter, ça évite de réinventer la roue pour plein de choses, ça simplifie certains aspects du C++ (par exemple, il y a foreach), et les QObject et tout ce qui est lié apportent toutes les fonctionnalités attendues d'un langage objet moderne: gestion des évènements (signaux et slots), introspection etc. Et puis c'est aussi un bon framework pour tous les jours, on peut utiliser la libQtCore et la libkdecore même pour les programmes sans interface, et pour les interfaces graphiques, Qt/KDE est tout simplement génial. Donc ce n'est pas un langage artificiel qu'on utilise pour débuter et puis plus jamais.

squalyl (./968) :
faut se méfier aussi
les design patterns, faut pas vouloir les utiliser "parce que c'est bien"

+1

Tu vois bien, certains projets te paraissent mal codés, tout simplement parce qu'en C++ ça arrive trop facilement d'écrire quelque chose qui te paraîtra nickel mais moche pour un autre.
Après le C# pour débuter... mouais je suis pas convaincu. Mais pour qqn ayant déjà fait du C/C++ oui, car il permet de garder les habitudes et la puissance de celui-ci tout en simplifiant infiniment le développement.
Sinon il lui reste le choix de C++ + Qt en effet. Je ne peux pas dire à quel point c'est bien ou pas, c'est en tous cas moins "standard" donc probablement moins académique, mais ça sera difficilement pire que le C++

Bah, on peut écrire du code de porc en pratiquement n'importe quel langage, même en Java.

Pour l'histoire de obj2ti, lis les [url=http://www.google.com/codesearch/p?hl=en#jS9GEwZLP_M/Archives/Static2Dynamic-v020.zip|CdH7qrV2LfY/Example/Obj2Ti/obj2ti.cpp&q=obj2ti]sources[/url] et tu comprendras peut-être ce que je veux dire. Il y a plein de lignes comme for (am++; n--; size--) *R32++ = br4 (am++);, il y a très peu de commentaires, les noms de variables sont tellement courts qu'on ne pourrait presque pas faire plus court, on trouve des constantes "magiques" comme 0x6100 (l'opcode de bra.w) sans aucune ébauche de commentaire etc. Je trouve le code de ld-tigcc nettement plus lisible.

Kevin Kofler (./969) :
Tu as tout ces concepts quand-même, tu as juste un langage pas du tout fait pour (il est fait pour programmer en procédural) que tu bidouilles pour le faire sembler objet (des pointeurs de fonction dans une structure ).

C'est pourtant hyper courant comme methode, et loin d'etre de la bidouilleko

Mais ce qu'il veut dire c'est que ce n'est pas de la POO. Ca y ressemble, mais ça n'en est pas.
Typiquement s'il veut simuler l'héritage il va se faire chier et ce sera très facile de faire des erreurs à coup de memcpy et autres. => encore pire pour apprendre.

L'héritage ?

Le "polymorphisme" est possible en C : struct truc1 { int bla char blo; } var1; struct truc2 { int bla; char blo; short blu; } var2; void func() { struct truc1 *test; test = (struct truc1) var2; test->blo = 42; printf("var2 blo = %d\n", var2.blo); }
est parfaitement valide. C'est pas mal utilisé, nottament dans la pile TCP/UDP/IP

Je sais, mais déjà que le C++ est dangereux comme tout, que dire d'une telle solution? Tu te plantes sur une variable et c'est fini.
L'intérêt que ça a c'est surtout pour avoir du polymorphisme sur des objets préalloués btw, chose impossible dans les autres langages.

struct Base {
    union {
        struct {
            int varBase;
        };
        char alloc[16];
    };
};

struct Derivate {
    union {
        struct {
            int varBase;
            int varSpecific;
        };
        char alloc[16];
    };
};

int main(int argc, char *argv[]) {
    Base var;
    Derivate *d = (Derivate*)&var;
    var.varBase = 10;
    d->varSpecific = 20;
    printf("%i %i\n", d->varBase, d->varSpecific);   // 10 20
}

Mais la sécurité est moisie (ça va merder si on dépasse les 16 octets alloués).

dans ce cas , si on veut absolument faire ça, on prend du vala ou autre, ça gère a notre place.

Godzil (./975) :
Le "polymorphisme" est possible en C :

struct truc1
{
int bla
char blo;
} var1;

struct truc2
{
int bla;
char blo;
short blu;
} var2;



void func()
{
  struct truc1 *test;
  test = (struct truc1) var2;
  test->blo = 42;
  printf("var2 blo = %d\n", var2.blo);
}

est parfaitement valide.

Non. C'est une violation des règles d'aliasing. Cf. ISO C99 paragraphe 6.5 §7. En revanche:

struct truc1
{
int bla
char blo;
} var1;

struct truc2
{
struct truc1 super;
short blu;
} var2;

void func()
{
  struct truc1 *test;
  test = (struct truc1*) var2;
  test->blo = 42;
  printf("var2 blo = %d\n", var2.super.blo);
}

est conforme d'après 6.5 §7, 5^ème énuméré.

Il me semble (à vérifier!) que la détection d'aliasing de GCC accepte aussi ton code (si tu rajoutes le * que tu as oublié), exactement pour permettre cette utilisation, mais ce n'est pas du C conforme au standard.

J'aurai directement fait comme ce que tu as proposé Kevin (pour une fois ! ), même sans aucune considération pour la norme (je m'en fous un peu), je trouve celle proposé par Godzil vraiment pas propre. Par contre l'inconvénient de l'héritage de structure avec imbrication c'est que ça augmente énormément la verbosité du code. Bref, autant coder ça directement en C++, ça sera et propre, et lisible :]
./970 & ./971 > Perdu, je pensais à VB.NET… Je suis quand même pas si prévisible que ça hein ^^ Contrairement à une certaine personne…

Je plusois kk sur le polymorphisme en C.
D'ailleurs si tu veux vraiment comprendre le C++ le meilleur moyen c'est d'y aller à la hard et d'essayer de refaire le polymorphisme en C avec les fonctions qui prennent un this etc. C'est vraiment comme cela que j'ai bien compris les vtables etc.

Sinon utiliser un framework comme qt me semble être une bonne idée. Il te permettra de faire des petits jeux, interfaces graphiques etc.
Et franchement je te rassure 80% des codeurs C++ "confirmés" codent comme des pieds. Les bons codeurs C++ avec de solides base POO et design c'est très rare.

PS: le design pattern visiteur c'est de la merde en boite! je vois même pas comment on peut faire un design comme celui ci qui en plus implique une dépendance circulaire.

Merci beaucoup pour tout. Bon, j'ai décidé de persévérer, mais un bête problème de curseur m'a révélé que j'ai un emboitement de classes mal pensé à un niveau, je suis bon pour en modifier 3...

JackosKing (./980) :
Et franchement je te rassure 80% des codeurs C++ "confirmés" codent comme des pieds.

C'est pas une bonne raison pour que je me laisse aller en disant "bof, avec un gros procs, ça ramera jamais plus que l'appli du gars à côté".
Mais c'est sûr, j'ai besoin d'entrainement, c'est vrai que je peux pas comprendre tout en profondeur en lisant et posant des questions.

Merci bien.

Folco (./981) :
Mais c'est sûr, j'ai besoin d'entrainement, c'est vrai que je peux pas comprendre tout en profondeur en lisant et posant des questions.

Non, il faut te poser des questions, mais peut-être plus prendre le temps de réfléchir.
Sinon je suis plutôt d'accord avec ce qu'à dit JackosKing en ./980, sur le fond. Essayer de comprendre les engrenages du C++ (remplace C++ par n'importe quel autre techno de ton choix) ça te permettra de bien maîtriser la chose. Par contre, langage C ou autre chose, peu importe (tu peux aussi penser en assembleur). Chacun à sa façon de faire qui lui est propre.
(Par exemple moi, je pose très rarement mes pensées par écrit… Je n'ai pas encore trouvé de format adapté, donc tout reste (et se perd) dans la tête.)

JackosKing (./980) :
PS: le design pattern visiteur c'est de la merde en boite! je vois même pas comment on peut faire un design comme celui ci qui en plus implique une dépendance circulaire.

Intéressant comme argument. Et tu proposes quoi comme solution intéressante pour permettre d’ajouter facilement un nouveau traitement à un graphe de classe qui n’évolue presque pas ?

GC> VB.NET ? Alors là je ne m’y attendais même pas. Tu peux m’indiquer ce que c’est, et pourquoi c’est bien par rapport à C# par ex ?

(c'est juste histoire de troller, vu que VB.NET c'est juste C# avec une syntaxe différente ^^)

(Que dalle oué, y'a des points communs avec C# au même titre qu'avec n'importe quel langage objet, particulièrement ceux sous .NET, mais ça s'arrête là)
Pourquoi VB.NET ? Parce que la syntaxe et les mots-clés sont explicites (quoi de plus explicite que « MustOverride » ou « MustInherit » … ?), ce qui rend le langage un peu plus verbeux, mais il possède en même temps toutes les fonctionnalités recherchées dans un langage objet. D'autre part il est bien plus simple à prendre en main que C#, qui est bien plus simple à prendre en main que C++, qui… heu je sais plus.
Enfin bon, crois moi VB.NET et C# sont deux langages différents. L'un a des fonctionnalités que n'a pas l'autre, et c'est valable dans les deux sens. (VB.NET a quelques fonctionnalités cool même pour les développeurs avancés, et qui n'existent pas en C#)
Si je pense que c'est adapté, c'est pour ces raisons et rien d'autre. Le fait que ça tourne sous .NET a juste augmenté la probabilité fortement (vers les alentours de 150 que je l'aie déjà utilisé. (Demandes toi avec quoi j'ai codé avant de faire du C#… En C certes, mais pas seulement…)

Euh, y'avait un document de MS qui donnait les différences entre C# et .NET... c'est essentiellement de la syntaxe, y'a quelques features exclusives à l'un des deux, mais globalement ça revient au même, et y'a rien qu'on puisse faire avec l'un qu'on ne puisse pas faire avec l'autre. Que la syntaxe du VB soit plus agréable quand on début, c'est probablement vrai, mais les concepts derrière sont les mêmes.

Zerosquare (./986) :
Euh, y'avait un document de MS qui donnait les différences entre C# et .NET... c'est essentiellement de la syntaxe, y'a quelques features exclusives à l'un des deux, mais globalement ça revient au même, et y'a rien qu'on puisse faire avec l'un qu'on ne puisse pas faire avec l'autre.

Détrompes toi ^^
Y'a des fonctionnalités du CLR accessibles en VB.NET mais pas en C#

Que la syntaxe du VB soit plus agréable quand on début, c'est probablement vrai, mais les concepts derrière sont les mêmes.

Justement, c'est là où je veux en venir. Syntaxe adaptée aux débutants mais fonctionnalités semblables => Apprentissage plus rapide des concepts.
Enfin bref, Folco a choisi le C++, on verra bien où ça le mène
Moi en tout cas ça m'avait pas mené bien loin… (il y a quoi… 10 ans ? Faudrait que je regarde tiens)

C'est sûr que le C++ ne m'a pas appris à bien coder (au contraire, j'ai écrit de ces horreurs...). Mais ça me paraissait naturel, je ne m'en suis rendu compte qu'en passant à d'autres langages qui ne me laissaient plus faire la même chose
(Et en suivant des cours sur la POO par la même occasion...)

GoldenCrystal (./987) :

vec l'un qu'on ne puisse pas faire avec l'autre.

Détrompes toi ^^
Y'a des fonctionnalités du CLR accessibles en VB.NET mais pas en C#

Ben je veux bien que tu me les cites, parce que quand j'avais regardé (mais c'était il y a un moment), j'avais pas remarqué ça.

La différence, c'est que le C++ est flexible, alors que d'autres langages d'objet essaient de t'obliger à penser objet.

Cela dit, même en Java, on peut écrire du procédural:

public class Everything {
  public static void foo() { … }
  public static void bar() { … }
  public static void toto() { … }
  public static void main(String args[]) { … }
}

Le C++ permet juste de faire ça avec une syntaxe qui ne prétend pas être de l'objet, mais qui reprend celle du C, rendant ainsi le code plus lisible.