Penser en C++ (Volume 1)

Version imprimable

08/03/2013, 11h53
Community Management

Penser en C++ (Volume 1)

Bonjour,

Le cours "Penser en C++" est une traduction du cours "Thinking in C++"

Préface:

Citation:

Comme n'importe quel langage humain, le C++ permet d'exprimer des concepts. S'il est réussi, ce support d'expression sera plus simple et plus flexible que les solutions alternatives, qui au fur et à mesure que les problèmes s'amplifient, deviennent plus complexes.

On ne peut pas simplement considérer le C++ comme un ensemble de fonctionnalités - certaines fonctionnalités n'ayant pas de sens prises à part. On ne peut utiliser la somme des parties que si l'on pense conception, et non simplement code. Et pour comprendre le C++ de cette façon, il faut comprendre les problèmes liés au C et à la programmation en général. Ce livre traite des problèmes de programmation, pourquoi ce sont des problèmes, et l'approche que le C++ a prise pour résoudre de tels problèmes. Ainsi, le groupe de fonctionnalités que je traite dans chaque chapitre sera organisé selon la façon que j'ai de voir comment le langage résout un type particulier de problème. De cette manière j'espère vous amener, au fur et à mesure, depuis la compréhension du C jusqu'au point où la mentalité C++ devient une seconde nature.

Du début à la fin, j'adopterai l'attitude selon laquelle vous voulez construire un modèle dans votre tête qui vous permettra de comprendre le langage jusque dans ses moindres détails - si vous avez affaire à un puzzle, vous serez capable de l'assembler selon votre modèle et d'en déduire la réponse. J'essayerai de vous transmettre les idées qui ont réarrangé mon cerveau pour me faire commencer à «penser en C++.»

Vous pouvez poster vos commentaires ici.

Merci
16/07/2013, 19h43
Hedert

Bonjour,
Merci pour la traduction !

J'ai remarqué un problème sur les caractères en gras, il n'y a pas de saut d'espace après les mots en gras, les mots sont collés, est-ce normal ? :?
17/07/2013, 17h16
ptyxs

Oui, enfin c'est un ouvrage qui est très daté maintenant, non ?
25/01/2014, 18h07
koala01

Salut,

Citation:

Envoyé par ptyxs

Oui, enfin c'est un ouvrage qui est très daté maintenant, non ?

Il est très daté, en effet.

Mais cela ne veut pas dire qu'il soit purement et simplement à jeter pour la cause ;)

Par certains aspects, ca reste quand meme l'une des références pour l'apprentissage "de base", meme si C++ a fortement évolué depuis ;)
25/01/2014, 19h16
athlon64

Y a t'il pas un ouvrage plus récent, mais de pareille qualité ?

Je trouve l'ouvrage très bien rédigé même si je n'ai lu que des parties, on parle pour dire quelque chose d'utile.

C'est pas du littéraire c'est de la technique, dommage j'aurai bien voulu qu'il s'attaque un peu aux patterns et à C++11.
02/02/2014, 20h31
koala01

Citation:

Envoyé par athlon64

Y a t'il pas un ouvrage plus récent, mais de pareille qualité ?

Je trouve l'ouvrage très bien rédigé même si je n'ai lu que des parties, on parle pour dire quelque chose d'utile.

C'est pas du littéraire c'est de la technique, dommage j'aurai bien voulu qu'il s'attaque un peu aux patterns et à C++11.

Nous te comprenons bien :D

Le fait est que l'écriture d'un livre, de manière générale, prend un temps à peine croyable. Et la traduction en demande peut être d'avantage : entre les autorisations indispensables à obtenir, l'équipe à mettre sur pied, le travail à organiser, la traduction, la relecture technique, la relecture orthographique et tout le reste, crois moi, ca demande de l'organisation et de longues heures de disponibilité :P

A titre d'exemple : je suis sur le point de faire éditer un livre que j'ai écrit (il sortira dans les bacs le 17 février). Il ne fait "que" 420 pages à peu près, mais nous sommes à la phase de relecture depuis le mois de septembre. Nous n'étions peut etre que trois à intervenir dans cette phase, mais nous n'avons pas chômé pendant tout ce temps :-S

