Discussion :

[Invité]

Oui les mot-clés final et override font parti du C++ désormais. Boost peut faire des lambdas, Boost reste un framework C++, pas le langage C++.

Je ne savais pas pour final et override, merci pour l'info.
Pour les lambdas, je voulais juste dire que des programmeurs C++ s'y intéressent depuis un petit moment et n'ont pas attendu Java pour cela.

[foetus]

Il y a des gens magiques ici

Pour le C++ le développeur lambda n'a toujours que 2 cas à retenir: la copie et la référence. Eventuellement la référence constante. Le reste, c'est pour les développeurs de bibliothèques.

Alors si c'est pour les développeurs de bibliothèques, alors pourquoi le C++1y met à disposition ces "outils" pour les développeurs normaux?
Donc le C++1y est en 2 parties: les outils standards et les outils pour les développeurs de bibliothèques.
Même en 3 parties si je ne me trompe pas, parce qu'il y a eu ajout de mots clefs pour marquer son code à destination des outils de compilation/ débogage.

Par exemple pour le passage de paramètres, tu ne parles pas des reference rvalue cela n'est destiné qu'aux développeurs de bibliothèques?

Du coup, on obtient une boite à outils très large. Et ce n'est pas parce que la caisse à outil contient beaucoup d'outils que je dois tous les utiliser

Oui j'ai un vague souvenir [peut-être erroné] qu'une fois les try-catch disponibles, les développeurs en mettaient partout.

C'est bien joli d'avoir une caisse à outils très large [voir même être un peu fier de cette grande largeur ], mais il faut après expliquer chaque outil.

Lorsque je vois les try-catch: quand en mettre? Est-ce qu'ils remplacent le retour d'erreurs C (<- très laid d'après certains)? Est-ce qu'on peut en mettre dans un constructeur? dans un destructeur? ...
Et aussi lire la documentation pour apprendre que le new lance une exception en cas de problème.
Et enfin les try-catch sont [j'ai l'impression] mis au rebut avec le noexcept tellement ils ont été bien expliqués/ utilisés.

Pour l'adoption de C++11 en industrie, ça dépend bien sûr de l'industrie. Et ça ne veut pas dire que tout le monde exploite toutes les fonctionnalités. Mais la vitesse à laquelle les compilateurs ont implémenté les évolutions est sans précédent.

"La vitesse à laquelle les compilateurs": les gens du comité ont sûrement regardé d'un côté le nombre de compilateurs compatibles C99 et de l'autre le taux d'adoption C99 pour en tirer des conclusions.

Pour cela on va me sortir le même laïus: "Les gens du comité proposent et ratifient des choses [pas forcément utiles, pas forcément pour les développeurs normaux, des fois à tord (le mot clef export)], et les autres font ce qu'ils en veulent"

D'ailleurs, l'idée des CppCoreGuidelines, c'est d'interdire l'utilisation des pointeurs bruts qui sont des tableaux en decay (la traduction m'échappe)

Tu confirmes ce que je pensais

Donc bientôt toute la partie historique C ne sera plus disponible aux développeurs: (<- *)
Déjà il y a tout un tas d'outils pour ne plus faire de macros et de tableaux fixes [même le faire en mieux]. Et le comité est en train de s'attaquer aux modules et refaire l'inclusion.

