nokomprendo a écrit 260 commentaires

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.

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.

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.

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.

PS : tu as réussi à provisionner la base? A utiliser l'appli?

C'est un peu compliqué…
J'ai testé sur une distrib Nixos, qui n'utilise pas de FHS classique. Jusqu'ici, j'arrive à lancer un environnement avec les bonnes dépendances et à faire le "docker-compose build" mais le provisionnement avec wait-for-it.sh ne fonctionne pas. Je crois qu'il faut patcher les scripts et que Nix a des outils qui font ça mais je ne les connais pas bien. Du coup, c'est un peu rageant de devoir utiliser du docker-compose tout moche alors que Nix est top pour gérer des services… Bref, je réessaierai plus tard, ou avec une distrib plus classique.

J'ai regardé vite fait le projet et si je peux me permettre quelques remarques :
- ce serait peut-être bien de mettre les issues et readme du dépôt en anglais.
- le fait de devoir passer par docker-compose + un script bash pour provisionner la base est assez contraignant. Je n'ai pas utilisé django depuis un moment mais il me semble que configurer django+postgres+redis est assez simple pour un développeur, avec un setup.py et un manage.py. Et ça faciliterait également la création de paquets par d'éventuels mainteneurs de distribs…
- par contre, une vraie image docker directement utilisable depuis dockerhub serait très pratique.

Oui, merci pour ce projet qui a l'air très intéressant.

Pour le nom, il vaut mieux un bon logiciel avec un nom peu flatteur qu'un logiciel pourri avec un joli nom (et je ne dis pas ça parce que l'éducation nationale utilise des logiciels comme Sirhen ou Apogé…).

Certaines écoles avaient pour mission de former techniquement les hauts fonctionnaires (je ne parle pas de l'ENA) de manière à ce qu'ils assurent un service public de grande qualité

Houla, que de confusion… Ces écoles représentent moins de 10% des 200 écoles d'ingé françaises. La plupart des écoles forment essentiellement pour travailler en entreprise et il y a très souvent des formations équivalentes dans les universités.

Les écoles délivrent un BAC+5 qui est l'équivalent d'un master. Le seul problème pour nos dirigeants du CAC40 issues de ces grandes écoles, c'est qu'à l'étranger, les dirigeants ont souvent un doctorat, ça pose problème quand ils essaient de se vendre en dehors de la France.

Houla, que de confusion… Le système des écoles (2 ans de CPGE + 3 d'école) est différent du système européen (3 ans de licence + 2 de master); et je ne parle même pas de la répartition du contenu d'enseignement… Quant aux "dirigeants du CAC40", ça représente quelle part des étudiants ? Je doute que ce soit le débouché principal des écoles d'ingé.

Alors ça, on s'en fout complètement. Ces classements sont tous biaisés et ne reflètent absolument pas la qualité des formations

Houla, que de confusion… Ce "on" n'est pas du tout celui qui prend les décisions. Le classement de Shangai n'est qu'un élément d'un ensemble de classements et de notations. Les universités et laboratoires de recherche sont classés (hcres, sanghai, qs…), les chercheurs sont classés (h-index, i10-index…), les publications scientifiques sont classées (impact factors)… même les banques AAA, les jeux vidéos AAA et les andouillettes AAAAA sont classés. Et tous ces classements sont directement ou indirectement pris en compte pour décider les financements, projets, partenariats, promotions… (sauf peut-être celui sur les andouillettes, j'avoue).

C'est très bien, ça incitera les étudiants à aller à la fac. Les écoles d'ingé sont un vestige de Napoléon qui n'a plus de raison d'être aujourd'hui. D'ailleurs ça n'existe quasiment pas à l'étranger et c'est incompatible avec le système LMD européen en place depuis plus de 10 ans. En plus, ça coûte cher et ça favorise la dispersion, avec les conséquences que l'on connait sur les classements internationaux des universités.

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.

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… ?

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…

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

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.

Quand on connait un peu des langages comme OCaml/Haskell et qu'on découvre Rust, leur influence saute aux yeux : types algébriques, traits, inférence, pattern matching… (https://doc.rust-lang.org/reference/influences.html).
Donc à mon avis, ce n'est pas tant un changement de langage mais plutôt de paradigme : de l'orienté objet au fonctionnel.

Effectivement. Et en Haskell, il y a reflex et miso.
J'ai un peu testé Elm mais je ne connais pas bien le dev frontend.

Merci. J'ai corrigé le titre de page.

http://gittup.org/tup/
https://buckbuild.com/

J'ai utilisé un peu Tup : c'était concis et rapide mais assez particulier à configurer.

Buck, je ne connais que de nom, si quelqu'un à un retour…

en gratuit:
- bitbucket = limité à 5 membres sur l'ensemble des dépôts privés
- framagit = limité à 42 dépôts (et c'est dommage car l'esprit git, c'est plutôt de faire plein de petits dépôts qui peuvent se combiner)

donc gitlab…

C'est original, d'habitude on demande de passer sous rust : https://www.reddit.com/r/rust/comments/62gzio/psa_please_stop_asking_other_projects_to_convert/

D'après l'article c'est plutôt gtk3 qui est prévu. Et apparemment cela corrigerait les soucis de dispositifs de pointage sous windows.

Et pour ceux qui utilisent Nix/Nixos, le paquet a été mergé et devrait bientôt apparaitre sur le canal instable (https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/graphics/gimp/default.nix).

Mais vous pouvez déjà tester en deux commandes :

git clone https://github.com/nixos/nixpkgs /path/to/my/nixpkgs
nix-shell -I nixpkgs=/path/to/my/nixpkgs/ -p gimp --run gimp

Complètement d'accord. Apparemment, c'était déjà le cas pour Ubuntu 14.04 LTS, qui utilisait le kernel 3.13 (non LTS). Je ne comprends vraiment pas l'intérêt.

Contrôle de qualité norme debian, est ce que les fichiers vont bien uniquement là où c'est convenue dans la charte…

Si tu ne connais pas déjà, tu devrais regarder du côté de Nixos.
Nixos essaie de vraiment résoudre ces problèmes, là où Debian se contente d'essayer de les éviter.

Qu'entends-tu par "vérification de qualité" ?
J'ai soumis quelques paquets pour Voidlinux et il y a pas mal de vérifications (j'imagine que ça doit être pareil pour Arch). Le fichier de packaging lui-même est vérifié avec un outil de type lint. Puis l'outil de construction de paquet vérifie l'archive, le checksum, les dépendances, les patches, la compilation, l'installation, les so-bumps… On peut construire le paquet dans un environnement isolé (en bootstrapping) et pour différentes architectures (en cross-compilation). Enfin, quand on soumet le paquet à l'upstream (via un simple PR), tout est revérifié par un système d'intégration continu (travis CI) et relu par les mainteneurs de la distrib.

C'est bien de le répéter à l'envi. Maintenant, il faudrait probablement citer avec une vraie comparaison, comme ça, on pourrait peut-être voir s'il y a une raison derrière cette complexité.

Avec Debian je ne sais pas mais avec Arch il faut avouer que la création de paquets est plutôt simple :
https://github.com/nokomprendo/tuto_fonctionnel/tree/master/tuto_fonctionnel_18/#cr%C3%A9er-ses-propres-paquets