Les modules c'est un peu l'IPv6 du C++, la promesse d'un futur meilleur qui n'arrive pas, depuis environ 20 ans. J'ai du mal à croire que leur utilisation va se généraliser ne serait-ce que dans la décennie à venir.
Tiens, quelle était la tendance sur les sujets de gestion des dépendances là-bas ? Voilà un sujet très tendance qui est loin d'être évident aussi.
J'ai l'impression que le C++ se trouve dans une situation bien bancale depuis quelques années. D'un côté ça pousse fort pour « moderniser » le langage et ajouter des trucs à la lib standard, mais de l'autre côté on aura toujours à supporter les bases. Au final on a pas loin de zéro simplification : Par exemple il faut toujours comprendre la syntaxe du for de base, et sûrement savoir ce qu'est un itérateur, mais il faut aussi maintenant connaître le range-based-for et ses subtilités, ainsi que <range> et ses pièges... Ça ne fait que s'empiler.
Et c'est un peu dommage. À force de vouloir tout mettre parce que tel autre langage fait ceci, ou un autre fait cela, on se retrouve avec une sorte de Rust--, un Python-mais-pas-aussi-concis, et des temps de build qui montent, qui montent, qui montent :/
# Ah les modules
Posté par Julien Jorge (site web personnel) . En réponse au journal De retour de conférence. Évalué à 10.
Les modules c'est un peu l'IPv6 du C++, la promesse d'un futur meilleur qui n'arrive pas, depuis environ 20 ans. J'ai du mal à croire que leur utilisation va se généraliser ne serait-ce que dans la décennie à venir.
Tiens, quelle était la tendance sur les sujets de gestion des dépendances là-bas ? Voilà un sujet très tendance qui est loin d'être évident aussi.
J'ai l'impression que le C++ se trouve dans une situation bien bancale depuis quelques années. D'un côté ça pousse fort pour « moderniser » le langage et ajouter des trucs à la lib standard, mais de l'autre côté on aura toujours à supporter les bases. Au final on a pas loin de zéro simplification : Par exemple il faut toujours comprendre la syntaxe du
forde base, et sûrement savoir ce qu'est un itérateur, mais il faut aussi maintenant connaître lerange-based-foret ses subtilités, ainsi que<range>et ses pièges... Ça ne fait que s'empiler.Et c'est un peu dommage. À force de vouloir tout mettre parce que tel autre langage fait ceci, ou un autre fait cela, on se retrouve avec une sorte de Rust--, un Python-mais-pas-aussi-concis, et des temps de build qui montent, qui montent, qui montent :/