Je ne savais pas pour final et override, merci pour l'info.Citation:
Envoyé par Gugelhupf
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.
Version imprimable
Je ne savais pas pour final et override, merci pour l'info.Citation:
Envoyé par Gugelhupf
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.
Il y a des gens magiques ici :mouarf: :mouarf:
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?Citation:
Envoyé par Luc Hermitte
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?
Oui j'ai un vague souvenir [peut-être erroné] qu'une fois les try-catch disponibles, les développeurs en mettaient partout.Citation:
Envoyé par Aurelien.Regat-Barrel
C'est bien joli d'avoir une caisse à outils très large [voir même être un peu fier de cette grande largeur :mrgreen:], 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.
"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.Citation:
Envoyé par Aurelien.Regat-Barrel
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"
Tu confirmes ce que je pensais :mrgreen:Citation:
Envoyé par Luc Hermitte
Donc bientôt toute la partie historique C ne sera plus disponible aux développeurs: :mrgreen: (<- *)
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
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.Citation:
Envoyé par foetus
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, ...)
Mauvaise foi :mrgreen: :mrgreen:Citation:
Envoyé par Luc Hermitte
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
Je note "formation sérieuse". Vous qui martelez que l'on peut apprendre le C++1y sans la case C.Citation:
Envoyé par Luc Hermitte
Mais il faut une formation sérieuse: tu m'étonnes :mouarf:
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.
Parce qu'elle est en cours de réflexion je supposeCitation:
Envoyé par Luc Hermitte
T'en distingues que 10 ? Petit joueur! Quitte à sortir un chiffre fou, autant y aller franco : 200 passages de paramètres possibles !Citation:
Envoyé par Gugelhupf
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 :)
Ben, justement, oui… Une bonne formation en C++ est une formation qui, entre autres, ne commence pas par aborder la case C.Citation:
Envoyé par foetus
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.Citation:
Mais il faut une formation sérieuse: tu m'étonnes :mouarf:
Tu cherches à démontrer quoi au juste ?
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, ...Citation:
Envoyé par foetus
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.
Il y a une super vidéo de Stroustrup à ce propos:Citation:
Envoyé par foetus
https://www.youtube.com/watch?v=2egL4y_VpYg
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.
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.Citation:
Envoyé par foetus
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