Je dois revenir au C++ quinze ans après l'avoir quitté. Qu'est-ce qui a changé ?

Bonjour,

J'ai entamé le C++ jadis à sa sortie, quand on développait encore sur Turbo C++.
Puis Borland C++ avec Owl pour Windows 3.x, et puis les MFC sous Visual C++.
Je l'ai quitté en 2001, quelques années avant que n'arrive Visual Studio et que ne débute côté Windows une unification avec .NET.

Je l'appréciais bien, mais c'est Java qui a été mon activité les années suivantes.

Depuis peu, j'y trouve un nouvel intérêt pour des programmes où la célérité va prendre plus d'importance.

À l'époque où je l'ai quitté le C++ avait connu pour dernière nouveauté d'évolution du langage (depuis deux ou trois ans, je crois), les références avec &.
Voilà, je crois que j'en étais là, alors, dans sa pratique. J'ai beaucoup codé avec, mais maintenant l'API de sous-bassement Windows que je connaissais à l'époque ne me servira plus à rien, elle est obsolète. Et de toutes façons, ce sera sur des environnement Debian que je vais développer.


J'aimerais bien savoir à quoi me préparer.
Quelles ont été les évolutions majeures du C++ depuis l'an 2000 ?
Avec quelles librairies de classes standard évolue-ton désormais avec les compilateurs gcc ou équivalents, pour faire l'essentiel de la programmation ?
Compile t-on toujours ses projets à l'aide de makefiles, ou bien la pratique a changé ?

Merci à vous !

Citation:

---

Envoyé par grunt2000

Quelles ont été les évolutions majeures du C++ depuis l'an 2000 ?

---

La méta-programmation (templates) partout :mrgreen:

Ensuite, le C++ moderne (C++1y avec C++11, C++14, C++17, C++19, ...)

• désambiguifie le C : par exemple les rvalue reference, les move constructor, pointeur NULL, de nouvelles façons de coder tout un tas de choses constant
• permet aux développeurs de se concentrer sur leur code et non plus sur le "comment faire" : les raw pointeurs sont planqués et par exemple il y a les lambdas, l'inférence des types, les fermetures (closures)
• a un timide élargissement des possibilités : par exemple inclusion des threads (mais ratée), de l'unicode, du temps, table de hachage, regex
• améliore/ renforce les templates : par exemple templates externes, templates variadiques, les chevrons >>, variable templates

Citation:

---

Envoyé par grunt2000

Avec quelles librairies de classes standard évolue-ton désormais avec les compilateurs gcc ou équivalents, pour faire l'essentiel de la programmation ?

---

Le compilateur numéro 1 c'est le compilateur Apple clang. C'est boost la bibliothèque non officielle qui a été reprise en partie par le C++ moderne

Citation:

---

Envoyé par grunt2000

Compile t-on toujours ses projets à l'aide de makefiles, ou bien la pratique a changé ?

---

Le comité C++ prévoit des changements qui se font attendre : par exemple les modules
Mais le seul truc que le comité est d'accord c'est de normaliser les entêtes pré-compilées pour pouvoir faire des exports dynamiques à la Java (si je ne dis pas de bêtises)

Le changement le plus profond et aussi le plus complexe à appréhender concerne la sémantique de déplacement (rvalue). Ce qui est est la base de pléthore de nouveautés dont les pointeurs intelligents font partie.

Au niveau langage:

