C++ Primer

C++ Primer


https://images-na.ssl-images-amazon....8.MZZZZZZZ.jpg

Citation:

---

Bestselling Programming Tutorial and Reference Completely Rewritten for the New C++11 Standard
Fully updated and recast for the newly released C++11 standard, this authoritative and comprehensive introduction to C++ will help you to learn the language fast, and to use it in modern, highly effective ways. Highlighting today's best practices, the authors show how to use both the core language and its standard library to write efficient, readable, and powerful code.
C++ Primer, Fifth Edition, introduces the C++ standard library from the outset, drawing on its common functions and facilities to help you write useful programs without first having to master every language detail. The book's many examples have been revised to use the new language features and demonstrate how to make the best use of them. This book is a proven tutorial for those new to C++, an authoritative discussion of core C++ concepts and techniques, and a valuable resource for experienced programmers, especially those eager to see C++11 enhancements illuminated.
Start Fast and Achieve More
- Learn how to use the new C++11 language features and the standard library to build robust programs quickly, and get comfortable with high-level programming
- Learn through examples that illuminate today's best coding styles and program design techniques
- Understand the “rationale behind the rules”: why C++11 works as it does
- Use the extensive crossreferences to help you connect related concepts and insights
- Benefit from up-to-date learning aids and exercises that emphasize key points, help you to avoid pitfalls, promote good practices, and reinforce what you've learned
C++ Primer, Fifth Edition, features an enhanced, layflat binding, which allows the book to stay open more easily when placed on a flat surface. This special binding method-notable by a small space inside the spine-also increases durability.

[Lire la suite]

---

• Avez-vous lu ce livre ou pensez-vous le lire ?
• Souhaitez-vous ajouter une critique de ce livre sur la page de la rubrique ?
• Avez-vous un commentaire à faire ?

:merci:

L'ouvrage est bien structuré et agréable à lire. Contrairement à "Programming Principes and practice using C++" de B. Stroustrup, les exemples sont bien conçus ici pour illustrer une notion précise.

