Faut‐il continuer à apprendre le C++ ?

Posté par  (site web personnel) . Édité par Davy Defaud, gbdivers, Ontologia, Nicolas Boulay, abriotde, freem, Benoît Sibaud, lmg HS, Snark, Guillaum, khivapia, whity, gusterhack, barmic, Cilyan Olowen, palm123, esdeem, Nils Ratusznik, ZeroHeure, bayo, Thomas Douillard, alkino, Anthony Jaguenaud, baobab, chicco, martoni, jc, wilk, Pascal Obry, Jona, lolop, nnamrok et lovasoa. Modéré par Nils Ratusznik. Licence CC By‑SA.
Étiquettes :
58
27
juil.
2018
C et C++

Le C++ est un langage qui a vu ses spécifications s’amonceler et se stratifier au cours des années. Il est encore très utilisé. Mais face à des concurrents comme Rust ou Go, quelle est sa place dans un environnement qui évolue ?

Cette dépêche qui a nécessité beaucoup de discussions, aura, vous le verrez, une forme un peu particulière.

Sommaire

Origine de cette dépêche

La dépêche C++17, genèse d’une version mineure a reçu 227 commentaires représentant un volume dix fois supérieur à la dépêche elle‐même. Et ces commentaires, très souvent bien écrits, nourrissent des trolls bien velus !

L’idée de créer cette dépêche vient de deux constats :

  1. l’énergie dépensée et les nombreuses heures consacrées à rédiger ces 227 commentaires est phénoménale ;
  2. en revanche, la lecture de tous ces commentaires est laborieuse.

Avec le recul, nous aurions pu concentrer tout cet investissement dans une dépêche collaborative du style « Aujourd’hui, est‐il pertinent de choisir le C++ pour une nouvelle application ? », afin de structurer et consolider tous les arguments dispersés au fil des commentaires.

Objectif de cette dépêche

Cette dépêche propose un sujet bien plus large : « Faut‐il continuer à apprendre le C++ ? ». Et de nombreux commentaires de qualité de la dépêche C++17, genèse d’une version mineure méritent d’être copiés, améliorés ou fusionnés ici. Malheureusement, ceux‐ci sont rarement sous licence compatible CC-BY-SA 4.0.

gbdivers proposition

Faire un article synthétique sur cette question n’est pas simple. En effet, le choix d’un langage pour un projet dépend énormément du contexte, en particulier le domaine d’application et l’environnement technique existant. Dans les discussions sur le choix d’un langage, certains avanceront des critères, mais ceux‐ci seront considérés par d’autres comme non pertinents.

Même des critères « historiques » du C++ ne sont plus des arguments suffisants dans de nombreux projets. Par exemple, le C++ est souvent évoqué pour ses performances lorsque l’on veut créer un jeu vidéo. Mais de nos jours, avec la puissance disponible sur le moindre appareil et la qualité des moteurs de jeux, il n’est plus pertinent que tous ceux qui veulent travailler dans les jeux vidéo apprennent le C++.

De même, si l’on prend un domaine dans lequel le C++ est généralement déconseillé, comme le développement Web. Et, cependant, de très grosses entreprises Web comme Google ou Facebook utilisent le C++.

Il convient donc de revenir dans un premier temps sur les critères à prendre en compte dans le choix d’un langage, puis de voir les qualités et défauts du C++ sur ces critères.

Dialogue sur divers aspects des enjeux brulants de C++ en 2018

La normalisation, un processus trop lent ? Et quid de la nouvelle norme ISO vs mise à jour d’un logiciel (compilo, VM, etc.).

Nicolas Boulay : Vu la base de code existante et vu le nombre de parties prenantes, une prise de décision est forcément lente, vu les enjeux par chacune des parties. De toute façon, ce n’est pas vraiment la rapidité des changements de la norme qui sont impactants, c’est la vitesse de conformité des compilateurs.
Si c’est lent, les fonctionnalités vont prendre du retard avec les langages comme C#, Rust, etc., surtout s’ils continuent à avancer. Si c’est rapide, il faut accompagner le changement, pour ne pas dérouter les codeurs. Il y a risque de ne pas utiliser les nouveautés par peur d’instabilité, d’immaturité du code, ou de méconnaissance.

gbdivers : Oui, je suis d’accord. À mon avis, c’est avec ce type d’arguments que l’article sera intéressant. Les lecteurs ne connaissent pas forcément le contexte et les contraintes du C++, donc c’est bien de donner le contexte, puis les avantages et défauts des choix possibles. Libre à eux ensuite de se faire leur propre opinion.

Anthony J. : Les industriels. Je pense que pour de nombreux industriels utilisant le C++ depuis plus de vingt ans, les besoins de rétrocompatibilité restent très importants.

gbdivers : Bonne question. Ont‐ils besoin de rétrocompatibilité sur les évolutions du C++, ou ont‐ils simplement besoin de ne pas suivre les évolutions ? On a au moins deux choix possibles : le choix entre suivre les évolutions du langage et mettre à jour son code, ou ne pas mettre à jour son code et ne pas suivre les évolutions du langage. Faut‐il avoir un troisième choix : suivre les évolutions et ne pas mettre à jour son code ? Est‐ce que ce troisième choix est intéressant ou pertinent pour les industriels ? Pour le C++ ?
Un exemple concret : dans ma boîte, ils ont choisi il y a trois ou quatre ans de mettre à jour le code et de ne plus assurer la rétrocompatibilité. Et, depuis, on est sur le C++11 (il n’est pas prévu que l’on passe au C++14 ou 17 pour le moment). Et l’on garantit la compatibilité du code sur une liste définie de compilateurs et de versions de compilateurs. C’était un choix stratégique à faire entre obliger nos clients à mettre à jour leur code (et donc potentiellement perdre des clients) ou continuer à assurer la compatibilité (avec les coûts de développement que cela implique).

gbdivers : Standard vs lib ? Pourquoi ne pas mettre toutes les fonctionnalités dans le standard. Exemple de regex, network, Unicode.

Nicolas Boulay : Une uniformisation serait souhaitable .

gbdivers : Idem. Quels sont les avantages et défauts d’une uniformisation ? D’une standardisation ? D’une standardisation ISO ? Vaut‐il mieux une fonctionnalité dans le standard ou dans une lib ? Quelles sont les conséquences de l’un ou l’autre choix ?

Nicolas Boulay : L’uniformisation permet tous les avantages de la standardisation. Si l’on parle de la lib standard, d’un point de vue utilisateur cela ne change rien.

gbdivers : L’antithèse est que l’uniformisation peut figer (dans le sens péjoratif, c.‐à‐d. bloquer les évolutions futures) une API ou des fonctionnalités. Prenons par exemple le protocole HTTP. Si le standard C++ fournit une API pour cela, il faut que l’API puisse suivre les évolutions. Sinon, s’il y a une mise à jour de HTTP, soit on continue à utiliser l’API pas à jour du C++, soit on utilise une API à jour fournie par une bibliothèque. Dans les deux cas, c’est problématique de fournir une API figée dans le standard. Il faut que l’API soit indépendante de la version du protocole, de façon à ce que les compilateurs puissent fournir des mises à jour du protocole sans que le standard ne change.

freem : Il y a aussi le problème de la rétro‐compatibilité. Par exemple, admettons que l’on intègre (reproche régulièrement lu et entendu) une section pour créer des IHM graphiques. Ce que le développeur voudra, c’est un truc qui soit stable au niveau UX et intégré dans les systèmes d’exploitation (Windows, macOS, GTK+, Qt…). Vu que celles‐ci évoluent au fil du temps, tant dans leurs API que dans leurs architectures, le risque d’avoir une partie du standard qui soit instable (au niveau API du moins) serait élevé.

gbdivers : Les nouveaux langages sont‐ils meilleurs que les anciens langages ? De grands débats apparaissent : const vs mutable, ref vs copie, explicit vs implicit.

Nicolas Boulay : Il ne faut pas oublier l’apport de la recherche dans le domaine : le temps de dev directement lié aux nombres de lignes de code (o(L1.2 ), cf. Cocomo). La liste des bogues les plus fréquents en C et C++ qui sont toujours les mêmes (NULL, off by one, débordement de tampon, allocation et désallocation mémoire, mauvaise gestion d’erreur, etc.), et qui n’existe pas dans les langages plus récents.
gbdivers :
L’argument sur les avantages que peut apporter un nouveau langage est à rapprocher du coup au problème de rétro‐compatibilité.
Je ne connais pas Cocomo.
freem : Cocomo est une méthode qui consiste à chiffrer le coût d’un projet en fonction de son nombre de lignes de code. C’est, euh, pas très moderne (né en 1970) et, de ce que j’en sais, totalement bancal : en C++, il est possible d’utiliser de l’objet, l’encapsulation est très encouragée par les mécanismes (RAII, move semantic, généricité) et donc, pour contribuer à un code C++ « idéal », le coût peut être très faible malgré un grand nombre de lignes de code, tant que l’on sait dans quelle couche on se situe. Par exemple, pour un bogue de mémoire (erreur de segmentation, débordement de tampon) il est peu pertinent d’attaquer le code haut niveau, qui peut représenter le plus gros (avec plein de règles métier ajoutées au fil du temps). Personnellement, de ce que je sais, la complexité cyclomatique de McCabe, dont j’ai personnellement tirée pas mal de leçons, me semble plus pertinente que le nombre de lignes pour estimer la complexité d’un code (je vous renvoie à l’outil cccc, présent dans toutes les bonnes distros). Le problème des underflows et overflows pourrait être contrecarré en encapsulant les types natifs dans des classes. Le problème, c’est que le coût à l’exécution serait non négligeable. Pour la constance, je rappelle que, par défaut, les paramètres d’une fonction en C++ sont invisibles par l’appelant : passage par copie, sauf si l’on passe une référence. Du coup, on choisit volontairement un type mutable (dont c’est le rôle). Quand on a besoin d’une référence constante, c’est en fait un contournement dû au fait que la copie est lente. Ce qui est, d’ailleurs, bien moins vrai depuis 2011. Ici encore, comme pour les flow errors, il serait possible d’implémenter une solution plus propre à base de pointeurs intelligents (weak_ptr dédié à unique_ptr, qui pourrait interdire l’altération de la variable cible).
Ici, je dirais que les erreurs les plus communes du « C/C++ » sont dues au fait que, en C++, on a tendance à programmer comme en C, comme le montre si bien la fusion de tant de gens : « C/C++ »…

gbdivers : Peut‐on envisager de casser la rétrocompatibilité ? L’exemple du Python 2 vs Python 3 montre l’étendue des problèmes que cela implique…

Nicolas Boulay : À ne surtout pas faire, cela revient à créer un nouveau langage (sauf à être compatible binaire, avec un drapeau dans le fichier, comme hhack de Facebook).
gbdivers : Idem, prise de position. Si on le fait, il y aura telles conséquences. Si on le fait pas, il y aura telles autres conséquences.
Nicolas Boulay: Avec un drapeau, vous gardez la rétrocompatibilité, et vous nettoyez en même temps le langage pour le futur. Si vous cassez la compatibilité, vous inventez un nouveau langage, il faut donc convaincre à migrer. Ce qui ne se fera pas. Pour migrer à un nouveau langage, il faut de sacrée bonnes raisons. C++ n-1 sera toujours « good enough » pour beaucoup.
gbdivers : Pour le drapeau, je sais pas trop. Toujours est‐il que je suis d’accord. Je pense que l’exemple de Python 2 vs Python 3 (et, plus précisément, la lenteur d’adoption de Python 3) est un bon exemple concret que ne pas assurer la rétro‐compatibilité du code peut ralentir l’adoption de la mise à jour.
freem : Compte tenu de la vitesse d’évolution du C++, si l’on commence à casser la compatibilité, les compétences et le code accumulés entre deux versions seront potentiellement perdus. Le coût de formation pour avoir un développeur C++ compétent est déjà élevé, si en plus il faut le réinvestir régulièrement juste sur une « lubie » du comité, on risque surtout de voir un retour du C, ce qui serait à mon humble avis une terrible régression (le C a bien moins de fonctionnalités, tout en offrant des performances comparables et moins de sécurité).
Pour parenthèses, l’obsolescence d’auto_ptr a dû être faite dans la douleur et dans le constat que c’était de toute façon peu utilisé (il serait intéressant de « grepper » auto_ptr dans la base de code des paquets Debian, par rapport au nombre de projets écrits en C++, je suis certain que c’est ultra‐minoritaire. Personnellement, je n’ai souvenir que d’un seul projet qui l’ait utilisé, et je ne me souviens même plus du nom…). J’ai un peu plus de doutes sur l’obsolescence des bind1st/2nd qui, bien qu’horribles à utiliser, ne me semblent pas avoir de raisons liées à des bogues.

gbdivers : Complexe ? Oh oui ! Multiplication des syntaxes, syntaxes pas forcément intuitives.

Nicolas Boulay : Nécessité d’une vérification des bonnes pratiques.
gbdivers : C’est un point auquel je n’avais pas pensé et qui serait intéressant d’aborder. Le C++ n’est pas simplement un langage, c’est un écosystème, qui doit être considéré dans son ensemble : compilateurs, bibliothèques, outils de vérifications, bonnes pratiques, apprentissage.
freem : La compatibilité avec le C est l’un des arguments forts pour pousser le C++ et la prise en charge des syntaxes du C est nécessaire pour cela (je pense surtout aux casts). Ceci dit, les bons compilateurs sont capables de prévenir de ce genre de choses. Il est possible de convertir partiellement en C++ un code C qui, par défaut, n’offre strictement aucun contrôle automatique de la bonne gestion d’une ressource, ce qui réduit les temps et les coûts de migration de C vers C++ de façon drastique. Mais il est vrai qu’il n’existe que trop peu d’outils et de documentations claires (leur étant liés) favorisant la vérification automatique des bonnes pratiques, ou même d’un simple coding style.
On peut cependant regretter qu’il soit difficile de s’assurer que son code n’utilise pas par erreur une fonctionnalité que l’on a voulu bannir pour différentes raisons (les exceptions, les templates, la RTTI, etc.).

gbdivers : Passage complexe entre langages.

freem : Si l’on parle d’utiliser plusieurs langages dans un projet, justement, c’est bien plus simple en C++ qu’en C# ou Java : le langage commun utilisé étant le C, a priori, et le C++ étant compatible avec une grande partie du C, il n’y a pas besoin de définir des points d’entrée comme en Java. J’ai un très mauvais souvenir également de l’usage de C en C#, où il faut concrètement lutter pour que le compilateur accepte de compiler du code « unsafe ».
En C++, il suffit d’encapsuler la ressource, ce qui est très simple grâce à, je me répète, la RAII.
En revanche, si l’on parle d’apprendre le C++ en venant d’un autre langage, c’est vrai que ce n’est pas trivial, surtout si l’on veut jouer avec les couches basses.

gbdivers : L’apprentissage du C++ est réputé difficile…

lmghs : J’imagine qu’on liste ici les trois niveaux : historique (mémoire à la main, pays magique où les erreurs n’existent pas), 98-RAII (que je continue à appeler moderne, si si), 11-RAII (où l’on introduit les trucs orientés utilisateur et « pythonisants » dès le début : auto, for-range-loop, lambdas pour algorithmes standards…).
Là, on rejoint la problématique de ce que l’industrie attend. Je suis encore en train de donner une formation cette semaine, et savoir si les formés vont travailler sur une CentOS 6, ou pire 5, plutôt qu’une 7, guide ce que je peux leur enseigner pour répondre à leurs besoins immédiats. Ce qui ne m’empêche pas de faire du teasing en revanche. Dans un cas, je vais parler d’auto_ptr et des boost::ptr_vector, tandis que dans l’autre, vector<unique_ptr<>> me suffit. Même problématique avec les projets en maintenance.
Il y a aussi la question des publics entre un dev futur informaticien, un gars en embarqué, un scientifique ou des gars en formation interne dans une SSII, les choix et possibilités ne sont pas toujours les mêmes.

gbdivers : Conclusion : est‐ce que le C++ est fini ? Non !

gbdivers : En fait, on peut même répondre à cette question (et à la question du titre) dès l’introduction. Pour directement mettre au clair les trolls : est‐ce que quelqu’un pense que le C++ aura disparu dans dix ans ? La réponse est non (même les trolls pourraient difficilement répondre oui a cette question. Même le COBOL est encore utilisé).

Le C++ en bref

Le C++ est un vieux langage (bientôt 40 ans) hérité du langage C avec lequel il entretient une compatibilité.

gbdivers : Compatibilité de syntaxe, mais divergence dans la façon de concevoir les choses. Cela rejoint un des points donnés plus haut : le passage entre plusieurs langages. Quand un dev connaît et utilise plusieurs langages, il ne maîtrise pas les spécificités de chaque concept dans chaque langage (un même concept peut avoir plusieurs interprétations proches, mais pas exactement identique).
Par exemple, pour le C vs C++, il y a des syntaxes communes, mais la façon de penser un code est complètement différente (gestion des ressources, des erreurs, etc.). Cela a donc un coût de passer d’un langage à un autre.
Anthony J. : La compatibilité de syntaxe n’est plus possible depuis déjà pas mal de temps : conversion pointeur → void* OK (c/c++) ; mais void* → type* OK(c)/KO(c++), les tableaux de taille dynamique à l’exécution (C99).
La fonction foo() => foo(…) en C, mais foo(void) en C++.
Un article sur le sujet ici.
gbdivers : Je n’ai pas suivi le C11, si ces syntaxes sont encore valides ? A priori, le C++11 (ou 14 ?) est censé se baser sur le C11, donc il est possible que ce ne soit pas compatible avec le C99. Mais, dans ce cas, le C actuel n’est pas non plus compatible avec le C99.
Du coup, au lieu de dire « il entretient une compatibilité », il faut préciser que la compatibilité syntaxique est limitée et la compatibilité « conceptuelle » diverge complètement.
freem : La compatibilité est limitée de facto par le fait que le C++ réserve plus de mots que le C. Un code en C peut, par exemple, très bien utiliser this, mais un tel code ne pourra pas compiler en C++ (mot réservé pour désigner l’instance de l’objet dont on appelle la méthode, le cas échéant). Il me semble qu’il existait d’autres points, mais je ne m’en souviens pas.

De tout ce long historique, le C++ a évolué du mieux possible entre paradigmes de programmation et nouveaux besoins. Au final, sa syntaxe évolue lentement, est complexe, bourrée de subtilités et lente à compiler.

gbdivers : Aborder le problème de l’enseignement du C++ ? Le C++ est permissif, il y a de multiples syntaxes pour faire la même chose. Beaucoup de cours essaient d’apprendre plusieurs syntaxes — en commençant par les plus obsolètes, en général — sans donner de hiérarchie d’importance à l’apprenant. Résultat : complexité à comprendre et moins bonne maîtrise en profondeur).
freem : Au sujet de la lenteur de compilation, le problème est‐il vraiment lié au langage, ou à l’implémentation de la STL et du compilateur ? Je me rappelle très bien le jour ou j’ai découvert Clang : la mémoire consommée par une compilation a été divisée par deux et les temps de compilation du projet sur lequel je travaillais par trois. Je n’ai pas fait de tests de vitesse (moins besoin, meilleur matos) entre la STL de GCC et celle de Clang, mais il est clair que ces derniers incluent beaucoup moins de fichiers, l’arborescence et les chaînes d’héritages sont bien moins complexes. J’ai vu au fil des années pas mal de messages sur le Net indiquant que GCC compilait également plus lentement que Visual C++. Alors ce problème de lenteur, ne serait‐il pas dû, au final, à un problème de qualité de GCC (passage à enlever, sauf si publication un trolldi, hi hi) ? Concrètement, GCC utilisait un ramasse‐miettes en C et, il y a quelques années (après ma découverte de Clang en tout cas), on a parlé de réimplémenter certains passages en C++, justement pour réduire la nécessité de ce ramasse‐miettes.

Mais c’est aussi un langage permettant des optimisations de folie (costless abstraction). Le C++ est utilisé au quotidien, ne serait‐ce que la plupart des environnements graphiques et des navigateurs Web (pour flâner sur LinuxFr.org). Et le C++ continuera pour encore de nombreuses années à être utilisé en production, notamment pour les applications critiques.

Le C++ n’est pas mourant. Au contraire, le C++ connait un vif intérêt depuis C++11.
De plus en plus de personnes s’investissent à améliorer davantage ce langage, comme sur la vitesse de compilation qui devrait être grandement améliorée avec C++20.

Alors, faut‐il tout effacer et recommencer un nouveau langage qui, par design, prend en compte les contraintes de concurrence (multicœur, NUMA) et de montée en charge (scalability) ? Des langages de programmation tentent d’obtenir des performances similaires avec une syntaxe expressive et concise.

freem : Inventer un nouveau langage from scratch, ne serait‐ce pas un peu comme reprendre un projet from scratch ? On perd l’historique, ce qui peut être bien (plus simple de faire une meilleure architecture) et mal (on perd les correctifs de bogues).

La puissance du C++