- Les nouveaux mots clefs auto, decltype, override, constexpr et changement sur for, if, while (http://en.cppreference.com/w/cpp/keyword)
- les lambdas
- les boucles sur intervalle
- plusieurs choses pour la méta-prog: template variadique, if constexpr, variable template et alias template, en tête <type_traits> etc

La liste des en-têtes: http://en.cppreference.com/w/cpp/header

C++20 ou après réserve pas mal de chose qui vont avoir de gros impacte sur le langage et la manière d'écrire son code:

- module
- méta-class
- coroutine
- reflexion
- concept
- range

@foetus: Pourquoi est-ce raté pour les threads ?

Citation:

---

Envoyé par jo_link_noir

@foetus: Pourquoi est-ce raté pour les threads ?

---

C'est vrai que c'est un retour que j'avais lu :oops: et que je n'arrive pas à retrouver :aie:

Mais, il me semble que, le problème des threads C++11, c'est que c'est un outil bas niveau :

• il faut savoir les utiliser : par exemple, on peut créer des fuites ThreadRAII + Thread Suspension = Trouble?
• il manque des outils plus haut niveau et qui arriveront avec le C++20 que tu mentionnes : coroutines, semaphores, latches et barriers, transactional memory, task blocks

Citation:

---

Envoyé par foetus

Le compilateur numéro 1 c'est le compilateur Apple clang.

---

Heu... non.
Déjà ce n'est pas Apple clang car le projet est désormais développé par une communauté. Et ensuite clang a amener un peu de concurrence bénéfique mais il n'est ni fondamentalement meilleur ni plus répandu que gcc (https://en.wikipedia.org/wiki/Clang#..._compatibility). Beaucoup d'OS de type BSD sont passés à clang pour des histoires de licences mais, à ma connaissance, les distributions linux sont toujours compilées avec gcc par défaut.

Salut,

Et pour ce qui est des makefiles, comme on utilise toujours (enfin, le plus souvent) make, il restent d'actualité.

Mais, bien que le système de configuration de projets des "autotools" (autoconf, automake, autoheaders, ...) on se tourne de plus en plus souvent ver l'outil CMake, qui présente l'énorme avantage d'être porté sur différentes plateformes.

Et puis, de manière générale, tu utilises à peu près l'outil que tu veux pour automatiser la compilation. Sauf erreur, ant, qui est pourtant plutôt orienté vers l'automatisation de java, fonctionne aussi très bien ;)

Citation:

---

Envoyé par foetus

C'est vrai que c'est un retour que j'avais lu :oops: et que je n'arrive pas à retrouver :aie:

---

Le 10/10/2011, Bartosz Milewski a publié un article : Async Tasks in C++11: Not Quite There Yet.

L'idée générale est que le développeur ne devrait pas gérer le parallélisme en terme de threads mais en terme de tâches. L'implémentation bas niveau, elle, se chargerait d'exécuter les tâches via un pool de threads. Si une tâche X se bloque, par exemple parce qu'elle attend une entrée utilisateur, le thread correspondant pourrait renvoyer la tâche dans la file des tâches en attente et piocher une autre tâche pour l'exécuter. La tâche X sera récupérée plus tard par un des threads, qui ne sera pas forcément le même que le thread de départ.

Or, le C++11 a été pensé comme si l'exécution d'une tâche commençait et se terminait dans le même thread.

Le plus gros changement, et pas des moindres et pourtant on tend à l'oublier, c'est qu'il ne faut en aucun cas essayer de gérer la mémoire à la main ou croire que l'on puisse y arriver dans un monde d'exceptions.

Ce petit gros détail est à l'origine de l’appellation "C++ moderne" en opposition à "C++ historique" où le C++ est perçu comme une simple surcouche du C. Si tu es resté aux références comme "nouveautés", c'est le premier changement important. Beaucoup d'autres choses dans le C++98, dans le C++11 et suivants découlent de cela. Le mot clé est RAII.

Je ne peux que renvoyer à https://www.developpez.net/forums/d1...ne-stroustrup/
Du même auteur, "A Tour of C++" est une présentation du langage orientée mise à niveau si mes souvenirs sont bons.

Merci pour vos premières orientations.

Ce que je comprends, c'est que je suis à la norme C++ 98, et que j'ai à rattraper les normes C++ 03, 11 et 14 au minimum.
La C++ 17 est en préparation, Ai-je bien compris que la C++ 1z désigne aussi cette future C++ 17 ?

Les templates, je me rappelle en avoir fait. La généricité sous Java ne doit pas en être trop éloignée.
La gestion de la mémoire à l'ancienne, je me doute qu'effectivement ça doit être fini. Prendre un pointeur dans un coin et lui loger des valeurs en *(monPointeur - 7) = 152; ça ne doit plus être très apprécié.

Je vais voir ce que je peux acquérir.
Je n'apprendrai pas tout. J'ai pour habitude de n'utiliser que ce que je peux ensuite expliquer à deux développeurs autour de moi au moins, d'une manière que je sois sûr qu'ils y adhèrent et acceptent de le maintenir.
Cela me permet d'exclure les choses trop originales qui ne peuvent finalement pas être soutenues. (Exemple typique en Java : la programmation orientée aspect. Géniale sur le principe, mais éminemment casse-gueule, incomprise et le plus souvent mal maitrisée avec tous les effets de bords dont on en cauchemarde la nuit qu'ils se soient provoqués pendant qu'on dormait).


@koala, ci-dessous : "– Je n'apprendrai pas tout.
– Tu aurais tort."
C'est humain de le souhaiter, mais Java ou C++ ont un univers de plus de 10 000 classes qu'ils proposent dans des domaines variés.
Dans la pratique, même un développeur faisant beaucoup de révisions et de veille ne gardera pas plus que la connaissance de l'emploi, d'une manière plus ou moins approfondie, de 1 500 classes.
Et rares sont ceux qui sont si connaisseurs qu'ils savent de plus utiliser chaque méthode de chaque classe, parce qu'ils ont pris le temps de les éprouver effectivement en les expérimentant et pas seulement en lisant leur documentation.

On ne peut pas apprendre tout. Il faut choisir ce que l'on apprend, puis accepter de le remplacer. Acquérir des connaissances nouvelles et accepter d'en abandonner d'autres. Cela, l'abandon, se fait naturellement :
On croit se rappeler ce que l'on savait dix ans auparavant, pour se rendre compte qu'on ne s'en souvient plus que des reliefs parce que le cerveau a acté qu'un certain nombre de connaissances ne lui serviraient plus et les a évacuées.

Ce qui fait que je pense que la stratégie n'est pas de tout apprendre. Mais plutôt d'avoir un fil directeur dans l'apprentissage.
Pour ma part, j'ai favorisé tout ce qui peut être transmis à une équipe de développeurs entre un et cinq ans d'expérience. Je connais des pratiques au delà, parfois. Mais je n'en fais la promotion qu'avec prudence.

Citation:

---

Envoyé par grunt2000

Merci pour vos premières orientations.

Ce que je comprends, c'est que je suis à la norme C++ 98, et que j'ai à rattraper les normes C++ 11 et 14 au minimum.
La C++ 17 est en préparation, Ai-je bien compris que la C++ 1z désigne aussi cette future C++ 17 ?

---

oui, ou n'importe quelle norme qui pourrait sortir entre maintenant et 2019 inclus (à cause du 1 :D) ;)

Citation:

---

Les templates, je me rappelle en avoir fait. La généricité sous Java ne doit pas en être trop éloignée.

---

Pour ce que j'en sais, il n'y a vraiment que le principe de base : si on ne sait pas quel type de donnée on va manipuler, on sait comment on va le faire

Pour le reste, je crois que c'est vraiment totalement différent :P

Citation:

---

La gestion de la mémoire à l'ancienne, je me doute qu'effectivement ça doit être fini. Prendre un pointeur dans un coin et lui loger des valeurs en *(monPointeur - 7) = 152; ça ne doit plus être très apprécié.

---

Ben, c'est toujours le même problème : si tu as de bonnes raisons de le faire, il n'est pas question de ne pas apprécier ;)

