Existe-t-il un langage qui empêche complètement les erreurs catastrophiques? Qui n'expose jamais au risque de perdre des données, qui génère des programmes dont on est sûrs à 100% qu'ils ne planteront jamais?
A priori, ADA pourrait coller à la description, mais, je ne l'ai pas vu cité encore. J'ai vu cités Swift, Go, et d'autres dont je n'ai jamais entendu parler. Ceux-la, ils y collent à la description? Et en pratique, ça donne quoi?
temps de compilation ;
Faut dire que, quand on voit le code le STL de g++, on comprend que ce soit long à compiler... ça s'include dans tous les sens, avec des macros en veux-tu en voila, des héritages et aggrégations tortueux... et de manière générale un code illisible (chose amusante: ils indentent parfois avec des espaces, parfois avec des tabulations. Je ne parle pas d'aligner le code, mais bien de l'indentation!).
Je n'ai pas fait de comparaisons sur les temps de compilations, mais depuis quelques temps j'utilise libc++ de llvm. Rien que pour comprendre pourquoi un truc merde, c'est 10 fois plus simple (même si je reste gêné par le fait qu'il soit impossible d'interdire au compilo les inline quand on debug...).
Au final, j'utilise clang parce que plus rapide et plus clair que gcc depuis plusieurs années, et cette année j'ai commencé à utiliser leur STL.
Plus ça va, moins j'utilise d'outils GNU pour le dev, et mieux je me porte. Ca ne m'empêche par de reconnaître que je leur dois une fière chandelle, hein, mais je pense que certains défauts repprochés au langage C++ sont plus dus aux outils libres «standards de facto» qu'au langage lui-même. Ou du moins, que ces fameux outils sont une cause aggravante. Le poids de l'historique, sûrement.
Ah oui, j'oubliai: j'essaie aussi de tendre vers l'utilisation de musl, histoire qu'on me dise pas que j'ai oublié la libc :) (mais bon, oui, il me reste pas mal de trucs à remplacer, faut du temps, surtout que je fais ça pour le fun surtout).
le langage de templates qui est parmi les plus abscons, parce qu'il mélange les génériques et la métaprogrammation (ou alors je suis le seul à trouver les templates récursifs imbitables) ;
Existe-t-il un autre langage natif ayant un mécanisme de templates aussi puissant que celui du C++, et qui offre les mêmes perfs (à peu près, du moins)?
Rust, peut-être? (vraie question)
le préprocesseur, vraiment ?
Malheureusement, on en a besoin pour pouvoir utiliser des trucs codés en C. Dans certains cas, ça permets aussi de réduire le code boiler-plate.
Mais, c'est vrai: ce truc est un générateur de galères, quand il est utilisé abusivement. Les fonction inlinées sont par exemple bien plus intéressantes que les macros (surtout en combinaison avec les template), et pourtant dans certains bouts de code on voit encore des macros.
La dernière fois que j'ai vu des macros utilisées, c'était soit dans du code C, soit dans des framework de test, cela dit.
Reste donc que l'usage d'import de header, et je suis d'accord pour dire que ça serait pas mal qu'il saute.
(pourquoi on ne peut pas définir une classe template ailleurs que dans son header ?)
Tu peux. Il suffit qu'elle soit déjà définie quand elle est utilisée. Ca m'arrive de faire des petites structures templates internes à un fichier, que je n'expose pas publiquement ça aucun intérêt.
Je me doute que tu le sais, mais ce n'est pas nécessairement le cas de tous, je me permets donc cette clarification :)
'évolution rachitique
Vrai. C'est lent.
Je me demande quelle est la part de responsabilité liée à l'ISO, ceci dit. La plupart des langages qui sortent, au final, n'ont qu'une implémentation de référence, pas de normalisation réelle.
Hors, cette standardisation officielle et internationale est une force de C++ pour moi.
Du coup, je comparerai la lenteur d'évolution de C++ à Debian: c'est lent et vieux, c'est vrai, mais le fait que ça n'aille pas trop vite semble avoir pour conséquence que la maintenance est plus simple pour les utilisateurs (un vieux code C++ compile sur un compilo moderne sans trop de soucis, et une Debian peut être up/down gradée de la même manière). Pas la création d'un système fonctionnel, sa maintenance, j'insiste.
la gestion mémoire qui accumule plusieurs couches au fil des années (pointeurs nus, références, puis pointeurs intelligents [unique_ptr/shared_ptr/etc.]) ;
Marrant, c'est justement pour la gestion de la mémoire que j'apprécie le C++. Parce qu'en C++, si je veux utiliser un GC, je peux. Si je veux utiliser des pointeurs intelligents, je peux. Si je veux utiliser des pointeurs nus, je peux encore!
J'ai le choix, bon sang, et c'est bien d'avoir le choix, de la meme manière que c'est bien de pouvoir choisir entre windows, mac OS, Debian, voidlinux, FreeBSD, OpenBSD, etc.
C'est perfectible, bien sûr, mais quand je lis qu'il est obligatoire d'utiliser des pointeurs nus en C++, je comprend que l'auteur de la phrase lue ne connaît pas le C++ (je ne dis pas l'avoir lue ici, mais j'ai déjà lu ça, plus d'une fois).
Sincèrement, avec la STL, les références et les itérateurs, les pointeurs nu ne sont simplement qu'une façon de s'interfacer avec le C ou les vieilles bibliothèques. Rien de plus.
A noter un repproche que je fais aux pointeurs intelligents standard: ils ne savent gérer que la mémoire, alors que ce n'est qu'une seule des ressources que l'on peut manipuler (alors qu'un descripteur de fichier UNIX est un int, par exemple). Sans parler du fait qu'ils aient un overhead pour moi inutile (évident pour shared_ptr, moins pour unique_ptr, mais le fait est qu'un pointeur pour stocker l'@ du destructeur est maintenu et testé, alors que ça aurait pu être passé en template. Mais j'imagine que certains ont l'usage de modifier le destructeur au runtime?).
Maintenant, oui, je l'admets: utiliser des références ou des itérateurs ne protège pas contre les segfaults, et il n'y a rien à ma connaissance en C++ pour gérer ça. C'est un des points qui font que je veux me mettre à Rust, un jour.
Le C++ ne permets pas non plus, à ma connaissance, de vérification sur les under/over-flow d'entier. C'est un problème, pour moi, vraiment. D'un autre côté, ça permets un code plus léger et plus rapide, parce que si à chaque addition on devait faire une vérification à l'exécution, c'est du code en plus à exécuter, de la lenteur.
Ce que j'apprécierai vraiment, ça serait de pouvoir faire ça, uniquement pendant le debug.
mais pas de vector::delete_at)
Et ça n'arrivera jamais, j'espère. Si une telle fonction devait exister, elle aurait plutôt sa place dans les algorithmes, autrement dit, ce serait std::delete_at( iterator it, container& cont ); ou un truc de goût là.
Les APIs de la STL sont déjà assez moyennes comme ça, à mon avis (à la fois trop riches et pas assez: trop riches parce que, par exemple, std::vector::insert pourrait être implémenté en dehors du conteneur (avec une combinaison de std::move&std::inserter par exemple) alors qu'il est difficile de connaitre le cout mémoire réel d'un conteneur (pour vector c'est faisable, mais pour std::map?) ).
En tout cas, c'est marrant, dans la liste des défauts de la STL, j'aurai pensé voir std::string au moins une fois (parce qu'elle s'interface relativement mal avec le reste de la lib standard, et que pour une gestion de chaine de caractères, ça ne permets meme pas de diviser facilement... bref je la trouve bancale.).
rétro-compatibilité avec le C, mais pas vraiment non plus.
Comme tout les langages sauf le C, en fait. Je pense que l'on devrait arrêter de ce soucier du C, franchement.
Je pense qu'une bonne part des emmerdes du C++ viennent du C.
dont une bonne partie sont ÀMHA imputable à son âge.
Personnellement, si j'apprécie énormément le C++, c'est parce que c'est un langage qui donne le choix.
Il me donne le choix d'utiliser les template.
Il me donne le choix d'utiliser le modèle mémoire que je veux (GC, pointeurs intelligents, pointeurs nu. Bon, ok, pour le GC il n'y a rien dans la lib standard, probablement parce que la culture C++ préfère la RAII).
Il me donne le choix d'utiliser la RTTI (j'inclue dedans les méthodes virtuelles).
Il me donne le choix de faire de l'héritage multiple et même en diamant (ça m'est déjà arrivé une fois de m'en servir).
Il me donne le choix d'utiliser les exceptions (à condition de se passer de la STL, certes).
Rien n'est obligatoire, il faut choisir ce que l'on utilise. Pour certains, c'est un défaut. Pour moi, c'est une force.
Pour refaire le parallèle avec les distributions Linux: pour moi, l'apparition de Devuan, d'Ubuntu, d'Archlinux, et j'en oublie, ce sont de bonnes choses, parce que ça donne le choix.
Alors bien sûr, avoir le choix implique de prendre des décisions, mais pour moi c'est un peu le coeur de métier d'un développeur, de prendre des décisions.
Mais ce n'est pas parce que j'aime beaucoup C++ que je dis qu'il n'a aucun défaut. Seulement, à l'heure actuelle, je ne vois que Rust pour le remplacer, et il est encore jeune, on n'a pas encore eu le temps de voir comment il vieillit.
Avant de dire que Rust peut remplacer C++, il faudra au moins 5 ans d'écart entre la sortie de sa 1ère version stable et l'heure du jugement, justement pour avoir du recul.
On n'a aucun recul sur Rust, contrairement à C++ ou l'on parle de près de 20 ans ( ~18 de standard ISO).
[^] # Re: Donc pour résumer...
Posté par freem . En réponse à la dépêche C++17, Genèse d’une version mineure. Évalué à 7.
Existe-t-il un langage qui empêche complètement les erreurs catastrophiques? Qui n'expose jamais au risque de perdre des données, qui génère des programmes dont on est sûrs à 100% qu'ils ne planteront jamais?
A priori, ADA pourrait coller à la description, mais, je ne l'ai pas vu cité encore. J'ai vu cités Swift, Go, et d'autres dont je n'ai jamais entendu parler. Ceux-la, ils y collent à la description? Et en pratique, ça donne quoi?
Faut dire que, quand on voit le code le STL de g++, on comprend que ce soit long à compiler... ça s'include dans tous les sens, avec des macros en veux-tu en voila, des héritages et aggrégations tortueux... et de manière générale un code illisible (chose amusante: ils indentent parfois avec des espaces, parfois avec des tabulations. Je ne parle pas d'aligner le code, mais bien de l'indentation!).
Je n'ai pas fait de comparaisons sur les temps de compilations, mais depuis quelques temps j'utilise libc++ de llvm. Rien que pour comprendre pourquoi un truc merde, c'est 10 fois plus simple (même si je reste gêné par le fait qu'il soit impossible d'interdire au compilo les inline quand on debug...).
Au final, j'utilise clang parce que plus rapide et plus clair que gcc depuis plusieurs années, et cette année j'ai commencé à utiliser leur STL.
Plus ça va, moins j'utilise d'outils GNU pour le dev, et mieux je me porte. Ca ne m'empêche par de reconnaître que je leur dois une fière chandelle, hein, mais je pense que certains défauts repprochés au langage C++ sont plus dus aux outils libres «standards de facto» qu'au langage lui-même. Ou du moins, que ces fameux outils sont une cause aggravante. Le poids de l'historique, sûrement.
Ah oui, j'oubliai: j'essaie aussi de tendre vers l'utilisation de musl, histoire qu'on me dise pas que j'ai oublié la libc :) (mais bon, oui, il me reste pas mal de trucs à remplacer, faut du temps, surtout que je fais ça pour le fun surtout).
Existe-t-il un autre langage natif ayant un mécanisme de templates aussi puissant que celui du C++, et qui offre les mêmes perfs (à peu près, du moins)?
Rust, peut-être? (vraie question)
Malheureusement, on en a besoin pour pouvoir utiliser des trucs codés en C. Dans certains cas, ça permets aussi de réduire le code boiler-plate.
Mais, c'est vrai: ce truc est un générateur de galères, quand il est utilisé abusivement. Les fonction inlinées sont par exemple bien plus intéressantes que les macros (surtout en combinaison avec les template), et pourtant dans certains bouts de code on voit encore des macros.
La dernière fois que j'ai vu des macros utilisées, c'était soit dans du code C, soit dans des framework de test, cela dit.
Reste donc que l'usage d'import de header, et je suis d'accord pour dire que ça serait pas mal qu'il saute.
Tu peux. Il suffit qu'elle soit déjà définie quand elle est utilisée. Ca m'arrive de faire des petites structures templates internes à un fichier, que je n'expose pas publiquement ça aucun intérêt.
Je me doute que tu le sais, mais ce n'est pas nécessairement le cas de tous, je me permets donc cette clarification :)
Vrai. C'est lent.
Je me demande quelle est la part de responsabilité liée à l'ISO, ceci dit. La plupart des langages qui sortent, au final, n'ont qu'une implémentation de référence, pas de normalisation réelle.
Hors, cette standardisation officielle et internationale est une force de C++ pour moi.
Du coup, je comparerai la lenteur d'évolution de C++ à Debian: c'est lent et vieux, c'est vrai, mais le fait que ça n'aille pas trop vite semble avoir pour conséquence que la maintenance est plus simple pour les utilisateurs (un vieux code C++ compile sur un compilo moderne sans trop de soucis, et une Debian peut être up/down gradée de la même manière). Pas la création d'un système fonctionnel, sa maintenance, j'insiste.
Marrant, c'est justement pour la gestion de la mémoire que j'apprécie le C++. Parce qu'en C++, si je veux utiliser un GC, je peux. Si je veux utiliser des pointeurs intelligents, je peux. Si je veux utiliser des pointeurs nus, je peux encore!
J'ai le choix, bon sang, et c'est bien d'avoir le choix, de la meme manière que c'est bien de pouvoir choisir entre windows, mac OS, Debian, voidlinux, FreeBSD, OpenBSD, etc.
C'est perfectible, bien sûr, mais quand je lis qu'il est obligatoire d'utiliser des pointeurs nus en C++, je comprend que l'auteur de la phrase lue ne connaît pas le C++ (je ne dis pas l'avoir lue ici, mais j'ai déjà lu ça, plus d'une fois).
Sincèrement, avec la STL, les références et les itérateurs, les pointeurs nu ne sont simplement qu'une façon de s'interfacer avec le C ou les vieilles bibliothèques. Rien de plus.
A noter un repproche que je fais aux pointeurs intelligents standard: ils ne savent gérer que la mémoire, alors que ce n'est qu'une seule des ressources que l'on peut manipuler (alors qu'un descripteur de fichier UNIX est un int, par exemple). Sans parler du fait qu'ils aient un overhead pour moi inutile (évident pour shared_ptr, moins pour unique_ptr, mais le fait est qu'un pointeur pour stocker l'@ du destructeur est maintenu et testé, alors que ça aurait pu être passé en template. Mais j'imagine que certains ont l'usage de modifier le destructeur au runtime?).
Maintenant, oui, je l'admets: utiliser des références ou des itérateurs ne protège pas contre les segfaults, et il n'y a rien à ma connaissance en C++ pour gérer ça. C'est un des points qui font que je veux me mettre à Rust, un jour.
Le C++ ne permets pas non plus, à ma connaissance, de vérification sur les under/over-flow d'entier. C'est un problème, pour moi, vraiment. D'un autre côté, ça permets un code plus léger et plus rapide, parce que si à chaque addition on devait faire une vérification à l'exécution, c'est du code en plus à exécuter, de la lenteur.
Ce que j'apprécierai vraiment, ça serait de pouvoir faire ça, uniquement pendant le debug.
Et ça n'arrivera jamais, j'espère. Si une telle fonction devait exister, elle aurait plutôt sa place dans les algorithmes, autrement dit, ce serait
std::delete_at( iterator it, container& cont );ou un truc de goût là.Les APIs de la STL sont déjà assez moyennes comme ça, à mon avis (à la fois trop riches et pas assez: trop riches parce que, par exemple, std::vector::insert pourrait être implémenté en dehors du conteneur (avec une combinaison de std::move&std::inserter par exemple) alors qu'il est difficile de connaitre le cout mémoire réel d'un conteneur (pour vector c'est faisable, mais pour std::map?) ).
En tout cas, c'est marrant, dans la liste des défauts de la STL, j'aurai pensé voir std::string au moins une fois (parce qu'elle s'interface relativement mal avec le reste de la lib standard, et que pour une gestion de chaine de caractères, ça ne permets meme pas de diviser facilement... bref je la trouve bancale.).
Comme tout les langages sauf le C, en fait. Je pense que l'on devrait arrêter de ce soucier du C, franchement.
Je pense qu'une bonne part des emmerdes du C++ viennent du C.
Personnellement, si j'apprécie énormément le C++, c'est parce que c'est un langage qui donne le choix.
Il me donne le choix d'utiliser les template.
Il me donne le choix d'utiliser le modèle mémoire que je veux (GC, pointeurs intelligents, pointeurs nu. Bon, ok, pour le GC il n'y a rien dans la lib standard, probablement parce que la culture C++ préfère la RAII).
Il me donne le choix d'utiliser la RTTI (j'inclue dedans les méthodes virtuelles).
Il me donne le choix de faire de l'héritage multiple et même en diamant (ça m'est déjà arrivé une fois de m'en servir).
Il me donne le choix d'utiliser les exceptions (à condition de se passer de la STL, certes).
Rien n'est obligatoire, il faut choisir ce que l'on utilise. Pour certains, c'est un défaut. Pour moi, c'est une force.
Pour refaire le parallèle avec les distributions Linux: pour moi, l'apparition de Devuan, d'Ubuntu, d'Archlinux, et j'en oublie, ce sont de bonnes choses, parce que ça donne le choix.
Alors bien sûr, avoir le choix implique de prendre des décisions, mais pour moi c'est un peu le coeur de métier d'un développeur, de prendre des décisions.
Mais ce n'est pas parce que j'aime beaucoup C++ que je dis qu'il n'a aucun défaut. Seulement, à l'heure actuelle, je ne vois que Rust pour le remplacer, et il est encore jeune, on n'a pas encore eu le temps de voir comment il vieillit.
Avant de dire que Rust peut remplacer C++, il faudra au moins 5 ans d'écart entre la sortie de sa 1ère version stable et l'heure du jugement, justement pour avoir du recul.
On n'a aucun recul sur Rust, contrairement à C++ ou l'on parle de près de 20 ans ( ~18 de standard ISO).