Ceci dit, on a beau être en 2014, C++11 est encore "fort jeune". Comme les auteurs C++ francophones ne sont pas légions (du moins, les auteurs francophone de qualité, s'entend) et que les auteurs anglophones viennent à peine de sortir la version (payante) de leur livre en anglais, je crains qu'il ne faille encore attendre un tout petit peu avant de ne commencer réellement à voir apparaître des ouvrages de qualité sur le sujet en francais. Surtout s'il doit s'agir d'une traduction librement disponible comme l'est celle de pencer en C++.

Une autre solution est de trouver un auteur francophone capable et motivé pour l'écriture du bouquin que tu recherches. Je t'avouerai que j'avais ce projet dans mes cartons depuis plusieurs années (bien avant l'arrivée de C++11) et que ma première expérience m'a incité à le ressortir. Malheureusement, il ne faudra surement pas compter dessus avant un an, dans le meilleur des cas :aie:
03/02/2014, 00h01
moldavi

Bonjour.

Merci pour cette traduction.

J'ai toujours considéré le livre de Bjarne Stroustrup comme suffisant à la compréhesion globale du C++ (ayant commencé par le C), mais l'introduction traduite de ce livre me donne envie de lire la suite.

Citation:

Quand j'ai commencé ma lutte pour apprendre le C++, le seul livre décent était l'autoproclamé "Guide de l'expert, (1)", de Bjarne Stroustrup, et j'étais donc livré à moi-même pour simplifier les concepts de base.

Je ne sais pas ce qu'il veut dire par "simplifier les concepts", mais c'est cela qui me donne envie de lire la suite. Parce que je ne vois pas ce qu'il y a à simplifier.
14/08/2019, 12h13
Visualski

Bravo !

Bonjour,

Après avoir déjà lu beaucoup de livre sur le c++,
Je suis tombé un peu par hasard sur cette traduction et je doit dire que j'ai été agréablement surpris de la qualité pédagogique de cet ouvrage.
En effet, il porte très bien son nom :"Pensez en c++" car il répond à une multitude de question que l'on se pose lorsqu'on commence à programmé en c++.
Il traite par exemple les choix à faire entre dériver un objet ou le faire par composition.
Il traite la surcharge de l'affectation par copie; la particularité des constantes; etc ...
Si c'est nécessaire il n''hésite pas à détailler les étapes de la compilation et des instructions en assembleur générées pour faire comprendre certains concepts très utiles.
Après la lecture de ce livre, on comprend bien la philosophie du c++ qui consiste à faire le lien entre, ce que l'esprit peut concevoir, et la machine.
L'auteur a enseigné à des étudiants le c++, et ça se voit !

Je remercie les traducteurs qui ont su exprimer ces concepts et cette pédagogie en français, bravo !
14/08/2019, 22h38
koala01

Salut, et bienvenue sur le forum :D

Au nom de tous les traducteurs, dont je fais partie, je te remercie pour ce petit message. Il faut malgré tout rendre à Cesar ce qui lui appartient : le gros du travail a été fait à l'origine par Bruce Eckel :D L'équipe de traduction ayant "juste" essayé de fournir une traduction "la plus juste possible" afin d'éviter certains non sens.

Malheureusement, malgré la qualité de l'ouvrage (aussi bien de la VO que de la traduction, s'entend), il souffre d'un énorme problème, qu'il est impossible d'éviter et pour lequel il y a peu d'espoir d'y trouver une solution : il se fait excessivement vieux : la traduction elle-même datant de 2008, la version originale date de ... 1995.

Le problème, c'est, non seulement, que depuis, certaines notions sont beaucoup mieux comprises et abordée de manière tout à fait différente qu'à l'époque, mais aussi que C++ a subi des évolutions majeures, en 2011, 2014, 2017, et qu'une nouvelle (déjà connue sous le nom de C++20) est prévue pour l'année prochaine. Bien sur, toutes ces évolutions (de compréhension et du langage) ne sauraient pas être prises en compte ;).