Ce qui est moins apprécié, c'est

Code:

---

1 2 3

Type * ptr = new Type; /*...*/ delete ptr;

---

(surtout si new et ptr ne sont pas dans la même fonction)
Que l'on remplacera de préférence par

Code:

---

std::unique_ptr<Type> ptr= std::make_unique<Type>();

---

ou par

Code:

---

std::shared_ptr<Type> ptr= std::make_shared<Type>();

---

car std::unique_ptr et std::shared_ptr nous garantisse que la mémoire allouée à l'élément sera libérée "en temps et en heure".

Et puis, on part du principe maintenant qu'il vaut mieux éviter l'utilisation d'un pointeur (et surtout de l'alloation dynamique de la mémoire) à chaque fois que faire se peut : on essaye de n'y avoir recours que... lorsque l'on n'a vraiment pas d'autre choix.

La différence entre la sémantique de valeur et la sémantique d'entité nous aide énormément à faire ce genre de choix

Citation:

---

Je vais voir ce que je peux acquérir.

---

Bah, si tu n'est pas totalement idiot, tu devrais pouvoir acquérir à peu près tout :D

Seul le temps que l'on met à le faire changera d'une personne à l'autre ;)

Citation:

---

Je n'apprendrai pas tout.

---

Tu aurais tord : quand on ne maitrise "qu'à moitié son véhicule", il arrive toujours un moment où l'on fini contre l'arbre ou dans le fossé qui trainait par là au moment où l'on en a perdu le contrôle ;)

