Discussion :

[fabthegreat]

Bonjour a tous!!

Voici le bilan de mon premier mois d'apprentissage du C++.
Au depart je voulais apprendre le C, car étant utilisateur depuis de nombreuse années de GNU/Linux, j'ai voulu apprendre le langage de prog de mon système et de ses nombreuses applications.
J'ai donc achete le Delanoy (très didactique) et je l'ai lu en entier en ayant codé derriere un petit prg de calcul d impot...

Un mois + tard, un ami m'a fait comprendre que la programmation procedurale etait une façon un peu "archaique" de voir la programmation et qu'il fallait mieux que je me tourne vers le C++.

J'ai donc achete le Bjarne Stroustrup 3eme edition et commencé à lire ce gros pavé. Evidemment, mon petit bagage en C ne m'a pas été inutile, j'ai cependant vite compris que l ouvrage etait plus une référence qu'un livre didactique. On s'enlise vite dans des pages assez compliquées qui nous empechent d avoir une premiere vision globale du sujet.
Je lit en entier le "Henri Garreta" dans lequel je trouve une bonne concision et une bonne description des concepts chers a Bjarne. Il n'est cependant pas assez etoffé, j'ai peur de rater des détails importants.
Je bifurque donc sur le Bruce Eckel (Thinking in C++) depuis quelques jours...et là après avoir affronté le BS, je le trouve limite "fade", bcp moins "précis" et surtout moins "philosophique" (et pour moins un programmeur doit aussi être habité par une philosophie de programmation).

Je suis donc prêt a réaffronter le BS même si j'ai peur d'en être decouragé, car j'ai cette vilaine manie de vouloir assimiler un bon pourcentage de théorie avant de passer à la pratique. Je sens que vous allez me conseiller le contraire, de commencer à concevoir, coder et revenir sur mon bouquin de temps en temps...
Cependant je me dis que coder, sans connaitre toutes les possibilites du langages, c'est un peu prendre de mauvaises habitudes dès le depart, non?

Que pensez vous de tout ca?

[Goten]

J'aime la théorie... si c'est ta façon d'apprendre alors pourquoi pas , mais c'est vrai qu'il va te falloir pratiquer tôt ou tard, c'est en codant et en lisant du code que t'apprendras le plus vite. Par contre de la à parler de : maitriser toute les possibilités du langages, à mon avis tu passeras à du concret bien avant ça .
Le bjarne je l'ai pas lu je peux pas te dire, mais c'est sur que c'est plus un ouvrage de référence qu'un guide de débutant...


Ah et euh, la programmation procédurale c'est pas archaïque hein, le concept objet c'est bien, mais faut pas non plus en servir à toute les sauces.

[koala01]

Salut,

La théorie est très importante, c'est un fait...

Mais mon avis personnel est qu'il y a deux "niveaux" dans la théorie:

Le niveau tout à fait général, celui qui aborde les grands principes de la programmation (procédurale, orientée objet voire générique) de manière plutôt indépendante de tout langage et le niveau particulier propre à un langage donné...

Mais si la connaissance de la théorie "du langage" n'est pas à minimiser, le morceau le plus important est, selon moi, la partie tout à fait générale de la théorie.

Trop souvent, on rencontre (surtout chez les débutants) des gens qui se jettent littéralement sur leur clavier et se mettent à "vomir" du code sans même avoir la moindre idée de ce qu'ils vont faire, de ce qu'ils ont, de ce qu'ils doivent avoir et de la logique à mettre en œuvre pour obtenir le résultat espéré...

A titre d'exemple, regarde les questions posées sur le forum...

Je n'ai jamais fait la moyenne, mais je suis persuadé que l'on approche de

• 40% des problèmes sont induits par le seul le seul fait d'utiliser une logique inadaptée / mal (pour ne pas dire pas du tout) conçue avant d'écrire le code
• 30% qui sont induits par une mauvaise délégation des tâches
• 20% qui sont induits par un problème de conception
• Les 10% restant ayant trait aux langage proprement dit, et seulement pas beaucoup plus d'une question sur cent (de ces 10% restants) traitant réellement des "arcanes" du langage

