Cinq mythes courants sur le C++ (traduction d'un article de Bjarne Stroustrup)

Bonjour à tous,

Je viens de publier une traduction d'un article de Bjarne Stroustrup discutant de Cinq mythes courants sur le C++.

Je trouve que cet article est intéressant non seulement pour ceux qui débutent en C++, mais aussi pour ceux qui connaissent un langage qui fait partie de la même famille (C, C#, Java...) et qui voudraient avoir une idée de ce qui caractérise le C++, de ce qui lui est spécifique.

N'hésitez pas à laisser vos commentaires !

PS : Suite à l'article et aux nombreuses remarques qu'il a suscitées, Bjarne a aussi publié une postface (pas encore traduite).

Bonjour et merci pour cette traduction, l'article est intéressant.

Je n'ai pas fini de le lire mais je pose une question. A plusieurs reprise les exemples de code donnés utilisent des accolades {} là où j'aurais naturellement mis des parenthèses ().

Code:

---

1 2 3 4 5 6

void user2() { Filter flt {"books","authors"}; unique_ptr<Filter> p {new Filter{"novels","favorites"}}; // on utilise flt et *p }

---

Dans cet exemple, je pensais qu'il était impossible d'utiliser des accolades pour passer les 2 arguments au constructeur de Filter. S'agit-il d'un des standard de C++ ou d'une erreur de recopie/traduction ?

Il s'agit de "nouvelles" notations introduites avec le C++11, en 2011.

C'est possible à partir du C++11, et ça permet une syntaxe d'initialisation plus uniforme dans les différents cas (même si les autres syntaxes d'initialisation restent possibles pour compatibilité, voire même indispensables dans certains cas). Une des nouveautés appréciables apportées par cette syntaxe est la capacité d'initialiser des collections :

Code:

---

map<string, string> m {{"Hello", "Bonjour"}, {"World", "Monde"}};

---

En tant que promoteur principale de cette syntaxe, Bjarne l'utilise systématiquement dans ses articles. Et l'idée est que si on souhaite n'apprendre qu'une seule syntaxe à quelqu'un, autant apprendre celle là.

Ok, je connaissais la nouvelle syntaxe pour initialiser un liste en passant toutes les valeurs séparées par des virgules, le tout entre accolades. Mais la possibilité d'utiliser cette syntaxe pour initialiser un objet classique m'avait complètement échappé. Je m'en vais trouver un peu de doc là dessus.
Merci

Un point d'entrée comme un autre, list initialization sur cppreference.com.

Mouai, intéressant mais surtout destinés a ceux qui commencent le C++ aujourd'hui et en utilisant des bibliothèques modernes et non pas des vieux machins legacy d'il y a 20+ ans.

Pour les vieux fossiles comme moi, a l’époque le char* était plus courant que le string, la lib standard C++ était peanuts, et la majorité des libs externes étaient écrites en C ou en C++ C-like. Donc oui ça avait beaucoup beaucoup plus de sens de commencer par C a l'epoque. Mais cela concernait les versions de C++ circa 96-98-01. Évidement c'est moins évident que de commencer directement en C++ '11. Porter l’intégralité d'un programme ou d'un framework pre-existant (donc écrit a l'ancienne) demande des investissements (entre autre dans mon cas la formation de scientifiques et mathématiciens qui développent des modèles) qu'on ne peut pas tout le temps se permettre (ou ne veut pas dans leur cas).

Pour le reste non, bien que The C++ Programming Language ~ Special Edition de Stroustrup (livre qui, a nouveau, concerne des anciennes versions de C++) trône sur mes étagères derrière moi depuis plus de 10 ans bien que je fasse du C++ assez régulièrement, j'ai toujours une réaction de rejet quand j'essaie de lire la doc d'une classe ou d'une méthode de fonction a 45 (j’exagère) arguments génériques imbriquées dont ni le nom ni la doc ne m'explique clairement ce a quoi ils ou elle servent. Probablement une déformation de faire du Java (que d'aucun trouvent trop verbeux justement a cause des noms trop long et trop explicites). Ceci dit les dernières évolutions de Java 8 font que désormais on peut retrouver cette même complexité de compréhension en utilisant trop de génériques et de lambda pour reduire un bloc de code a une instruction d'une seule ligne donc en gros on a atteint le même niveau.

Ensuite, n'essaie-t-il pas de prêcher des convertis ? Je veux dire, prenons les sessions vidéo de la dernière conf C++ qui ont été publié ici sur Developpez. Rien que les sessions présentées par Ubisoft sont quand même parlantes : si on veut de la perf brute (et dans le cas d'Ubi de la portabilité sur les plateformes de jeux via leurs framework maison), on fait du C++. Pour eux le C# ne sert que pour les outils middleware qu'ils utilisent en interne ; le produit qui sera publié et vendu sera lui écrit en C++ principalement.

Il est évident que les évolutions des langages (ou les nouveaux langages) ne vont pas intéresser ceux qui n'ont pas évolué depuis 20 ans.
Par contre, ces évolutions ne vont pas intéresser que les débutants, mais également ceux qui ont compris que le coût de mise a niveau de ses connaissances et des projets est largement compensé par les résultats obtenus (efficacité pour écrire des programmes et surtout corriger les problèmes).

Beaucoup de ceux qui continue de faire du C++ old school ne le font pas parce qu'ils maîtrisent le C++ old school (beaucoup de codes C++ old school sont crades, en particulier sur la gestion des erreurs).
Il y a pleins de personnes sur ce forum qui travaillent sur du code ancien ou avec des scientifiques, ce n'est pas forcement impossible de faire évoluer les choses.

Merci Loïc pour cette traduction. J'ai trouvé cet article très intéressant.

Je suis tout à fait d'accord avec les points cités par Bjarne.

Pour moi si ces problèmes perdurent, c'est qu'on ne va pas à la source des problèmes, voici quelques facteurs qui font que pour moi on reste dans le passé avec le C++ :

• Les vielles distributions à l'école avec GCC et C89 (ou G++).
• Les compilateurs plus récents (je pense à GCC) qui n'activent pas par défaut C++11/14 (ps : en espérant que cela ait changé depuis...)
• Beaucoup de tutoriel sur internet, mais la plupart sont nuls, on ne montre pas toutes les possibilités offertes par C++11/14 (je pense aux variétés de pointeur intelligent ou aux threads par exemple).

Autrement l'impression que j'ai eu il y a quelques années lorsque j'apprenais le C++ sur les forums (SdZ principalement à l'époque) est que les gens (peut-être des "vieux") avaient un manque de volonté phénoménal à vouloir partager leurs connaissances (ils ne s'aidaient vraiment entre eux que lorsque les sujets abordés leurs semblaient suffisamment "intéressant"). D'ailleurs j'avais lu quelque part une personne du forum (developpez) avoir eu le même ressenti pour le langage Java à une certaine époque mais que les choses avaient changés depuis l'expansion de C# et PHP pour le web (peut-être la peur de voir sa communauté disparaitre à cause des concurrents). Par contre pour le langage PHP je n'ai jamais eu de mauvais retour, peut-être parce que c'est un langage à la base plus ouvert de par sa simplicité et que la volonté de sa communauté (dont non informaticien) n'est pas de garder le "secret" des connaissances pour eux-même.
Bien sûr les choses ont beaucoup changé depuis je pense, un problème fréquent rencontré ? Et hop go sur stack.
Bref c'était mon ressenti, vous pouvez ne pas être d'accord.

Citation:

---

Envoyé par bouye

Mouai, intéressant mais surtout destinés a ceux qui commencent le C++ aujourd'hui et en utilisant des bibliothèques modernes et non pas des vieux machins legacy d'il y a 20+ ans.

---

L'article en lui même vise surtout les "anciens" comme nous, car justement beaucoup n'ont pas encore intégré le fait qu'il y avait des exceptions en C++, ou ne serait-ce ce que les destructeurs peuvent faire pour nous -- là, je suis toujours en C++98/03. Et aussi ceux qui n'ont pas encore eu le temps de regarder, ensuite, ce que les C++11 et 14 apportent.

Après, il y a certes les problèmes de base vieilles bases de code, et de compilos limités par les distribs linux/windows. Mais cela n'empêche en rien de former les gens à développer dans un C++ plus moderne.

Citation:

---

Envoyé par Gugelhupf

Autrement l'impression que j'ai eu il y a quelques années lorsque j'apprenais le C++ sur les forums (SdZ principalement à l'époque) est que les gens (peut-être des "vieux") avaient un manque de volonté phénoménal à vouloir partager leurs connaissances (ils ne s'aidaient vraiment entre eux que lorsque les sujets abordés leurs semblaient suffisamment "intéressant").

---

C'est un phénomène classique. On forme une première fournée de débutants, et petit à petit on leur refile les réponses simples. Si on voit que les questions simples sont pas ou mal traitées, on intervient. Mais il arrive, il est vrai, que l'on finisse par en avoir marre de répondre aux mêmes exos très basiques (car après tout, on ne doit rien à personne quand on répond bénévolement), ou aux questions où les choses deviennent inutilement des usines à gaz (un effet pervers est que l'on ne tient pas à se prendre le choux sur des codes d'autres personnes qui sont à l'ancienne quand on a déjà nos bases de codes à maintenir/moderniser, et de fait on voit une recrudescence de "bashage de profs qui apprennent le C++ old school").
Cela me fait penser "Hacker guide" d'Eric Raymond qui décrit (entre autres), un phénomène très similaire, IIRC.

Bonjour,

Citation:

---

Envoyé par JolyLoic

C'est possible à partir du C++11, et ça permet une syntaxe d'initialisation plus uniforme dans les différents cas (même si les autres syntaxes d'initialisation restent possibles pour compatibilité, voire même indispensables dans certains cas). Une des nouveautés appréciables apportées par cette syntaxe est la capacité d'initialiser des collections :

Code:

---

map<string, string> m {{"Hello", "Bonjour"}, {"World", "Monde"}};

---

En tant que promoteur principale de cette syntaxe, Bjarne l'utilise systématiquement dans ses articles. Et l'idée est que si on souhaite n'apprendre qu'une seule syntaxe à quelqu'un, autant apprendre celle là.

---

J'avoue que je ne comprend pas vraiment son raisonnement. Comme tu l'as dit :

Citation:

---

même si les autres syntaxes d'initialisation restent possibles pour compatibilité, voire même indispensables dans certains cas

---

En effet, si on a :

Code:

---

1 2 3 4

class C{ C( std::initializer_list<int>() values ); // (1) C(int taille, int default value = int() ); // (2) };

---

Alors :

Code:

---

1 2 3 4 5

C(5,5) C{5,5}   C(4) C{4}

---

Ne font pas du tout la même chose, c'est donc, de mon avis, un hérésie de mélanger les deux.
En effet, si on n'utilise que {}, il y a de fortes chances qu'on ne fasse pas la distinction entre {} et () ce qui sera très préjudiciable par la suite.
Autant se dire tout de suite : () = constructeur normal et {} = constructeur par liste d'initialisation.

Imaginons qu'on ai uniquement le constructeur (2) et qu'on utilise des accolades. On décide ensuite d'ajouter le constructeur (1) quelques mois plus tard. Que fait-on par la suite ? On réécrit tout notre code ? On oublie certaines partie et on laisse des {} là où il faudrait maintenant des () ?

De plus, je ne comprend pas l'argument d'uniformisation, pour moi, c'est encore moins uniforme !
Pour les initialiseurs, {}
Pour les autres constructeurs, {} ou () si un initialiseur d'arguments "similaire" existe.

Citation:

---

Envoyé par Neckara

De plus, je ne comprend pas l'argument d'uniformisation, pour moi, c'est encore moins uniforme !

---

C'est plus uniforme car la même syntaxe est utilisée pour constructeurs par initializer_list et les constructeurs classiques. C'est le seul moyen pour écrire des constructions de collections imbriquées. L'ancienne syntaxe doit être conservée car la rétro-compatibilité est une feature en C++.

Citation:

---

Envoyé par Neckara

Imaginons qu'on ai uniquement le constructeur (2) et qu'on utilise des accolades. On décide ensuite d'ajouter le constructeur (1) quelques mois plus tard. Que fait-on par la suite ? On réécrit tout notre code ? On oublie certaines partie et on laisse des {} là où il faudrait maintenant des () ?

---

Pour cette même raison, si tu conçois ton code de sorte à ce que n'utiliser que la notation {} donne un code valide, le problème ne se posera pas. Et s'il se pose, si tu utilises la différence ce notation pour lever l'ambiguité, il y a un risque de mal utiliser le code car les deux syntaxes sont quand même disponibles. Oui, ça peut introduire des confusions, c'est un défaut notable, mais que perso je considère acceptable au regard du gain.

Citation:

---

Envoyé par jblecanard

C'est plus uniforme car la même syntaxe est utilisée pour constructeurs par initializer_list et les constructeurs classiques.

---

Sauf dans le cas où on a les deux (initializer_list et les constructeurs classiques) possibles pour les même arguments.
Imagine aussi, tu veux appeler C(int, int).
Tu vas mettre des {} par habitude. Grossière erreur, il faut au préalable et systématiquement vérifier si ta classe C ne possède pas de constructeur avec initializer_list pouvant "matcher".
Je ne pense pas que ce soit vraiment pratique pour l'utilisateur, et pire encore pour le débutant.
Le pauvre qui n'arrivera pas à comprendre pourquoi sa classe n'est pas initialisée comme il le souhaiterait :aie:.

Je trouve qu'il est plus simple de lui dire "utilise ()".
Puis plus tard, quand on voit les initializer_list, lui dire "utilise {} pour les initializer_list".

Plutôt que de lui dire "utilise {}" et quand il a pris l'habitude d'utiliser les {}, on lui montre les initializer_list et on lui dit, "on t'as menti, en fait c'est pas toujours {}, parfois faut utiliser ()".
Ou alors travailler en C++90 sur des projets et en C++11 sur d'autres, passer de () à {} et inversement, cela peut vite devenir soûlant.

Je ne parle pas de la configuration des IDE pour les auto-complétion et extraits de codes…

Citation:

---

Et s'il se pose, si tu utilises la différence ce notation pour lever l'ambiguité

---

Donc on doit modifier tout code qui utilise notre classe ? :aie:
Cela va à l'encontre des bon principes de programmations.

Encore pire si notre classe fait partie d'une bibliothèque utilisée par d'autres…

Citation:

---

perso je considère acceptable au regard du gain.

---

J'ai, personnellement du mal à voir le gain apporté par l'utilisation de {} pour le constructeur au lieu de ().

@Neckara
Je te conseille très fortement la lecture de Effective Moderne C++, de Scott Meyers

Pour la confusion entre () et {} lorsque tu as un initializer_list constructor est effectivement problématique (Scott Meyers parle même d'une erreur de conception de vector).
Donc si tu as une classe qui n'a pas de constructeur par liste, tu ne dois surtout pas l'ajouter dans un second temps. Sinon, comme tu l'as dit, cela peut provoquer un changement de comportement du code, qui serait indétectable et donc galère à corriger.
Le problème ne se pose pas si on passe d'un code C++03 et qu'on compile avec un compilateur C++11 (qui ajoute donc par exemple std::vector(initializer_list) ) puisque l'ancien code n'utilisait pas les {}

En termes d'enseignements, cela veut dire effectivement que l'on ne peut pas dire "il faut utiliser {}" ou "il faut utiliser ()". Cela dépend. Et c'est donc plus complique à expliquer.
Il faut probablement éviter d'utiliser les initializer_list constructor, excepté dans les rares cas de création d'une classe "conteneur" (type vector, list, etc). Dans ce cas, on peut considérer que l'utilisateur sait qu'il y a une différence entre () et {}, du fait que la STL utilise aussi cette approche.

Pour l'utilisation de "uniform initialisation", cela vient du fait qu'en C++03, il n'est pas toujours possible d'utiliser = ou () pour initialiser une variable. Alors que {} sera toujours utilisable :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

int x(0); // ok int x = 0; // ok int x{0}; // ok   int x(); // problème // pas de default initialization avec = int x{}; // ok   int x[] = { 1, 2, 3}; // ok vector<int> x = { 1, 2, 3}; // ok en C++11, pas en C++03   class A { int x(0); // erreur int x = 0; // ok int x{0}; // ok };   // class non copiable atomic<int> x(0); // ok atomic<int> x = 0; // erreur atomic<int> x{0}; // ok

---

Il y a d'autres problèmes avec () et {}, en particulier concernant la déduction automatique des types avec auto ou dans les templates, ce qui influence comment on doit écrire et appeler ce type de fonction. Cf le livre pour les détails

Citation:

---

Envoyé par mintho carmo

Je te conseille très fortement la lecture de Effective Moderne C++, de Scott Meyers

---

Le problème, c'est que je suis dans une période où je n'ai pas forcément beaucoup de temps :aie:.

Citation:

---

Pour la confusion entre () et {} lorsque tu as un initializer_list constructor est effectivement problématique (Scott Meyers parle même d'une erreur de conception de vector). Donc si tu as une classe qui n'a pas de constructeur par liste, tu ne dois surtout pas l'ajouter dans un second temps. Sinon, comme tu l'as dit, cela peut provoquer un changement de comportement du code, qui serait indétectable et donc galère à corriger.

---

Dans ce cas là, pourquoi ne pas interdire l'ambiguïté au niveau du compilateur/norme ?

Et dans le cas du vecteur, quel serait la "bonne solution" ?
Ne pas pouvoir ajouter l'initializer_list après coup est aussi relativement dommage.

Citation:

---

Il faut probablement éviter d'utiliser les initializer_list constructor, excepté dans les rares cas de création d'une classe "conteneur" (type vector, list, etc). Dans ce cas, on peut considérer que l'utilisateur sait qu'il y a une différence entre () et {}, du fait que la STL utilise aussi cette approche.

---

Le C++ a plutôt, je pense, une philosophie, "soyons idiot-proof". Ex. cast implicite des void * en C est interdit en C++.
Partir du principe que l'utilisateur connaît la différence me semble être, à mon sens, une erreur.

Citation:

---

Pour l'utilisation de "uniform initialisation", cela vient du fait qu'en C++03, il n'est pas toujours possible d'utiliser = ou () pour initialiser une variable. Alors que {} sera toujours utilisable :

---

Je vois.

int x();On déclare une fonction, il faudrait utiliser
int x;ce qui perd parfois des utilisateurs, en effet.

Mais d'un autre côté, int x{};, c'est deux caractère de trop pour moi, développeur fainéant.

Code:

---

1 2	int x[] = { 1, 2, 3}; // ok vector<int> x = { 1, 2, 3}; // ok en C++11, pas en C++03

---

Donc là, c'est les initializer_list.

Code:

---

1 2 3 4 5

class A { int x(0); // erreur int x = 0; // ok int x{0}; // ok };

---

C'est à mon sens le problème le plus gênant, en effet.
Mais j'aurais plutôt préféré autoriser int x(0) que "d'interdire sans interdire" l'ambiguïté c(int), c(intializer_list).

C'est d'ailleurs surtout cela qui me gêne.

Citation:

---

Envoyé par Neckara

Dans ce cas là, pourquoi ne pas interdire l'ambiguïté au niveau du compilateur/norme ?
Et dans le cas du vecteur, quel serait la "bonne solution" ?

---

Il faudrait voir les discussions qui ont menées a ce choix. Mais c'est clairement un choix qui a été fait volontairement (pas un effet indésirable non prévu) a priori.
Les initializer_list constructor sont prioritaires sur les autres constructeurs, si tu écris :

Code:

---

vector<double> v { static_cast<size_t>(1) };

---

Il y aura une conversion int vers double puis appel du constructeur par liste, même si le constructeur vector(size_t) correspond mieux

Citation:

---

Envoyé par Neckara

Ne pas pouvoir ajouter l'initializer_list après coup est aussi relativement dommage.

---

Si tu n'as pas une sémantique de conteneur, la question ne se pose pas, cela n'a pas de sens d'ajouter ce constructeur.
Si tu as une sémantique de conteneur, il faut effectivement faire le choix des le début. A mon sens, le plus simple est de respecter l'API de la STL et proposer ce constructeur (au pire, tu mets un static_assert(false, "don't do that!") dedans pour explicitement interdire son utilisation :) )

Citation:

---

Envoyé par Neckara

Le C++ a plutôt, je pense, une philosophie, "soyons idiot-proof". Ex. cast implicite des void * en C est interdit en C++.
Partir du principe que l'utilisateur connaît la différence me semble être, à mon sens, une erreur.

---

Si c’était "idiot proof", il n'y aurait pas du tout de void*.

Je ne voulais pas dire qu'il fallait partir du principe que l'utilisateur connait cette différence. Je voulais dire que ce problème existe, indépendamment de ce que tu feras. Le comité aurait probablement du voir ce problème plus en détail, mais pour le moment, il existe.
Donc tu peux partir du principe que tu n'introduis pas de nouvelle difficultés en faisant cela, tu utilises une difficulté existante. Le seul moyen pour éviter cette difficulté est de ne pas utiliser les initializer_list...

Citation:

---

Envoyé par Neckara

int x;ce qui perd parfois des utilisateurs, en effet.

Mais d'un autre côté, int x{};, c'est deux caractère de trop pour moi, développeur fainéant.

---

Attention, c'est pas la même chose.
Dans le premier cas, tu as une default-initilization, dans le second tu as une value initialization.
Pour un objet avec constructeur, tu vas appeler le constructeur par défaut dans les 2 cas.
Pour un build-in type, tu vas avoir une variable qui aura une valeur aléatoire dans le premier cas et une "zero initialization" dans l'autre (selon le type : 0, false, nullptr, etc)

HS : pour ajouter a la confusion (pour les débutants), selon la position des parenthèses, tu as une déclaration de fonction ou d'un valeur :

Code:

---

1 2	int i(); // declaration d'une fonction int(); // creation d'un int

---

Citation:

---

Envoyé par Neckara

Donc là, c'est les initializer_list.

---

C'est le constructeur par liste pour vector et une aggregate initialization pour le tableau style C.

Citation:

---

Envoyé par Neckara

Mais j'aurais plutôt préféré autoriser int x(0) que "d'interdire sans interdire" l'ambiguïté c(int), c(intializer_list).
C'est d'ailleurs surtout cela qui me gêne.

---

Tu n'es pas le seul :)
Je crois qu'il y a des discussions sur ce point, il faudrait vérifier.
Pour le moment, on doit continuer a expliquer les différentes syntaxes. Mais si on commence par {}, il y a quand même moins de cas particulier a expliquer. La situation est moins pire qu'avec le C++03 (bien qu'au final, un "vrai" développeur C++ devra connaitre les syntaxes C++11 et C++03)

Un beau bazar ces {} vs ().

auto x = {"qsdf", "323"}; c'est ça la plus belle des aberrations (que Meyers fustige si je ne me trompe ?).

Et il va effectivement falloir apprendre la totalité des subtilités pour peu qu'on ait à toucher des libs qui ne soient pas en C++11.

Citation:

---

Envoyé par germinolegrand

auto x = {"qsdf", "323"}; c'est ça la plus belle des aberrations (que Meyers fustige si je ne me trompe ?).

---

D'un autre côté, tu aurais voulu quoi comme type pour auto ici ?

Je crois que c'est surtout avec une valeur qui pose problème (du fait que l'on a des écritures très proches, mais qui ne donnent pas à chaque fois le même type déduit)

Code:

---

1 2 3 4

int i { 0 }; // int auto i = 0; // int auto i { 0 } // initialiser_list auto i = { 0 } // initialiser_list

---

Je me souviens plus ce que Meyers dit là dessus

moi ça me saoule ce troll qui revient sans cesse que apprendre le C c'est pas intéressant, qu'on peut apprendre le C++ sans apprendre le C d'abord,

c'est débile, et ça devrait être clair depuis le temps

moi j'ai très bien vu la différence de compréhension entre quand je programmais à 12 ans en Basic puis quand à 19 ans je suis passé au C et que j'ai programmé des fonctions de manipulation de char* et de liste chaînée, et vous aussi vous l'avez vécu donc bon : stop, fini, merci

et alors vos discussions sur "comment apprendre aux élèves le C++ version pointeur intelligents boost etc." mais c'est d'un ridicule : s'ils sont pas capables vos élèves d'apprendre eux-mêmes tout ça ben ça sert à rien d'essayer de le leur apprendre, c'est comme ça la programmation c'est mieux d'avoir 105 de QI sinon ça marche pas trop hein, alors vu les tonnes de langages d'api et tout ça, apprendre les spécificités d'un truc comme le C++11 alors qu'il y a beaucoup plus intéressant en bac+2 ou bac+3 : apprendre la cryptographie ou la programmation 3D ou même je sais pas comment marche mathematica (bon aucun prof n'est capable de l'enseigner mais ça peut changer), des trucs qui sont objectivement difficiles à apprendre tout seul et qui permettent de former l'esprit bien plus ..

Je suis en parti d'accord avec acx01b.

Le but n'est pas de faire apprendre toute l'informatique aux étudiants, mais de leur apprendre à apprendre.

En effet, il n'est pas possible en 8 ans de devenir un expert en tout et tout au long de notre carrière, les technologies sont susceptibles de s'améliorer, d'évoluer, de changer. Ce n'est pas parce qu'on sort d'école qu'on cesse d'apprendre, sauf que là, il faudra apprendre en autodidacte. Le but n'est pas d'avoir une masse de connaissance, mais de pouvoir s'adapter à chaque situations.

Pour cela, il faut donner des bases et une culture informatique aux étudiants. Apprendre par cœur toute l'API Java, c'est impressionnant mais pas très utile.

D'un autre côté, on ne peut pas se contenter de tout survoler, ni même de tout survoler. Il faut bien à un moment ou à un autre approfondir un langage, ne serait-ce que pour se rendre compte de sa complexité et de sa puissance.
Donc oui, malheureusement, on est contraint à faire des choix, on ne peut pas tout apprendre.

Je suis d'avis qu'il faut connaître le C pour bien utiliser le C++, et qu'il ne faut pas séparer ces deux langages.

Personnellement lorsque que j'ai commencé à passer du C au C++, j'était méfiant, J'allais jusqu'à faire des sorties assembleur avec gcc pour voir les différences entre le code C et le code C++. J'avais peur pour la rapidité d'exécution entre autre, et la lourdeur du code. Mais au final le C++ donne des programmes très optimisés. Il faut ce dire que tout ce que cache le C++ au profit de la "beauté du code" est réalisé aussi bien voir mieux que le C. D'un autre côté, pas de miracle, si le C++ donne une certaine liberté, son utilisation coûte autant au niveau complexité que la même liberté que l'on ce serait octroyée en C. C'est d'ailleurs là qu'il faut faire attention.

Ainsi je pense qu'il vaut mieux apprendre le C pour mieux comprendre le C++. De plus je trouve inutile de débuter le c++ en apprenant les dernières spécificité de celui-ci, je pense par exemple à la manipulation des strings, ou au constructeur qui accepte une liste d'initialisation définie à l'aide des crochets. Pour moi ces propriétés relèvent plus du gadget. Le C++ ne se réduit pas à ses fonctionnalités de manipulations de caractère...

Pour autant je trouve le C++ très puissant et je conseil son utilisation au profit du C. D'ailleurs le C est totalement compatible avec le C++, à la différence que le compilateur C++ est souvent plus efficace et plus sûr. Alors quitte à garder ses habitudes C et utiliser quelques fonctionnalité du C++ qui nous plaise, pas de problème! Et si l'on veut aller plus loin dans le C++ on n'est pas pour autant obligé d'utiliser toutes ses fonctionnalités. On peut trouver certaines fonctionnalité lourdes et dangereuse. Et le choix est vite fait! : Si l'on a fait du C et que l'on a ses règles : On prend les possibilités du C++ qui donnent un équivalent en C qui respecte les règles que l'on s'est donné. Par exemple :

En C est ce que j'utilise des pointeurs de fonctions à tout bout de champ? Non! -> Pas de fonctions virtuelles en C++.
En C est-ce que je fait une structure qui pourra fonctionner avec plusieurs types en même temps et perdre le typage, ou est ce que je fais une structure pour chaque type et garder le typage? Une structure par type! Le typage avant tout! -> On utilise les template en C++ pour nous faciliter la tâche.

Finalement j'utilise le C++ pour ses templates, sa surcharge d'opérateur, ses constructeur/destructeur, et c'est tout.

Citation:

---

Envoyé par PierroVsf

Ainsi je pense qu'il vaut mieux apprendre le C pour mieux comprendre le C++.

---

Tu penses, mais tu ne donnes pas d’arguments...

Citation:

---

De plus je trouve inutile de débuter le c++ en apprenant les dernières spécificité de celui-ci, je pense par exemple à la manipulation des strings

---

Et pourtant, les strings, c’est l’exemple type de pourquoi c’est plus simple d’apprendre directement le C++. En C, il faut comprendre que les chaînes sont terminées par \0, mais pas toujours, que ce sont des tableaux, que souvent il faut passer la taille avec, mais pas toujours, etc. En C++, tu as un objet std::string qui est là et fait à peu près ce qu’on attend de lui.

Salut,

Citation:

---

Envoyé par PierroVsf

Je suis d'avis qu'il faut connaître le C pour bien utiliser le C++, et qu'il ne faut pas séparer ces deux langages.

---

Permet moi de ne pas être d'accord avec toi (et d'argumenter sur ce point en sus):

De nombreuses techniques issues du C, indispensables en C sont purement et simplement nocives et contre productives en C.

Tout ce qui rattache le C++ au C, c'est la syntaxe (et encore, on ne peut le dire que pour le sous ensemble commun entre C et C++), autrement, ce sont deux langages fondamentalement différents, à l'instar du latin de Jules Cesar et du français actuel.

Je ne nie absolument pas l'intérêt que peut apporter la connaissance du latin de Jules Cesar dans la compréhension que l'on peut avoir du français moderne, tout comme je ne nie pas l'intérêt qu'il peut y avoir à connaitre le C pour comprendre les rouages du C++.

Par contre, tu conviendra avec moi que la connaissance du latin de Jules Cesar ne peut absolument pas être considérée comme un prérequis à l'apprentissage du français moderne, autrement, nous n'apprendrions pas à parler avant la première année de collège!!!

Et si tu convient de cela pour le latin et le français, tu dois également en convenir pour ce qui concerne le C et le C++. Simplement parce que ce sont des langages fort proches, mais fondamentalement différents ;)

Citation:

---

Personnellement lorsque que j'ai commencé à passer du C au C++, j'était méfiant, J'allais jusqu'à faire des sorties assembleur avec gcc pour voir les différences entre le code C et le code

---

Mmmhh... Oui, en fait, passons... C'est à vrai dire une excellente chose que de s'interroger sur l'efficacité des outils mis à sa disposition ;)

Citation:

---

Ainsi je pense qu'il vaut mieux apprendre le C pour mieux comprendre le C++.

---

Nuançons un peu les choses : si tu veux comprendre l'intérieur des rouages du C++, la connaissance de C t'y aidera très certainement.

Mais le fait est que, sauf exception, il n'y a absolument aucune raison de s'intéresser réellement au rouages du C++. dans la plupart des cas, on se contente d'utiliser les fonctionnalités "de surface" qu'il nous propose; tout comme on se contente généralement d'utiliser fopen (et autre fonctions associées aux fichiers) sans commencer à s'inquiéter de la composition réelle de la structure FILE et de la manière dont elle est traitée par les dites fonctions ;)

Mieux (ou pire, c'est selon) encore : la gestion dynamique de la mémoire est un processus qu'il est indispensable d'assimiler très rapidement en C; on n'a purement et simplement pas le choix. Mais c'est un processus particulièrement complexe à comprendre, à assimiler et, surtout, à maitriser suffisamment en C++ pour éviter les catastrophes (un peu moins en C, grâce à l'absence de système d'exceptions, comme on en retrouve en C++)

Or, C++ nous permet de postposer toute la problématique jusqu'à un moment où l'on en aura vraiment besoin (lorsqu'il commence à être question d'héritage et de polymorphisme), nous permettant d'attendre de nous être approprié un minimum le langage et d'avoir acquis un minimum d'expérience avant de devoir nous frotter au problème.

Cela rend la courbe d'apprentissage beaucoup plus facile à suivre ;)

Citation:

---

De plus je trouve inutile de débuter le c++ en apprenant les dernières spécificité de celui-ci, je pense par exemple à la manipulation des strings, ou au constructeur qui accepte une liste d'initialisation définie à l'aide des crochets.Pour moi ces propriétés relèvent plus du gadget.

---

Sur ce point non plus, je ne suis pas d'accord.

La manipulation des chaines de caractères est un véritable calvaire en C. A moins, bien sur, de définir une taille arbitraire une bonne fois pour toutes pour tes chaines de caractères... Avec tous les problèmes que cela sous-entend ;)

Or l'utilisation et la manipulation des chaines de caractères est une constante dans tout programme : tôt ou tard, on voudra récupérer, afficher ou transmettre une information sous cette forme. La classe std::string (et ses consoeurs) nous permet de manipuler ce genre de donnée en nous concentrant sur les manipulations que nous devons faire au lieu de passer notre temps à nous inquiéter de savoir si "mais aurai-je assez d'espace pour stocker tout cela".

L'utilisation des accolades pour les listes d'initialisateurs est loin d'être un gadget, mais permet de résoudre une problématique réelle. un simple exemple : que fait, à ton avis un code proche de

Code:

---

1 2 3 4 5 6

class MaClasse{ /* on se fout pas mal du contenu }; int main(){   MaClasse foo(); }

---

Le résultat n'est absolument pas ce que tu pourrais croire à la première lecture et en suivant ta première intuition ;)

Citation:

---

Le C++ ne se réduit pas à ses fonctionnalités de manipulations de caractère...

---

sur ce point, au moins, nous sommes d'accord ;)

Mais la conclusion que l'on en tire est radicalement différente :boom:

Car il faut te dire que la manipulation de chaine de caractères est une constante importante de n'importe quel programme, développé dans n'importe quel langage. En particulier lorsqu'il est question de transmettre des informations à l'utilisateur ;)

Citation:

---

En C est ce que j'utilise des pointeurs de fonctions à tout bout de champ? Non! -> Pas de fonctions virtuelles en C++.

---

Pas de fonction virtuelle-->pas d'héritage -->soit de sérieux problèmes de conception, soit, tu te limites vraiment dans l'utilisation des possibilités offertes par le langage (et, s'il n'était question que de cela, tu aurais sans doute intérêt à rester en C qui est malgré tout moins complexe ;) )

j'adore c++ et ses dernières evolutions, je suis impatient de voir la norme c++23 etc (surtout la réflexion de Herb Sutter).

Par contre le problème est de pouvoir travailler sur du code base propre. J'ai au boulot un code C# mais genre grosse bouse, fait à l'arrache, par des personnes qui sont partis. et c'est du c#... On galère un max pour remettre ça bien !

vous imaginez du c++ ? quand je vois le massacre en c#, j'ai du mal a imaginer ce que ca doit être en c++.
Est-ce que quelqu'un a eu cette expérience ?

J'imagine bien un projet C# CLI C++. Je n'ai jamais vu de projet qui n'avait pas de problème avec ce mélange :D mais c'est hors sujet