Le principe est le même ici: il y a une différence entre connaitre (et donc, maitriser le langage) et utiliser ;)

Citation:

---

J'ai pour habitude de n'utiliser que ce que je peux ensuite expliquer à deux développeurs autour de moi au moins, d'une manière que je sois sûr qu'ils y adhèrent et acceptent de le maintenir.
Cela me permet d'exclure les choses trop originales qui ne peuvent finalement pas être soutenues.

---

Alors là, je ne peux que te féliciter de cette manière de voir les choses.

Mais, encore une fois, il y a une différence entre connaitre et utiliser ;)

De mon point de vue, après une utilisation intensive depuis ~5 ans, je dirais presque que c++11 est un langage différent de C++98/C++03.
La façon de programmer n'est plus du tout la même, tout comme le passage du C au C++ est plein de nouveautés et différences, le passage à C++11 c'est vraiment un nouveau monde.

Beaucoup plus simple, avec notamment les pointeurs intelligents, move et les rvalues, les templates variadiques, les lambdas, etc, ainsi que des ajouts très bénéfiques a la bibliothèque standard (thread, random, chrono par ex).
On n'utilise plus de pointeurs nus, à part en tant "qu'observateurs" (dont on sait qu'ils n'ont pas la main mise sur la ressource), on fait du RAII, on ne s’embête plus a retourner de gros objets par reference dans les paramètres de fonction, on les retournes par valeur (et avec move, c'est tout aussi rapide).
Sans compter le nombre incroyable d'ajouts de choses qui paraissent "mineures" a première vue, mais qui changent définitivement la façon de programmer (et en bien).

C++14 pour sa part je ne peux pas encore l'utiliser, j'ai regardé un peu mais les changements sont "mineurs".
C++17 n'apporte pas autant de choses incroyables qu'entre le passage c++03/c++11, mais il y a beaucoup d'outil très intéressants (if_constexpr, fold expressions, structured binding) et des ajouts importants a la bibliothèque standard (comme filesystem qui manquait vraiment).

C++20 quand a lui semble sur la voie de changer beaucoup de choses, tout comme c++11, avec les modules (finis la "galère" des includes?) et les concepts par exemple (qui vont vraiment changer la façon de coder en c++).

Le futur du c++ semble très prometteur en tout cas (reflexion, networking...).
Et certains papers sont très alléchants, comme les metaclasses:
https://herbsutter.com/2017/07/26/me...-generative-c/