Malheureusement, il n'existe, encore aujourd'hui, que très peu de ressources (toutes langues confondues) qui arrivent à prendre ces évolutions (de mentalité et du langage) en compte, ce qui va rendre le conseil que je vais te donner très difficile à suivre :aie: :

Pensez en C++ t'aura surement énormément appris, et une bonne partie de ce qu'il contient te servira sans doute encore pendant longtemps, et peu-être même pour d'autres langages moins complexes, moins "difficiles" et moins "permissifs" que le C++.

Et pourtant, la manière dont le développement en C++ est envisagée aujourd'hui n'a absolument rien à voir avec de nombreuses techniques présentées dans le livre.

Je ne pourrais donc pas faire autrement que de te conseiller de faire "aussi vite que possible" (avant d'avoir pu laisser certaines mauvaises habitudes se fixer de manière trop importante) la transition vers les techniques "actuelles".

La meilleure piste que je puisse te donner pour y arriver étant de hanter les forums, non seulement pour suivre les discussions des autres, mais aussi pour y poser tes propres questions. A défaut d'une ressource spécifique (comme un livre ou l'autre) tu y croisera un grand nombre de gens près à t'apporter toute l'aide que tu peux souhaiter ;)
15/08/2019, 17h11
Visualski

Merci pour ton conseil Koala01

Je suis tout à fait d'accord avec toi sur le fait que cet ouvrage est excessivement vieux et que bien sûr des évolutions ont été apportées depuis.
Ceci a d'ailleurs suscité une certaine interrogation de ma part et j'ai même hésité à mettre ce commentaire sur ce forum qui n'avait pas été actualisé depuis 2004.
J'avais comme impression d'être un peu décalé et je ne m'attendais pas à avoir une réponse aussi objective et sympathique.
Je l'ai fait en me disant que ce n'est pas parce qu'un concept est ancien qu'il n'est pas toujours d'actualité.
J'ai étudié sommairement les évolution du C++11, C++14, c++17 et j'ai compris quelques évolutions comme les fonctions 'Lambda', l'apparition des pointeurs intelligent shared_ptr, weak_ptr et unique_ptr.
En effet il y a des évolutions pour rendre le c++ moins permissif et encore mieux structuré, c'est une bonne chose, et ton conseil de ne pas prendre de mauvaises habitudes est précieux.
Cependant, il existe encore pas mal de cas ou l'on rencontre des syntaxes anciennes qu'il faut comprendre pour pouvoir les utiliser ou les transcrire dans un style plus moderne.
C'est en cela que l'utilisation d'un ouvrage ancien peut éclairer certaines pratiques.

Pour ma part, je travail sur un projet utilisant le pipeline3D de directX11(windows) et les interfaces ODBC.

Certes l'interface ODBC est ancienne mais les base de données le sont également et il est difficile de s'en passer.
Curieusement, microsoft en conseil encore sont utilisation, parce qu’elle est devenu probablement un standard.
Il y a beaucoup de buffers et de mémoire à gérer, d’où une programmation de bas niveau nécessaire.
.
Pour directX, il y a énormément d'objet COM et on se retrouve avec pas mal de concepts.
L'écriture des Shaders par exemple, utilise une syntax HLSL proche du C.
J'utilise également du CUDA pour une accélération matériel faite par le coprocesseur graphique et la encore, on est assez proche du C.

Malgré tout, ces techniques sont plutôt récentes et c'est très curieux de ressentir ce sentiments d'être "ringard" alors que l'on utilise les dernières innovations des coprocesseurs graphiques et du calcul parallèle.

C'est en cela que j’apprécie ta réponse.
Ceci m'encourage à commencer par utiliser les pointeur intelligent du c++11, pour les objets COM, cela me parait nécessaire.
Et peut être, que le travail de traduction que vous avez fait il y a quelques années est toujours d'actualité !
22/08/2019, 10h26
0x100

Je pense commencé le livre

Salut,

Étonnant de voir encore des gens parler sur des discutions aussi anciennes. Je comptais lire le livre même si il est trop vieux, ais-je tort ?

Salut, et bienvenue sur le forum :D

Citation:

Envoyé par 0x100

Salut,