Et il va rester quoi au C? les types de bases (et encore certains veulent l'intégration des uint32, uint64, ....) et le fait que tout ne soit pas objet.


Édit: *: Un Java++ , en plus verbeux et sans VM.
Quoique j'ai entendu parler [peut-être à tord] d'un début de réflexion sur l’intégration d'une VM

[Luc Hermitte]

a- Alors si c'est pour les développeurs de bibliothèques, alors pourquoi le C++1y met à disposition ces "outils" pour les développeurs normaux?
Donc le C++1y est en 2 parties: les outils standards et les outils pour les développeurs de bibliothèques.
Même en 3 parties si je ne me trompe pas, parce qu'il y a eu ajout de mots clefs pour marquer son code à destination des outils de compilation/ débogage.

Par exemple pour le passage de paramètres, tu ne parles pas des reference rvalue cela n'est destiné qu'aux développeurs de bibliothèques?



b- Oui j'ai un vague souvenir [peut-être erroné] qu'une fois les try-catch disponibles, les développeurs en mettaient partout.

C'est bien joli d'avoir une caisse à outils très large [voir même être un peu fier de cette grande largeur ], mais il faut après expliquer chaque outil.

Lorsque je vois les try-catch: quand en mettre? Est-ce qu'ils remplacent le retour d'erreurs C (<- très laid d'après certains)? Est-ce qu'on peut en mettre dans un constructeur? dans un destructeur? ...
Et aussi lire la documentation pour apprendre que le new lance une exception en cas de problème.
Et enfin les try-catch sont [j'ai l'impression] mis au rebut avec le noexcept tellement ils ont été bien expliqués/ utilisés.



c- Donc bientôt toute la partie historique C ne sera plus disponible aux développeurs: (<- *)
Déjà il y a tout un tas d'outils pour ne plus faire de macros et de tableaux fixes [même le faire en mieux]. Et le comité est en train de s'attaquer aux modules et refaire l'inclusion.

Et il va rester quoi au C? les types de bases (et encore certains veulent l'intégration des uint32, uint64, ....) et le fait que tout ne soit pas objet.

a- Ce n'est pas parce que le langage offre une large panoplie d'outils que tout le monde en a besoin dans ses développements. A-t-on tous besoin de "asm", de "volatile", de "restrict", ou de "register" en C? Et bien là, c'est pareil. Toutes les applications n'ont pas besoin que leurs développeurs les connaisse.
La formulation employée aujourd'hui: rvalue références, atomics, noexcept, constexpr, méta-programmation, ... pour les dévs de bibliothèques, auto, lambdas, for range loops: pour les développeurs métiers (et autres bien sûr).

b- C'est le problème quand on passe dans un langage sans suivre une formation sérieuse dans ce dernier. C++ n'est pas BASIC: il ne suffit pas de connaitre la liste des fonctions pour savoir s'en servir.
Accessoirement, setlongjump & cie, c'est pas mieux.
try-catch ne sont pas mis au rebut avec noexcept. On avait déjà throw(), et aussi un cerveau pour savoir qu'il est inutile de rattraper une exception depuis une fonction dont la doc dit ne lancer aucune exception.
Pire, try-catch ne doit être employé qu'aux points où l'on sait pouvoir faire quelque chose avec l'exception (notification utilisateur, log, reprise, ...). Ce n'est pas pour gérer les ressources (je sais beaucoup de cours de C++98 sont exécrables et n'ont jamais su enseigner le RAII). Certes en Java <7 on aura un try, mais avec un finally, pas un catch pour les ressources autre que la mémoire.

c- Elle est disponible, mais fortement déconseillée. Chose que l'on retrouve dans pas mal de règles qualités en industrie. Donc rien de nouveau ici non plus.
Quant à ce qu'il reste au C : des archis limitées, les ABIs standardisées, du code en maintenance et des psycho-rigides qui ne veulent que ce langage et surtout pas d'autres qui pourraient faire le même boulot (NB: cela existe dans tous les langages : C++, python, Java, ksh, fortran, ...)

[foetus]

a- Ce n'est pas parce que le langage offre une large panoplie d'outils que tout le monde en a besoin dans ses développements. A-t-on tous besoin de "asm", de "volatile", de "restrict", ou de "register" en C? Et bien là, c'est pareil. Toutes les applications n'ont pas besoin que leurs développeurs les connaisse.
La formulation employée aujourd'hui: rvalue références, atomics, noexcept, constexpr, méta-programmation, ... pour les dévs de bibliothèques, auto, lambdas, for range loops: pour les développeurs métiers (et autres bien sûr).

Mauvaise foi
Tu prends en exemple des mots clefs qui n'existent que par eux-même.

Alors que, même si je ne connais pas le C++1y, les rvalue références introduisent la move semantic, constexpr c'est ce qui doit remplacer les macros (et même cela fait plus que cela), la méta-programmation c'est la base du C++1y

b- C'est le problème quand on passe dans un langage sans suivre une formation sérieuse dans ce dernier. C++ n'est pas BASIC: il ne suffit pas de connaitre la liste des fonctions pour savoir s'en servir.

Je note "formation sérieuse". Vous qui martelez que l'on peut apprendre le C++1y sans la case C.

Mais il faut une formation sérieuse: tu m'étonnes

Lorsque je vois que tout le monde attend un vrai objet string, soyons fou un string templaté avec toutes les moulinettes de conversions de l'un vers l'autre std::string<std::UTF8> my_string, non ces boulets nous rajoutent 2 pauvres types qui ne servent juste à pas grand chose mais surtout à alourdir le nombre de boulets à se farder.

c- Elle est disponible, mais fortement déconseillée.

Parce qu'elle est en cours de réflexion je suppose

[Bousk]

[*]C++ (10 cas) : par défaut copie de valeur pour tous SAUF pour les tableaux qui passent par référence (2 cas ici), copie de référence pour les pointeurs, passage par référence SAUF le cas où on écrit par exemple un entier en dure et donc obligation de préciser le mot-clé const (2 cas ici), les rvalue reference SACHANT QUE ce dernier a priorité sur un passage par référence constant lors d'une surcharge de fonction (2 cas ici), les pointeurs intelligents divisés en plusieurs catégories (pointeur unique, partagé, et weak pour éviter les références circulaires)... et j'en oublie surement d'autres... mais en gros à vue d'oeil j'ai l'impression que nous sommes passé de 5 cas à 10 cas différents d'un coup... c'est beaucoup pour un concept constituant la base du langage, et tous ces cas particuliers du C++ font que le langage est toujours plus complexe.[/LIST]

T'en distingues que 10 ? Petit joueur! Quitte à sortir un chiffre fou, autant y aller franco : 200 passages de paramètres possibles !
Bon après c'est dur d'atteindre ce chiffre j'avoue, mais tu étais pourtant sur la bonne voie en citant unique, shared & weak _ptr, t'aurais pu lister toutes les classes de std, pi celles de Boost s'il restait de la place

[white_tentacle]

Je note "formation sérieuse". Vous qui martelez que l'on peut apprendre le C++1y sans la case C.

Ben, justement, oui… Une bonne formation en C++ est une formation qui, entre autres, ne commence pas par aborder la case C.

Mais il faut une formation sérieuse: tu m'étonnes

Franchement, j’ai vu trop de code pourri dans des langages « accessibles aux débutants », ça m’a convaincu qu’il faut une formation sérieuse tout court, quelque soit le langage. C++ n’est probablement pas le meilleur pour apprendre, mais dans tous les cas, il faudra une formation sérieuse.

Tu cherches à démontrer quoi au juste ?

[Luc Hermitte]

a- Mauvaise foi
Tu prends en exemple des mots clefs qui n'existent que par eux-même.

b-Alors que, même si je ne connais pas le C++1y, les rvalue références introduisent la move semantic, constexpr c'est ce qui doit remplacer les macros (et même cela fait plus que cela), la méta-programmation c'est la base du C++1y


c- Je note "formation sérieuse". Vous qui martelez que l'on peut apprendre le C++1y sans la case C.

Mais il faut une formation sérieuse: tu m'étonnes

d- Lorsque je vois que tout le monde attend un vrai objet string, soyons fou un string templaté avec toutes les moulinettes de conversions de l'un vers l'autre std::string<std::UTF8> my_string, non ces boulets nous rajoutent 2 pauvres types qui ne servent juste à pas grand chose mais surtout à alourdir le nombre de boulets à se farder.

e- Parce qu'elle est en cours de réflexion je suppose

a- mauvaise foi de qui ? Tout le C n'est pas destiné à tous les développeurs C, et c'est la même chose avec le C++. Et pareil avec le Java aussi : Jouer avec la réflexion ou les annotations ce n'est pas destiné à tout le monde. Même chose avec l'héritage multiple d'interface v8 qui ont des comportements ; et j'ai même envie de dire "inherits" au vu de l'héritage entre List et SortedList dans la v1 de la lib du Java. Pour python on pourrait parler des contournements d'encapsulation, de l'injection de fonctions dans des classes, voire des objets déjà existants, de l'héritage multiple, ...

b- constexpr c'est surtout ce qui doit se taper l'incruste dans les définitions de fonctions inlines. Les macros cela fait longtemps qu'elles sont bannies aussi souvent que possible et en particulier pour définir des constantes. Par contre, en C++17 on pourrait avoir des constantes inlinées histoire d'éviter de mettre le nom dans un .h, et la définition dans un .c(pp). Ca, c'est pour les end-users.

La meta-prog, même si la lib standard s'en sert énormément, ce n'est pas destiné aux end-users. Pas plus en C++98, qu'en C++17 (ni aucune des étapes intermédiaires).

c- On peut définitivement. Il m'empêche qu'il ne faut pas que cela soit fait par des profs qui maitrisent (?) le C et qui croient qu'ils pourront alors maitriser le C++. Pour les exceptions, il y a des règles simples à apprendre. Mais pour les transmettre il faut : les connaitre. Cela peut requérir de ne pas vivre au pays magique où les erreurs n'existent pas (cas de l'essentiel des cours de C), et probablement d'avoir expérimenté un code un temps soit peu réel où des erreurs se propagent entre l'instant de leur détection jusqu'au lieu où on a quelque chose à en faire.
Quand on ne montre que la syntaxe, les élèvent ont vite fait de croire qu'il faut intercepter pour relancer à chaque niveau.

d- Les chaines de caractères et l'UTF-8, c'est pour moi toujours un échec. Il y a des progrès avec boost.locale, mais ce n'est que semi-standard (à l'image des apaches commons (nom à vérifier) en Java)

e- Non. Non. Rien de nouveau non plus. <(c)stdlib(.h)>, <(c)stdio(.h)>, ... sont déjà mises au ban dans les règles qualités, applicables au C++, que je fréquente.

[Aurelien.Regat-Barrel]

Oui j'ai un vague souvenir [peut-être erroné] qu'une fois les try-catch disponibles, les développeurs en mettaient partout.

Il y a une super vidéo de Stroustrup à ce propos:

En gros, quand un nouveauté débarque dans un langage, elle a tendance à être verbeuse syntaxiquement afin d'être bien visible (comme struct en C). Et les utilisateurs ont tendance à l'utiliser partout parce que c'est nouveau et aussi pour montrer qu'ils maîtrisent cette nouveauté.

Ca a été le cas en C++ avec les exceptions, la POO, les templates... Et, avis perso, je pense que c'est le cas en ce moment avec les rvalue reference.

C'est bien joli d'avoir une caisse à outils très large [voir même être un peu fier de cette grande largeur ], mais il faut après expliquer chaque outil.

Tu peux le voir ainsi. Tu peux aussi voir ça comme l'apprentissage des mathématiques à l'école : au début on apprend juste l'addition, puis doucement on apprend autre chose en fonction de ses besoins.

Ce qui est discutable je pense c'est de prétendre à la non existence d'une fonctionnalité au motif que l'on n'en n'a pas personnellement besoin [de manière directe du moins]. J'ai l'impression que c'est un comportement plus courant avec C++ qu'avec d'autres langages. Mais je peux me tromper.

Maintenant, si on pose les choses ainsi : "quel est le sous ensemble utile de C++?", alors répondre à cette question est difficile en effet. Les Cpp Core Guidelines sont une aide dans ce sens. Mais d'un autre côté, c'est le boulot d'un développeur senior de répondre à cette question dans un contexte donné. Et si un développeur junior se sent perdu face à ce qu'il convient de faire, je crois qu'il doit davantage se tourner vers sa boite / son prof pour être guidé que vers ceux qui font évoluer le langage.

Aurélien