c'est à dire ? Si tu fais référence aux accès mémoires invalides, il est facile aujourd'hui d'écrire du code qui ne génère pas plus de segfault que de NULLPointerException.
Je voulais parler des messages d'erreurs, mais je ne me suis rendu compte de l'ambiguïté après avoir validé. Par contre, je rebondis sur la prétendue facilité : quand définir un membre statique (encore un exemple de syntaxe absconse d'ailleurs) au mauvais endroit fait segfault le programme totalement ailleurs, ce n'est pas facile d'écrire du code sans segfault. Par ailleurs, il y a plein de facilités pour écrire du code qui segfault (arithmétique des pointeurs, casts à l'arrache, padding des structs, pas de garantie de la durée de vie des objets, ...).
je ne rentre pas çà dans les lacunes très importantes ; de plus encore une fois pour avoir vu de l'environnement Java complexe
Ce n'est pas parce que c'est un potentiel défaut de Java (je ne connais pas assez le langage pour en juger) que ce n'en est pas un pour C++.
j'ai pas souvenir de préprocesseur qui soit meilleur ailleurs, quand il y a ; qu'est-ce qui te manque et qui existe ailleurs ?
Il devrait simplement disparaître. Les #include c'était bien en 1960, mais on fait mieux maintenant (même Turbo Pascal avait déjà un système de modules) et les macros sont un cauchemar de lisibilité et de maintenance, sans oublier qu'elles pourrissent le scope global.
je partage ton sentiment mais est-ce réellement un problème ? Le templating pose problème aux gens utilisant vraiment le template (les boss quoi), car pour les cas les plus simple j'ai le sentiment que c'est pas plus compliqué que Java pour la très grande des développeurs
Premièrement, Java n'a AFAIK que les génériques et pas le côté méta-programmation, ce n'est donc pas comparable. Ensuite, l'ordre et la nécessité des mots-clefs sont imbitables et les erreur souvent incompréhensibles (cf. l'exemple du post d'ailleurs). Enfin, je doute fortement qu'il faille être un « boss » pour utiliser des génériques (ou alors je suis un dieu de la programmation qui s'ignore :p).
il n'a qu'à utiliser les smart pointer ; non ?
Non, parce que l'ABI des smart pointers n'est pas définie ; donc l'interopérabilité du code n'est garantie que pour des libs headers-only.
la question est plutôt qu'est-ce qui devrait être là aujourd'hui ?
Récupérer boost en dépendance pour pouvoir gérer le FS correctement, c'est tout de même un peu fort ; d'autant plus quand on trouve dans la stdlib des trucs complètement chiadés, mais rien de portable pour récupérer le $HOME. Ensuite, si la culture c'est de récupérer des libs externes pour faire des trucs de base, alors qu'il y ait un gestionnaire de paquets correct (comme pip/gem/cargo/...). On en a vu défiler une kyrielle ces dernières années, mais aucun n'est resté.
pas d'accord car c'est surtout une manière de coder
Pas d'accord, parce que soit on a une stdlib simple et on rajoute plein de trucs en dépendances (comme Rust), mais on se débrouille pour que rajouter des dépendances ne soit pas infernal ; soit un a une stdlib bien remplie (comme python, et pourtant il a pip) et on pense à introduire une fonction pour enlever un élément d'un vecteur avant le générateur de gaussiennes.
pour quelqu'un codant en C++ c'est pas gênant ; je vois pas où est le problème
Parce que ça implique de maintenir plein de choses dans le langage juste pour conserver cette compatibilité, ce qui freine l'évolution du standard.
Je ne vois rien là dedans de catastrophique
Tant mieux pour toi, et je suis sincèrement ravi que tu aies trouvé un langage qui te convienne. Toutefois, je me porte bien mieux depuis que j'ai remplacé C++ par Rust dans ma boîte à outils (instant pub, je conseille à tous les C++-eux d'y jeter un coup d'oeil).
et il me semble qu'ils y travaillent
Depuis 2011, on a réussi à avoir Go, Rust, Swift, Elixir, Nim et sûrement plein d'autres que j'oublie. En C++, on a toujours pas de librairies pour le système de fichiers. Donc s'ils y travaillent, soit ils prennent beaucoup de temps, soit ils n'en ont rien à carrer, soit il passent leur temps à tirer la couverture à eux (de ce que j'ai pu lire par-ci par-là, cette dernière hypothèse serait la plus probable).
le C++ n'a pas vocation à remplacer/dominer tous les autres langages.
Ce n'est pas une question de dominer qui que ce soit ou de savoir qui a la plus grosse qui pisse plus loin, c'est une question de fournir un environnement de travail agréable à l'utilisateur. Et pour ça, C++ ne part pas gagnant.
[^] # Re: Donc pour résumer...
Posté par lockidor . En réponse à la dépêche C++17, Genèse d’une version mineure. Évalué à 5.
Je voulais parler des messages d'erreurs, mais je ne me suis rendu compte de l'ambiguïté après avoir validé. Par contre, je rebondis sur la prétendue facilité : quand définir un membre statique (encore un exemple de syntaxe absconse d'ailleurs) au mauvais endroit fait segfault le programme totalement ailleurs, ce n'est pas facile d'écrire du code sans segfault. Par ailleurs, il y a plein de facilités pour écrire du code qui segfault (arithmétique des pointeurs, casts à l'arrache, padding des structs, pas de garantie de la durée de vie des objets, ...).
Ce n'est pas parce que c'est un potentiel défaut de Java (je ne connais pas assez le langage pour en juger) que ce n'en est pas un pour C++.
Il devrait simplement disparaître. Les
#includec'était bien en 1960, mais on fait mieux maintenant (même Turbo Pascal avait déjà un système de modules) et les macros sont un cauchemar de lisibilité et de maintenance, sans oublier qu'elles pourrissent le scope global.Premièrement, Java n'a AFAIK que les génériques et pas le côté méta-programmation, ce n'est donc pas comparable. Ensuite, l'ordre et la nécessité des mots-clefs sont imbitables et les erreur souvent incompréhensibles (cf. l'exemple du post d'ailleurs). Enfin, je doute fortement qu'il faille être un « boss » pour utiliser des génériques (ou alors je suis un dieu de la programmation qui s'ignore :p).
Non, parce que l'ABI des smart pointers n'est pas définie ; donc l'interopérabilité du code n'est garantie que pour des libs headers-only.
Récupérer boost en dépendance pour pouvoir gérer le FS correctement, c'est tout de même un peu fort ; d'autant plus quand on trouve dans la stdlib des trucs complètement chiadés, mais rien de portable pour récupérer le $HOME. Ensuite, si la culture c'est de récupérer des libs externes pour faire des trucs de base, alors qu'il y ait un gestionnaire de paquets correct (comme pip/gem/cargo/...). On en a vu défiler une kyrielle ces dernières années, mais aucun n'est resté.
Pas d'accord, parce que soit on a une stdlib simple et on rajoute plein de trucs en dépendances (comme Rust), mais on se débrouille pour que rajouter des dépendances ne soit pas infernal ; soit un a une stdlib bien remplie (comme python, et pourtant il a pip) et on pense à introduire une fonction pour enlever un élément d'un vecteur avant le générateur de gaussiennes.
Parce que ça implique de maintenir plein de choses dans le langage juste pour conserver cette compatibilité, ce qui freine l'évolution du standard.
Tant mieux pour toi, et je suis sincèrement ravi que tu aies trouvé un langage qui te convienne. Toutefois, je me porte bien mieux depuis que j'ai remplacé C++ par Rust dans ma boîte à outils (instant pub, je conseille à tous les C++-eux d'y jeter un coup d'oeil).
Depuis 2011, on a réussi à avoir Go, Rust, Swift, Elixir, Nim et sûrement plein d'autres que j'oublie. En C++, on a toujours pas de librairies pour le système de fichiers. Donc s'ils y travaillent, soit ils prennent beaucoup de temps, soit ils n'en ont rien à carrer, soit il passent leur temps à tirer la couverture à eux (de ce que j'ai pu lire par-ci par-là, cette dernière hypothèse serait la plus probable).
Ce n'est pas une question de dominer qui que ce soit ou de savoir qui a la plus grosse qui pisse plus loin, c'est une question de fournir un environnement de travail agréable à l'utilisateur. Et pour ça, C++ ne part pas gagnant.