Étonnant de voir encore des gens parler sur des discutions aussi anciennes.

Pas plus que de voir un type répéter un tas de conseils plus d'une fois par mois depuis des années ;)

C'en est arrivé à un point tel qu'un jour, ce type, ben il a décidé de faire un ticket de blog sur le sujet, mais, comme il atteignait la dizaine de page, il a décidé d'en faire un article. Seulement, les dix pages en sont devenue vingt, puis cinquante, puis elles ont dépassé la centaine, pour en arriver au final à près de 400...

Alors, le type en question a décidé d'en faire un livre :D

Citation:

Je comptais lire le livre même si il est trop vieux, ais-je tort ?

Voilà bien une question à laquelle il est très difficile de répondre, car, à l'heure actuelle, la réponse oscille sans doute entre "oui, mais non" et "non, mais oui" :aie: je m'explique:

Au vu des évolutions du langage et de l'évolution des compréhensions, il n'y a rien à faire : Penser en C++ est un livre que l'on peut aisément qualifier "d'obsolète". A ce titre, si c'est pour apprendre le C++, la réponse raisonnable serait de se tourner plutôt vers la dernière édition du lipman (C++ primer, 5^eme édition), a défaut de disposer d'une ressource en français.

Après avoir étudié le lipman, si c'est dans l'optique de s'améliorer en C++, j'aurais tendance à dire que... on est déjà trop bon pour Penser en C++.
Pour aller dans le même sens, les développeurs C++ poussent, depuis C++11, de plus en plus les "nouveaux" développeurs à utiliser les fonctionnalités "modernes", et à juste raison, vu que cela facilite énormément la vie. D'ailleurs, si tu devais parcourir l'ensemble des discussions que l'on a pu avoir sur ce forum (et sur d'autres) depuis 2012, tu te rendrais sans doute compte qu'un "recadrage quasi systématique" a lieu dés que le développeur arrive avec une approche "plus ancienne", parce que:

auto, les lambda, le range based loop sont systématiquement mis à l'honneur
les fonctionnalités du fichier d'en-tête random sont systématiquement proposées en lieu et place de (s)rand
l'utilisation de std::function (ainsi que les labmda) sont systématiquement préférées aux pointeurs de fonction,
j'en passe, et sans doute encore de meilleures

On peut donc réellement se poser la question qui fâche "est-ce que cela vaut la peine de perdre son temps à lire Penser en C++?".

Cependant, tout ce dont je viens de parler, c'est très bien pour du code moderne, du code écrit après 2011, et qui a volontairement décidé de profiter des "nouvelles fonctionnalités". Mais, C++ est un langage qui a près de trente ans au moment d'écrire ces lignes; et nombreux sont les programmes (ou les bibliothèques) qui ont été créés bien avant l'apparition de C++11, et qui n'ont pas été "remis à jour".

Autant dire que, à l'heure actuelle, un développeur C++ a autant de chances de se retrouver confronté à un code moderne qu'à un code "historique" quand il lit du code qu'il n'a pas lui-même écrit. Et, pour être franc, il a peut-être encore plus de chances d'être confronté à un code "historique" qu'à du code moderne, surtout s'il se met à farfouiller dans les archives ;)

C'est pour cette raison qu'il peut s'avérer utile de lire Penser en C++ aujourd'hui. Non pas dans l'espoir d'apprendre quelque chose de nouveau au niveau du langage, mais bien pour se donner "une chance" de comprendre "un peu mieux" la tournure d'esprit de ceux qui ont écrit le code "historique".

Pour essayer de te faire comprendre le gouffre qui peut séparer l'approche "historique" et l'approche "moderne", je vais prendre un exemple presque amblématique: le fameux principe connu sous le nom de LSP (Liskov Substitution Principle ou Principe de Substitution de Liskov en français).

Pour ne pas trop entrer dans les détails, ce principe place les bases nécessaire à la décision de recourir à une relation d'héritage entre deux classes.

A l'heure actuelle, tout le monde est tout à fait d'accord pour dire que le respect de ce principe doit être évalué avant d'écrire le code, vu que c'est un principe de conception.