La seule chose regrettable est que le support semble assez lent à se faire, que ce soit en entreprise, ou du côté des SDK, comme par exemple pour export sur les consoles de dernière génération (qui semblent limités a c++11 d'après les retours).

Pour ma part, les plus gros changements ont été, et donc la courte liste de choses à voir et utiliser qui sont vraiment game changer que je conseillerais :
- variadic templates
- lambda
- move semantic
- if constexpr (C++17)

Les pointeurs intelligents c'est mignon, mais on avait déjà vite fait d'avoir l'équivalent d'un unique_ptr sur un projet un minimum gros donc c'est juste sympa de fournir ça dans la std mais n'est pas une révolution imo.
shared_ptr ça reste un gadget dont on peut se passer dans de très nombreux cas où leur utilisation relève plus de la feignantise ou mauvaise conception.
Je range les ranged-for-loop dans la catégorie gadget aussi : si tu connais autant les utiliser, mais tu ne perds rien à ne pas le faire dans un premier temps en tous cas.

Petit commentaire sur "les templates sont pas trop éloignée des generics de java".
En fait, si.
Et c'est lié à l'essence même des deux langages, et de leurs histoires.

Dans les deux cas, le mécanismes est arrivé après la première version du langage. Il a fallut faire au plus direct avec ce qui était présent.

Le code Java est compilé en bytecode, qui lui est interprété par le programme java (la JVM).
Le code C++ est compilé en code binaire directement exécutable par le processeur ciblé.

Le besoin initial est le même: n'écrire qu'une seule fois du code utilisable avec des types distincts.

En Java, c'est direct. List<String> et List<Integer> sont deux types distincts, tous deux définis par public class List<T>.

En bytecode, par contre, les génériques n'existent pas.
Ainsi List<T> est compilé comme si elle n'était pas générique, en utilisant des Objects (classe de base de toute classe, donc de T), et en introduisant des casts non validant dans le code (non validant, puisque vérifiés à la compilation).
Ceci explique pourquoi il ne peut pas y avoir de List<int>, pourquoi Integer existe, et permet l'utilisation de List sans paramêtre template (avec une montagne de warnings)

A l'opposé, en C++, on génère plusieurs classes strictement distinctes.
Ainsi, template <typename T> capsule { T value; }; permet de générer des structures capsule<int> et capsule<double>. Ces deux structures sont distinctes, non convertible (a priori).

Le C++ générant des classes distinctes lorsque nécessaire, il est possible de définir des spécialisations de template, pour un cas particulier.
En Java, c'est impossible, parce qu'il n'y a qu'une seule classe (dans le bytecode).

Vu le nombre d'années pendant lesquelles tu n'as pas pratiqué, je te conseille de reprendre à 0.
Tu iras plus vite dans l'apprentissage, mais il vaut mieux ne pas faire l'impasse sur des choses que tu n'as pas vues depuis très longtemps.

Quelques titres d'ouvrages, à lire dans cet ordre :

C++ Primer, 5th edition
The C++ Standard Library - A Tutorial and Reference, 2nd Edition
Effective modern C++

Je n'ai pas mentionné Stroustrup, car je trouve qu'il écrit très mal.

Tu peux également lire tous les anciens ouvrages de Scott Meyers, Herb Sutter, Andrei Alexandrescu... Bien qu'il aient tous de 10 à 15 ans, ils ont encore de la valeur.
Il y a même des livres bien plus anciens qui vaudraient d'être mentionnés (la plupart chez Addison-Wesley Professional).

J'ai réfléchi à cette possibilité.
Bon mais autrefois j'ai fais la transition C++ vers Java, je pourrais refaire celle Java vers C++.

Bien sûr, le risque, c'est qu'on me voie un temps programmer "à l'ancienne" le temps que je récupère les nouvelles bonnes pratiques.
J'ai conscience que l'effet sera un peu comme voir débarquer un développeur Java 4 dans un monde Java 8. Il faudra que la transition se fasse sans trop traîner.

Mais de mon point de vue, c'est surtout l'acquisition des bibliothèques de classes qui va m'occuper.

Familles de classes de départ
Avec quel "panorama de classes" vit-on habituellement ?
En Java, globalement, un développeur qui connait une bonne part des classes présentes dans les packages java.lang, java.util, java.io (ou nio), et quelques classes d'apache commons lang, il a le socle de départ qu'il faut.
Après ce qu'il apprendra dépendra du thème du projet sur lequel il se trouve pour le compléter de quelques familles de classes s'accordant bien avec la nature de son travail.
packages Java = namespaces C++ ?

Frameworks recommandés ?
Par contre, l'on demande quasi-systématiquement aux développeurs Java d'apprendre un framework : soit celui JEE (EJB), soit celui Spring. Ils proposent une manière organisée de bâtir des serveurs d'applications ou des serveurs web. Ils établissent, en quelque-sorte, une sorte de convention, d'architecture générale à suivre.
Les développeurs C++ sont-ils eux aussi enjoints à suivre des frameworks analogues quand ils ont à bâtir de tels serveurs (si cela leur est demandé) ?

Il y a effectivement des bibliothèques en C++, mais je dirai que ce n'est pas dans la connaissance de ses bibliothèques que se mesure la maitrise.
A la limite, il faut comprendre l'architecture actuelle de la bibliothèque standard du C++ héritée de la STL historique: conteneurs + itérateurs (très différents de ceux du java) + algorithmes -- tu as vraiment une philo très différente de celle du Java. Quand je dis "actuelle", c'est parce que les choses sont bien parties pour évoluer vers cela: https://github.com/ericniebler/range-v3 sur cet aspect là.

Après il y a des frameworks assez récurrents comme boost, ou Qt qui vont avoir des objectifs parfois différents, parfois avec recouvrement, et plein d'autres choses. Mais il n'y a pas que ça, il y a les chaines de compilations, de CI, les outils d'analyse de code, de comportement, de performances, etc.

Le truc est qu'il y a déjà bien assez à faire avec l'utilisation idiomatique du langage pour se mettre à jour. Le reste est en perpétuel changement. P.ex. "récemment" on a vu apparaitre encore d'autres bibliothèques dédiées comme p.ex. spdlog qui remplace avantageusement ce que l'on pouvait bien utiliser avant. On a quelques grosses libs + des centaines de petites spécialisées. Pas deux gros machins qui font tout entre lesquels il faut choisir (hormis peut-être Qt?).

Franchement, je ne me stresserai pas là dessus. Quand on part sur du C++, c'est rarement pour s'encombrer de frameworks. Je trouve plus que c'est pour répondre efficacement à des besoins en fournissant des briques élémentaires qui pourront ensuite être intégrées ailleurs -- mais bon ma vision est déformée par les métiers sur lesquels j'interviens: traitement d'images, de données, ou plus anciennement écriture de chaines de contrôle de satellites.

Je ne cherche vraiment pas une maîtrise fine du C++ dans ses arcanes.

Pour faire simple : quel que soit le langage que j'utilise : C, C++, Java ou Python (tout neuf pour moi : ai-je écrit seulement 200 lignes de code avec ?),
mes applications sont proches du sujet que j'ai à traiter, et leur code décrit le métier s'y rapportant et agit dessus,
plutôt que chercher à engager le langage dans toutes ses capacités.

Je vais privilégier une application simple et documentée à une qui sera plus élaborée mais nettement moins explicable.
Je vais également chercher des implémentations existantes et éprouvées des algorithmes habituels dont je pourrais avoir besoin plutôt que les réécrire à la main.

En 25 ans de job, j'ai probablement écrit 10 000 000 de lignes de code tous langages confondus.
Quand j'examine le passé, je regrette beaucoup que 2 millions d'entre-elles aient sûrement servi à réinventer la roue, moi croyant bien de faire quelque-chose par moi-même... qui existait déjà ailleurs tout prêt... quel gâchis et quels risques !
Et à chaque fois que je me replonge dans des existants, les miens, ceux d'autres personnes pour les maintenir, ce sont souvent les prouesses d'alors qui nous font achopper et nous gênent quinze ans plus tard.
Avez-vous déjà maintenu un programme C qui écrit une de ses méthodes partiellement en assembleur, mais d'une manière telle que le langage machine produit s'il est exécuté décalé d'un octet produit une deuxième séquence d'instructions exécutables elles aussi, quoi que non immédiatement visibles ?
Une prouesse des années 1985 - 87 où c'était le fin du fin de ce que les experts faisaient...

Aujourd'hui, mes règles sont :
- Toujours simple : tout est écrit pour la maintenance future par des développeurs autres que soi, ayant de un à cinq ans d'expérience.
- Toujours appuyé sur des API externes éprouvées. On n'invente aucun algorithme que quelqu'un a déjà codé ailleurs de manière connue comme fiable par la communauté informatique.
- Tout code non commenté est rejeté quelle que soit la valeur de son créateur. De ce côté-là, les merge-request / pull-request apportés par les Gitlab, Github ont vraiment fait progresser la qualité des développements en permettant de refuser des commits impropres.

En un mot : j'écris des applications pour qu'elles fassent un travail particulier, clair et précis,
pas pour mettre en valeur le langage utilisé. Qu'importe si je ne l'emploie qu'à 70% de ses capacités, si 99% de ceux qui le lisent peuvent ensuite le comprendre et le maintenir.

Citation:

---

Envoyé par grunt2000

Je ne cherche vraiment pas une maîtrise fine du C++ dans ses arcanes.

---

C'est un tort. Il vaut bien mieux connaître les arcanes que les bibliothèques.
Tout faire pour éviter d'y avoir recours, mais le faire quand la situation l'exige.

Le seul "framework" qu'il est indispensable de connaître, c'est la STL. Et pour cela, je te renvoie au deuxième ouvrage que j'ai recommandé.
Tu peux aussi avoir une bonne connaissance de la liste des bibliothèques fournies par Boost. Mais seulement la liste. Tu approfondiras quand le besoin se présentera.
La STL et Boost t'éviteront de réinventer la plupart des roues, même les carrées.
En entretien, tu n'est jamais interrogé sur les frameworks autres que la STL, sauf quand le l'intitulé du poste mets l'accent sur Qt ou autre.
En tout cas, moi, je teste la compréhension du langage. Et crois-moi, ça écrème déjà pas mal.

Par ailleurs, si tu codes en C++, c'est que sont attendues d'autres choses que ce que peuvent offrir les autres langages. En général les performances.
Et pour cela, il faut tout de même s'intéresser à des subtilités qu'on néglige quelque peu dans les autres langages.
C++ n'est pas le langage le plus productif. Il faut lui donner l'occasion de briller là où il est bon.

Tu ne connais pas mon contexte d'utilisation.

Je dois bâtir un système capable de récupérer des données rapidement, de faire des calculs mathématiques (surtout : statistique) dessus ensuite,
et de les afficher sous forme cartographique dans une interface utilisateur assez conviviale.

– Lorsque les volumes de données initiales à classer seront importantes, et particulièrement pour les sections rapides qui peuvent se faire en mémoire vive, je serai peut-être amené à privilégier le C++.
Tant qu'il y a peu d'entrées/sorties, il peut mettre en avant sa vitesse.
S'il y en a trop, en revanche, il aura moins d'intérêt : sa plus grande vitesse entre les E/S ne se remarquera pas.

– Pour les traitements mathématiques, j'ai l'impression que Python a vraiment des atouts. Je vais voir si mes expériences le confirment.

– Pour la partie SIG et interface web, Java me semble qui aura le plus de facilités.

Sauf si je parviens à réduire le nombre des langages que je vais utiliser, si je vois comment n'en utiliser que deux (un seul, ça me semble difficile : mais ce serait alors Java), il y aurait trois langages différents engagés dans l'ensemble de la chaîne logicielle.

Si elle aboutit et que je la confie ensuite à quelqu'un qui veut l'utiliser à son tour, il ne pourra la maintenir que si chacune de ses parties est écrite de la manière la plus simple, la plus efficace et la plus lisible possible.
Car il n'existera à priori pas de personnes détentrices de connaissances poussées dans ces trois langages à la fois (en tous cas... pas moi),
et si des interventions sont à faire par la suite il faudra qu'elles puissent se faire très intuitivement.

Cela exclut, dans mon idée, l'emploi de toutes les techniques de programmation très élaborées dans chacun de ces langages si elles réclament un temps d'apprentissage assez long et de la pratique.
De là, je choisis des instructions simples, des mots-clefs et opérateurs connus, des API dont le principe se retrouve à peu près partout et sont toujours documentées et bien expliquées sur Internet ou ailleurs.

Pour info, Python est le langage de prédilection pour le SIG.