Je ne veux certainement pas dire que la théorie du langage n'est pas importante, loin de là, mais, quelque part, elle n'est (même si c'est exagéré) composée que de quelque mots de vocabulaire, de quelques règles de grammaire et d'un peu de philosophie...

A partir du moment où tu connais quelques mots de vocabulaire, la différence entre un pointeur et une référence (au sens du langage s'entend, pas au niveau du code généré), les gros problèmes auxquels il faut être attentif avec l'allocation dynamique de la mémoire et les différentes classes fournies par le standard (et encore, tu peux très bien te contenter d'une connaissance "superficielle" de celles-ci), si tu as correctement assimilé la théorie générale, tu as plus que largement de quoi commencer à coder sereinement...

D'autant plus que, connaitre la théorie, c'est très bien... Mais si tu ne la confronte pas à la pratique, cela restera de la théorie

Ceci dit, j'approuve entièrement ton approche qui me parait être la plus sensée pour l'apprentissage

[fabthegreat]

A partir du moment où tu connais quelques mots de vocabulaire, la différence entre un pointeur et une référence (au sens du langage s'entend, pas au niveau du code généré), les gros problèmes auxquels il faut être attentif avec l'allocation dynamique de la mémoire et les différentes classes fournies par le standard (et encore, tu peux très bien te contenter d'une connaissance "superficielle" de celles-ci), si tu as correctement assimilé la théorie générale, tu as plus que largement de quoi commencer à coder sereinement...

Justement, j'ai toujours peur d'avoir "raté" un truc, d'avoir mal compris un autre ou d'être passé a cote d'une notion importante.
Par exemple, dans le Bruce Eckel, j'ai pris conscience de la difference heritage/composition. Alors que je ne m'etais meme pas pose la question en lisant le BS.

... entre autres

a+

[koala01]

Justement, j'ai toujours peur d'avoir "raté" un truc, d'avoir mal compris un autre ou d'être passé a cote d'une notion importante.
Par exemple, dans le Bruce Eckel, j'ai pris conscience de la difference heritage/composition. Alors que je ne m'etais meme pas pose la question en lisant le BS.

Mais justement, la notion d'héritage et les regles permettant de déterminer s'il faut l'utiliser ou non font partie de la théorie tout à fait générale propre à l'ensemble des langages OO...

Pour parler des particularités de C++ concernant l'héritage, on épingle "juste" le fait qu'il est potentiellement multiple et potentiellement virtuel, et... la messe est dite...

Evidemment, cela mérite d'être expliqué plus en profondeur, mais, on constate effectivement l'existence de ces deux grands axes théoriques

[fabthegreat]

Mais me conseilles tu d'essayer de "m'enteter" à bien assimiler ma "bible" ?

[r0d]

Cependant je me dis que coder, sans connaitre toutes les possibilites du langages, c'est un peu prendre de mauvaises habitudes dès le depart, non?

Le problème c'est que "connaître toutes les possibilités du c++" est tout simplement impossible. BS lui-même ne le peut pas, le c++ est trop vaste. Et en plus il évolue constemment.

En revanche, la théorie est une bonne chose, et la pratique aussi. Je suis partisans de faire les deux à la fois: lorsque tu penses avoir saisi une nouvelle notion, met-là en pratique directement, et tu vois ce que ça donne. Ca te permettra de voir si tu as bien compris, et si tu es curieux, d'élargir un peu ton "champ de vision", car lorsqu'on écrit le programme, il surgit toujours des points de détails qui peuvent générer de nouvelles questions.

Pour moi les deux (théorie et pratique) sont intimement complémentaires, et il ne faut négliger ni l'un ni l'autre.

[koala01]

Pour moi les deux (théorie et pratique) sont intimement complémentaires, et il ne faut négliger ni l'un ni l'autre.

d'autant plus que, malheureusement, la pratique est souvent assez éloignée (totalement opposée ) à la théorie... qui doit alors servir de "fil d'Ariane"