Pourtant, il y a "moultes années", quelqu'un a posé la question qui fache:

Citation:

Peut-on envisager de faire passer une fonction publique de la classe de base dans l'accessibilité privée au niveau de la classe dérivée :question:

Ayant été parmi les premiers à répondre, j'ai répondu

Citation:

Non, parce que le LSP ne serait alors plus respecté

Ce qui me semblait tellement logique (déjà à l'époque) que je n'ai pas donné beaucoup plus d'informations sur le sujet.

Et pourtant, il y a eu tellement de réaction à mon intervention qu'on a décidé de scinder la discussion en deux, pour en créer une qui se porte exclusivement sur ce sujet: changer l'accessibilité d'une fonction dans la classe dérivée brise-t-elle le respect du LSP (je te donnerai le lien si tu le souhaites ;) )

A vrai dire, en dehors de mon point de vue (que j'étais au début seul à partager), il y avait deux autres points de vues généraux, à savoir:

ceux qui trouvaient effectivement qu'il "n'était pas logique" d'accepter le changement d'accessibilité, mais qui ne voyaient pas en quoi cela brisait le LSP et
ceux qui se basaient sur le fonctionnement du compilateur (car le compilateur accepte ce genre de décision) pour dire que "c'est peut-être pas logique, mais c'est autorisé"

On a discuté pendant des mois (trois mois, 9 pages de forum, à 20 interventions/pages) pour savoir si un code proche de
Code:

1 2 3 4 5 6 7 8 9 class Base{ public: /* je passe tout ce qui n'a aucun intérêt */ virtual void foo(); }; class Derivee : public Base{ protected: void foo() override; // syntaxe C++11 et ultérieure };
brisait ou non le LSP.

Et la plupart de mes contradicteurs sont des gens dont j'apprécie énormément le professionnalisme et la compétence.

J'ose espérer / je veux croire que, à l'heure actuelle, plus personne (en dehors des débutants qui peine à prendre l'entière mesure de ce qu'impose le LSP, s'entend) ne me contredirait aujourd'hui sur un sujet similaire. Mais, à l'époque (en 2010), les choses n'étaient pas comprises et appréhendées de la même manière.

22/08/2019, 16h11
0x100

Merci pour ta réponse très complète enfaite je pense avoir un niveau moyen en c++ je connais les bases ect... mais j'ai souvent trop l'habitude à penser en C donc oui l'idée c'était de me perfectionner un peu plus dans le langage et je n'ai pas un niveau assez fluide en anglais encore pour le lipman.
24/08/2019, 22h46
Visualski

Bonjour 0x100 et koala01

Citation:

Citation : "Je comptais lire le livre même si il est trop vieux, ais-je tort ?"
"Après avoir étudié le lipman, si c'est dans l'optique de s'améliorer en C++, j'aurais tendance à dire que... on est déjà trop bon pour Penser en C++".

Ces citations introduisent les notions de niveau d'abstraction.8O

En effet, plus ont acquière des connaissances en c++, plus les raisonnement peuvent avoir un degré d'abstraction élevés.
Ceci ne veut pas dire que l'on ne peut pas rester dans un degrés d'abstraction moindre pour résoudre un problème.

L'important est d'être dans le niveau d'abstraction correspondant au problème :lol:.

Loin de moi, l'idée de relancer la discutions sur le bien fondé de l'évolution du c++, car c'est évident, c'est une bonne chose.
Des recherches et des concepts de programmation ont été développer pour permettre au génie logiciel de repousser le mur de la complexité.

Cependant, une des idées du c++ est d'être évolutif. C'est pour cette raison, à l'époque, qu'il n'a pas abandonné la syntaxe du C.
Ceci a permis réutiliser des milliers de ligne de code C tout en évoluant vers de nouvelles techniques de programmation en C++.
Par analogie, on pourrait peut-être dire qu' aujourd'hui le Moderne C++ n'a pas abandonné la syntaxe du C++ (Stroustrup) pour les mêmes raisons.

Alors Oui, les transitions entre les différentes techniques ne sont pas parfaites.
La présence de code ancien, empêche d'évoluer rapidement vers du code plus moderne, et c'est vrai.
Mais cette capacité d'évolution n'est-il pas, justement tout la force du C++ ?

Ce langage permet tout de même de passer d'un niveau d'abstraction proche de la machine à des niveaux de concepts de programmation découvert ressemant.

Le plus important, est de bien savoir ce que l'on fait, et de toujours se poser la question suivant: "Suis-je bien dans le niveau d'abstraction correspondant au problème à résoudre ?

Peut importe l'époque du concept, l'important est de savoir pourquoi ce concept existe. 8O

Ce qui est important, lorsque vous lisez un document, est simplement de comprendre pourquoi ce concept existe et de le situer par rapport au degré de complexité et des contraintes matériel de l’époque concernée.

Par exemple:
Il y a eu une époque ou les ressources mémoires des appareils étaient limités, des techniques d'optimisations étaient importantes !
Les appareil ont évolué et les ordinateurs d'aujourd'hui ont suffisamment de mémoire pour ne plus se poser cette question, le concept d'optimisation de mémoire peut-être abandonné !
Oui mais voila, l'apparition des objets connectés relance la problématique car les microprocesseurs sont plus modestes !
L'appareil nomade fonctionnant sur batterie doit optimiser sa consommation électrique, les copies, et recopies inutiles d' informations dans différentes zone mémoire consomme cette précieuse énergie!
Alors le programmeur est de nouveau confronté à la problématique de la gestion de la mémoire, mais pas forcement pour les mêmes raison qu'à l’époque ou le concept a été développé!

C'est pourquoi il faut bien séparer le concept de son époque.
Il ne faut pas dire "Ce concept est un concept d'optimisation de la mémoire".
Mais plutôt : "Ce concept est un concept de gestion de la mémoire qui répond à une problématique de volume mémoire ou de consommation d’énergie"
Et encore mieux : "Ce concept est un concept de gestion de la mémoire qui répond à toutes problématiques qui peuvent-être résolues par une gestion de la mémoire" :oops:

Maintenant un autre exemple:
Il y a eu une époque ou les ressources mémoires des appareils étaient limités, les programme ne pouvait pas être très volumineux !
Les appareil ont évolué et les ordinateurs d'aujourd'hui ont suffisamment de mémoire pour ne plus donner de limite à la taille d'un programme!
Oui mais voila, les programme deviennent de plus en plus complexe!
Le problème, c'est qu'a l'époque, nous avions pas prévu que l'on pourrait atteindre un tel niveau de complexité!
De nouveau concept apparaissent pour résoudre cette problématique!
Les objets connectés fonctionnant sur batterie et pourvu d'une certaine intelligence, deviennent complexes et ne doivent pas trop consommer!
Alors le programmeur est de nouveau confronté à la problématique de la gestion de la mémoire mais aussi à une problématique de complexité logiciel!

On devine, que le problème de complexité logiciel est un problème actuel!
Il va falloir donc utiliser des concepts de l'époque actuelle!
Le moderne c++ est peut-être une des solutions!
Néanmoins, on est toujours confronté à un problème de consommation d’énergie qui attache une attention particulière à la gestion des objets en mémoire afin de limiter les copies et recopies inutiles.

Toute la puissance du c++, est certainement de pouvoir résoudre ce genre de problème:ptdr:

En d'autre termes:

Il faut comprendre:
pourquoi on a inventé le C :D
pourquoi on a inventé le C++ :D
pourquoi on a inventé le moderne C++ :D

Si on garde cela à l'esprit, je pense que l'on peut s'inspirer des différentes ressources documentaires et en extraire la philosophie sans pour autant être obsolète.
Il faut s'en nourrir et surtout, elle illustre une progression des techniques qui favorise l'apprentissage.

J'aime le langage C++ parce qu’il permet d'avoir un style de programmation correspondant au niveau d'abstraction du problème à résoudre.
Le fait qu'il évolue en maintenant les concepts d'une époque est déroutant mais c'est justement en cela qu'il garantie une évolution progressive.

Tout cela me laisse pensez que le c++ n'a pas d'age !:oops:
ou en a plusieurs ! :?:?:?