Les points positifs qui démarquent le C++ sont sa programmation générique et sa méta‐programmation qui permettent d’avoir des abstractions sans pénalité de performance. Mais aussi les possibilités de libération déterministe et implicite de n’importe quel type de ressource au travers du RAII, si on le compare au C — les autres langages à exceptions disposent d’un ramasse‐miettes (garbage collector) et suivent le dispose pattern pour les autres ressources, voire offrent des facilités équivalentes au RAII (try‐with‐resources en Java 7, using en C#, etc.). Certains estiment que si l’on ne profite pas de ces fonctionnalités, mieux vaut utiliser un autre langage.

freem : Mais justement : les ramasse‐miettes, ça pose des problèmes de performance que la RAII n’a pas. Par exemple, une connexion à une base de données en Java, si l’on ne la ferme pas manuellement, on risque de faire exploser la charge du SGBD tant qu’il ne passe pas pendant trop longtemps. On s’expose aussi à des ralentissements conséquents quand le ramasse‐miettes passe s’il a beaucoup de travail à faire. Choses qui auraient pu être faites à des moments moins critiques. Certaines ressources peuvent aussi se retrouver à manquer si l’on en alloue trop vite pour que le ramasse‐miettes nettoie tout… Bref, le ramasse‐miettes à ses avantages (pas besoin de s’occuper de gérer les choses) mais implique de maîtriser l’outil, sans quoi des problèmes différents arrivent.

Les alternatives

  • C ;
  • Rust ;
  • Go ;
  • Dart ;
  • Elixir ;
  • Phoenix ;
  • Pony ;
  • D ;
  • OCaml ;
  • Haskell ;
  • Ada ;
  • etc.

Parmi ces langages, en excluant ceux qui ne sont qu’interprétés et ceux qui utilisent un ramasse‐miettes, les seuls qui pourraient remplacer C++ à performances égales sont donc : C, Rust et D.

gbdivers : Pourquoi exclure les interprétés et les ramasse‐miettes ? Ça serait l’occasion de tordre le cou a un mauvais argument sur le C++ : les performances. On entend souvent « Je veux faire des jeux vidéo, on m’a dit qu’il fallait les faire en C++ pour les perfs ». Alors qu’en pratique, les perfs ne sont pas critiques pour beaucoup d’applis et que les perfs dépendent aussi beaucoup de l’algorithme et des structures de données. Il vaut mieux n’importe quel langage correctement utilisé que le C++ mal utilisé.

wilk : Peut‐être préciser ce que l’on entend par performance. Ce n’est pas la même chose au niveau d’une interface graphique, d’un serveur, d’un mobile, etc.
khivapia : « Il vaut mieux n’importe quel langage correctement utilisé que le C++ mal utilisé » : argument valable pour tous les langages. Pour tirer le maximum de perfs de la machine physique, il ne faut pas de ramasse‐miettes (il n’y en a pas de temps réel et parallèle ; donc, s’il se réveille au milieu du jeu d’action, paf, grosse latence ! ) ni, bien sûr, de langage interprété (perte de perfs liées à la machine virtuelle).
gbdivers : Je dis que « les performances du C++ ne sont pas forcement un critère pertinent », vous me répondiez « le C++ est plus performant ». OK, mais cela ne change rien à mon argument.

Pour détailler : écrire du code performant a un coût. Beaucoup n’ont pas le temps et les compétences pour mettre en place les méthodes permettant d’optimiser correctement le code. On peut écrire en C++ un code qui sera plus performant qu’un ramasse‐miettes, mais on peut également écrire pire.
Un exemple concret : http://0x80.pl/articles/simd-strfind.html. Indéniablement, on peut avoir de meilleures performances si l’on sait tirer le meilleur de la machine. Mais combien sont capables de faire cela ? Et a‐t‐on le temps de faire cela sur un vrai projet ? C’est dans ce sens là que je dis que les performances ne sont pas toujours un bon critère.
Nicolas Boulay : Pour prendre un exemple, je saurais faire ce genre d’optimisation, mais seul C/C++ me donne accès aux fonctionnalités pour faire le travail. Avec les autres langages, c’est simplement hors de portée, ou beaucoup plus complexe (assembleur ou appels de fonctions externes).
gbdivers : Oui, mais tu reconnaîtras sans problème, je pense, que tous ceux qui veulent faire du C++ n’ont pas forcement ces compétences ou le temps de faire correctement les choses pour un projet donné (deadlines).
L’argument « faire du C++ pour les performances » n’est donc pas valide seul. Il faut regarder le contexte du projet, les moyens disponibles, les compétences, etc. C’est un problème que l’on voit souvent sur les forums, où les débutants arrivent et disent « je veux faire un jeu, on m’a conseillé le C++ parce que c’est le plus performant ». Alors qu’en pratique, avec un autre langage, ça ne sera pas moins performant (parce qu’ils ne sont pas capables d’aller chercher les performances du C++).
freem : Je suis d’accord avec gbdivers (je n’arrête pas de lire gdbivers, grrr) : je ne compte plus les push_back dans un vector dans une boucle de taille définie sans appel à réserver au préalable, et c’est bien moins complexe que le lien donné plus haut (pas encore lu, mais il est probable que je ne sache pas tout faire dedans). Je passerai également sur les vectors multiples de même nombre d’éléments utilisés ensemble (cache miss et appels à malloc inutiles). Et ce sont les bases pour écrire un code rapide en C++.
Nicolas Boulay : Tous les moteurs de jeux (Unity3D, etc.) sont écrits en C++, en revanche la logique des jeux elle‐même est en JavaScript, en C#, en Lua… En gros, cela demande moins d’efforts de faire propre avec n’importe quoi d’autre que C++, sauf si les performances sont une absolue nécessité.

Critères pour adopter un nouveau langage

Mais pour qu’un langage soit adopté plusieurs ingrédients sont nécessaires :

  • un gage de pérennité ;
  • la facilité de débogage (déverminage) ;
  • la facilité d’augmenter un programme ;
  • une communauté, des meet‐ups, des entreprises ;
  • une galaxie de sites Web, d’outils divers, des bibliothèques, des tutoriels, de la documentation, etc. ;
  • des performances raisonnables.

Sur ce terrain, le C++ est bien doté avec de très nombreux outils, bibliothèques et communautés.

Popularité du C++

Et toi, chère lectrice, cher lecteur, penses‐tu que les nouvelles fonctionnalités du C++ ne font que compliquer inutilement le langage le plus complexe que l’humanité ait inventé ?
Ou, au contraire, es‐tu persuadé·e que, grâce à ces évolutions, le C++ va progresser dans le classement du TIOBE Index et garder loin derrière des prétendants comme D, Dart, Nim, Rust ou Pony ?

Indice TIOBE de popularité des langages de programmation, la courbe en vert clair représente l’inexorable descente du C++, qui reste quand même en troisième place derrière Java et C, mais devant Python et C#

Autres sources :

lmghs : Autre indicateur : celui d’ohloh qui ne compte pas les recherches sur les moteurs de recherche, mais qui observe l’activité sur les projets FOSS → https://www.openhub.net/languages/compare?language_name%5B%5D=c&language_name%5B%5D=cpp&language_name%5B%5D=python&language_name%5B%5D=java&language_name%5B%5D=rust&language_name%5B%5D=-1&measure=commits.

Questions

  • Faut‐il considérer le C++ comme langage potentiel au développement d’une nouvelle application ?
  • Est‐il pertinent d’apprendre le C++ aujourd’hui ?

Go

Go a été créé par Google parce que la compilation C++ devenait rédhibitoire pour ses applications serveur.

C++ a été initialement créé comme une extension du C, gardant la compatibilité avec lui, et non un pur langage objet. Il y a donc un mélange entre objets et types primitifs (comme dans java). Toutefois, contrairement à Java ou C#, C++ ne fait pas de différences fondamentales entre les types primitifs et les objets définis par l’utilisateur : c’est au programmeur de décider si les types sont copiables, l’usage des références est explicite, l’allocation sur la pile est possible.

Certaines briques « de base », telles que les conteneurs ou les string, sont toutefois arrivées tardivement dans la spécification, ou de manière incomplète. Ainsi, beaucoup de bibliothèques réinventent la roue, ce qui peut mener à des difficultés ou un surcoût (conversions multiples) dans l’interopérabilité entre bibliothèques.

Le compilateur permet de faire de la vraie métaprogrammation. Et c’est réellement utilisé. La métaprogrammation en C++ repose sur un modèle de typage structurel.

En revanche, il n’y a pratiquement aucune aide à la gestion d’erreurs, bien que C++11 ait introduit static_assert. Les messages d’erreurs liés à la métaprogrammation sont souvent particulièrement cryptiques et demandent un certain degré d’habitude ou d’expertise pour être compris, et un degré encore supérieur pour savoir écrire des bibliothèques fortement génériques provoquant des messages d’erreurs intelligibles. Voir à ce sujet la présentation de Roland Block donnée lors de la CppCon 2015 : Pruning Error Messages From Your C++ Template Code [diapos]. À noter toutefois que les progrès récents du côté des compilateurs, tels que g++ ou Clang++, font que les messages d’erreurs sont un peu moins longs qu’avant.

La gestion de la mémoire, et des ressources en général, en C++ est laissée à la charge du développeur. Cela a pendant longtemps abouti à la multiplication des problèmes tels que les fuites mémoires ou l’utilisation après libération, qui se manifestent aujourd’hui en autant de failles de sécurité. Toutefois, C++ fournit maintenant des outils intégrés à la bibliothèque standard, qui suivent le principe de RAII (Ressource Acquisition Is Initialization) pour gérer finement l’utilisation des ressources. Ce principe a été repris et généralisé dans le langage Rust (créé par Mozilla), qui veut se poser en alternative, mais reste aujourd’hui inférieur en termes d’écosystème (SIMD, multicœur / OpenMP, toolkit graphique façon Qt).

D’un autre côté, si C++ trouve un moyen de détecter les vieilles constructions à éviter, que les types somme et le filtrage de type par motif (type pattern matching) est ajouté, que les pointeurs soient vus comme des types somme avec détection des « appels sur NULL » à la compilation, si des conteneurs sont introduits avec des interfaces fold/map/reduce pour réduire les erreurs off‐by‐one lors des parcours, si la compilation est plus rapide (peut‐être avec une gestion multi‐fichier du compilateur), si le modèle mémoire devient plus précis pour gérer les alignements mémoire, l’appartenance des objets en mémoire pour chaque fil d’exécution, et pour un éventuel ramasse‐miettes, C++ est là pour longtemps.

Les spécifications

Tiré du commentaire : https://linuxfr.org/news/c-17-genese-d-une-version-mineure#comment-1676200.

La volonté de compatibilité des différentes versions de la norme pousse le comité de standardisation à ajouter des parties plutôt qu’à les remplacer. Cela pose plusieurs problèmes :

  • il est possible de voir différentes strates d’un mécanisme dans la spec et il n’existe pas vraiment d’outils pour savoir ce qui est bien ou pas ;
  • le maintien des programmes existant peut être compliqué pour se conformer à la nouvelle bonne pratique ;
  • les différentes bibliothèques utilisées ne sont pas forcément toutes homogènes et peuvent contraindre à utiliser toutes les parties de la spec.

En outre, le comité de normalisation est fermé. Même si le langage est ouvert (son implémentation), les spécifications sont payantes et soumises à des droits. Une aberration qui entraîne parfois des soupçons de corruption ou du moins une volonté d’entretenir une complexité spéciale pour justifier des experts. Ces critiques sont toutefois largement injustifiées, les brouillons des spécifications (quasiment identiques à la version finale) étant en accès libre, et le comité de normalisation s’étant énormément ouvert à la communauté C++ depuis le début des années 2010.

La bibliothèque standard pas homogène

Tiré du commentaire : https://linuxfr.org/news/c-17-genese-d-une-version-mineure#comment-1676200.

La bibliothèque standard est très poussée pour des domaines assez pointus (comme les mathématiques), mais ne propose rien pour des usages très courants comme le multitâche qui est, lui, géré nativement par Rust.

lmghs [Réponse au commentaire — brouillon à retravailler] : La situation a évolué depuis le C++11 qui a introduit les mutex et autre verrous, des fils d’exécution (threads) et des mécanismes pour l’asynchrone. L’asynchrone était assez imparfait et des efforts continus ont été investis dessus au point que les évolutions les plus visibles pour le C++17 concernent les aspects de la concurrence et du parallélisme. On observe une synergie importante avec la bibliothèque open source HPX.

Nicolas Boulay : La méthode lock/thread est une méthode qui engendre un paquet d’erreurs (situation de concurrence [race condition], inversion de priorité, interblocage…), un cerveau humain normal a trop de mal avec ces paradigmes. Ce qui semble marcher est le passage de messages (Erlang, Qt…), surtout si l’on sait faire du « zéro copie » (programmation linéaire).

Des problèmes quotidiens semblent compliqués

Tiré du commentaire : https://linuxfr.org/news/c-17-genese-d-une-version-mineure#comment-1676523.

Des problèmes tout à fait quotidiens (comme le fait de n’inclure qu’une seule fois chaque fichier à la compilation) n’ont pas de solution triviale. Chaque développeur ou chaque projet gère donc cela à sa façon avec potentiellement des erreurs et sans capitalisation au sein de la communauté C++.

La gestion de dépendance, la portabilité, le construction et la reproductibilité

N. D. M. : Paragraphe à travailler, je jette des idées en vrac

La gestion de dépendances en C++ est complexe. il faut pouvoir compiler un logiciel dans un contexte reproductible, qui, dans le meilleur des cas :

  • est indépendant de la machine de compilation et de la machine cible ;
  • garantie que les bibliothèques utilisées seront toujours les mêmes (mêmes numéros de version, mêmes paramètres de compilation) ;
  • que le compilateur utilisé est le même ;
  • que tout cela est portable sur plusieurs systèmes ;
  • que le programme (binaire, répertoire de code source…) peut être livré facilement sur une machine cible non maîtrisée. En gros, qu’il vienne avec ses dépendances.

Ce type de problème est souvent géré dans d’autre langages par des outils de gestion de dépendances, comme en Python avec pip, Haskell avec Stack, etc. Ces outils permettent de construire son programme dans un environnement restreint en fournissant tout ou partie des garanties listées au‐dessus.

À ma connaissance, il n’existe pas d’outil multi‐plate‐forme de ce type en C++. Ainsi, chaque bibliothèque vient avec sa propre méthode de compilation et d’installation non générique et l’empaquetage d’un programme revient souvent à faire soi‐même, à la main, la construction de toutes les dépendances dans un répertoire dédié du projet, ce qui devient fastidieux quand on cherche aussi à s’assurer des numéros de version des outils de compilation utilisées.

lmghs : Il existe conan.io qui veut fédérer les choses, et Nuget sous Windows. À voir où cela va nous mener.

Sous Windows, il n’y a rien de vraiment solide, chaque année voit son lot de gestionnaire de paquets, comme Chocolatey, mais rien de suffisamment robuste ou exhaustif permettant de choisir les versions exactes des bibliothèques et outils.

Sous GNU/Linux, chaque distribution propose son gestionnaire de paquets, garantissant que les dépendances fonctionnent au sein du système. Cependant, si la version de bibliothèque fournie ne correspond pas à celle nécessaire au programme, on en revient à une gestion à la main.

On peut aussi utiliser une technologie de conteneur léger comme Docker et installer une distribution GNU/Linux spécifique avec un ensemble de paquets choisis. Mais cette méthode pose le problème des performances. Or, une des raisons de l’utilisation de C++ étant les performances, on peut se retrouver bloqué [citation/link needed].

freem : Je ne comprends plus là… On parle de construire l’application (build, compilation, linking ?) ou de l’exécuter ? Qu’il n’existe pas de gestionnaire de dépendances binaires est au contraire une bonne chose pour moi : c’est le boulot du système d’exploitation ça. Enfin, de la distribution autour du système d’exploitation.
Si le problème c’est de détecter les dépendances et de compiler en fonction, alors je trouve que cmake est un très bon candidat, malgré un certain nombre de défauts (il semblerait que ce ne soit pas nickel niveau portabilité, bien que les textes que j’ai lu dans ce sens n’ont pas vraiment argumenté. Il y a aussi le fait que le système de construction ne puisse être promené d’un dossier à l’autre [usage de chemins absolus dans le Makefile généré]).

Avantages du C++ sur les autres langages

Le C++ a malgré tout des avantages que l’on ne retrouve dans aucun autre ou pratiquement :

  • une manipulation bas niveau voire très bas niveau (du fait de sa proximité avec le langage C, aujourd’hui majoritairement utilisé dans les microcontrôleurs à la place de l’assembleur) qui permet des optimisations très fines (on peut même y intégrer de l’assembleur) ; il tient cette puissance de sa très forte proximité dans son fonctionnement avec l’ordinateur (au moins son architecture de von Neumann, les machines actuelles ont seulement l’apparence de machines de von Neumann, mais si l’on veut des performances, il faut aller plus loin) ;
  • il a évolué plus que tout autre langage en restant extrêmement rétro‐compatible, cela lui apporte :
    • un gage de stabilité (le code a de forte chance de compiler avec la prochaine version de C++) qui rassure les responsables des logiciels,
    • une capacité haut niveau tout en restant extrêmement performant qui n’a pas d’équivalent ; c’est ce que lui envient, entre autres, le Go ou le Rust ;
  • les systèmes d’exploitation étant écrits en C/C++, il est le langage pour parler nativement au système et donc efficacement, profitant de ces avantages, de nombreuses bibliothèques système ou bas niveau sont aussi en C ou C++ ;
  • l’écosystème C++ est riche de nombreuses bibliothèques inévitables dans certains domaines ; par exemple, de nombreux formats de fichiers et utilitaires de l’industrie du cinéma, tel que OpenEXR, OpenFX, OpenColorIO, OpenImageIO, Alembic, OpenVDB, OpenEXRID, etc., sont fournis sous la forme de bibliothèques C++. Bien que des bibliothèques de liaison (bindings) vers d’autres langages existent, celles‐ci ne garantissent pas forcement une compatibilité parfaite, aussi bien en termes de fonctionnalités que de performances. Par exemple, un tableau dynamique C++ (std::vector) n’est pas forcement compatible au niveau binaire avec son équivalent Rust, imposant la création d’une interface.

Note aux lecteurs‐commentateurs

Je donne des exemples de bibliothèques de cette industrie parce que c’est celle que je connais et c’est actuellement la seule raison qui justifie notre utilisation du C++. D’autre personnes sont invitées à ajouter des exemples venant d’autres industries. De façon amusante, on dit souvent que des langages comme Python servent à faire la glu sur les entrées d’un programme et que le cœur est écrit dans un langage plus « sérieux » type C++. Nous, nous aurions plutôt tendance à vouloir utiliser du Rust ou du Haskell pour le cœur et à utiliser C++ pour la glu et les entrées‐sorties. C’est un point de vue assez amusant et à contre‐courant des idées habituelles.

Et c’est ce point sur les performances tout en étant relativement haut niveau qui fait du C++ un langage que l’on ne peut remplacer dans beaucoup de projets. Les seuls candidats sont des langages aussi très anciens et qui finalement ont moins évolué (Pascal, Fortran…).
Bien souvent, on développe une application dans un langage de haut niveau (Python, PHP, Ruby ou autres). Puis vient un moment où, pour des raisons de performance, on doit réécrire les parties les plus sollicitées. Par exemple, dans notre société, on développe en PHP et awk. Et quand les charges serveurs augmentent, on réimplémente le cœur en C/C++ et on garde une couche Bash ou PHP au‐dessus. La raison pour laquelle on ne développe pas directement en C/C++, est que son développement et sa maintenance sont plus longs. En C/C++, un bogue peut survenir sur un détail difficile à identifier, là où le PHP, très tolérant, accepte les problèmes. Il y a aussi en C/C++ le risque de ne plus savoir quelle version exacte du code avait servi à compiler la précédente version et donc une difficulté à savoir si lors d’une mise à jour les dernières évolutions du code ne vont pas perturber le fonctionnement en place. Autrement dit, il est difficile de savoir entre deux exécutables quelles sont les modifications apportées.

Le C++ fait aussi son apparition dans l’embarqué. Là où il n’y avait qu’assembleur et C, la suite logique pour des composants toujours plus complexes est le C++. D’abord à travers l’utilisation simple de classes, permettant une meilleure architecture soit par encapsulation, soit par héritage. Mais de plus en plus, on voit arriver des morceaux de la bibliothèque standard, au fur et à mesure que l’embarqué accepte l’allocation dynamique de mémoire.

Une autre force du C++ est la base d’utilisateurs le connaissant, du fait de sa longévité — il date de 1983.

  • # Mon avis personnel

    Posté par  (site web personnel) . Évalué à 10.

    À mon avis, le C++ est un langage complexe et seuls des développeurs déjà un peu expérimentés avec d'autres langages devraient se lancer dans son apprentissage. Pour un premier langage, Python ou Go me semblent plus pertinents : ils permettent de faire beaucoup de choses avec moins de complexité que le C++.

    Après, est-ce que j'irais recommander C++ pour des développeurs avancés ? Ça dépend. Déjà, il y a de fortes chances que ces développeurs soient suffisamment matures pour se passer de mes conseils ;-) Mais ça dépend surtout de ce que l'on veut faire avec. C++, bien maitrisé et avec une bonne connaissance informatique bas-niveau, reste le langage de prédilection quand les performances passent en premier. Mais Rust monte petit à petit en puissance et est déjà plus intéressant que le C++ sur pas mal d'aspects : l'outillage, éviter les problèmes de sécurité dus à la mauvaise gestion de la mémoire, etc.

    • [^] # Re: Mon avis personnel

      Posté par  (Mastodon) . Évalué à 1. Dernière modification le 27 juillet 2018 à 23:43.

      Pour un premier langage, Python ou Go me semblent plus pertinents

      Tu viens de péter mon trollomètre. Dans les universités, les discussions sur les langages de programmation à apprendre à des débutants ressemblent à ça : c'est violent et ça n'avance pas parce que chacun a ses idées préconçues et ses préférences.

      Après, ça dépend ce qu'on veut faire avec un premier langage. Si par exemple un des objectifs est d'apprendre les types (types simples puis structurés), je ne suis pas sûr qu'un langage à typage implicite comme Python soit une bonne idée. Choisir le bon type, c'est aussi de la programmation, et ça se fait beaucoup plus facilement si le type est explicite. Après, si on ne s'intéresse qu'aux structures de contrôle, tous les langages partagent à peu près les mêmes à un chouia près.

      Mon avis, c'est que le C++ est un bon langage pour débuter. Évidemment, pas tout C++, juste ce qu'il faut pour comprendre les concepts de base. Parmi les avantages que je vois : les entrées/sorties sont «faciles» (même si la syntaxe peut paraître bizarre), et quand on commence, c'est un frein en moins ; les fonctions permettent de passer les arguments par valeur ou par référence au choix, et c'est un des rares langages qui le permettent (avec la famille Pascal/Ada) ; le langage est suffisamment peu verbeux au démarrage (je dis ça parce que dans mon université, on utilise Java comme premier langage et il y a tout un tas de trucs que les étudiants écrivent sans les comprendre «public class Toto { public static …»). Sans même utiliser la bibliothèque standard (sauf les entrées/sorties), on peut faire un cours pour débutant sans aucun problème et voir tout ce qu'il y a à voir pour commencer (structures de contrôle, types, fonctions).

      • [^] # Re: Mon avis personnel

        Posté par  (site web personnel) . Évalué à 4.

        Ce que tu dis de C++ est vrai pour Golang.

        "La première sécurité est la liberté"

        • [^] # Re: Mon avis personnel

          Posté par  (site web personnel) . Évalué à 10.

          Tout à fait, j'avais justement cité Go et Python pour ne pas prendre parti sur le fait de commencer par un langage à typage statique ou dynamique. Et si on part sur du typage statique, Go me paraît être un bien meilleur choix que C++ pour commencer. Par exemple, un hello world en C++ fait appel à std::cout, et donc implicitement à la notion de namespace qui n'est intéressante que bien plus tard.

          • [^] # Re: Mon avis personnel

            Posté par  (site web personnel) . Évalué à 10.

            Mouais enfin à mon avis dans :

            std::cout << "hello world" << std::endl;
            la difficulté n'est pas std::cout mais plutôt tout le bordel de chainage d'opérateur qui suit…

            • [^] # Re: Mon avis personnel

              Posté par  . Évalué à 2.

              Ce qui est difficile, c'est de l'implémenter et comprendre comment cela marche, à utiliser je trouve ça aussi (peu) naturel que la séparation par des virgules ou autre. Voir même un poil mieux, mais je ne sais pas à quel point mon "naturel" est biaisé par mes habitudes.

              Après, faire du c++ sans comprendre comment cela marche, ça n'est pas idéal et si une personne en arrive à faire cela, c'est que de toute façon elle n'aura ni les compétences ni la compréhension nécessaires pour tirer partie du langage.

    • [^] # Re: Mon avis personnel

      Posté par  (site web personnel) . Évalué à 8. Dernière modification le 30 juillet 2018 à 21:11.

      Dans le cadre d'une formation de développeur, je trouve qu'un des meilleurs langages pour débuter est l'assembleur sur une petite plate-forme (comme les TI-89/92). Il y a la plupart des composants d'un ordi moderne sans avoir une complexité inutile pour la compréhension. C'est assez facile de faire des choses simples (long, peut-être, mais pas très compliqué). Au moins, on est sûr de comprendre qu'il n'y a rien de magique dans un ordinateur.
      Le passage au C se fait assez facilement et permet de bien saisir le travail d'un compilateur.

      À côté de ça, il est certainement nécessaire d'avoir un langage plus algorithmique, de plus haut niveau.

      Bien sûr, ça prend sûrement plus de temps que de commencer avec un langage de plus haut niveau mais à mon avis les bases seraient parfois mieux comprises.

    • [^] # Re: Mon avis personnel

      Posté par  . Évalué à 3.

      À mon avis, le C++ est un langage complexe et seuls des développeurs déjà un peu expérimentés avec d'autres langages devraient se lancer dans son apprentissage. Pour un premier langage, Python ou Go me semblent plus pertinents : ils permettent de faire beaucoup de choses avec moins de complexité que le C++.

      Moi j'ai eu le chemin inverse, 1 mois de basic, quelques mois de C/C++, un petit passage par l'assembleur (x86), et je suis remonté vers du C++. Puis, j'ai appris d'autres langages.
      Ça s'est très bien passé et avec le recul je trouve que je n'aurais pas fait mieux en commençant par autre chose pour arriver par la suite au c++
      Je dirais donc que cela dépend de la personne, de sa façon d'apprendre et de comprendre les choses.

  • # Rust et SIMD

    Posté par  . Évalué à 8. Dernière modification le 27 juillet 2018 à 14:18.

    [la mise en gras est de moi]

    Ce principe a été repris et généralisé dans le langage Rust (créé par Mozilla), qui veut se poser en alternative, mais aujourd’hui reste inférieur en termes d’écosystème (SIMD, multicore / OpenMP, toolkit graphique façon Qt).

    L'utilisation de SIMD (pour x86 en tout cas) est désormais possible dans Rust stable depuis la version 1.27 sortie au mois de juin.

    C'est un point de détail, mais c'est assez révélateur de la vitesse à laquelle Rust progresse aujourd'hui.

    • [^] # Re: Rust et SIMD

      Posté par  . Évalué à 7.

      Ça, et en plus, je ne vois pas comment sérieusement prétendre que le multicore est à la traîne en Rust.

      Non seulement son modèle mémoire est un atout précieux pour éviter les conflits entre threads, mais ses caractéristiques intrinsèques permettent le développement de libs d'excellente qualité (coucou Rayon !) qui son, ÀMHA, au dessus de ce qu'on peut trouver en C++ (même si j'aimais beaucoup TBB).

      • [^] # Re: Rust et SIMD

        Posté par  (site web personnel) . Évalué à 10. Dernière modification le 27 juillet 2018 à 18:07.

        La dépêche est restée longtemps dans l'espace de rédaction. La partie sur le multicore a probablement été écrite fin 2016 / début 2017, et comme Rust évolue assez rapidement, en 18 mois, ça a pas mal changé.

        • [^] # Re: Rust et SIMD

          Posté par  . Évalué à 8.

          Arrêtez moi si je dis une connerie mais je crois bien que Rust est intrinsèquement conçu depuis le début pour, entre autres, intégrer de la sûreté poussée dans son type system relativement au multithreading. Bien meilleure que le C++, ça va sans dire (le C++ même le plus moderne ne propose jamais de sûreté garantie ou au pire d'identifier explicitement de manière obligatoire les sections de code potentiellement dangereuses, la moindre "mauvaise" utilisation de tout truc ressemblant conceptuellement à une référence engendrera potentiellement un UB, la plupart du temps sans aucune détection statique, et ça inclut par ex les string_view tout neufs)

          Et en pratique, dès que vous avez 2 threads (pour de la concurrence) dans un programme non trivial qui ne propose pas de garantie sur ce point, vous avez des tonnes de data races (sauf théoriquement s'il a été écrit intégralement par des experts de ce domaine, mais cette théorie ne se réalise pas en vrai, de plus ce type de raisonnement permettrait de conclure qu'on peut concevoir n'importe quoi parfaitement avec n'importe quel langage de merde et sans aucune analyse statique automatique, donc étant donné qu'on n'est plus en 1950 je considère que cette approche n'est plus pertinente)

          • [^] # Re: Rust et SIMD

            Posté par  (Mastodon) . Évalué à -4.

            Avoir une garantie de sûreté d'un code threadé avec Rust est un leurre puissant mais qui, au fond, ne sert pas à grand chose. Parce que personne ne devrait lancer un thread directement, tout le monde devrait utiliser un modèle de programmation parallèle. Par exemple, en Go, il y a un modèle de programmation parallèle, certes vieux, certes plein de limites, mais qui fonctionnent et offre des garanties sans avoir à manipuler le moindre thread. Autre exemple, MapReduce qui est un modèle de programmation parallèle (qui ne résout pas tous les problèmes, mais if non plus ne résout pas tous les problèmes séquentiels) où l'utilisateur final n'a pas à se soucie de l'ordonnancement, ça marche. On pourrait aussi parler des futures, du vol de travail, ou de tout un tas d'autres modèles déjà existants et éprouvés et dont on sait comment ça se programme correctement avec des threads.

            Le seul qui doit faire attention, c'est celui qui va implémenter le modèle de programmation parallèle par dessus les threads, mais a priori lui il sait ce qu'il fait, il peut tout vérifier de son côté (soit directement, soit à l'aide d'un outil, soit parce que comme Rust le compilateur va lui dire que c'est bon). Mais ça fait quand même peu de monde qui a une réelle utilité de cet outil de mon point de vue.

            • [^] # Re: Rust et SIMD

              Posté par  (site web personnel) . Évalué à 10.

              Par exemple, en Go, il y a un modèle de programmation parallèle, certes vieux, certes plein de limites, mais qui fonctionnent et offre des garanties sans avoir à manipuler le moindre thread.

              De quelles garanties tu parles ?

              Le modèle de programmation parallèle de Go est intéressant mais il ne propose pas les mêmes garanties que le typage de Rust. Par exemple, ce programme compile et le résultat dépend d'une race condition : il peut afficher ["foo" "qux" "baz"] ou ["foo" "bar" "baz"].

              package main

import "fmt"

func main() {
    c := make(chan []string)

    go func() {
        a := []string{"foo", "bar", "baz"}
        c <- a
        a[1] = "qux"
    }()

    b := <-c
    fmt.Printf("%q\n", b)
}

              En rust, ce n'est pas possible de compiler un programme avec ce comportement. Il faudrait dire si le tableau sous-jacent au slice a est modifiable (mutable) et, si c'est le cas, les autres contextes d'exécution ne peuvent pas du tout y accéder. Ou alors, il n'est pas modifiable et peut-être partagé entre plusieurs contextes d'exécution. Si on veut pouvoir modifier le tableau dans un contexte et y accéder depuis un autre contexte, il faut en faire une copie, ce qui résout le problème de la race condition.

              En pratique, c'est un problème que je rencontre de temps en temps sur cozy-stack (la partie de Cozy Cloud écrite en Go) et je considère que c'est une faiblesse de Go. Il y a un outil pour détecter les race conditions en Go, race detector, mais je ne le trouve pas très efficace. À l'inverse, le modèle de Rust est plus sûr mais il est plus contraignant (on perd pas mal de temps à se battre avec les types, surtout quand on est un débutant comme moi en Rust).

              Pour ce qui est de la question thread / goroutine / futures, ce n'est pas dans le langage (Rust), mais ça s'implémente bien en dehors. Par exemple, actix propose un modèle à base d'acteurs et futures.rs propose des futures.

              • [^] # Re: Rust et SIMD

                Posté par  . Évalué à 2. 

                Il y a un outil pour détecter les race conditions en Go, race detector, mais je ne le trouve pas très efficace.

                Juste pour compléter, l'outil race detector est basé sur de la détection des accès concurrents non protégés qui se produisent lors des tests unitaires lancés avec le mode race ou sur une des instances en production qui a été compilée avec le mode race. Les erreurs sont sorties sur l'erreur standard, elles donnent les goroutines incriminées en écriture (voire en lecture) et la zone mémoire (variable, tableau…).
                Il n'analyse pas le code source pour trouver les accès concurrents non protégés (pas d'analyse statistique). Il ne permet pas de garantir que le code est sûr s'il ne détecte rien par contre s'il détecte une erreur c'est vraiment un accès concurrent non protégé qu'il faudra corriger. Il n'est donc pas parfait mais il a le mérite d'exister.
                Pour moi, le couple benchmark ou test unitaire avec plusieurs appels en parallèle (par exemple pour une API WS plusieurs requêtes jouées lors des tests unitaires) et le mode race activé fonctionne très bien. Il me donne une bonne garantie que le code est sûr d'un point de vue des accès concurrences non protégés et il est exécuté dans la CI sur chaque push.

            • [^] # Re: Rust et SIMD

              Posté par  . Évalué à 9.

              Avoir une garantie de sûreté d'un code threadé avec Rust est un leurre puissant mais qui, au fond, ne sert pas à grand chose.

              De ce que j'ai compris de ma discussion avec un développeur Mozilla qui bosse sur Firefox. Ça leur a permis d'implémenter ce que l'on trouve depuis Firefox 57. Ils ont longtemps essayé de gèrer leur thread en c++, mais ils n'ont pas réussi a avoir un résultat sans trop de bug. Comme quoi ça a dû leur servir à quelque chose.

            • [^] # Re: Rust et SIMD

              Posté par  (site web personnel) . Évalué à 6.

              Les "modèles de programmation parallèle" simplifient un peu les choses, mais ça n'enlève pas le risque de data-races sur les données partagées.

              Par ailleurs, en rust, Tu n'est pas non plus encourager à utiliser des thread directement. Tu utilise une des API de la librairie standard ou des différentes crate qui exposent des abstractions.

              • [^] # Re: Rust et SIMD

                Posté par  . Évalué à 3. Dernière modification le 14 août 2018 à 16:55.

                Tu peux enlever les guillemets à « "modèles de programmation parallèle" ». ;-)
                Plus sérieusement, tu as techniquement raison, mais ce qui est intéressant avec les langages qui offrent un modèle de programmation parallèle, c'est qu'ils ont aussi tendance à définir un modèle d'execution parallèle qui va avec. Dans le cas de C11/C++1x c'est un modèle très (trop) relâché selon moi, mais c'est parce qu'ils sont tributaires de l'existant (Pthreads en particulier, mais aussi le besoin de pouvoir laisser une machine parallèle optimiser tout un tas de trucs à sa façon).

                Mais les langages/modèles de prog de type OpenMP offrent un modèle d'exécution expliquant quand une région parallèle peut être créée (modèle de concurrence), quel est le mode d'orchestration des threads (modèle de synchronisation), et comment et dans quel ordre la mémoire peut être accédée (modèle mémoire). Dans le modèle de synchro, on compte par exemple une proposition de moniteurs dans OpenMP (via la construction critical), etc. Maintenant, ça n'empêche pas qu'il reste possible d'avoir une data race, mais justement, c'est l'intérêt d'un modèle d'exécution : il spécifie un modèle mémoire. Dedans, on spécifie le mode d'adressage (au minimum, si on a une mémoire partagée ou distribuée), et le modèle de constance mémoire (memory consistency). Dans ce dernier cas, on spécifie dans quel ordre les différentes opérations mémoire peuvent arriver, s'il y a une différence entre des opérations normales ou des opérations « synchronisantes » (par exemple dans OpenMP, il y a la clause atomic; dans Java, il y a le mot-clef volatile; etc.).

                De façon générale, la question n'est pas tant de savoir s'il peut y avoir un conflit sur les données partagées — dès lors que tu autorises le partage mémoire implicite, ça peut arriver. Cependant, si le modèle mémoire que tu utilises est logique/compréhensible, tu peux espérer débugger ton code plus facilement qu'avec un modèle complexe. Ironiquement, je pense qu'il est plus facile de débugger du code C++ concurrent, car data race = UB, et donc généralement ça veut dire « on laisse le matériel sous-jacent se débrouiller », alors qu'en Java par exemple, c'est plus subtil, et potentiellement le compilateur a fait des trucs pas cool (aka « des optimisations » — qui sont légales hein).

                • [^] # Re: Rust et SIMD

                  Posté par  (site web personnel) . Évalué à 2.

                  Je suis plutôt d'accord avec toi, mais le commentaire auquel je répondait semble utiliser le terme "modèles de programmation parallèle" pour dire api de haut niveau, telle que les go-routines ou map réduce. d'où les guillemets.

                  Ironiquement, je pense qu'il est plus facile de débugger du code C++ concurrent, car data race = UB, et donc généralement ça veut dire « on laisse le matériel sous-jacent se débrouiller », alors qu'en Java par exemple, c'est plus subtil, et potentiellement le compilateur a fait des trucs pas cool (aka « des optimisations » — qui sont légales hein).

                  Sur ce point je ne suis pas d'accord.
                  UB en C++ veux aussi dire que le compilateur peut faie n'importe quoi.

                  • [^] # Re: Rust et SIMD

                    Posté par  . Évalué à 2. Dernière modification le 14 août 2018 à 22:26.

                    D'où mon « généralement » pour les UB. ;-)
                    Pour MapReduce il s'agit réellement d'un modèle de programmation parallèle assez limité. Et qu'on parle d'API (ce qui est le cas pour MPI par exemple), ou de syntaxe (pour Erlang, OpenMP, Java, ou C#), ça reste des modèles de programmation et d'exécution parallèles.

            • [^] # Re: Rust et SIMD

              Posté par  . Évalué à 4.

              Je suis intéressé par plus de détails dans certaines affirmations…

              Par exemple, en Go, il y a un modèle de programmation parallèle, certes vieux, certes plein de limites, mais qui fonctionnent et offre des garanties sans avoir à manipuler le moindre thread.

              Je ne connais pas par coeur Go mais son modèle ressemble également à celui d'Erlang. Pourquoi dire que ce sont de vieux modèles de programmation parallèle?

              Qu'est-ce qui est plus moderne? Aurais-tu des exemples?

              MapReduce qui est un modèle de programmation parallèle (qui ne résout pas tous les problèmes)

              Un exemple qu'il ne résout pas?

              Je peux probablement chercher plus attentivement sur le net mais sans référence ou mots clés c'est un poil tendu.

              Merci.

              • [^] # Re: Rust et SIMD

                Posté par  . Évalué à 4.

                Go et erlang sont très différents. Je ne pense pas qu'on puisse considérer go comme un système à acteurs. Les systèmes à acteurs sont théorisés depuis les années 70.

                Pour le map redduce beaucoup plus récent mais pas très novateur. Il est de plus en plus délaissé car il ne fonctionne que pour des batchs là où on arrive maintenant à faire le boulot en continue avec tous les stream processing.

                Les modèles de programmation (qu'ils soient parallèles, asynchrones, architecturaux,…), ne sont pas bons ou mauvais. Ce sont juste des outils efficace dans certains contextes.

                • [^] # Re: Rust et SIMD

                  Posté par  . Évalué à 3.

                  Merci,

                  Go et erlang sont très différents. Je ne pense pas qu'on puisse considérer go comme un système à acteurs.

                  Non mais on pourrait le simuler si je ne m'abuse.

                  D'ailleurs je disais ressemble car si on lit la page wikipedia à propos Go (concurrency: goroutine and channels), on trouve des affirmations de la sorte:

                  The language specification does not specify how goroutines should be implemented, but current implementations multiplex a Go process's goroutines onto a smaller set of operating system threads, similar to the scheduling performed in Erlang.

                  ou encore:

                  The existence of channels sets Go apart from actor model-style concurrent languages like Erlang, where messages are addressed directly to actors (corresponding to goroutines). The actor style can be simulated in Go by maintaining a one-to-one correspondence between goroutines and channels, but the language allows multiple goroutines to share a channel or a single goroutine to send and receive on multiple channels.

                  C'est issue de la même source cependant.

                  Mais oui le modèle de concurrence diffère, je suis d'accord.

                  • [^] # Re: Rust et SIMD

                    Posté par  . Évalué à 0.

                    Plus j'y réfléchis et moins je me suis que ça ressemble. Le modèle de messagerie est très différents. Un channel ne normalise pas les messages là où dans un système d'acteur ça l'est. Ce n'est pas un détail car c'est ce qui permet de gérer les dead letter. Un système d'acteur utiliser du one-to-many, là où go fais du one-to-one. C'est critique pour la répartition de charge. Si tu ne fais que du one-to-one comment fais tu scaler ton système ? Augmenter le nombre d'instances d'un acteur n'est pas anodin.

                    Bien sûr qu'on peut stimuler, on peut implémenter les acteurs dans probablement tous les langages, mais il manque de base des bois suffisamment important pour ne pas pouvoir dire que c'est un modèle d'acteur. Tout comme on ne peut pas dire que java est un langage fonctionnel.

              • [^] # Re: Rust et SIMD

                Posté par  (Mastodon) . Évalué à 6. Dernière modification le 30 juillet 2018 à 10:22.

                Je ne connais pas par coeur Go mais son modèle ressemble également à celui d'Erlang. Pourquoi dire que ce sont de vieux modèles de programmation parallèle?

                Le modèle de Go est un dérivé de CSP qui date des années 70. Ce modèle a été étudié en continu depuis et est extrêmement bien connu.

                Qu'est-ce qui est plus moderne? Aurais-tu des exemples?

                Le vol de travail par exemple est un modèle un peu plus récent.

                • [^] # Re: Rust et SIMD

                  Posté par  . Évalué à 3.

                  Merci,

                  Ce modèle a été étudié en continu depuis et est extrêmement bien connu.

                  Je ne suis pas du milieu académique informatique mais lire une biblio. dessus ne me dérangera pas si "abordable".

                  Aurais-tu des papiers ou références, livres (surtout majeurs) dessus. L'article original de Hoare est un bon départ ou il y a plus "digeste"?

                  • [^] # Re: Rust et SIMD

                    Posté par  . Évalué à 3. Dernière modification le 14 août 2018 à 17:05.

                    L'article de Hoare est très bien, dans le sens où il propose son idée, mais donne aussi des problèmes connus de programmation concurrente pour montrer comment son langage y répond. Par contre, ça reste un article un peu académique sur la forme.

                    Hoare a aussi écrit un bouquin complet sur la question mais c'est tout plein de maths/info théorique. J'avais trouvé il y a un moment cette présentation qui me semble pas mal pour introduire le concept.

                • [^] # Re: Rust et SIMD

                  Posté par  . Évalué à 2. 

                  Le vol de travail par exemple est un modèle un peu plus récent

                  Ce mécanisme est aussi implémenté dans le runtime de Go. En effet, les M goroutines sont réparties sur N threads (un thread par core de la machine) avec un M en général beaucoup plus important N (c'est le principe du scheduler M:N). Le principe du vol de travail (c'est à dire des goroutines en attentes) est mise en œuvre entre les différents threads dans le runtime de Go cf. https://rakyll.org/scheduler/

            • [^] # Re: Rust et SIMD

              Posté par  . Évalué à 1.

              Je suis par contre entièrement d'accord sur le modèle de threads. Je me bats régulièrement contre des new Thread().start() en java.

  • # Phobie du GC

    Posté par  . Évalué à 10.

    Parmi ces langages, en excluant ceux qui ne sont qu'interprétés et ceux qui utilisent un garbage collector, les seuls qui pourraient remplacer C++ à performances égales sont donc C, Rust et D.

    C'est un peu raté, D est un langage à Garbage Collector (GC).

    Je regrette la phobie des GC dans les discussions sur les choix des langages de programmation. Il y a certains types d'applications très spécifiques qu'on veut écrire sans GC, et certains GCs peuvent parfois causer des problèmes de performance et demander du tuning ou un comportement pour certains usages. Mais ça reste très rare; c'est bien d'avoir des langages sûrs comme Rust pour écrire ces parties d'un programme, mais ça ne concerne pas la plupart des applications et la plupart des programmeurs.

    (On disait avant qu'on ne pouvait pas coder de jeux vidéos sérieux dans un langage à GC, maintenant il y a énormément de gens qui utilisent Unity depuis un code en C# et… ça marche. Certaines parties de Unity sont codées en C++ en dessous, mais ça n'affecte pas les utilisateurs.)

    C++ est un langage qui part d'un principe intéressant et personne ne nie son droit à exister. Mais par contre ce n'est pas forcément très raisonnable de continuer utiliser des piles applicatives qui sont très majoritairement écrites en C et C++, comme la grande majorité de ce qui se trouve sur un environnement de bureau libre—de grosses codebases Gtk en C, Qt en C++, et des navigateurs globalement en C++ et Javascript.

    Je me sentirais beaucoup mieux si mon userland était écrit dans un langage sûr par défaut, même un langage aussi verbeux et peu tentant que Java.

    • [^] # Re: Phobie du GC

      Posté par  (site web personnel) . Évalué à 2.

      Est-ce que l'utilisation de pointeurs intelligents style std::shared_ptr (ou leur ancêtre dans Boost) est considéré comme un GC ?

      Leur utilisation permet d'enlever une bonne partie des problèmes de libération de la mémoire en C++ avec un coût minimal. C'est utilisé par de grosses applications industrielles (robotique, CAO, etc.) qui exigent pourtant des performances élevées.

      • [^] # Re: Phobie du GC

        Posté par  (site web personnel) . Évalué à 10.

        Dans les applications temps réel, le plus simple est de ne pas faire d'allocation mémoire, tout est statique. Ainsi, il n'y a jamais de problème de new ou de delete, ni de latence associé.

        "La première sécurité est la liberté"

      • [^] # Re: Phobie du GC

        Posté par  . Évalué à 10.

        Oui, pour moi le comptage de références (reference counting) est une forme de GC, mais une différence importante entre C++ et les langages managés est que, en C++, les constructions du langage ne t'imposent pas l'usage de shared_ptr ou d'un autre schéma automatique pour tracer les allocations mémoires, donc c'est facile de s'en passer et il y a des pratiques reconnues pour écrire du code où tout est géré manuellement. On peut aussi écrire du code qui n'utilise pas le GC dans un langage managé, mais c'est souvent beaucoup moins bien compris et donc plus délicat, et ça peut mal interagir avec le reste de l'écosystème logiciel.

        C'est utilisé par de grosses applications industrielles (robotique, CAO, etc.) qui exigent pourtant des performances élevées.

        Oui enfin tout le monde "exige des performances élevées", ça ne veut pas dire qu'un GC n'aurait pas été un choix raisonnable aussi—on peut écrire des applications performantes dans des langages avec GC, et d'ailleurs pas mal de code à haute performance côté serveur est écrit en Java.

        • [^] # Re: Phobie du GC

          Posté par  (site web personnel) . Évalué à 5.

          Oui, pour moi le comptage de références (reference counting) est une forme de GC, mais une différence importante entre C++ et les langages managés est que, en C++, les constructions du langage ne t'imposent pas l'usage de shared_ptr ou d'un autre schéma automatique pour tracer les allocations mémoires, donc c'est facile de s'en passer et il y a des pratiques reconnues pour écrire du code où tout est géré manuellement. On peut aussi écrire du code qui n'utilise pas le GC dans un langage managé, mais c'est souvent beaucoup moins bien compris et donc plus délicat, et ça peut mal interagir avec le reste de l'écosystème logiciel.

          Dans l'ensemble tu as raison, mais après ne pas oublier que ces pointeurs intelligents s'imposent de plus en plus car c'est considéré comme une bonne pratique.

          C'est de mon point de vue de plus en plus rare de trouver des codes C++ avec une gestion complètement manuelle de la mémoire.

          • [^] # Re: Phobie du GC

            Posté par  (site web personnel) . Évalué à 2.

            Pour moi les shared_ptr ne sont pas du GC car on sait quand et sur quelle étendue la libération mémoire peut se produire; on ne sait juste pas si elle va vraiment se produire.
            En C++, il est effectivement recommandé d'éviter les new/delete notamment en utilisant les unique_ptr mais les shared_ptr avec comptage-de-référence-pseudo-GC ne sont pas particulièrement conseillés.

        • [^] # Re: Phobie du GC

          Posté par  (site web personnel) . Évalué à 0.

          et d'ailleurs pas mal de code à haute performance côté serveur est écrit en Java.

          Tu as des noms en tête ?

          J'ai souvent remarqué que dès qu'une app serveur dépasse une certaine échelle ou requiert une latence stable, elle est réécrite tôt ou tard en C++

          • [^] # Re: Phobie du GC

            Posté par  . Évalué à 10. Dernière modification le 28 juillet 2018 à 23:14.

            Pour des exemples de serveurs qui tournent sur la JVM (c'est ça l'important plutôt que Java en particulier), regarder par exemple la liste d'utilisateurs de Netty, ou bien de Akka. Netty est utilisé, par exemple, par Ebay pour construire des équilibreurs de charge (load balancers), et Akka par Intel pour faire du streaming de données en temps réel.

            Il y a des domaines applicatifs dans lesquels le C++ est plus populaire, mais le runtime de la JVM est quand même méchamment bien optimisé pour des types de charge où le code tourne pendant très longtemps sur le serveur en traitant un grand nombre de données/requêtes de façon proche les unes des autres. Le JIT fait un excellent travail de spécialisation, et ça va vraiment très vite—j'imagine que dans les bons cas on peut même battre une application en C++ à niveau d'abstraction du code égale, grâce aux optimisations spéculatives. Il y a aussi beaucoup d'analyse des performances—ce qui montre aussi qu'il y a beaucoup de gens qui écrivent du code haute-performance, assez pour générer les besoins de peaufiner ces outils.

          • [^] # Re: Phobie du GC

            Posté par  (site web personnel) . Évalué à 6.

            Il y a presque une contradiction entre :
            1. des applications serveurs d'une certaine échelle
            2. des applications requérant une latence stable..

            Pour 1, à part quelques vieille application Corba, je ne connais pas de nouvelles grosses applications C++ maintenable, je serais intéressé d'en connaitre. Par contre il y a beaucoup d'utilisateur de la JVM pour ce genre d'application (SAP, 95% des application d'IBM / Oracle / HP / Talend, tous les ETL, les ESB (qui doivent avoir une latence stable) …).

            Certaines applications comme les bus d'entreprise (ESB) sont à la fois 1 et 2. Je n'en connais pas qui ne soit pas en Java…

            • [^] # Re: Phobie du GC

              Posté par  (site web personnel) . Évalué à -2.

              Pour 1, à part quelques vieille application Corba, je ne connais pas de nouvelles grosses applications C++ maintenable, je serais intéressé d'en connaitre

              Le C++ est surtout utilisé pour des applications systèmes, moins pour des applications métiers.

              La plupart des grosses DB, File system distribué, Load balancer, Object Store & co sont.

              Ça dépend aussi beaucoup de la politique de ta boite, où je travaille c'est généralement plutot backend en C++ avec des micro-services en python / node / plutot que les classiques bloatware en Java.

              Par contre il y a beaucoup d'utilisateur de la JVM pour ce genre d'application (SAP, 95% des application d'IBM / Oracle / HP / Talend, tous les ETL, les ESB (qui doivent avoir une latence stable) …).

              Si j'avais envie de troller, je dirai que déja SAP, JVM et latence stable dans la même phrase c'est déja une oxymore en soit.

      • [^] # Re: Phobie du GC

        Posté par  . Évalué à 3.

        Un des critère de distinction est le déterminisme de la libération, et bien que l'état de l'art des GC soit impressionnant, il reste en dessous des shared_ptr.

        Reste que conceptuellement la sur-utilisation des shared_ptr est un problème lorsque l'on utilise des objets dont le contrôle de la durée de vie est important: mieux vaut un système pour interdire statiquement les utilisations (ou tentatives) trop tardives. Mais a défaut, c'est sûr que mieux vaut souvent une logique impropre à cause d'une durée de vie trop allongée (ou une suppression des derniers accès—ou un crash déterministe suite à la détection déterministe dynamique du problème) qu'une undefined behavior.

    • [^] # Re: Phobie du GC

      Posté par  (site web personnel) . Évalué à 10.

      Unity c'est ~20 millions de ligne de C++, et un jeu c# rajoute ~100k ligne dessus. La partie temps réel dure est à 100% en C++.

      Le problème des GC est qu'il rajoute des latences à peu n'importe où, et un peu n'importe quand. Golang dispose d'un gc avec des latences ajouté super courte (9ms de mémoire), mais au pris d'un usage du cpu plus gros. Avec l'augmentation de la RAM, un GC n'est pas raisonnable. C'est amusant de lire les exploits techniques des systèmes de bases de données en "RAM". Ce sont des grappes de x86, avec des To de RAM. Il est plus rapide de faire un reset que de se prendre le full GC de java. Il y a donc une foule de technique pour l'éviter.

      "La première sécurité est la liberté"

      • [^] # Re: Phobie du GC

        Posté par  (site web personnel) . Évalué à 9.

        Golang dispose d'un gc avec des latences ajouté super courte (9ms de mémoire)

        Il y a eu récemment un article intéressant sur le blog de Go : https://blog.golang.org/ismmkeynote. Les pauses du GC sont inférieures à la milliseconde, d'après les chiffres de ce billet.

        • [^] # Re: Phobie du GC

          Posté par  (site web personnel) . Évalué à 3.

          Les pauses du GC sont inférieures à la milliseconde, d'après les chiffres de ce billet.

          j'ai toujours des problèmes avec les benchmarks fait par les concepteurs du langage eux même.

          • [^] # Re: Phobie du GC

            Posté par  . Évalué à 2.

            Tu fais référence à qui au juste ? À ma connaissance les gens qui ont fait ce bench ne les auteurs d'aucun langage en particulier, ça vient d'un workload qui a été observé en practice comme un pire-cas pour la latence du GC de GHC (Haskell)—donc le benchmark est un peu injuste avec GHC, dans le sens où on sait déjà qu'il devrait faire pire que les autres ici.

            • [^] # Re: Phobie du GC

              Posté par  (site web personnel) . Évalué à 2.

              Tu fais référence à qui au juste ? À ma connaissance les gens qui ont fait ce bench ne les auteurs d'aucun langage en particulier

              Le blog post, la présentation sur le sujet et les measurement viennent directement des devs de Go et sont chez google.

              • [^] # Re: Phobie du GC

                Posté par  . Évalué à 2.

                Flûte, je me suis trompé de sous-fil, je pensais que tu parlais de cet autre billet sur les temps de latence de Go et d'autres langages, désolé.

          • [^] # Re: Phobie du GC

            Posté par  (site web personnel) . Évalué à 6.

            Les chiffres ne viennent pas d'un benchmark mais d'une vraie application en production avec 18 Go de heap, sur plusieurs serveurs (on peut d'ailleurs voir les déploiements avec un canari : un serveur migre vers une nouvelle version de Go avant les autres pour vérifier qu'il n'y a pas de régressions sur les performances).

      • [^] # Re: Phobie du GC

        Posté par  . Évalué à 5.

        Le fait qu'Unity en interne soit du C++ ne change rien au fait que des milliers de développeurs créent des jeux en C# grâce à cette bibliothèque. Je le mentionnais dans mon message pour expliquer que le nombre de domaines applicatifs perçus comme "ne tolérant pas un GC" diminue, longtemps les jeux vidéos ont été cités en exemple, ce n'est plus pertinent aujourd'hui.

        (Le fait qu'en interne des bouts de code critiques soient écrits dans un autre langage que le reste de l'application n'est pas nouveau. Tous les langages managés ou presque ont un runtime en C (plus rarement en C++), par exemple.)

        Le problème des GC est qu'il rajoute des latences à peu n'importe où, et un peu n'importe quand.

        C'est un peu simplificateur. On peut écrire du code à faible latences dans un langage à GC—mais il faut un GC raisonnablement prévu pour ça. En OCaml par exemple, les latences du GC sont courtes pour la plupart des types de charge de calcul (il y a des cas particuliers mauvais, comme sur tous les systèmes).

        Golang dispose d'un gc avec des latences ajouté super courte (9ms de mémoire), mais au pris d'un usage du cpu plus gros.

        Dans ce billet de blog, qui part d'un benchmark des latences (sur un workload spécifique) que j'ai contribué à écrire / alimenter, on voit que les latences du GC OCaml sont inférieures à celles de Go 1.7—OCaml a une implémentation plus simple car le GC n'est pas concurrent.

        • [^] # Re: Phobie du GC

          Posté par  (site web personnel) . Évalué à 3. Dernière modification le 14 août 2018 à 22:31.

          Je le mentionnais dans mon message pour expliquer que le nombre de domaines applicatifs perçus comme "ne tolérant pas un GC" diminue, longtemps les jeux vidéos ont été cités en exemple, ce n'est plus pertinent aujourd'hui.

          Je ne suis pas d'accord. Les jeux vidéos ont, sont toujours, et seront toujours en C++ ( du moins à court terme ). Ce qui est en C# c'est l'interface de scripting des jeux pour Unity, ce qui est normale et n'a rien de révolutionnaire. Elle était en Lua, python ou home made script ( Unreal script ) pendant très longtemps.

          Le C# ne remplacera jamais le core même de l'Engine car critique. Il rend juste l'interface externe plus "accessible". Tout comme le calcul scientifique ne sera jamais entièrement fait en python…. Il rend juste l'interfaçage à BLAS plus accessible. Tout comme la plupart des frameworks de machine learning ne seront jamais fait entièrement en Lua / Python / JS…. ils wrappent simplement des libs systèmes existante.

          Je pense au contraire l'opposé. Dans le sense où le temps des languages frameworks monolitiques géants, vivant sur leur propre ecosystème, le tout tournant sur un Garbage Collector comme Java est révolu.

          Ils perdent de la vitesse et tend à disparaitres en ce faisant remplacer par des languages de scripts haut niveau ( donc souvent à GC ) associés à des libs systèmes justement codé en C, C++ ou Rust.

          − C'est le cas de Python devenu le de-factor standard en Calcul Scientifique ( Même si Julia tente de se faire une place )

          • C'est le cas de Python / Lua pour quasiment TOUS les frameworks de Machine learning.

          • C'est le cas de Golang qui crée des binaires static, AOT tout en incluant directement des fichier objets en code C pour s'interfacé avec les libs tiers.

          • C'est le cas de Swift qui a trés justement éviter les erreurs faites avec Java & Android en se basant sur une grosse stack existante en ObjectiveC.

          Prends un bon 90% des logiciels que tu vois sur ton écran à l'instant ils suivent ce pattern :

          • Ton Web Browser: un core en C++ et un scripting en JS

          • Ton Environment GNOME SHELL ou PLASMA : Un core en C ou C++ et un language de scripting

          • Ton client mail, ton file browser, Même trés certainement le GUI de l'ordinateur de bord voiture fonctionne pareillement… Le mien est en JavaScript avec un Backend en C.

          Les languages système sans GC comme C++ ne disparaîtront pas, trés loin de là, ils sont derrière un peu prés tous les outils que l'ont utilise tous les jours, et encore pendant trés longtemps…. Le code "métier" par contre, le code "GLUE" entre les composants… lui ira de plus en plus vers des languages de haut niveau pour des raisons d'accessibilité…. Trés vraisemblablement.

          • [^] # Re: Phobie du GC

            Posté par  . Évalué à 1.

            Je ne suis pas d'accord. Les jeux vidéos ont, sont toujours, et seront toujours en C++ ( du moins à court terme ). Ce qui est en C# c'est l'interface de scripting des jeux pour Unity, ce qui est normale et n'a rien de révolutionnaire. Elle était en Lua, python ou home made script ( Unreal script ) pendant très longtemps.

            Aujourd'hui il y a plein de jeux dont le code source (le truc écrit par les gens qui sont les auteurs du jeu) est écrit intégralement en C# (ou Lua, etc.). Les grosses boîtes de production vont avoir plus de code bas niveau, les indépendant-e-s vont beaucoup plus reposer sur un moteur existant, mais ma remarque était qu'on peut aujourd'hui tout à fait "écrire un jeu vidéo" dans un langage à GC, c'est même la norme. (Voir aussi les jeux sur le web, Android, iOS, etc…)

            Le fait que le moteur 3D (ou IA, ou son, ou…) soit fait dans un autre langage n'est pas visible pour les personnes qui créent le jeu vidéo.

            Prends un bon 90% des logiciels que tu vois sur ton écran à l'instant ils suivent ce pattern : […] ton web browser, ton environnement de bureau, ton client email.

            Ces observations sont biaisées par le fait que l'écosystème logiciel pour les ordinateurs personnels GNU/Linux est fortement biaisé en faveur de C (pour GNOME) et C++ (pour KDE), avec une toute petite place pour les langages de plus haut niveau, à l'inverse de iOS, Android etc.

            • [^] # Re: Phobie du GC

              Posté par  (site web personnel) . Évalué à 3.

              avec une toute petite place pour les langages de plus haut niveau, à l'inverse de iOS, Android etc.

              Il en vas de même avec iOS et Android.

              Android a un core en C++, La plupart des ses libs systèmes ont un backend en natif… C'est encore plus vrai avec l'OS Android "next-gen" Fushia de Google qui lui est entièrement en C++, incluant même le Kernel.

              Android est un bel exemple de ce que je disais je pense. Quand Android est apparu, la majorité des Apps était effectivement quasiment intégralement dans un Java maison Google, L'OS étant également principalement en Java.

              Aujourd'hui Android a vu une grosse parti de ses deps systèmes re-codés en natif, et la grosse majorité des Apps sont maintenant purement des WebApp en JS, avec un petit frontend en Java… se basant sur les libs native et le browser d'Android… qui lui est en C++.

              iOS quand a lui a toujours été en langage relativement bas niveau (Objective-C) et sans garbage collector.

              • [^] # Re: Phobie du GC

                Posté par  . Évalué à 5.

                Comme je l'ai de nouveau expliqué pour Unity, le fait qu'une bibliothèque soit en interne codée dans un autre langage ne change rien au calcul "on peut parfaitement écrire une application pour faire X dans un langage à GC". Ça ne veut pas dire que tout le code qui tourne aura été écrit dans ce langage, il va y avoir aussi du code C qui tourne (si tu es sous Linux), du code assembleur, des opcodes écrit en microcode processeur, et alors ?

                iOS quand a lui a toujours été en langage relativement bas niveau (Objective-C) et sans garbage collector.

                À ma connaissance Apple impose l'utilisation de leur technique de gestion de mémoire automatique, ARC (qui est bien une forme de gestion automatique de la mémoire, quoi que tu sembles dire), à la fois pour les applications en Objective-C, et aussi en Swift où c'est le seul choix.

                • [^] # Re: Phobie du GC

                  Posté par  (site web personnel) . Évalué à 2.

                  À ma connaissance Apple impose l'utilisation de leur technique de gestion de mémoire automatique, ARC (qui est bien une forme de gestion automatique de la mémoire, quoi que tu sembles dire

                  J'assimile plus ARC à une technique de RAII qu'a un Garbage Collector pure jus.

                  ARC en Swift est en tout point commun à une utilisation de shared_ptr en C++, juste intégré directement au lanuage au lieu d'être templatée.

                  Elle nécessite également une certaine gestion manuelle pour éviter les dépendances cycliques potentielles.

      • [^] # Re: Phobie du GC

        Posté par  (site web personnel) . Évalué à 6.

        Le GC est pénalisant quand il prend beaucoup temps, cad quand il y a un très grand nombre d'objets à se débarrasser. Mais la cause reste tout de même un très grand nombre de créations d'objets dans un temps très courts.

        Allouer des objets par millions, c'est contre productif en C++ tout comme avec les langages avec GC (Java, C#, etc…) l'allocation mémoire est très pénalisante en C++ (moins rapide qu'en Java par exemple). De plus, la fragmentation mémoire augmente et l'utilisation de la mémoire vive aussi inutilement.

        Avoir un programme performant en C++ c'est surtout s'assurer de minimiser les allocations et d'avoir le plus possible un "layout" mémoire optimal (localité des données).

        En Java, il y a tout un tas de GC différents à utiliser en fonction des besoins.
        Je pense que les programmeurs utilisant Unity se définissent plus comme programmeurs C#, le moteur Unity étant manipulé en C# à la manière d'une librairie quelconque. Bref, à moins de vouloir recoder un moteur 3D, on peut très bien se passer du C++ ;)

        • [^] # Re: Phobie du GC

          Posté par  (site web personnel) . Évalué à 3.

          Allouer des objets par millions, c'est contre productif en C++ tout comme avec les langages avec GC (Java, C#, etc…) l'allocation mémoire est très pénalisante en C++

          C++ ainsi que la plupart des languages à allocation manuel te donne un contrôle très fin sur ton layout mémoire.

          Allouer un million d'objet en C++ ne pose aucun problème si c'est fait de manière intelligente… dans un vecteur ou avec ta propre pool… Ça sera même dans ce cas une seule et unique allocation.

          Ce qui est souvent non-trivial, ignoré par la majorité des programmeurs, ou totalement impossible dans les languages à GC / de trés haut niveau.

    • [^] # Re: Phobie du GC

      Posté par  (site web personnel) . Évalué à 2. Dernière modification le 15 août 2018 à 14:38.

      Je me sentirais beaucoup mieux si mon userland était écrit dans un langage sûr par défaut, même un langage aussi verbeux et peu tentant que Java

      Suivant la définition de sûreté que tu utilises, Java n'est pas plus sûr qu'un programme en C++ moderne.

      Je n'appelle pas un programme qui crash avec un null pointer exception plus "sur" qu'un programme qui segfault.

      Java n'offre pas non plus d'avantage de sûreté en environnement multi-threadé ou une race condition et un crash y ait tout aussi simple à faire qu'en c++.

      Son seul "gain" en terme de sûreté face à C++ concerned l'absence theorique de memory leak… Au prix d'un GC aux latences linéaire au nombre d'objets…. Problème qui est par ailleurs pratiquement éliminé en C++ avec la RAII

      • [^] # Re: Phobie du GC

        Posté par  . Évalué à 4.

        Son seul "gain" en terme de sûreté face à C++ concerned l'absence theorique de memory leak… Au prix d'un GC aux latences linéaire au nombre d'objets…. Problème qui est par ailleurs pratiquement éliminé en C++ avec la RAII

        L’absence (réel) de buffer overflow. J'imagine que ça n'arrive pas si on utilise les bonnes pratiques (rien arrive quand on utilise les bonnes pratiques) de la version suffisamment à jour du C++, mais comment s'assure-t-on que notre base de code est bien passé à ces pratiques ?

        • [^] # Re: Phobie du GC

          Posté par  (site web personnel) . Évalué à 1. Dernière modification le 15 août 2018 à 15:47.

          mais comment s'assure-t-on que notre base de code est bien passé à ces pratiques ?

          Static analyzer et adresse sanitizer sur chaque build en continuous integration.

          Plus banissement de tout utilisation des raw pointers si pas explicitement justifiée via les coding guidelines.

          Les plus grosses sources de buffer overflow en C sont généralement : les manipulations de string, l'utilisation de buffer pour I/O.

          En C++, std::string est heap-alloué et "safe". L'utilisation de buffet se fait via std::Vector qui est lui aussi heap-allocated

  • # Mon histoire avec le C++

    Posté par  (site web personnel) . Évalué à 10. Dernière modification le 27 juillet 2018 à 18:05.

    Avec mon premier ordinateur (un Sinclair ZX81), ainsi qu'avec ceux que je me suis offerts par la suite (y compris mes calculatrices HP), mon activité principale a toujours été la programmation. Durant un certains temps, j'ai papillonné entre différents langages, essentiellement différentes versions de BASIC.

    Lors de ma première année de mon cursus informatique, on a vu plusieurs langages, mais essentiellement à titre d'information (Fortran, LISP, Prolog, divers assembleurs…), pour finalement se concentrer sur le Pascal. Dés lors, je développais tous mes logiciels en GFA Basic sur mon Amiga, avant de les transcrire en (Turbo-)Pascal, pour pouvoir les faire tourner sur nos PC du lycée, qui faisait tourner MS-DOS.

    Puis j'ai découvert le C. Enfin pouvoir faire tourner (après recompilation, évidemment) tous mes programmes développés sur mon Amiga sur les PC du lycée sans avoir à les transcrire. Bon, évidemment, j'ai été confronté a quelques problèmes de portabilité, mais qui ont vite été résolu avec quelques directives préprocesseurs bien senties.

    Puis j'ai été amené à choisir entre le C++ (oui, on y arrive) et Java. J'ai hésité pendant assez longtemps pour finalement choisir le C++. Rétrospectivement, je me rend compte que j'ai choisi le C++ pour des mauvaises raisons, dû à une certaine méconnaissance de Java, mais que j'ai finalement quand même fait le bon choix.

    Je suis quasiment resté au C++ de mes débuts. Les seules nouveautés que j'ai adoptées sont les mutables (parcimonieusement), mais surtout, et c'est relativement récent, les variadics templates (je ne connais pas le terme français). J'étais souvent tenté d'utiliser les fonctions variadiques, issues du C, mais je me réfrénais car ce sont de vrais appeaux à bugs. Mais, depuis que je peux utiliser les variadics templates à la place, je me lâche. Ceci dit, il m'arrive encore d'utiliser les fonctions variadiques, car il y a des situations où l'on ne peut les remplacer par des variadics templates.

    Quand je fais référence au langage que j'utilise pour développer, je parle de C/C++, mais pas au sens donné dans la dépêche. Je signifie par ce terme que je développe en langage C++, mais sans utiliser les bibliothèques C++, ni même C, standards. Comment ce fait-ce ?

    J'ai, un jour, était engagé sur une mission durant laquelle je devais développer un logiciel en C++, logiciel destiné à être utilisé en production. Comme compilateur, je disposais d'une des premières versions de Visual C++ (sur cette version, le multitâche était une option expérimentale qui devait être explicitement activée ; par défaut, lorsqu'on lançait une compilation, on ne pouvait pas manipuler les fichiers sources en même temps !). Je prend donc la documentation papier officiel sur la STL, et voit, en première page, une notice enjoignant de ne pas utiliser la STL en production car celle-ci n'est pas suffisamment stable. Donc, exit la STL.

    Pour les autres bibliothèques, j'ai été un jour été confronté à une fonction de la bibliothèque C++ standard qui ne se comportait pas de la même façon sur mon Amiga que sur un PC sous Windows. Du coup, je l'ai recodée en m'appuyant sur des fonctions de la bibliothèque C standard. Malheureusement, l'une de ce fonctions était sérieusement buguée. Du coup, j'ai recodé ma fonction en utilisant les bibliothèques systèmes, et j'ai constaté un net gain en matière de performance par rapport à la même fonction proposée par la bibliothèque standard. C'est là que j'ai commencé à développer et à utiliser mon propre jeu de bibliothèques basées sur des fonctions des bibliothèques systèmes, et à définitivement tourner le dos aux bibliothèques C et C++ standards.

    Je n'ai jamais regretté d'avoir choisi le C++, car j'ai toujours pu compter sur lui pour développer de nouvelles fonctionnalités. Je me suis longtemps cantonné aux daemons et aux utilitaires en ligne de commande, puis j'ai du développer des interfaces bureau. Pour ce faire, je me suis appuyé sur XULRunner (https://linuxfr.org/users/epeios/journaux/xulrunner-et-c), codé en C++, et donc avec une API C++, bien que mal documentée, l'API officielle étant celle en JavaScript. J'ai également développé mes premières applications web, de type CGI, en C++, bien que, déjà à l'époque, on prétendait que le C++ n'était pas adapté à cet usage.

    Cependant, les applications web CGI ne sont pas adaptées à certains types d'applications qui réclament un minimum de réactivité, et je me suis demandé si, encore une fois, je pouvais compter sur le C++ pour réaliser une bibliothèque me permettant de développer des applications web du même niveau que celles réalisés avec les meilleurs technologies actuelles. Là, j'avoue que ça n'a pas été facile, mais, encore une fois, il ne m'a pas laissé tombé, et je peux ainsi prétendre être un développeur C++ fullstack, pour reprendre un terme à la mode (c'est important les termes à la mode pour trouver du boulot !).

    En outre, le C++ est relativement facilement interfaçable avec à peu prés n'importe quel langage. J'en ai donc profité pour écrire des bindings de la bibliothèque ci-dessus pour différents langages (https://linuxfr.org/users/epeios/journaux/le-developpement-full-stack-facilite).

    Pour en revenir au sujet de la dépêche, est-ce qu'aujourd'hui encore, avec tout le choix de langages actuel, choisirais-je encore le C++ ? Si c'est pour parvenir au même confort d'utilisation que j'ai aujourd'hui grâce à mes bibliothèques, et sachant qu'il n y a rien qui ne puisse être fait avec les langages actuellement disponibles que je ne puisse faire en C++, la réponse est oui.

    Mais, d'un autre coté, le développement de ces bibliothèques prends du temps. J'ai eu de la chance de pouvoir développer les fonctionnalités relatives à certaines technologies au fur et à mesure qu'elles se sont répandues. Quand j'ai commencé à travailler sur mes bibliothèques, Internet n'était pas démocratisé, et le web n'existait pas. J'ai testé mes bibliothèques réseaux sur un réseau constitué de ma machine de développement reliée à l'une de mes vieilles machines, n'ayant pas alors accès à Internet.

    Bref, j'ai pu entreprendre à l'époque, vu le contexte, une démarche qui est inenvisageable aujourd'hui, car elle me prendrait trop de temps avant de pouvoir être concurrentiel par rapport à la plupart des développeurs au regard de toutes les fonctionnalités disponibles en standard avec la plupart des autres langages. Donc, aujourd'hui, le C++, juste avec les bibliothèques standards ou des bibliothèques tierces, ne me parait plus être le plus adapté pour certains types de logiciels, surtout si l'on peut apprendre plusieurs langages pour choisir lequel on utilise en fonction du type d'application à développer…

    Cyberdépendance, cyberharcèlement, pédocriminalité… : Zelbinium, pour que les smartphones soient la solution, pas le problème !

    • [^] # Re: Mon histoire avec le C++

      Posté par  . Évalué à 6.

      La portabilité du C++ moderne, y compris et surtout avec une bibliothèque standard moderne, n'a rien a voir du tout avec la situation que tu as vécu lors de ton utilisation initiale. Les progrès ont été énormes surtout ces dernière années avec la mise en conformité et le rattrapage de MS pour MSVC (gcc et clang sous Nux étaient déjà beaucoup plus conformes depuis quelques années de plus).

      Aujourd'hui pour la plupart des applications dans les domaines ou le C++ est applicable, il est de moins en moins pensable de s'abstenir d'utiliser la bibliothèque standard. La plupart de ceux qui le faisaient avaient de bonne raisons historiquement, mais au fur et à mesure de l'évolution du langage, les freins historiques sont traités et les raisons en question disparaissent ou s'amenuisent, et même certains projets historiques migrent petit à petit vers de plus en plus de bibliothèque standard. Permettre cela semble même être un des critères essentiels pour les évolutions du langage décidées par le commité.

    • [^] # Re: Mon histoire avec le C++

      Posté par  . Évalué à 7. 

      GFA Basic sur mon Amiga

      Les petits trolls entre C, C++, Go, Rust bla bla bla, c'est du pipi de chat.

      Le GFA Basic c'était est d'abord et avant tout un BASIC révolutionnaire sur Atari ST.
      Alors tu prends ta pelle et ton sot, tu retournes jouer à Shadow of the Beast sur ton Amiga qui-a-un-un-blitter-que-l-Atari-ST-il-a-pas (mais qui est cadencé à 8Mhz et pas à 7.44, et toc!) et tu laisses les grands travailler sur leur Atari, OK ?
      M'enfin ! ;-D

  • # Les avantages de C++ ne sont pas bien différentes avec Rust

    Posté par  . Évalué à 7. Dernière modification le 27 juillet 2018 à 19:31.

    Des avantages que tu listes, je ne vois rien qui soit un réel frein à l'usage de Rust. Bas niveau, possible réutilisation des bibliothèques C/C++, le langage peut parfaitement être stable dans le temps bien qu'il soit encore jeune. Pour moi c'est tout bon.

    • [^] # Re: Les avantages de C++ ne sont pas bien différentes avec Rust

      Posté par  (site web personnel) . Évalué à 4. Dernière modification le 27 juillet 2018 à 20:38.

      Oui les avantages sont rarement un frein…
      Par contre les désavantages oui, et pour Rust c'est moins de maturité, un écosystème moins fourni, moins de développeurs formés, etc

      • [^] # Re: Les avantages de C++ ne sont pas bien différentes avec Rust

        Posté par  . Évalué à 5.

        Attention, je parlais des "avantages de C++" par rapport à d'autres, pas de ceux de Rust. ;)

        Et oui, il n'a pas la maturité de C++… est-ce réellement une bonne raison pour ne pas le choisir, je suis pas sûr. Tout langage sorti après C++ est forcément moins mature. Et pas que je sois un prosélyte de Rust, mais il a déjà fait parlé de lui en bien dans des projets de très grande ampleur, notamment parce qu'il est mieux pensé que C++ sur pas mal d'aspects.

        L'écosystème est moins fourni, d'accord, mais les bibliothèques C (voire C++) peuvent être réutilisées en Rust (ok pour C++ c'est un peu pénible, mais faisable), donc bon, là encore, pas un très bon argument.

        Et quant au manque de développeurs formés, là encore, c'est pas un super argument, c'est en forgeant qu'on devient forgeron. Je conçois que dans quelques cas il soit compliqué de trouver un peu de temps pour apprendre un nouveau langage, mais ça ne devrait pas être la norme.

        • [^] # Re: Les avantages de C++ ne sont pas bien différentes avec Rust

          Posté par  (site web personnel) . Évalué à 1.

          Et oui, il n'a pas la maturité de C++… est-ce réellement une bonne raison pour ne pas le choisir, je suis pas sûr. Tout langage sorti après C++ est forcément moins mature. Et pas que je sois un prosélyte de Rust, mais il a déjà fait parlé de lui en bien dans des projets de très grande ampleur, notamment parce qu'il est mieux pensé que C++ sur pas mal d'aspects.

          Pour ton projet perso, problablement "Non", car tu recherches le fun.

          Pour un projet Pro, c'est une autre histoire. Dans la majorité des boites, si tu vas voir ton boss en lui disant: "J'ai ce nouveau projet, je voudrais le faire en Rust", la réponse sera "Non". Et pour de trés bonne raison: pérénité, maintanabilité, expertise.

          Recruter quelqu'un qui a une expertise C ou C++, c'est trivial… Les programmeurs C++ sont chers et trés bien payés, mais ils existent… Trouver quelqu'un qui a un niveau réel d'expertise en Rust, c'est autre chose.

          • [^] # Re: Les avantages de C++ ne sont pas bien différentes avec Rust

            Posté par  (site web personnel) . Évalué à 4. Dernière modification le 14 août 2018 à 23:13.

            Trouver quelqu'un qui a un niveau réel d'expertise en Rust, c'est autre chose.

            Il suffit de recruter un programmeur C ou C++ et de le faire coder en Rust. Il s'adaptera assez vite.

          • [^] # Re: Les avantages de C++ ne sont pas bien différentes avec Rust

            Posté par  . Évalué à 8.

            Encore et toujours la même rengaine, c'est un argument circulaire : il faut du C++ parce qu'il y a actuellement du C++, donc demain il faudra du C++ car hier on avait du C++. Il y a mieux comme langage ? Pas grave, on garde C++ parce que c'est ce qu'on a donc c'est ce qu'il nous faut.

            Dire "ouais mais tu dis ça parce que tu parles de projets perso où t'es le seul dev dans ton garage", ça se tient parfaitement… sauf que le langage a désormais 7 ans, un succès auprès des développeurs qui sont de plus en plus nombreux à l'utiliser pour tous les projets possibles et imaginables (en allant jusqu'à des OS et du code très bas niveau, y compris dans des projets très visibles comme ffmpeg). Donc s'il y avait des critiques techniques, je veux bien les voir, là visiblement on en reste à des critiques très superficielles et génériques.

            Au final, il faudrait quoi du coup pour faire changer les mentalités à propos du C++ ? Parce qu'à part fournir un langage bien plus simple, ayant globalement les mêmes performances, une meilleur gestion des bibliothèques tierces, une manière plus élégante de déployer le code, un système de dépendance moins archaïque, une analyse statique du code permettant de déceler plus rapidement des erreurs, une gestion plus pratique (et sûre) de la mémoire, une compilation qui dure pas des plombes, une documentation fournie lisible et maintenue… il faut quoi de plus ?

            • [^] # Re: Les avantages de C++ ne sont pas bien différentes avec Rust

              Posté par  (site web personnel) . Évalué à 3.

              Donc s'il y avait des critiques techniques, je veux bien les voir, là visiblement on en reste à des critiques très superficielles et génériques.

              Si la qualité technique faisait le succès, ça se saurait depuis longtemps. Windows n'existerait plus, linux non plus, on aurait tous un système Minix avec une logithèque Nix, on coderait en Haskell et docker serait uniquement un métier exercé dans les ports.

              • [^] # Re: Les avantages de C++ ne sont pas bien différentes avec Rust

                Posté par  . Évalué à 1. Dernière modification le 15 août 2018 à 11:06.

                Je pense plutôt que Docker n'existerait tout simplement pas. Mais bon, on va pas commencer une guerre de trolls. :p

                Plus sérieusement, je ne viens pas sur LinuxFR en demandant des arguments pour qu'on me réponde "ouais mais de toutes façons on ne fait pas ce qu'on veut". Ce n'est pas pertinent comme réponse. C'est superficiel, générique, peu construit et peu intéressant : oui, on sait très bien pourquoi on n'utilise pas des techno intéressantes au quotidien dans toutes les entreprises, mais ce n'est pas la question ici.

                • [^] # Re: Les avantages de C++ ne sont pas bien différentes avec Rust

                  Posté par  (site web personnel) . Évalué à 3. Dernière modification le 15 août 2018 à 12:23.

                  Plus sérieusement, je ne viens pas sur LinuxFR en demandant des arguments pour qu'on me réponde "ouais mais de toutes façons on ne fait pas ce qu'on veut".

                  Que veux-tu que je te dise ? Oui, tu as raison sur certains points mais je ne peux pas changer le monde d'un claquement de doigts pour appliquer tes remarques. Après il faut quand même faire attention : tu trouves que C++ est pourri comparé à Rust, mais peut-être que si tu connaissais mieux Haskell/OCaml ou autre, tu apprécierais beaucoup moins Rust.

                  Maintenant, si tu veux des réponses "pertinentes" à tes questions, essayons…

                  un langage bien plus simple

                  Heu… non. Le C++ est plus "complexe" que "compliqué" mais c'est le prix à payer pour assurer la compatibilité ascendante (coucou Python3). C++ et Rust sont juste très différents. Pour moi, Rust est quasiment un langage fonctionnel et il y a plein de concepts qui ne le rendent pas spécialement simple : ownership/borrowing, lifetime, trait, macro, generics, la notion de fermeture des Box, la notion de monade des Result…

                  une meilleur gestion des bibliothèques tierces

                  Les langages ont plus de 20 ans de décalage donc forcément. Cela dit, ça évolue côté C++ : déjà un cmake + apt-get install est souvent suffisant, et sinon il existe des outils comme conan, meson, bazel, nix…

                  une manière plus élégante de déployer le code, un système de dépendance moins archaïque

                  Oui mais non. Déployer un binaire du langage avec des dépendances du langage ça n'a rien de compliqué. Mais dans la vraie vie, ton déploiement va concerner aussi d'autres langages, des data, des services genre base de données… Et si je peux me permettre un troll : regarde du côté de Nix et tu verras que "cargo" c'est proche de "docker".

                  une analyse statique du code permettant de déceler plus rapidement des erreurs

                  Je ne vois pas trop à quoi tu fais référence. Il y a aussi des analyseurs statiques et des linters pour C++. D'ailleurs clang/llvm a apporté un peu de fraicheur à niveau il me semble.

                  une gestion plus pratique (et sûre) de la mémoire

                  Cette remarque classique est surtout valable pour du C++98. Aujourd'hui avec le RAII et les pointeurs intelligent, ce n'est plus tellement le cas.

                  une compilation qui dure pas des plombes

                  Si tu n'abuses pas des templates la compilation n'est pas si longue, surtout en incrémental. Je ne connais pas bien les macros de Rust mais j'imagine que ça doit avoir le même effet.

                  une documentation fournie lisible et maintenue

                  C'est pas faux. Cela dit, une autre interprétation est que Rust est obligé d'avoir cette doc car il n'est pas normalisé, ce qui a aussi des inconvénients.

                  • [^] # Re: Les avantages de C++ ne sont pas bien différentes avec Rust

                    Posté par  . Évalué à 3.

                    une gestion plus pratique (et sûre) de la mémoire

                    Cette remarque classique est surtout valable pour du C++98. Aujourd'hui avec le RAII et les pointeurs intelligent, ce n'est plus tellement le cas.

                    On lis continuellement cette rengaine « faut regarder le C++11/14/17/… », mais tu ne peux pas nous dire que C++ c'est bien parce qu'il a un écosystème qui est là depuis super longtemps et demander de ne pas juger les anciens standards. Si tu t'interface avec du code qui est en C++98, alors tu peux pas te permettre d'oublier cette version.

                    D'autre pars comment est-ce que je peux savoir que mon code est bien en C++XX (XX étant la version que tu préfère évaluer) ? Il existe des linters qui te permettent de t'assurer de faire de la RAII par exemple ? Parce que sinon tu viens juste de nous dire qu'il n'y a pas de problème de gestion non sûre de la mémoire parce que si les développeurs font attention il n'y a pas de problème…

                    • [^] # Re: Les avantages de C++ ne sont pas bien différentes avec Rust

                      Posté par  (site web personnel) . Évalué à 1.

                      On lis continuellement cette rengaine « faut regarder le C++11/14/17/… », mais tu ne peux pas nous dire que C++ c'est bien parce qu'il a un écosystème qui est là depuis super longtemps et demander de ne pas juger les anciens standards. Si tu t'interface avec du code qui est en C++98, alors tu peux pas te permettre d'oublier cette version.

                      Alors déjà question rengaine, Rust a aussi un niveau honorable : https://www.reddit.com/r/rust/comments/62gzio/psa_please_stop_asking_other_projects_to_convert/. Ensuite, le "C++ moderne" c'est C++11 et ça fait déjà 7 ans. C'est pas non plus du moderne de la semaine dernière et depuis le temps il commence à y avoir pas mal de bonnes libs en "C++ moderne". Et si vraiment tu dois t'interfacer avec du vieux C++ dégueu ou même du C, bah tu fais comme tout développeur normal et tu codes une classe ou quelques fonctions qui l'encapsule proprement et limite le couplage de code.

                      D'autre pars comment est-ce que je peux savoir que mon code est bien en C++XX (XX étant la version que tu préfère évaluer) ? Il existe des linters qui te permettent de t'assurer de faire de la RAII par exemple ? Parce que sinon tu viens juste de nous dire qu'il n'y a pas de problème de gestion non sûre de la mémoire parce que si les développeurs font attention il n'y a pas de problème…

                      Pour la gestion mémoire, en statique : cppcheck, en dynamique : valgrind; et il doit y en avoir plein d'autres. Concernant le RAII, pointeur intelligent, move-semantic tout ça, le compilateur détecte et garantie effectivement pas mal de choses. Après quand on commence à taper dans le bas-niveau, on perd forcément beaucoup de garanties et c'est aussi le cas avec Rust sur les sections unsafe.

                      • [^] # Re: Les avantages de C++ ne sont pas bien différentes avec Rust

                        Posté par  . Évalué à 3. Dernière modification le 15 août 2018 à 18:05.

                        Ensuite, le "C++ moderne" c'est C++11 et ça fait déjà 7 ans.

                        Oui, mais un écosystème ça met potentiellement un temps encore plus important à se mettre en branle. 2011 c'est la date de sortie de la spec, il faut que les compilateurs arrivent (ça arrivent assez vite parce qu'ils font le travaille en avance de phase), que c'est compilateurs soient dispo dans les distrib' et ensuite il faut faire évoluer l'écosystème et ça n'est vraiment pas un problème trivial quand le changement demande à casser la compatibilité (l'intérêt du C++ c'est sa compatibilité à toute épreuve ?).

                        Et si vraiment tu dois t'interfacer avec du vieux C++ dégueu ou même du C, bah tu fais comme tout développeur normal et tu codes une classe ou quelques fonctions qui l'encapsule proprement et limite le couplage de code.

                        Dans la liste des arguments comme quoi le C++ est cool il y a :

                        • depuis C++11 on a plus de problème de gestion de la mémoire
                        • on peut s'interfacer avec du C++ comme du C nativement donc réutiliser un écosystème très large

                        Cet interfaçage demande à faire une couche de translation C ou C++98 vers C++11. Hors ces 3 langages sont presque totalement compatibles donc il est assez subtile de s'assurer que l'on ne leak pas du C dans le reste de ton programme. Une méthode C++98 qui te retourne un objet dont les méthodes manipulent des pointeurs nus. Tu va devoir proxifier l'ensemble de l'objet en tenant potentiellement compte de l'overhead que tu introduit (c'est important pour un langage dont l'un des principaux arguments c'est la performance).

                        Pour la gestion mémoire, en statique : cppcheck, en dynamique : valgrind;[…]

                        cppcheck se contente de voir les bugs, non ? Tu peux lui dire d'interdire l'utilisation des pointeurs nus par exemple ? De bien déprécier tout ce qui a était rendu smell par C++11 ? Ça me paraît compliqué parce que la RAII est de l'ordre du design. Mais s'il le fait c'est génial :)

                        Je sais que j'ennuie au plus haut point ceux qui aiment bien le C++ et qui disent que depuis C++11 le langage est devenu vraiment cool (on pouvait faire des smart pointer intelligents avant), mais pour moi tant qu'un projet tel que C++ Core Guideline n'aura pas véritablement diffusé au sein de la communauté ça restera en langage dangereux. La plupart des fois où on en parle j'ai comme réponse qu'il faut suivre les bonnes pratiques, mais chacun a un peu les siennes et les rendre contraignantes (que le build ne passe pas si on les viole) est nécessaire. J'ai pas de doute que vous écrivez du code de qualité, que vous connaissez les bonnes pratiques, que vous suivez l'évolution du C++, mais il y a des fois où vous êtes fatigués, des fois c'est juste un truc qui vous a échappé, une subtilité dans le code qui ne se voit pas facilement,…1

                        1. soyez humble, mais les développeurs du noyau linux, qui utilisent un langage simple et qui ont un processus de revu drastique laissent des fois passer des choses. ↩

                        • [^] # Re: Les avantages de C++ ne sont pas bien différentes avec Rust

                          Posté par  (Mastodon) . Évalué à 7. Dernière modification le 15 août 2018 à 18:39.

                          Cet interfaçage demande à faire une couche de translation C ou C++98 vers C++11. Hors ces 3 langages sont presque totalement compatibles donc il est assez subtile de s'assurer que l'on ne leak pas du C dans le reste de ton programme. Une méthode C++98 qui te retourne un objet dont les méthodes manipulent des pointeurs nus. Tu va devoir proxifier l'ensemble de l'objet en tenant potentiellement compte de l'overhead que tu introduit (c'est important pour un langage dont l'un des principaux arguments c'est la performance).

                          Là, tu racontes absolument n'importe quoi. Faire une surcouche C++ d'une bibliothèque en C, ça améliore la sûreté d'utilisation de la bibliothèque en C sans ajouter aucun overhead. Petit exemple, disons que j'ai une bibliothèque C avec des fonctions de ce genre:

                          struct foo;

struct foo *foo_create(int foo_param);
void foo_delete(struct foo *f);

void foo_do_something(const struct foo *f);

                          Je fais ma surcouche de la manière suivante:

                          class Foo {
public:
  Foo(int foo_param)
  : m_f(foo_create(foo_param))
  {
  }

  ~Foo() {
    if (m_f) {
      foo_delete(m_f);
    }
  }

  // j'interdis les copies parce que l'API de base ne permet pas de copier l'objet
  Foo(Foo&) = delete;
  Foo& operator(Foo&) = delete;

  // j'autorise le transfert de propriété
  Foo(Foo&& other)
  : m_f(std::exchange(other.m_f, nullptr))
  {

  }

  Foo& operator=(Foo& other) {
    std::swap(m_f, other.m_f);
  }

  void doSomething() const {
    foo_do_something(m_f);
  }

private:
  foo *m_f;
};

                          Comme tout va être inliné, je n'ai aucun overhead, et je m'assure que le destructeur fait bien son boulot dans tous les cas. Et du point de vue du programmeur C++, il n'y aucun pointeur venu du C à gérer, c'est totalement transparent.

                          • [^] # Re: Les avantages de C++ ne sont pas bien différentes avec Rust

                            Posté par  . Évalué à 1. Dernière modification le 16 août 2018 à 00:13.

                            Là, tu racontes absolument n'importe quoi.

                            Si tu as :

                            struct foo {
    struct bar *bar_create();
    void add_bar(struct bar *b);
};

struct foo *foo_create(int foo_param);
void foo_delete(struct foo *f);

void foo_do_something(const struct foo *f);

                            Ton héritage continuera d'exposer les méthodes que tu veux cacher. Pire encore si cette classe foo évolue tu va récupérer du code de manière totalement transparente.

                            Mais surtout, j'ai parlé d'un potentiel overhead. Je dis qu'il faut y faire gaffe.

                        • [^] # Re: Les avantages de C++ ne sont pas bien différentes avec Rust

                          Posté par  (site web personnel) . Évalué à 2.

                          Oui, mais un écosystème ça met potentiellement un temps encore plus important à se mettre en branle. 2011 c'est la date de sortie de la spec, …

                          La norme a été finalisée en 2011 mais elle a été discutée pendant des années et une grosse partie des fonctionnalités était déjà implémentée dans les compilateurs.

                          l'intérêt du C++ c'est sa compatibilité à toute épreuve ?

                          Quasiment, oui. Il me semble qu'un code C++98/03 compile bien en C++11. Après certains compilateurs n'implémentaient pas parfaitement les normes pré-C++11 (je ne citerai pas de nom…) et donc des erreurs tolérées avant ne passaient plus sur la nouvelle version. Mais ça c'est un problème de compilateur, pas du langage.

                          le C++ est cool

                          Non, le C++ est juste un outil avec des avantages et des inconvénients.

                          Cet interfaçage demande à faire une couche de translation C ou C++98 vers C++11. Hors ces 3 langages sont presque totalement compatibles donc il est assez subtile de s'assurer que l'on ne leak pas du C dans le reste de ton programme.

                          Oui c'est le principe de la compatibilité. Si tu veux compiler du C ou du C++98 directement dans du C++11, tu peux. Si tu veux interfacer proprement, tu peux. Tu aurais voulu quoi ? Que le C++11 interdise tout code antérieur et demande de tout réécrire en Rust ? Quand tu appelles du code C depuis le FFI, Rust ne vérifie pas non plus magiquement que ce code est sûr.

                          cppcheck se contente de voir les bugs, non ?

                          Je ne sais pas ce que tu appelles bugs mais cppcheck est capable de détecter des problèmes comme les fuites mémoires. Je ne pense pas que ce soit fiable à 100% cependant.

                          Tu peux lui dire d'interdire l'utilisation des pointeurs nus par exemple ? De bien déprécier tout ce qui a était rendu smell par C++11 ?

                          Interdire des fonctionnalités n'est pas la "façon de penser" de C++ et ça casserait la compatibilité.

                          ça restera en langage dangereux

                          Oui c'est vrai. Et c'est le cas de tous les langages qui autorisent du bas niveau, même de Rust en unsafe. Maintenant on peut en discuter des heures mais il n'y a pas de langage parfait (à part haskell installé par nix sur minix, bien-sûr), il faut forcément faire des compromis qui forcément ne plairont pas à tout le monde.

                          • [^] # Re: Les avantages de C++ ne sont pas bien différentes avec Rust

                            Posté par  . Évalué à 3.

                            Ça va les sophismes…

                            Tu commence bien en coupant ma phrase… M'enfin bref…

                            La norme a été finalisée en 2011 mais elle a été discutée pendant des années et une grosse partie des fonctionnalités était déjà implémentée dans les compilateurs.

                            C'est exactement ce que je dis dans ce que tu as remplacer par "…".

                            Non, le C++ est juste un outil avec des avantages et des inconvénients.

                            Si il l'est et Serge sans paille nous le montre régulièrement.

                            Cet interfaçage demande à faire une couche de translation C ou C++98 vers C++11. Hors ces 3 langages sont presque totalement compatibles donc il est assez subtile de s'assurer que l'on ne leak pas du C dans le reste de ton programme.

                            Oui c'est le principe de la compatibilité. Si tu veux compiler du C ou du C++98 directement dans du C++11, tu peux. Si tu veux interfacer proprement, tu peux. Tu aurais voulu quoi ? Que le C++11 interdise tout code antérieur et demande de tout réécrire en Rust ? Quand tu appelles du code C depuis le FFI, Rust ne vérifie pas non plus magiquement que ce code est sûr.

                            Il pourrait très bien me permettre de compiler certains fichiers dans un mode compatible C/C++98 et compiler le reste dans un mode strict. J'ai pas besoin que ce soit le compilateur ça peut être un outil qui répond 1 ou 0 et ça me permettrais de maitriser où est-ce que j'utilise ou non des fonctionnalités particulièrement dangereuse (soit pour m'assurer que c'est limité soit pour switcher progressivement de l'un vers l'autre). Ça ne casse en rien la compatibilité le code généré peut être identique c'est juste dans les étapes de vérifications qu'il y a une différence.

                            Je ne sais pas ce que tu appelles bugs mais cppcheck est capable de détecter des problèmes comme les fuites mémoires. Je ne pense pas que ce soit fiable à 100% cependant.

                            Il ne te dis pas que là tu devrait utiliser du RAII.

                            Interdire des fonctionnalités n'est pas la "façon de penser" de C++ et ça casserait la compatibilité.

                            C'est ce que les développeurs font ! Les développeurs C++ s'interdisent des pans de la norme pour certains les exceptions pour d'autres les pointeurs nus. Que ce soit fait par le compilateur ou un quelconque outil d'analyse statique je m'en fous, mais si ça n'est pas outillé c'est à la responsabilité des développeurs et c'est forcément moins fiable que si c'était un outil.

                            De plus les compilateurs ne se gênent pas pour ajouter de nouveaux warning ce qui peu potentiellement ça suffirait amplement. Toujours pas besoin de casser la compatibilité.

                            Oui c'est vrai. Et c'est le cas de tous les langages qui autorisent du bas niveau, même de Rust en unsafe. Maintenant on peut en discuter des heures mais il n'y a pas de langage parfait (à part haskell installé par nix sur minix, bien-sûr), il faut forcément faire des compromis qui forcément ne plairont pas à tout le monde.

                            Bla bla bla. Les autres aussi ne sont pas parfait donc on a le droit de… Bref

                            La gestion de la mémoire en C++ est dangereuse particulièrement car l'utilisation correcte du RIAA est à la charge du développeur, s'assurer qu'il le fait bien est un travaille continue de l'équipe. Là où un énorme paquet de langage vont faire quelques trucs pour te contraindre (être plus sécurisés par défaut, t'obliger à écrire juste avant « attention je suis peut être entrain de faire une grosse connerie ici ! », etc). Si tu ne souhaite pas voir l'importante différence qu'il y a entre ces approches, c'est dommage.

                            Mais se poser la question de comment industrialiser la qualité d'une base de code ce n'est pas insulter le langage, hein ?

                            • [^] # Re: Les avantages de C++ ne sont pas bien différentes avec Rust

                              Posté par  (site web personnel) . Évalué à 0.

                              Bon d'accord, tu as raison : C++ est un langage géré n'importe comment, qui provoque systèmatiquement des fuites mémoires, qui n'a pas d'outils d'analyse corrects et qui fait du lobbying pour empêcher le monde d'utiliser d'autres langages bien meilleurs. Allez salut.

                            • [^] # Re: Les avantages de C++ ne sont pas bien différentes avec Rust

                              Posté par  . Évalué à 1.

                              La gestion de la mémoire en C++ est dangereuse particulièrement car l'utilisation correcte du RIAA est à la charge du développeur

                              Oh trop dur faut trouver un développeur qui réfléchit… Même java se rends compte que l'absence de cette fonctionnalité est gênante et se mette à avoir du try with ( Closable… )

                              Mais merde quoi, faut que les gens soient un minimum formés; et quand on fait une liste pour stocker les messages entrant, il faut à un moment se poser la question de fréquence, taille et nombre qu'on stock. C'est une problématique qui n'est pas nouvelle; mais j'ai l'impression qu'avec la grande quantité de RAM à pas cher on omet de contrôler ce détail.

                              En c++ tu écrivais un new, il fallait nécessairement se poser la question du delete, et ça pouvait vite tourner au cauchemar pour peu que la suite pouvait péter des exceptions en cour de route, et encore… un dev avisé pouvait se servir d'auto_ptr

                              maintenant c'est encore plus simple avec uniq_ptr.

                              La RAII, c'est un peu fermer ta connexion quand tu n'en a plus besoin (coucou les finally, closable maintenant), et merci aux ftp limités à 5 connexions, c'est aussi ces même mécanisme qui te permettent d'avoir un logger sax qui va pas te laisser un xml invalide (ou faux) parce que tu as pété là où tu ne le pensais pas.

                              Et c'est loin d'être les seuls exemples, mais un mauvais codeur trouvera toujours le moyen de faire de la merde; et s'il ne se pose déjà pas les bonnes questions faut peut être en changer ;)
                              Par contre effectivement avoir un Warning : you used new operator, this is so old school, serait pas mal

                              Il ne faut pas décorner les boeufs avant d'avoir semé le vent

            • [^] # Re: Les avantages de C++ ne sont pas bien différentes avec Rust

              Posté par  (Mastodon) . Évalué à 4.

              Au final, il faudrait quoi du coup pour faire changer les mentalités à propos du C++ ?

              Et il faut aussi s'excuser de continuer à faire du C++ ? Franchement, C++ a des défauts, personne ne dit le contraire, il a aussi des qualités, il a un écosystème gigantesque, c'est un standard international qui évolue très activement, il a trois compilateurs majeurs, il a une gestion bas niveau de la mémoire (oui, pour certains, c'est un avantage), il a une tétrachiée de bibliothèques disponibles pour tout et son contraire (en incluant les bibliothèques en C puisqu'elles sont quasiment directement utilisables en C++). Il faut quoi de plus ?

            • [^] # Re: Les avantages de C++ ne sont pas bien différentes avec Rust

              Posté par  (site web personnel) . Évalué à 3. Dernière modification le 15 août 2018 à 14:20.

              il faut du C++ parce qu'il y a actuellement du C++, donc demain il faudra du C++ car hier on avait du C++

              Tu peux dénigrer l'argument autant que tu veux, mais fait est que dans le monde de l'entreprise, la taille de l'écosystème et la pérennité d'un language sont des arguments prépondérant, que tu le veuilles ou non, car ton manager décidera pour toi.

              Si c'était vendredi, je dirai Et heureusement pour Java sinon il serait mort depuis longtemps.

              • [^] # Re: Les avantages de C++ ne sont pas bien différentes avec Rust

                Posté par  . Évalué à 1.

                La pérennité d'un langage et que dans l'écosystème il y ait ce qu'on souhaite, oui. De même, si t'as un projet sur lequel tout est en C++, il n'y a pas lieu de changer sous prétexte qu'il y a un nouveau langage qui brille.
                Se baser uniquement sur le fait qu'on ait du code dans un langage dans un coin pour justifier que tout ce qu'on fera par la suite sera dans ce même langage, y compris d'autres projets qui n'ont rien à voir, alors qu'un autre langage pourrait parfaitement te satisfaire tout en étant plus simple et plus sûr, tout en ayant les fameux écosystème de grande taille et qu'il ait déjà un paquet d'années, bof. J'ai pointé du doigt un argument qui est donné en boucle… et qui n'est pas lié à un raisonnement valide, ce n'est qu'une justification pour ne jamais rien changer, quelqu'en soit les conséquences, peu importe s'il y aurait effectivement mieux à faire.

                Et je me fiche complètement de l'argument "ouais mé ton manager y ve pa lol", la question ici s'adresse à des gens intelligents qui comprennent les tenants et aboutissants y compris techniques, pas des managers.

                Mais bon, j'ai l'impression de m'embêter pour rien, face à des arguments creux autant s'arrêter de tourner en rond.

                • [^] # Re: Les avantages de C++ ne sont pas bien différentes avec Rust

                  Posté par  (Mastodon) . Évalué à 0.

                  Personne ne t'a jamais empêché de faire un projet en Rust tout seul dans ton coin, et c'est bien comme ça.

                  J'ai pointé du doigt un argument qui est donné en boucle… et qui n'est pas lié à un raisonnement valide, ce n'est qu'une justification pour ne jamais rien changer, quelqu'en soit les conséquences, peu importe s'il y aurait effectivement mieux à faire.

                  Ton argument ne prend pas en compte la réalité. Si tu as tout un tas de gens qui programment en C++ depuis très longtemps, c'est-à-dire qui ont atteint un niveau de productivité en C++ qui permet aux entreprises qui les emploie de faire du profit, quel est l'intérêt de les faire changer de langage ? À part perdre du temps, de l'argent à les former pendant des années avant qu'ils atteignent la même productivité, je ne vois pas. C'est un comportement totalement non-rationnel, quand bien même ton super langage serait top-moumoute.

                  On l'a déjà dit mais C++ a déjà vu passer bon nombre de ces langages révolutionnaires qu'il fallait absolument utiliser tellement ils étaient trop bien et qu'ils allaient remplacer C++. Bizarrement, C++ est toujours là, c'est peut-être, comme on le dit, qu'il n'y a pas que les fonctionnalités remarquables qui comptent, il y a tout le reste.

                  Et je me fiche complètement de l'argument "ouais mé ton manager y ve pa lol", la question ici s'adresse à des gens intelligents qui comprennent les tenants et aboutissants y compris techniques, pas des managers.

                  C'est une question éminemment technique ! Pourquoi crois-tu que Google, Apple, Microsoft et tant d'autres investissent autant de temps et d'argent pour faire avancer le standard C++ ? Ce n'est pas une lubie de managers, c'est bien parce qu'il y a un passif technique et qu'ils préfèrent sans doute faire évoluer l'existant (et donc le langage) plutôt que de passer complètement à un autre langage.

                  Se baser uniquement sur le fait qu'on ait du code dans un langage dans un coin pour justifier que tout ce qu'on fera par la suite sera dans ce même langage

                  Ton raisonnement ne tient pas debout. Du nouveau code est créé chaque jour, dans tout un tas de langage. Rien n'empêche plein de gens de créer plein de code en Rust, Brainfuck ou autre. S'ils ne le font pas, c'est qu'ils ont leurs raisons. Un langage en remplace un autre quand il atteint une masse critique. Rust en est encore loin, très loin. Ce n'est pas parce qu'un langage est «meilleur» qu'un autre qu'il le remplace auto-magiquement (et je mets des guillemets parce que chacun a une définition de «meilleur»).

  • # C++ mon amour

    Posté par  (site web personnel) . Évalué à 9.

    Il y a encore des projets passionnants en C++. Je travaille sur un gros système financier sous fortes contraintes de performance et de latence dont la plus grosse partie sort d'une base de code d'environ 2 million de lignes de C++, dont une grosse moitié est générée via une moulinette maison.

    Pour nous, le C++ a vraiment très bien marché. Nous avons pu utiliser les fonctionnalités du langage pour monter un cadre orienté événements qui fait la part belle à l'héritage multiple: je m'enregistre sur toutes les sources de données qui m'intéressent, et je me fais appeler sur mon objet de manière thread-safe. Comme ces sources de données se ressemblent beaucoup, nous utilisons à fond les templates pour factoriser le code et réduire la duplication. Nous utilisons le plus possible la bibliothèque standard, qui s'est étoffée et est maintenant de très bonne qualité.

    Nous pouvons nous interfacer avec des bases de données en écrivant des adapteurs RAII autour de leurs API C, avec des variadic templates pour avoir des types sûrs, nous avons un accès bas niveau sur le disque et sur le réseau, et pouvons bénéficier de tout un tas d'outils de mesure de performances, de Valgrind à gprof en passant par Intel VTune. Nous utilisons même Wt, une bibliothèque qui propose la création d'applications Web que l'on code comme en QT, pour nos interfaces utilisateurs.

    Comme nous avons la main sur tout ce qui se passe, il est aisé, quand c'est nécessaire, de descendre aussi bas que voulu: éviter les allocations, faire attention au principe de localité, voire tenter de transformer les "if" pour réduire les branches.

    Tout cela est également possible en Java, par exemple, mais éviter les allocations en Java présuppose de passer par des réservoirs d'objets et devient rapidement moche. Avec le C++, nous arrivons souvent à encapsuler ces constructions très bas niveau derrière de belles interfaces afin de garder un ensemble propre et bien architecturé.

    • [^] # Re: C++ mon amour

      Posté par  (site web personnel) . Évalué à 3.

      Nous utilisons même Wt, une bibliothèque qui propose la création d'applications Web que l'on code comme en QT, pour nos interfaces utilisateurs.

      Intéressant, je ne connaissais pas. Pourtant, j'ai cherché. En fait, j'étais tombé dessus, mais je me suis fait avoir par alternativeTo, qui présente Wt comme une alternative à Apache, nginx, lighttpd… donc j'ai cru que Wt est un serveur web…

      Est-ce que Wt propose un langage descriptif d'interface, comme QML pour Qt, ou est-ce qu'il faut construire l'interface programmatiquement, élément par élément ? Personnellement, je préfère partir d'un fichier qui décrit globalement l'interface (j'utilise HTML(/CSS)), même pour des applications avec interface bureau. C'est cette approche que j'ai choisie pour le projet dont j'ai donné le lien dans mon précédent commentaire, et qui à le même but que Wt, sauf qu'il n'a pas (encore) d'API C++, bien que ce soit le langage avec lequel il est codé. Si j'avais eu connaissance de Wt, peut-être que je ne me serais pas lancé dans ce projet…

      Cyberdépendance, cyberharcèlement, pédocriminalité… : Zelbinium, pour que les smartphones soient la solution, pas le problème !

      • [^] # Re: C++ mon amour

        Posté par  (site web personnel) . Évalué à 3.

        Non Wt ne s'utilise qu'en C++ pur, il faut écrire du code C++ pour générer des interfaces. Ce que je n'aime pas trop avec ces frameworks c'est l'inclusion de code javascript maison automatiquement sans aucun contrôle dessus dans les pages générées.

        J'ai testé plusieurs frameworks web en C++ dont Wt, cppcms qui est plutôt bon mais je n'ai pas trop aimé son système de templates.

        Et comme Boost a rajouté un nouveau module HTTP je me suis dit que j'allais coder mon service de pastebin en C++, je l'ai terminé en environ deux jours. J'ai utilisé mstch pour génerer mes pages web et j'adore.

        Seul hic, Beast n'a pas encore de parseur URL mais le développeur principal a dit que c'était prévu.

        git is great because linus did it, mercurial is better because he didn't

  • # TIOBE

    Posté par  . Évalué à 1.

    Vous avez commencer à discuter il y a longtemps apparemment, parce que la courbe TIOBE actuelle, c'est ça:

    TIOBE 2018

    • [^] # Re: TIOBE

      Posté par  . Évalué à 3.

      Bon évidemment, je n'ai pas réussi à incorporer correctement l'image. Elle est bien sur visible ici: TIOBE

      • [^] # Re: TIOBE

        Posté par  (site web personnel) . Évalué à 3.

        Je trouve la chute puis remontée du C très bizarre. Je me demande à quel point ces données sont fiables …

        • [^] # Re: TIOBE

          Posté par  (site web personnel) . Évalué à 7.

          Elles ne sont pas très fiables. Par exemple, si tu prends l'évolution de Go sur TIOBE, ça n'a pas grand sens : https://www.tiobe.com/tiobe-index/go/. Ça aurait baissé entre 2010 et 2012, puis stable jusqu'à mi-2016, ensuite un grand boom sur quelques mois et depuis ça rebaisse. En vrai, ça a plutôt été tout le temps en croissance.

          Ça permet quand même d'avoir une petite idée des tendances, surtout qu'on croise ça avec d'autres sources. Redmonk publie un classement à partir de données provenant de Github et de Stack Overflow (ça doit probablement favoriser les langages récents). PYPL a aussi un classement, à partir des données de Google Trends et avec seulement 22 langages.

          Ça permet de se rendre compte que JavaScript a beaucoup progressé en une décennie, alors que Perl a beaucoup baissé, ou que Swift est passé devant Objective-C, mais il ne faut pas accorder trop d'importance à tel langage est à telle place.

          • [^] # Re: TIOBE

            Posté par  (site web personnel) . Évalué à 4. Dernière modification le 28 juillet 2018 à 20:45.

            En fait, on parle de progression régression en terme de pourcentage… Par exemple, la part du RAIL dans le transport de marchandise diminue MAIS en pratique, le tonnage transporté par rail augmente chaque année (d'où peut être la tendance à mettre les passagers dans les cars et les avions).

            Bref, les régressions sont peut être juste relative ;-)

  • # À la fois troll, à la fois fait divers

    Posté par  . Évalué à 2.

    Hello,

    <megatroll nuance="quoi que ... pas que ...">

    Le C++, c'est pour ceux (dont je fais partie bien entendu !) qui savent ce qu'ils manipulent. Les langages comme Java ont été créés pour "produire" du programmeur à la chaîne.
    Ce qui peut donner, et c'est le témoignage véridique d'un pote adminsys, des batchs journaliers qui prennent plus de 24 heures pour s'achever. Oui, relisez : journalier … > 24 h …
    Ces "ptits cons" font attention à rien !

    Autre exemple perso, quand j'étais en intercontrat, j'ai bricolé un peu de Java sur ordre de mon patron (il voulait que je devienne une référence ! Ah ces SSII …). J'ai trouvé marrant de coder un ptit bout de code qui résous les sudoku en force brute : on lui file une grille à trou, il cherche toutes les solutions possible; on lui file une grille vide, il cherche tout les sudoku de l'univers. Et quand j'ai eu terminé la version Java, je me suis dis : hum, ça se traîne un peu cette histoire, qu'est-ce que ça donnerait en C++ ?
    Hop, c'est parti, version C++ et premier tests : dedju, la vache, ça arrache !
    J'ai plus les chiffres exacts en tête, mais la version C++ est 100 fois, 1000 fois plus rapide au moins.

    Alors, quels enseignements tirer de cette expérience ?
    Aucun !
    Je n'ai pas écrit la version Java comme j'ai écrit la version C++.
    En Java, comme je ne suis pas (plus) un "ptit con" (depuis longtemps ! Je suis un vieux con maintenant !), j'ai pondu du code "propre", lisible.
    En C++, j'ai pondu du code optimisé en utilisant plein d'astuces de manipulation de bits, etc.
    Est-ce qu'on peut optimiser mon Java comme le C++ ? J'en doute.
    Et dans les deux cas, c'était naturel de procéder de la sorte.

    Autre exemple : IoT. J'ai perdu une bataille sur un projet devant tourner sur un Pico-Pi / i.MX7D (un truc qui ressemble à un Raspberry Pi mais de loin seulement). Je devais "fabriquer" l'OS Linux et développer la partie "métier" qui cause I2C et GPIO.
    La solution royale, c'est Yocto, mais pour tout un tas de raison, c'est devenu une galère monumentale (*).
    Alternative : Buildroot, beaucoup plus direct, configurable par make menuconfig & cie. Problème : le système qui en résulte est très "raw" et il reste pas mal de boulot pour faire fonctionner l'écran du kit, avoir un environnement graphique potable (Qt5), et tout un tas de petits détails.
    Du coup, je me suis vu imposé Android Things. Mon collègue des App Mobile va s'occuper de la partie IHM.
    Et moi, je m'occupe de la partie I2C et GPIO.
    En Java.
    Avec le type byte qui est signé et donc de -128 à + 127.
    unsigned ? Java connaît pas, faut caster en short pour passer à l’intervalle [-32768..32767]. Je vous raconte pas la lourdeur de ces conneries. Faut recoder une arithmétique unsigned alors que le langage n'a que des types signed. Aberrant !

    Bref …

    Alors, derrière la question "Faut‐il continuer à apprendre le C++ ?", est-ce que ce n'est pas plutôt la sempiternelle question "quel est le meilleur langage ?" … Bien tenté, j'ai plongé et j'ai écrit mon troll à moi ! Merci, ça fait du bien, c'est comme une thérapie !

    Non, mais, essayez un peu de faire la liste des langages existant … impossible hein ? Je pense qu'un choix dépend de tellement de paramètres que ça ne sert à rien de se poser la question : contexte, historique à garder ou pas, expérience perso des programmeurs, décision du chef qui a lu un truc sur le nouveau langage Rouille dans 01 et qui veut briller en réunion en disant que son équipe utilise les nouvelles techno … Et j'en oublie beaucoup certainement.

    Moi, tant que je continue à prendre mon pied SM à coder …

    (*) les raisons : Yocto lui-même, on m'a refilé le mauvais point de départ (mauvais GitHub TechNexion), etc.
    Et quel putain de sac de nœuds ce Yocto ! Je ne comprends pas que ce soit utilisé en embarqué. Impossible de garantir que deux builds à partir de la même base soient identiques.
    Et si quelqu'un connaît un "Yocto pour les nuls", un "Que sais-je / Yocto", je suis prenneur.
    Pour le moment, les "outils" que j'utilise le plus dans ce contexte, c'est find et grep !

    </megatroll>

    • [^] # Re: À la fois troll, à la fois fait divers

      Posté par  (site web personnel, Mastodon) . Évalué à 6.

      Et moi, je m'occupe de la partie I2C et GPIO.
      En Java.
      Avec le type byte qui est signé et donc de -128 à + 127.

      Ah ah ah ! Tu viens de réveiller un très vieux souvenir :)

      Dans les années 80, je travaillais dans le labo R&D d'une boite qui fabriquait des machines de traitement d'image. Et un jour, un des commerciaux de la boite débarque avec un grand sourire : « ouééé, les mecs, j'ai vendu un truc, vous allez vous éclater, il faut concevoir un hardware spécialisé, toussa ».

      Et nous, dans le labo, on aimait bien ça, faire des cartes de traitement d'image, donc grand sourire. On regarde le cahier des charges, on envisage plusieurs solutions : logique cablé, microcode, processeur dédié, vous voyez le genre de délire… Que du bonheur d'électroniciens/codeurs sauvages…

      Quelques jours plus tard, on demande des précisions sur ce que doit être le logiciel applicatif souhaité par le client. La réponse a été cinglante : « le client veut développer en Pascal ». En Pascal Intel. En Pascal académique, quoi…

      [-128..127], va traiter du pixel avec ça…

    • [^] # Re: À la fois troll, à la fois fait divers

      Posté par  (site web personnel) . Évalué à 9.

      La guerre du "c'est qui le plus rapide" entre C++ et Java est terminée depuis un bout de temps.

      Un code bien écrit en Java est en moyenne plus lent (de l'ordre de 10 %) car la JVM doit interpréter les instructions et compiler à la volée les méthodes les plus pénalisantes pour les performances.
      Je parle de moyenne ici, il y a des cas (rares) ou Java sera beaucoup plus lent qu'un code ultra optimisé en C++ mais il sait être plus rapide dans certains cas (car la JVM est capable de générer du code machine mieux optimisé car elle a plus de contexte à l'exécution qu'un compilateur), ce n'est pas un mythe.
      Les allocations mémoires en Java sont aussi beaucoup plus rapides qu'en C/C++.
      Des centaines de benchmarks sont disponibles sur internet pour qui chercherait des chiffres précis.

      Concernant le fait qu'il n'y ait pas de 'unsigned' en Java, c'est effectivement embêtant pour l'écriture du code mais en runtime cela n'a pas d'impact. Quand on pense que la gestion des 'unsigned' était prévue en Java 1.0 mais viré à la dernière minute car "pas le temps"…

      Et si on parlait aussi du nombre de crash sans stacktrace et du temps de développement lors de la création de votre programme C++ ?

      Avec 10 ans d’expérience en C++ et 20 en Java, de mon point de vue, le plus gros "gap" entre les 2 n'est pas tant le langage que les outils autours. Rien dans le monde C++ n'égale le trio Java/Eclipse/JProfiler.

      Faut-il apprendre C++ de nos jours : OUI. Cela permet d'apprécier Java ;)

      • [^] # Re: À la fois troll, à la fois fait divers

        Posté par  (site web personnel) . Évalué à 1.

        Des centaines de benchmarks sont disponibles sur internet pour qui chercherait des chiffres précis.

        J'aimerais bien que tu donnes des liens car ce n'est pas vraiment ce que dit la page wikipedia : https://en.wikipedia.org/wiki/Java_performance. De plus, parmi les appli ou lib qui ont besoin de performances, j'en connais beaucoup qui sont codées en C++ (tensorflow, v8, electron…) mais très peu en Java.

        Rien dans le monde C++ n'égale le trio Java/Eclipse/JProfiler.

        C'est vrai : dans le monde C++ le Java n'est pas bien géré… Et sinon tu connais visual studio, clion, qtcreator, xcode… ?

        • [^] # Re: À la fois troll, à la fois fait divers

          Posté par  . Évalué à 4. Dernière modification le 29 juillet 2018 à 00:57.

          De plus, parmi les appli ou lib qui ont besoin de performances, j'en connais beaucoup qui sont codées en C++ (tensorflow, v8, electron…) mais très peu en Java.

          Netty, lucene, vertx, ratpak, lagom, énormément de l'écosystème big data (Cassandra, hazelcast, hadoop, spark, storm,…). Kafka et akka sont écrits en scala et utilisent donc la même jvm et le même jit.

          • [^] # Re: À la fois troll, à la fois fait divers

            Posté par  (site web personnel) . Évalué à 4.

            Des trucs comme Kafka et akka, sont surtout IO bound, donc cela concerne surtout la qualité des lib réseau et disque.

            "La première sécurité est la liberté"

            • [^] # Re: À la fois troll, à la fois fait divers

              Posté par  . Évalué à 2.

              Akka ? Je ne suis pas certain c'est un modèle de programmation parallèle. Oui il génère beaucoup de communication entre les acteurs, mais les acteurs ne sont pas mappés sur des threads système. Du coup c'est le runtime qui fais tout le boulot de communication. Je ne suis pas un spécialiste, mais je ne crois pas qu'il y ai une entrée ou une sortie du processus (ou du thread système) lors d'un passage de message simple (mais je peux totalement me tromper).

              • [^] # Re: À la fois troll, à la fois fait divers

                Posté par  (site web personnel) . Évalué à 3.

                J'ai écrit un peu vite. Je ne connais pas Akka. Pour cassandra, il y a une tentative de réécriture en C++ qui annonce des perf bien supérieur à la version d'origine.

                "La première sécurité est la liberté"

                • [^] # Re: À la fois troll, à la fois fait divers

                  Posté par  . Évalué à 1. Dernière modification le 30 juillet 2018 à 12:47.

                  ScyllaDb ? Je ne sais pas où ça en est mais au début ils avaient des problèmes de résilience (ce qui est dommage pour une base de données sont c'est le principal intérêt). Mais c'était il y a 3 ans ça a pu évoluer.

                  Mais je suis d'accord que c'est pas CPU bound. C'est pour ça que le C++ n'a pas un si grand intérêt amha et que Cassandra vie toujours très bien malgré l'arrivée de Scylla

                  • [^] # Re: À la fois troll, à la fois fait divers

                    Posté par  (site web personnel) . Évalué à 2. Dernière modification le 14 août 2018 à 23:44.

                    ScyllaDb ? Je ne sais pas où ça en est mais au début ils avaient des problèmes de résilience (ce qui est dommage pour une base de données sont c'est le principal intérêt). Mais c'était il y a 3 ans ça a pu évoluer.

                    Pour l'avoir utilisé, ScyllaDB est un monstre de qualité et de complexité designé par des programmeurs C++ dans le top 0.5% des meilleurs disponibles au monde je dirai….. Ce genre de code n'est pas accessible au premier venu.

                    Mais le résultat parle de lui même, ScyllaDB démonte littéralement Cassendra en terme de performance sur tous les points de vues ( Latence, Throughtput, Scalabilité ).

                    Ce qui n'est pas forcément étonnant quand tu vois qu'ils ont réimplémenter leur propre stack TCP en user-space et leur propre model de threading….

                    • [^] # Re: À la fois troll, à la fois fait divers

                      Posté par  . Évalué à 2.

                      Tu parle de Seastar? Ça a l'air d'être un framework réactif avec une event loop en c++. Encore un bon exemple pour le discussion qu'on avait sous mon précédent journal :-)

                      • [^] # Re: À la fois troll, à la fois fait divers

                        Posté par  (site web personnel) . Évalué à 3.

                        Ça a l'air d'être un framework réactif avec une event loop en c++.

                        C'est beaucoup plus que ça si tu regardes en détail. C'est un mélange de ce que tu peux faire avec boost.Fibers, un système d'I/O a la boost.Asio mais zero sharing et message passing. Ca see rapproche de ce que fait CAF ( c++ actor framework ) mais très orienté performance ( et pas mal bloated )

        • [^] # Re: À la fois troll, à la fois fait divers

          Posté par  (site web personnel) . Évalué à 3.

          Pas besoin de refaire la bataille, le C++ (et le C) est gagnant de quelques pourcents.
          Pour les calculs scientifiques, cela se vérifie avec scimark2 (FFT, calcul matriciel… ) http://scribblethink.org/Computer/javaCbenchmark.html

          Ne connaissant pas clion, je peux te répondre sur les 3 autres que j'ai pu utiliser pour de vrais projets. Leur debuggers ne rivalisent pas avec celui d'Eclipse, la raison technique est simple : le fait de pouvoir discuter avec la JVM permet de tout contrôler et d'avoir un état complet et fiable de tous les threads, des "stacktraces" et des objets.

          Pour JProfiler, c'est exactement la même chose, mais une vidéo sera plus parlante : https://www.youtube.com/watch?v=032aTGa-1XM et ce n'est qu'une toute petite partie des possibilités.
          J’apprécie aussi beaucoup d'avoir une vue d'ensemble chronologique (en temps réel) sur les attentes liés aux IO et aux locks.

          Pour Eclipse vs les autres, en C++ les IDE ne peuvent pas faire de miracle pour le refactoring ou la complétion à cause principalement des void** et des directives de preprocessing.

          Je pense que la seule vraie façon d’appréhender les avantages du trio Java/Eclipse/JProfiler est de l'utiliser dans un projet conséquent.

          • [^] # Re: À la fois troll, à la fois fait divers

            Posté par  (site web personnel) . Évalué à 1.

            Et pour les cas où il faut diagnostiquer des lenteurs sur un serveur sans rien toucher ni perturber : https://www.youtube.com/watch?v=tYieP2s34YI . Bon courage pour faire ça en C++ :)

            • [^] # Re: À la fois troll, à la fois fait divers

              Posté par  (site web personnel) . Évalué à 2.

              Leur debuggers ne rivalisent pas avec celui d'Eclipse, la raison technique est simple : le fait de pouvoir discuter avec la JVM permet de tout contrôler et d'avoir un état complet et fiable de tous les threads, des "stacktraces" et des objets.

              Je ne suis pas un grand fan des debugger mais il me semble que n'importe quel debugger C++ digne de ce nom est capable d'inspecter les threads, stacktraces et objets.

              Pour JProfiler, c'est exactement la même chose, mais une vidéo sera plus parlante : https://www.youtube.com/watch?v=032aTGa-1XM et ce n'est qu'une toute petite partie des possibilités.

              Merci pour l'info, je ne savais pas qu'on peut faire des memory leaks en Java… Sinon il y aussi des profilers et des analyseurs de mémoire en C++. Les outils open-source sont souvent austères mais il y a aussi des outils proprio très bien faits.

              Pour Eclipse vs les autres, en C++ les IDE ne peuvent pas faire de miracle pour le refactoring ou la complétion à cause principalement des void** et des directives de preprocessing.

              A peu près personne ne programme en C++ avec des void**. Pour les directives de preprocessing, déjà c'est relativement rare ou limité; ensuite ça doit effectivement pouvoir être génant sur du refactoring mais pour la complétion, je ne vois pas quels problèmes ça peut poser (à moins d'avoir un code vraiment mal conçu).

              Et pour les cas où il faut diagnostiquer des lenteurs sur un serveur sans rien toucher ni perturber : https://www.youtube.com/watch?v=tYieP2s34YI . Bon courage pour faire ça en C++ :)

              C'est vrai que c'est difficile de diagnostiquer la JVM en C++… Beaucoup de profilers C++ sont également capables de se connecter à un programme à distance et au pire tu peux diagnostiquer directement le système, vu que l'exécution est native.

            • [^] # Re: À la fois troll, à la fois fait divers

              Posté par  (site web personnel) . Évalué à 1.

              Bon courage pour faire ça en C++ :)

              Y a une 50ène de solutions qui existent pour remote débugger un programme en C++, ou même le profiler en temps réel sur un serveur en prod.

              Incluant des softs qui fonctionne du supercalculateur, ou cluster trés large scale avec GUI & co ….

      • [^] # Re: À la fois troll, à la fois fait divers

        Posté par  (site web personnel) . Évalué à 2. Dernière modification le 14 août 2018 à 23:47.

        Et si on parlait aussi du nombre de crash sans stacktrace et du temps de développement lors de la création de votre programme C++ ?

        Un snippet de 50 lignes de code que tu trouves dans un peu prêt tous les lib utilities C++ digne de ce nom peut te donner les stack trace en C++ si tu les veux.

        Mais un programme C/C++ qui crash, il "stack-trace" pas… Il coredump… C'est différent…. Ce qui te donne ta "trace".

    • [^] # Re: À la fois troll, à la fois fait divers

      Posté par  (site web personnel) . Évalué à 1.

      Je devais "fabriquer" l'OS Linux et développer la partie "métier" qui cause I2C et GPIO.
      La solution royale, c'est Yocto, mais pour tout un tas de raison, c'est devenu une galère monumentale (*).
      Et quel putain de sac de nœuds ce Yocto !

      Ah, ça. On est loin de l'élégance d'une poudriere.

      Je ne comprends pas que ce soit utilisé en embarqué. Impossible de
      garantir que deux builds à partir de la même base soient identiques.

      Curieux, j'ai l'expérience inverse, si l'on ne change rien, on obtient strictement la même image.

      Et si quelqu'un connaît un "Yocto pour les nuls", un "Que sais-je / Yocto", je suis prenneur.

      Je conseillerais celui là
      * http://book.yoctoprojectbook.com/

      mais uniquement pour débuter. Il faut, en fait, rapidement connaître et maîtriser la hiérarchie de répertoires créé sous Yocto. Bref, savoir où bitbake va coller ses fichiers.

      Pour un usage avancé, les difficultés ne sont pas dues à yocto, selon moi, mais à linux et son écosystème.
      - et à tous ceux qui utilisent CMake ou autre bidules pas foutu de gérer proprement la cross-compilation.-

      Alternative : Buildroot, beaucoup plus direct, configurable par make menuconfig & cie.

      pareil:

      bitbake nom-du-noyau menuconfig

      • [^] # Re: À la fois troll, à la fois fait divers

        Posté par  (site web personnel) . Évalué à 3. Dernière modification le 30 juillet 2018 à 13:23.

        et à tous ceux qui utilisent CMake ou autre bidules pas foutu de gérer proprement la cross-compilation.

        Tu es sérieusement entrain de dire que CMake ne gère pas proprement la cross compilation ?

        Parce que -pour info-, voici les seules variables minimum à définir juste pour compiler pour android :

        cmake .                                   \
    -DCMAKE_SYSTEM_NAME=Android           \
    -DCMAKE_SYSTEM_VERSION=21             \
    -DCMAKE_ANDROID_NDK=/opt/ndk-bundle

        Sans compter qu'il y a d'autres exemples encore plus concis

        git is great because linus did it, mercurial is better because he didn't

    • [^] # Re: À la fois troll, à la fois fait divers

      Posté par  (site web personnel) . Évalué à 3.

      Et moi, je m'occupe de la partie I2C et GPIO.
      En Java.

      Q? tu peux pas passer en Kotlin ?

      Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141

  • # Conclusion?

    Posté par  . Évalué à 7. Dernière modification le 28 juillet 2018 à 16:09.

    J'ai tout lu et j'ai encore du mal à discerner un message clair.
    Le C++, c'est encore pertinent pour:

    • Les dévs qui le maîtrisent déjà (enfonçage de porte ouverte…)
    • Le code existent qui doit continuer à évoluer
    • Les applis pour lesquelles la perf est critique, mais c'est un outil difficile à manier
    • L'embarqué?
    • Le code glue là où Python n'a pas de solution toute prête

    J'ai bien compris?

    Si je devais ajouter mes 2 cents de non développeur mais de vieux con, je dirais qu'on a vu pas mal de candidats au remplacement du C et du C++, mais qu'ils arrivent et repartent tout doucement sans qu'aucun ne s'impose formellement.
    Je veux dire: D, Vala devaient déjà être la génération de langages de remplacement.
    Objective-C devait remplacer le C++ et était déjà "tellement mieux".
    C# est arrivé présenté comme tel aussi, mais il y a quand même eu un "besoin" de faire Go et Rust.

    La part de Go et Rust peut être biaisée par le support de très grandes organisations, ce qui veut aussi dire que chacun peut s'écrouler si Google ou Mozilla changent leur fusil d'épaule.

    C++ est déclaré vieux et obsolète depuis au moins 10ans. Pourquoi serait-ce plus crédible ce coup-ci?

    • [^] # Re: Conclusion?

      Posté par  (site web personnel) . Évalué à 8. Dernière modification le 28 juillet 2018 à 18:40.

      C++ est en train d'évoluer rapidement, et la façon de coder avec le vieux C++ d'il y a 10 ans (C++98) est différente du C++ d'aujourd'hui.

      Il y a 10 ans, on avait l'impression que le C++ était un langage qui n'évoluait plus. Aujourd'hui, c'est tout un écosystème qui bouillonne, plusieurs compilateurs avec une concurrence positive, des outils de test/vérification très poussés, des optimisations de folie, même du code C++ qui s'exécute dès la compilation pour générer du code qui est pris en compte par le compilateur…

      Je pense que de jeunes diplômés peuvent se lancer dans l'apprentissage du C++ moderne sans regret, s'ils apprécient ce langage bien sûr, sachant que dans plusieurs domaines, le C++17 est le langage le plus adapté.

      Par contre, les développeurs C++ sont les premiers à se plaindre de sa complexité. On veut un C++ qui évolue plus rapidement avec une sémantique qui se simplifie, mais sans sacrifier ni ses performances, ni ses capacités à méta-programmer. Les nouvelles directions à donner à ce vieux langage de 40 ans ne sont donc pas faciles à trancher.

      Aujourd'hui, je ne connais aucun langage qui puisse remplacer pleinement le C++.

      Commentaire sous licence Creative Commons Zero CC0 1.0 Universal (Public Domain Dedication)

      • [^] # Re: Conclusion?

        Posté par  (site web personnel) . Évalué à 7.

        (je tempère mon point de vue ci-dessus)

        Néanmoins, bien que j'apprécie le potentiel du C++
        et que je suis fan des évolutions actuelles du langage,
        je NE recommande PAS souvent de s'orienter vers le C++.

        Pour moi, le désavantage du C++ pour un débutant
        est de devoir y investir beaucoup de temps
        pour comprendre/profiter de toute la puissance du langage.
        Cela peut être décourageant.

          Est-ce que l'investissement en vaut la chandelle ?

        Oui, le C++ est certainement le langage
        avec la plus longue courbe d'apprentissage
        (du moins, parmi les langages les plus utilisés).

        Les subtilités de la méta-programmation font fuir beaucoup de personnes !

        Je conseille de commencer avec un langage
        avec lequel on se sent en confiance et
        qui permet de se concentrer sur le métier,
        sur les aspects fonctionnels et de passer plus de temps
        avec les utilisateurs afin de mieux cerner
        leurs préoccupations/soucis/frustrations (pain points).

        Si le temps de réponse (montée en charge) est problématique,
        on pourra optimiser l'application/infrastructure dans une second temps.
        Au moins, on aura un prototype fonctionnel pour se comparer.

        Donc ma conclusion personnelle :

          Oui, le C++ vaut la peine
          d'être appris et maîtrisé
          si sa complexité ne rebute pas.

          Mais plus important que le langage :
          Les besoins/attentes/préoccupations
          des utilisateurs du logiciel.

        Commentaire sous licence Creative Commons Zero CC0 1.0 Universal (Public Domain Dedication)

        • [^] # Re: Conclusion?

          Posté par  . Évalué à 5.

          Bof on est pas obligé de se farcir toute la complexité du langage du premier coup aussi hein ;)

          On peut se limiter à un sous ensemble, et agrandir ce sous ensemble avec le temps et la pratique; cependant certains reflexes sont difficile à perdre ou à prendre; le pire étant de prendre un langage à syntaxe proche, mais fondamentalement différent.

          J'ai vu beaucoup trop de codeur venir de java et faire du c++ comme s'ils étaient en java.

          • Et que je te met un new à la place d'une variable locale
          • et que je ne fait que du shared_ptr parce que c'est trop compliqué de réfléchir un minimum
          • et que je t'écris un singleton qui te renvoie un putain de shared_ptr
          • et que je fais un find suivit d'un insert dans une map pour ajouter s'il n'est pas déjà la…
          • et que je ne te met pas les const sur les getter ou const ref ou…
          • et que je te réécris la même fonction avec un je de paramètres différent parce que j'ai pas pensé aux paramètres par défaut…

          Et j'en passe

          Et j'ai parlé de la gestion des const?

          Il ne faut pas décorner les boeufs avant d'avoir semé le vent

          • [^] # Re: Conclusion?

            Posté par  (site web personnel) . Évalué à 4.

            Pour faire ça, il faudrait encore avoir des cours et des livres de C++ "moderne". Les 3 quart ne font que reprendre le livre d'origine complètement obsolète sur les bonnes manières de faire.

            "La première sécurité est la liberté"

          • [^] # Re: Conclusion?

            Posté par  (site web personnel) . Évalué à 2.

            Et que je te met un new à la place d'une variable locale

            Ça c'est mon test niveau 0 pour détecter un programmeur Java qui a touché à mon code C++. Malheureusement, que je vois validé beaucoup trop souvent.

            et que je ne fait que du shared_ptr parce que c'est trop compliqué de réfléchir un minimum

            Te plains pas, c'est déja mieux que ceux qui te passe uniquement des raw pointeurs C, parce que "les smart pointeurs j'ai pas confiance" :D

    • [^] # Re: Conclusion?

      Posté par  . Évalué à 6. Dernière modification le 29 juillet 2018 à 11:27.

      C# est arrivé présenté comme tel aussi

      Euh, non ?

      C'est le Java de Microsoft que Microsoft a dû sortit après avoir violé la licence de la JVM/Java.

      Ça s'inspire du C et ça ne s'appelle pas C# sans raison, mais à la base c'est juste un langage à VM de plus, et à l'époque (en 2001) c'était risible de vouloir remplacer C++ avec ça (et ça l'est encore aujourd'hui).

      "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

    • [^] # Re: Conclusion?

      Posté par  (site web personnel) . Évalué à 4.

      C++ est déclaré vieux et obsolète depuis au moins 10ans. Pourquoi serait-ce plus crédible ce coup-ci?

      Bjarne Stroustrup à la CPPCON2017 : "C'est très dur de concurrencé C++, beaucoup ont essayé, personne n'y ait parvenu "

  • # La question est où et comment apprendre le C++

    Posté par  (site web personnel) . Évalué à 9.

    J'utilise principalement C++ avec Qt même pour des programmes non graphique (je supporte pas la stl) et je me retrouve à toujours utiliser des new et delete parce que… même en lisant ce post et les commentaires je vois toujours pas avec quoi je suis censé les remplacer.

    Je sais même pas où chercher des bonnes pratiques/informations sans être noyé par tout et son contraire (envoyé/retourné des strings sur la pile c'est un coup bien ou pas, ça dépend du compilateur, du sens du vent, du numéro de serie de ton CPU…)

    • [^] # Re: La question est où et comment apprendre le C++

      Posté par  (site web personnel) . Évalué à 8.

      Tu remplaces new par make_unique, et tu n'as plus besoin de delete.
      Quand tu passe ton pointeur à une fonction qui prends un raw pointer et qui garde l'ownership, utilise my_ptr.release().

    • [^] # Re: La question est où et comment apprendre le C++

      Posté par  . Évalué à 4.

      J'utilise principalement C++ avec Qt même pour des programmes non graphique (je supporte pas la stl)

      Le problème est là. Qt s'adapte avec lenteur aux nouvelles possibilités du C++ (mais il y a de bonnes raisons à cette lenteur).

      (envoyé/retourné des strings sur la pile c'est un coup bien ou pas, ça dépend du compilateur, du sens du vent, du numéro de serie de ton CPU…

      Si tu fais référence à Return Value Optimization, cela dépend de ton code à moins d'utiliser un compilateur des années 90.

  • # Kotlin

    Posté par  (site web personnel) . Évalué à 3.

    C'est un langage à GC, mais c'est dommage de ne pas le nommer :
    - DSL natif au langage (avec support de l'IDE, comme pour Groovy par exemple)
    - Trait, Closure, Delegate (ça ressemble à Groovy)…
    - Pas de NPE

    Fonctionne dans le navigateur (vraiment et simplement, interopérable avec votre code Javascript), sur la JVM, et bientôt, hors JVM, de façon native.

    • [^] # Re: Kotlin

      Posté par  (site web personnel) . Évalué à 1. Dernière modification le 30 juillet 2018 à 12:15.

      Fonctionne dans le navigateur

      C++ aussi (merci emscripten), on a juste l'avantage d'avoir un langage qui a plus d'antériorité (code réutilisable), standardisé (pas un décideur unique), et qui s'adaptera plus facilement à la prochaine "nouveauté plus mieux bien" à la mode.
      Je suis assez vieux maintenant pour avoir vu tant de modes différentes… Et vu le C et C++ les traverser en s'adaptant pas mal, alors que d'autre langages sont à la mode puis redescendent (Ruby…)

      sur la JVM,

      J'ai l'impression qu'à force il va falloir une JVM C++ pour faire plaisir à ceux qui veulent déployer un "binaire" unique sur toute les plateformes (critique classique et non contournable de C++ de devoir fournir plusieurs binaires)

      • [^] # Re: Kotlin

        Posté par  . Évalué à 1.

        Tellement incontournable qu'il a fallu que tu la donné, c'est ça ?

      • [^] # Re: Kotlin

        Posté par  (site web personnel) . Évalué à 4. Dernière modification le 30 juillet 2018 à 17:26.

        Je pense que je suis plus vieux que toi pour ne pas considérer l'antériorité comme un avantage et synonyme de "code réutilisable". Pour avoir compilé des millions de loc de C++, datant des années 90, jusqu'au milieux des années 2000 (et testé le runtime), j'en connais plus que je n'en supporte concernant les avancées du C++.. Je suis vraiment trop vieux pour le réapprendre aujourd'hui.

        C'est très bien si après tant d'années, de surcouche et d'aller-retour vers le meilleur des mondes, de divergence entre les plateforme, d'évolutions non compatibles, le "standard" arrive enfin à converger qqp (à condition de tout compiler avec le même compilateur, avec le même runtime, avec les même options, sur la même distrib… triviale dans le monde réel).

        Maintenant, ne pas considérer un autre langage en parlant de popularité, c'est dommage.

        Moi j'utilise un langage pour des tas d'autres raisons que la beauté du langage, mais quand même. Ce que j'attends d'un langage moderne n'est même pas effleuré dans tous les commentaires de ce thread…

        par exemple : l'introspection, la programmation par aspect, l'inversion de dépendance, les annotations, les DSLs… Comment vous programmez vos applications??

        C'est ça qui fait le succès du java, malgré l'impopularité des acteurs le poussant.

        • [^] # Re: Kotlin

          Posté par  (site web personnel) . Évalué à 4.

          Merci @YBoy360 pour avoir mentionné Kotlin. À l’époque de la rédaction de la dépêche, en 2016, Kotlin n’était pas aussi connu qu’aujourd’hui. J’espère que ce langage prometteur puisse concurrencer Go, Rust, Dart, Elixir, C++… Cette concurrence a du bon, cette émulation donne des idées aux uns et aux autres pour s’améliorer 👍

          Commentaire sous licence Creative Commons Zero CC0 1.0 Universal (Public Domain Dedication)

    • [^] # Re: Kotlin

      Posté par  (site web personnel, Mastodon) . Évalué à 4.

      Fonctionne dans le navigateur

      Ha hahah hahahah hahaha…

      Franchement, cette obsession de vouloir tout faire tourner dans le navigateur, ça me dépasse. Parce qu'il faut bien reconnaitre que coté gestion des fenêtres, scheduling, widgets interactifs, un brouteur c'est vraiment la misère…

      • [^] # Re: Kotlin

        Posté par  (site web personnel) . Évalué à 2.

        C'est juste une possibilité, qui peut être utile quand tu veux développer la partie web de ton application sans changer de langage ou parce que tu n'aimes pas JavaScript.

        Le navigateur n'est pas la cible principale de Kotlin.

      • [^] # Re: Kotlin

        Posté par  . Évalué à 2.

        C'est un autre débat, mais :

        • peu de gens se motivent à installer ton application native alors que cliquer sur un lien même madame michu sait faire
        • ton projet perso, tu le code et le maintiens sur Windows, MacOS, Linux, Android et iOS ou tu fais une version web
        • quels ont étaient les innovations de ces 10 dernières années dans les toolkits graphiques natifs (choisi celui que tu veux libre ou pas multi plateforme ou pas) pour l'utilisateur. Si tu as ça m'intéresse parce que j'ai rien vu d'intéressant, mis à par Windows pour PC et mobile avec les tuiles qui apportent un nouveau concept (ça n'a pas beaucoup plus sur PC, mais j'ai vu des widgets sympas sur téléphone) et quelques trucs lié au ruban

        C'est affreux c'est triste ça ne permet pas d'avoir du code taillé comme un diamant. Ça ne va pas du tout avec la philosophie de ta machine configurée au poil, mais c'est le plus petit dénominateur commun et c'est ce qui demande le moins de travaille. Tant qu'il n'y aura pas d'autres alternatives, ça devrait logiquement rester en place. Mais libre à toi d'y accéder avec une instance de surf pour qu'à minima ça soit fenetré.

        • [^] # Re: Kotlin

          Posté par  (site web personnel, Mastodon) . Évalué à 5.

          quels ont étaient les innovations de ces 10 dernières années dans les toolkits graphiques natifs (choisi celui que tu veux libre ou pas multi plateforme ou pas) pour l'utilisateur.

          La possibilité d'avoir deux fenètres d'une application placées chacune sur son écran. La possibilité de regrouper des applications sur des bureaux différents.

          Ne pas avoir un firefox collé au taquet parce qu'une de ces applis web passe son temps à crapauter on ne sais quoi dans son coin.

          Bref, ce qu'on attend d'une machine un peu moderne : du confort.

          • [^] # Re: Kotlin

            Posté par  . Évalué à 1.

            La possibilité d'avoir deux fenètres d'une application placées chacune sur son écran. La possibilité de regrouper des applications sur des bureaux différents.

            Rien à voir avec les toolkits graphiques. Tu peux très bien faire ça avec n'importe quel que web. Tu prends ton navigateur (Firefox, Chrome, surf ou uzbl par exemple). Tu le lance avec les bonnes portions et tu as une fenêtre unique que tu manipuler comme une application. Séparé de ta navigation web classique (sur Chrome ça s'appelle l'app mode, Mozilla avait un navigateur fais pour ça, mais maintenant tu peux le faire via des paramètres en cli).

            Ne pas avoir un firefox collé au taquet parce qu'une de ces applis web passe son temps à crapauter on ne sais quoi dans son coin.

            Quelqu'un qui fais une appli lourde en js, ferais une appli lourde en c++ aussi. Il ne faut pas blâmer la techno quand c'est le dev qui fait n'importe quoi. Une conception pourrie l'est aussi bien en js qu'en rust.

        • [^] # Re: Kotlin

          Posté par  (site web personnel) . Évalué à 6.

          peu de gens se motivent à installer ton application native alors que cliquer sur un lien même madame michu sait faire

          Ça va, les gens savent installer une application native quand ils veulent.
          Je pourrais même te dire qu'avec les téléphones portables ils préfèrent installer une application native que d'utiliser le site web du service correspondant (tu crois que les gens consultent gmail ou Youtube depuis leur navigateur sur téléphone ?).

          ton projet perso, tu le code et le maintiens sur Windows, MacOS, Linux, Android et iOS ou tu fais une version web

          Car tu crois qu'un site web universellement compatible cela est aussi facile à faire que de pondre une application multiplateforme ?

          Avec Qt tu peux faire une application sur les plateformes que tu cites. Pas sûr que cela demande plus de travail qu'une version full web.

          L'API du web (ou l'écosystème de ses frameworks) est aussi très changeant, c'est un monde qui évolue vite contrairement à celui de l'OS. Donc niveau maintenance ce n'est pas une mince affaire que de gérer une application Web.

          • [^] # Re: Kotlin

            Posté par  . Évalué à 1.

            Ça va, les gens savent installer une application native quand ils veulent.

            Ils veulent pour ton appli? Tu t'appelles google ou doodle? Moi j'ai pas la place pour installer la moindre application que je vais utiliser une seule fois.

            Car tu crois qu'un site web universellement compatible cela est aussi facile à faire que de pondre une application multiplateforme ?

            Pas plus qu'avec un toolkit natif.

            Avec Qt tu peux faire une application sur les plateformes que tu cites. Pas sûr que cela demande plus de travail qu'une version full web.

            Bof c'est peut être aussi simple avec qml qu'avec du html/css, soit. Maintenant gère tes 5 builds (tant pis pour Blackberry et Windows mobile) un déploiement sur 2 à 3 stores et on parle de comment ça va se passer sur linux ?… Pas trop de travaille tu dis ? D'ailleurs tu le génère comment ton ipa ?

            L'API du web (ou l'écosystème de ses frameworks) est aussi très changeant, c'est un monde qui évolue vite contrairement à celui de l'OS. Donc niveau maintenance ce n'est pas une mince affaire que de gérer une application Web.

            Il y a pleins de nouveautés oui, mais niveau compatibilité dans le temps il n'y a aucun problème. Prends un site d'archives d'internet et voit ce que ça donne avec ton navigateur bleeding edge. Par contre oui il faut gérer la compatibilité gecko, blink et celui de edge, mais d'expérience pour ce que j'ai voulu en faire ça se fait plutôt bien. Tu me parle d'évolution des techno mais quel âge a QML, déjà ?

          • [^] # Re: Kotlin

            Posté par  (site web personnel) . Évalué à 6.

            Ça va, les gens savent installer une application native quand ils veulent.

            Tu as une source pour dire ça ? Il me semblait avoir lu des études qui montraient le contraire : la majorité des gens ont installé 0 application sur les 12 derniers mois.

            tu crois que les gens consultent gmail ou Youtube depuis leur navigateur sur téléphone ?

            Ce sont de très mauvais exemples, ces applications sont pré-installées sur les téléphones, il n'y a pas besoin de les installer pour les utiliser.

            • [^] # Re: Kotlin

              Posté par  (site web personnel) . Évalué à 6. Dernière modification le 02 août 2018 à 12:08.

              Tu as une source pour dire ça ? Il me semblait avoir lu des études qui montraient le contraire : la majorité des gens ont installé 0 application sur les 12 derniers mois.

              Sur le bureau je veux bien le croire, en général tu en as quelques unes seulement.
              Sur mobile j'ai du mal à le croire, tous ceux que je connaissent (qui ne sont pas des technophiles) avec un smartphones installent / désinstallent régulièrement des applications. Dont des jeux.

              Ce sont de très mauvais exemples, ces applications sont pré-installées sur les téléphones, il n'y a pas besoin de les installer pour les utiliser.

              Peu importe, ils installent des applications pour tout. Wikipédia, Facebook, le magasin préféré (Amazon, Ikea, Auchan, Carrefour, etc.), Netflix, le site d'actu (Le Monde, Le Figaro, 20 minutes, NextINpact, etc.), l'application de la banque, du réseau de transport du coin voire national comme SNCF et j'en passe.

              Pourtant ce que je te liste existe en version Web et souvent avec une interface mobile semblable à celle de l'application.

              Le navigateur est bien moins utilisé sur mobile que sur les ordinateurs de bureau à cause de cela.

          • [^] # Re: Kotlin

            Posté par  (site web personnel) . Évalué à 8.

            De mon expérience (plus de web que d'apps mobiles ou desktop, mais j'ai quand même été confronté aux deux), la publication d'une app web est quand même d'un incroyable confort par rapport à celle d'une app desktop ou mobile. Voici à titre d'exemples quelques problèmes que l'on a rencontré avec les apps mobiles et desktop :

            • L'app desktop est bloquée de temps à autre par tel ou tel anti-virus, il faut contacter l'éditeur de l'anti-virus qui, en général après une période de quelques semaines, finit par faire une mise à jour pour sa base de signatures et débloquer l'app.
            • Plusieurs versions de nos apps iOS ont été bloquées sur l'app store pour non-respect des guidelines. Le processus pour débloquer ça est toujours laborieux, la réponse d'Apple est souvent très vague et dans la plupart des cas, le comportement fautif était déjà présent depuis longtemps (donc regarder juste les derniers changements pour voir ce qui bloque est une approche qui nous a fait perdre pas mal de temps).
            • Les systèmes de mises à jour automatiques pour les apps desktop ne marchent pas super bien. Par exemple, un utilisateur nous a remonté que la mise à jour cassait les raccourcis quand l'app était installée via AppImage.
            • On a publié une fois une version franchement cassée d'une app android, elle a été validée sans problème par Google. On a rapidement fait une autre mise à jour derrière pour corriger ça (dans les 24h), mais plusieurs semaines après, on avait encore des remontées de personnes qui étaient sur la version cassée.

          • [^] # Re: Kotlin

            Posté par  (site web personnel) . Évalué à 6. Dernière modification le 02 août 2018 à 19:28.

            Avec Qt tu peux faire une application sur les plateformes que tu cites. Pas sûr que cela demande plus de travail qu'une version full web.

            Mais dans ce cas, il ne faut pas être très exigeant sur la qualité de l'intégration à l'OS. Sur macOS, on reconnaît tout de suite les quelques applis codées en Qt…

      • [^] # Re: Kotlin

        Posté par  (site web personnel) . Évalué à 1.

        Dans pas mal d'application t'en à RAF de la gestion des fenêtres, du scheduling, des widgets interactifs. C'est triste pour moi car ça m'intéresse. Les problèmes sont la sécurité, la stabilité, la simplicité de développement, la monté en charge, la coopération avec l'existant…

        Quand tu as une application d'entreprise type formulaire / graphique en lecture seul / recherche (pas genre Catia, jeux vidéo, ou Krita ou Gimp ou Photoshop ou …), le navigateur c'est quand même ce qu'il y a de mieux.

        • C'est plus simple à déployer
        • plus simple à développer
        • il y a plus de cadriciel d'outils disponibles que pour les applications natives (qui soient réellement portable).

        Je n'aime vraiment pas "faire des pages web", on fait tout pour les générer automatiquement, à partir de DSL justement. Avec quelques efforts, on pourrait même générer des interfaces d'application native.

        Moralité, t'es bien content de pouvoir te passer du Javascript quand t'aime pas ça avec d'autres langages plus "IDE compliant", ça rend le développement Web plus facile.

  • # Super facile !

    Posté par  . Évalué à 6.

    Il y a quelques années maintenant … je n'avais aucune base en C++ ou en POO hormis deux trois notions lues ici et là, je touchais seulement un peu au Perl, au PHP et au Python.

    J'ai choisi cette formation à l'époque sur mon DIF car C++ avait la réputation d'être un des langages les plus compliqué à appréhender, surtout pour ceux dont comme moi ce n'est pas le métier.

    Au bout du 2 eme jour je ne peux que confirmer cette réputation, j'étais largué :D

    Les autres participants à la formation avaient l'air de mieux s'en sortir (manifestement ils étaient déjà tous des Dev C dans l'industrie).

    Moi je souffrais je me souviens encore de cette semaine (en plus c'était sur Paris il faisait super chaud dans les locaux de l'Arche tout ça … fiou coup de barre de 14h00 ..).
    J'avais du mal à terminer le TP seul surtout le dernier jour, surcharge, dérivation, polymorphisme de classe qu'est ce que tu me racontes là … bon ok ça a l'air super puissant, mais qu'est ce que ça a l'air complexe … tout ça pour faire une calculatrice ça fait grosse artillerie tout de même … ça a l'air plus simple en Pascal tout de même …

    Résultat depuis lors tout les langages (que j'ai abordé) me paraissent super simple à apprendre en comparaison :-)
    Mon conseil faite une formation C++ ça va vous changer la vie.

    • [^] # Re: Super facile !

      Posté par  (site web personnel) . Évalué à 8.

      J'avais du mal à terminer le TP seul surtout le dernier jour, surcharge, dérivation, polymorphisme de classe qu'est ce que tu me racontes là … bon ok ça a l'air super puissant, mais qu'est ce que ça a l'air complexe … tout ça pour faire une calculatrice ça fait grosse artillerie tout de même … ça a l'air plus simple en Pascal tout de même …

      Tu pointes je pense des difficultés de concept plus que des difficultés liées au C++ lui même. Après tous ces notions existent dans beaucoup de langages orientés objets. Si tu les as découvert avec le C++, c'est normal que la combinaison d'apprentissage OO + C++ t'aies paru lourd.

      La difficulté du C++ ne réside pas dans les concepts que tu as pointé, mais plutôt :

      • Bibliothèque standard assez pauvre (du moins avant C++11) ce qui obligeait à réinventer la roue ou à utiliser les bibliothèques externes pour tout ;
      • Beaucoup trop de paradigmes dans un seul langage : impératif, objet, fonctionnel, méta-programmation avec les templates, etc. Du coup tu as une syntaxe très lourde et riche ce qui rend difficile sa maitrise ;
      • Compatible avec C (ou presque) ce qui pose un soucis d'héritage historique qui alourdit la sémantique et autorise un curieux mélange des genres qui est délicat pour le débutant ;
      • Souffre malheureusement d'un enseignement souvent porté sur C puis vers C++ en considérant les deux comme liés ce qui maintient les mauvaises habitudes. Il vaut mieux considérer le C++ comme différent du C et ne pas parler de la compatibilité syntaxique au début.

      Cet ensemble de choses font du C++ comme difficile à maitriser. En général tu te spécialises dans un sous ensemble du C++.

      • [^] # Re: Super facile !

        Posté par  (site web personnel) . Évalué à 2. Dernière modification le 14 août 2018 à 23:22.

        Beaucoup trop de paradigmes dans un seul langage : impératif, objet, fonctionnel, méta-programmation avec les templates, etc. Du coup tu as une syntaxe très lourde et riche ce qui rend difficile sa maitrise ;

        J'aurais tendance à penser qu'un langage multi-paradigme pour apprendre la programmation est mieux qu'un language "pure", car il permet de toucher plus de concepts.

  • # GTK+ / gObject ?

    Posté par  . Évalué à 6.

    Une question qui me taraude : pourquoi les développeurs de GTK+ ont-ils créé gObject (en C, donc) plutôt qu'utilisé directement le C++ ?

    Et du coup, est-il plus facile de programmer en gObject (GTK+) qu'en C++ (Qt) ?

    • [^] # Re: GTK+ / gObject ?

      Posté par  (site web personnel) . Évalué à 10.

      Une question qui me taraude : pourquoi les développeurs de GTK+ ont-ils créé gObject (en C, donc) plutôt qu'utilisé directement le C++ ?

      Ne pas oublier que le C++ à l'époque n'était pas aussi populaire qu'aujourd'hui, d'ailleurs la première norme du C++ date de 1998 soit l'année de la sortie de GTK+ / GLib (mais le tout reposait sur des travaux sur GIMP qui existait depuis 1995).

      Le C était aussi à l'époque le langage de référence de la programmation système dont ces couches font partie.

      Et l'un des avantages de GTK+ / GLib je crois c'est qu'il supporte plus de ports vers d'autres langages (enfin, de bindings) que Qt. En particulier le C évidemment.

      Et du coup, est-il plus facile de programmer en gObject (GTK+) qu'en C++ (Qt) ?

      Qt est bien plus vaste que GTK+, il faudrait comparer à minima le couple GLib / GTK+ avec Qt et encore je crois que même là Qt reste plus complet.

      À titre personnel je n'ai pas vraiment de préférence ayant fait les deux. Peut être que c'est plus naturel pour un développeur C++ de faire du Qt que pour un développeur C de faire du GTK+. Mais si tu as un développeur Python qui utilise les ports de chacun d'eux j'ignore s'il trouvera l'un plus agréable que l'autre.

      Je pense que ce qui intéresse le plus les gens est plutôt la direction des projets. GTK+ reste piloté par GNOME et Linux en tête quand Qt est plus générique dans son orientation.

    • [^] # Re: GTK+ / gObject ?

      Posté par  . Évalué à 8.

      Pour gtk, l'objectif ce n'est pas de faire de l'objet en C, mais de définir des abstractions indépendante du langage. Ainsi ils ont pu générer des bindings, vers pleins de langages automatiquement. Le C est alors intéressant car :

      • presque tous les langages savent s'y associer
      • d'un point de vu expressivité le c représente un minimal implémenté par tous les autres langages. Donc si tu fais une abstraction en C, tu devrais pouvoir la reproduire dans n'importe quel langage (si elle n'existe pas déjà)

    • [^] # Re: GTK+ / gObject ?

      Posté par  (Mastodon) . Évalué à 9. Dernière modification le 31 juillet 2018 à 11:31.

      Et du coup, est-il plus facile de programmer en gObject (GTK+) qu'en C++ (Qt) ?

      Il y a deux questions là. S'il s'agit de comparer uniquement gObject et C++, alors C++ est clairement gagnant, puisqu'en gObject, il faut faire à la main ce qui est fait automatiquement par le compilateur en C++, à savoir le polymorphisme via les vtables. S'il s'agit de comparer GTK+ à Qt, c'est une affaire de goûts et de couleurs. Il existe même Gtkmm qui permet d'utiliser GTK+ en C++.

      • [^] # Re: GTK+ / gObject ?

        Posté par  (site web personnel) . Évalué à 10.

        Et du coup, est-il plus facile de programmer en gObject (GTK+) qu'en C++ (Qt) ?

        Petite anecdote :

        L'auteur de Gwenview, Aurélien Gâteau, m'avait expliqué qu'il avait commencé à implémenter sa visionneuse de photos pour GNOME, donc avec GTK+, il y a une petite vingtaine d'années.

        Mais Aurélien avait beaucoup de mal avec cette bibliothèque, et un des mainteneurs de GTK+ lui aurait conseillé d'utiliser plutôt Qt s'il voulait développer en C++. Et finalement, Aurélien était tellement à l'aise avec Qt, que sa visionneuse est devenue une application officielle du projet KDE.

        Par contre, Aurélien s'était attaché au nom originel commençant par un G (Gwenview) et n'a pas choisi un autre nom commençant par un K (ou un Q) comme s'était la pratique à l'époque. Aurélien a ainsi contribué à la cacophonie des noms des logiciels des environnements de bureau…

        Bien que cette anecdote date de 20 ans (et que Qt et GTK+ aient pas mal évoluées), je pense que nous pouvons statuer:
        ⇒ Si on veut écrire une application graphique en C++, vaut mieux partir sur Qt que sur GTK+.

        Commentaire sous licence Creative Commons Zero CC0 1.0 Universal (Public Domain Dedication)

        • [^] # Re: GTK+ / gObject ?

          Posté par  . Évalué à 2.

          Il y a aussi Gcompris qui est passé de Gtk+ à Qt. Gcompris a également intégré KDE par la suite.

          Cette signature est publiée sous licence WTFPL

  • # OK...

    Posté par  . Évalué à -2.

    OK, je vois un peu mieux…
    Merci à vous !

  • # Ailleurs

    Posté par  (site web personnel) . Évalué à 10.

    Sur lobsters, il y a une discussion similaire : https://lobste.rs/s/zw9i1f/should_c_programmers_learn_c_go_rust. L'avis de l'auteur de l'article est que rien ne remplace le C. Dans les commentaires, c'est évidemment plus nuancé et plein d'avis différents. On peut quand même voir une sorte d'adhésion pour apprendre :

    • Rust quand on vient du C
    • D quand on vient du C++
    • Go quand on vient de Python ou comme premier langage

    • [^] # Re: Ailleurs

      Posté par  (site web personnel) . Évalué à 1.

      Go quand on vient de Python ou comme premier langage

      Personnellement, avec du recul, je déconseillerais franchement Go pour un programmeur débutant. Les choix fait pour le design Go sont tellement peu orthodoxes que c'est un peu comme s'isoler sur une ile déserte dés le début de son apprentissage.

  • # Oui mais non !

    Posté par  . Évalué à 1.

    Bonjour

    N'etant pas developpeur (en programmation je me limite aux shell scripts), je n'ai bien sur aucun avis sur la question, et si j'en avais un je le considererais comme non-pertinent. Par contre :

    Par exemple, le C++ est souvent évoqué pour ses performances lorsque l’on veut créer un jeu vidéo. Mais de nos jours, avec la puissance disponible sur le moindre appareil et la qualité des moteurs de jeux, il n’est plus pertinent que tous ceux qui veulent travailler dans les jeux vidéo apprennent le C++.

    Alors là, oui mais non ! Stop à la course au surarmement ! C'est à cause de ce type de raisonnement qu'on n'a jamais assez de ressources, même si on en a toujours plus.

    • [^] # Re: Oui mais non !

      Posté par  . Évalué à 9. Dernière modification le 13 août 2018 à 14:50.

      Alors là, oui mais non ! Stop à la course au surarmement ! C'est à cause de ce type de raisonnement qu'on n'a jamais assez de ressources, même si on en a toujours plus.

      Dit comme cela, on a l'impression que l'on échange des ressources contre rien du tout, juste pour se faire plaisir. Mais ça n'est pas exact: en pratique, on échange ces ressources contre du temps de développement.

      Le temps de dev, c'est souvent la ressource dont on manque le plus. Il y a beaucoup plus de logiciels qui disparaissent ou ne voient jamais le jour par manque de (temps de) dev. Les logiciels qui disparaissent à cause de leurs mauvaises performances sont beaucoup plus rare.

      • [^] # Re: Oui mais non !

        Posté par  . Évalué à 1. Dernière modification le 13 août 2018 à 17:14.

        Je comprends cet argument mais d'un autre coté, dans le cadre d'un jeu video, le rendre moins gourmand permettrait de le vendre à plus de monde, et donc de financer du temps de développement en plus, non ?

        J'imagine que les gens qui gèrent ça ne sont pas stupides et ont étudié la question et qu'ils pensent que c'est plus rentable comme cela, mais je me demande si l'étude a pas été biaisée par l'envie toute naturelle et humaine de "pas se faire chier".

        • [^] # Re: Oui mais non !

          Posté par  (site web personnel) . Évalué à 1.

          le rendre moins gourmand permettrait de le vendre à plus de monde

          qui donc?
          - Ceux qui ont une machine pourrie et ne veulent/peuvent pas changer de machine, tu crois qu'ils achèteront un jeu, sérieusement?
          - Ceux qui ont une machine moyenne feront tourner le jeu de façon moyenne, ils achèteront et seront satisfaits, qu'est-ce que la rapidité changera? Désolé, mais passer 2x plus de fric pour gagner 10% CPU ou RAM (car même si tu double les perfs de la partie non C/C++, ça ne va pas aller bien loin…) n'est pas rentable. En gros, ta phrase sous-entend que gagner 10 permet de dépenser 100, les comptables disent le contraire.

          mais je me demande si l'étude a pas été biaisée par l'envie toute naturelle et humaine de "pas se faire chier".

          En gros, tu refuses par avance le résultat d'une étude si celle ci ne va pas dans ton sens.

          Bref, je suis le premier à conseiller C++ (j'en fait un max que je peux), mais ça ne m’empêche pas de comprendre l'argument sans "mais" (attention à la phrase "je […] mais […]", ça montre souvent que le premier crochet est faux).

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.