Pour faire écho à la polémique récurrente concernant le "C++ moderne", on note que les aspects dits "bas niveau" restent traités (tableaux natifs, y compris multi-dimensionnels, chaînes de type C, opérateurs new et delete, tableaux dynamiques...) et surtout qu'ils sont bien intégrés au fil de l'ouvrage et non rejetés à la fin.
En revanche, les exceptions ne sont traitées en détails qu'en toute fin d'ouvrage (dans un chapitre dans lequel on trouve également : la surdéfinition de new et de delete, l'héritage multiple, le RTTI, les énumérations, les pointeurs sur des classes membres, les classes locales, les unions, les champs de bits...). Pourquoi pas si l'on considère que l'on est en phase d'apprentissage. De toutes façons, dans un bouquin didactique, on ne cherche pas à écrire du code susceptible de faire l'objet d'une "revue" sinon la plupart des exemples seraient pollués, entre autres choses, par une multitude de blocs try--catch... Je note au passage que, pour l'auteur, l'abord des exceptions est moins prioritaire que celui des aspects de bas niveau !

En revanche, je reste perplexe quant au choix fait par l'auteur de présenter intégralement la bibliothèque standard, dont les conteneurs, avant d'aborder la gestion dynamique (y compris la classe allocator<T>) et le développement de ses propres classes (avec les opérations de copie et de déplacement) et les patrons (templates). La même remarque s'applique à l'héritage et au polymorphisme. Tout se passe comme si l'on était d'abord utilisateur de classes avant d'être amenés à en développer. L'idée me semble être de dire que l'on peut essayer de "faire son marché" dans la bibli standard avant de développer ses propres classes. Mais, dans ce cas, l'apprenant découvre bien tardivement les fonctionnalités de la P.O.O. J'aimerais bien avoir l'avis d'autres utilisateurs sur cet aspect....

C'est une excellente question.
Tout dépend de l'étendue de la couverture de la bibliothèque standard.

Dans les formations "débutant C++" que je donne à mes collègues (dont j'attends une familiarité avec le développement impératif et procédural, avec l'algorithmie, voire la notion de mémoire), je ne présente l'allocation de mémoire qu'assez tardivement. Je ne rentre pas dans le détail de toute la partie STL de la bibliothèque standard, mais ils auront manipulé std::string, les flux, dont fichier, et std::vector bien avant de voir les allocations dynamiques et les côtés objet, et template (développement de classes et de fonction). Je rejoins assez l'approche de Francis Glassborrow dans son /Je Me Lance/ -- pour le coup, il ne traite ni de la POO, ni de l'écriture de templates, ni de la gestion de la mémoire, ni des exceptions. Je n'ai pas un souvenir précis, mais il me semble qu'Accelerated C++ suivait une approche de ce genre également -- relativement à l'utilisation intensive de la bibliothèque standard.

Toujours avant d'entrer dans le vif du sujet, je présente les 3 grands axes de la STL v1: conteneurs, itérateurs et algorithmes. L'idée n'est pas de faire un tour complet des conteneurs et des algorithmes, mais de comprendre les fondements et de savoir lire une doc en ligne comme celle de cppreference.

A aucun moment je ne les fais travailler avec des char* car on ne veut pas voir ce type manipulé à la main dans nos codes industriels. malloc et free sont des parenthèses pour ceux qui se souviennent du C. new et delete, sont abordés quand je leur fais développer une capsule RAII exception-safe à sémantique de valeur: une matrice. Mon objectif, leur faire sentir qu'ils ne veulent pas manipuler ces bêtes à la main et comprendre qu'il n'est pas possible d'écrire du code robuste et maintenable qui manipule la mémoire (ou autre ressource: FILE, socket, mutex, lock de base de donnée, pot de peinture...) à la main. Du coup, j'ai tout un chapitre qui démontre les problèmes dans la manipulation de la mémoire à la main dans un contexte où les exceptions existent -- pour autant je ne rentre dans les détails de comment les exceptions se lancent, s'attrapent, s'écrivent, se réfléchissent que le dernier jour. Pour la démonstration j'ai honteusement repris (et cité) les codes d'Aaron Lahman dans sa réponse à Raymond Chen sur comment reconnaître rapidement un code incorrect -> traduit ici: http://alexandre-laurent.developpez....ou-exceptions/

J'enchaîne ensuite sur la sémantique d'entité et le cas particulier de l'héritage orienté sous-typage/substituabilité (i.e. le public). Je parle pas mal des bonnes pratiques: SOLID, Déméter...
L'écriture de code template arrive après. Ils sont déjà familier avec son utilisation à ce niveau.

Je conclue donc avec exceptions, mais aussi programmation par contrat histoire de calmer et de cadrer les ardeurs de programmation défensive que l'on a facilement quand on débute. Et l'exercice de l'aquarium même si j'ai rarement le temps de dépasser l'étape de la conception qui me permet de présenter quelques design patterns et des rudiments d'UML.


Dans la formation "révision", la première chose dont je parle, c'est du RAII, et j'insiste que c'est la chose la plus importante qu'ils doivent retenir car le reste, c'est de la syntaxe, et le langage au fond, il ressemble suffisamment aux autres pour qu'ils sachent s'adapter. Mon public n'est pas sensé n'avoir jamais programmé de sa vie -- même si le cas s'est présenté une fois suite à une erreur d'aiguillage.

Je ne parle pas un seul instant de la surcharge de new et de delete. Je parle plus ou moins rapidement de l'héritage multiple (MI) selon le niveau public. Mais à ce stade, j'ai déjà beaucoup insisté sur le LSP, sur l'héritage d'import de code uniquement (le privé), ce qui ce permet de parler du MI pas seulement sous l'angle syntaxique, mais aussi et surtout sous l'angle conception qui permet de ne pas se tirer une balle dans le pied. La méta-programmation est réservée à la formation "expert".

Citation:

---

Envoyé par delannoy

De toutes façons, dans un bouquin didactique, on ne cherche pas à écrire du code susceptible de faire l'objet d'une "revue" sinon la plupart des exemples seraient pollués, entre autres choses, par une multitude de blocs try--catch...

---

Je ne vois vraiment pas pour quelle raison. C'est une question de cohérence dans l'approche. Si on commence par l'apprentissage des allocations/libérations manuelle de la mémoire, en plus de montrer un usage non idiomatique, on se retrouve effectivement bloqué dans le dilemme code complexe (try/catch) ou code incorrect (pas exception safe). À partir du moment où l'on utilise dès le début les classes du C++ qui sont prévues pour (string, vector, rien que ça, on a le temps de voir venir), il n'y a pas besoin d'écrire un seul bloc try/catch pour que le code soit correct. Après tout, c'est à ça que ça sert, le RAII... D'ailleurs, même dans un vrai programme, les try/catch sont généralement rarissimes, par rapport à la taille du code.

Citation:

---

Envoyé par delannoy

L'idée me semble être de dire que l'on peut essayer de "faire son marché" dans la bibli standard avant de développer ses propres classes. Mais, dans ce cas, l'apprenant découvre bien tardivement les fonctionnalités de la P.O.O. J'aimerais bien avoir l'avis d'autres utilisateurs sur cet aspect....

---

Je suis pour ma part persuadé que, quel que soit le domaine d'apprentissage, vouloir partir des concepts les plus bas niveaux, les plus fondamentaux, pour ensuite arriver aux concepts utilisés couramment n'est pas la bonne approche. On n'enseigne pas à un bébé l'indo-européen et la linguistique pour lui apprendre à parler français. Quand on apprend à compter, on ne commence pas par l'algèbre de Peano. Et bien je pense que c'est pareil en C++. Voici quelques raisons :
- Déjà, il y a toujours plus bas niveau. Si on décide de partir de là, où s'arrêter.. Au C ? À l'assembleur ? À l'électronique digitale ?...
- Ensuite, le code bas niveau n'est pas le code que l'on écrit normalement. Autant commencer par montrer dès le début le code que l'apprenant sera sensé utiliser 99% du temps par la suite, afin de lui donner les bons réflexes.
- De même, il est souvent rébarbatif, ce qui ne va pas dans le sens d'intéresser l'apprenant. Si je veux développer un pauvre programme "Comment tu t'appelles ?" "xxx" "Bonjour xxx", pourquoi devrais-je manipuler des notions complexes comme un pointeur, une allocation dynamique (ou l'alternative, un tableau qui habituera les gens à écrire du code remplis de failles de sécurité) ? Et quand on dira : "Bon, maintenant que vous savez faire ça, oubliez tout, ce n'est pas comme ça qu'on fait pour de vrai", ceux qui auront résisté jusque là risque d’avoir des envies de meurtre...
- Enfin, vouloir faire ça demande de présenter 50 notions d'un coup avant de pouvoir écrire le moindre programme vaguement utile. Alors, certes, manipuler std::string demande aussi de connaitre plein de choses. Mais il s'agit de choses assez basiques (pour accéder à un caractère, c'est [], pour comparer, c'est < ou ==, pour il y a plein d'autres choses, on verra plus tard), là ou autrement, il s'agit de concepts plus chauds (indirection mémoire, allocation dynamique, sémantique de copie, encapsulation,...). Et d'expérience, pour un parfait débutant, une string n'est pas plus mystérieuse qu'un int, et il manipule l'un comme l'autre, et c'est avec surprise qu'il découvre plus tard qu'il ne s'agit pas d'un type de base (après tout, c'est le cas dans d'autres langages...), mais qu'il peut lui même créer son propre type. Je trouve que ça permet une courbe d'apprentissage bien plus lisse.


Attention, je ne préconise pas de ne pas montrer les aspects bas niveau, ils sont nécessaires eux aussi. Je parle juste de l'ordre de présentation des sujets.

Et je ne préconise pas non plus de montrer toute la STL avant de regarder comment elle est faite, ce serait contre-productif. Typiquement, string/vector/(unordered_)map/iostream me semble un bon sous-ensemble, qui permet d'écrire déjà pas mal de programmes sans que ce soit trop douloureux ou artificiel. Ensuite, il est temps de lever le capot, en utilisant d'ailleurs ces types comme exemples privilégiés, car leur comportement a été intégré par l'apprenant. Et finalement, une fois que ce genre de choses est faite, il n'y a pas même plus trop besoin de montrer la suite de la STL, les bons concepts sont là pour permettre une certaine autonomie (en consultant une référence, bien entendu).