Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Le comité ISO C++ a proposé une feuille de route pour C++ 23 et finalisé la nouvelle version du langage C++ 20
La norme devrait être publiée dans les mois à venir

Le , par Stéphane le calme

148PARTAGES

16  0 
La dernière réunion du comité ISO C++ s’est tenue à Prague, en République tchèque. Durant cette réunion, le comité a fait des ajouts au brouillon de C++ 20 et a opté pour l'envoyer au Draft International Standard (DIS) pour approbation finale et publication. Sur le plan de la procédure, il est possible que le DIS soit rejeté, mais en raison des procédures et processus du comité, il est très peu probable que cela se produise. Cela signifie que le développement de C++ 20 est terminé, et dans quelques mois la norme sera publiée.

Lors de la réunion, les modifications et ajouts suivants au projet C ++ 20 :
  • Amélioration de la reconnaissance contextuelle du « module » et de « l'importation » pour permettre aux outils non compilateurs tels que les systèmes de génération de déterminer plus facilement les dépendances de génération.
  • Ajout de plusieurs nouveaux algorithmes de classement.
  • Ajout de ranges::ssize.
  • Affinage de la signification de static et inline dans les interfaces de module (P1779 et P1815).
  • Résolution de nombreux problèmes de langage et de bibliothèque de base et amélioration substantielle des spécifications.

Les éléments suivants sont des fonctionnalités clés dans C++20 :
  • Les Modules.
  • Les Coroutines.
  • Les Concepts.
  • Les Ranges.
  • Les constexprification: constinit, consteval, std::is_constant_evaluated, constexpr allocation, constexpr std::vector, constexpr std::string, constexpr union, constexpr try and catch, constexpr dynamic_cast and typeid.
  • std::format("For C++{}", 20)
  • operator<=>
  • Macros de test de fonctionnalités.
  • std::span
  • std::source_location.
  • std::atomic_ref.
  • std::atomic::wait, std::atomic::notify, std::latch, std::barrier, std::counting_semaphore, etc.
  • std::jthread and std::stop_*.



Comme l’explique Herb Sutter, président du comité de normalisation ISO C++, les Modules constituent une nouvelle alternative aux fichiers d’entête et apportent un certain nombre d’améliorations clés notamment en isolant les effets des macros et en permettant des générations évolutives. Cette fonctionnalité permet aux utilisateurs du langage de définir une limite d’encapsulation. Il existait jusque-là trois fonctionnalités de ce type qui permettent aux développeurs de créer leurs propres mots de pouvoir en (a) donnant un nom défini par l'utilisateur en (b) quelque chose dont l'implémentation est cachée, explique Sutter. Ce sont : la variable (qui encapsule la valeur actuelle), la fonction (qui encapsule le code et le comportement) et la classe (qui encapsule les deux pour délivrer un ensemble d’états et de fonctions).

Même des fonctionnalités majeures telles que les Modèles constituent des moyens de décorer ou de paramétrer ces trois fonctionnalités fondamentales. À ces trois, est ajoutée maintenant une quatrième, les Modules qui encapsulent les trois pour en livrer un ensemble. Les Coroutines quant à elles, sont des fonctions qui peuvent suspendre et reprendre leur exécution tout en conservant leur état. L'évolution en C++ 20 va encore plus loin. Le terme Coroutines est inventé par Melvin Conway. Il l'a utilisé dans sa publication pour la construction d'un compilateur en 1963. Cette fonctionnalité existe également dans les langages comme Python. L'implémentation spécifique de Coroutines en C++ est un peu intéressante. Au niveau le plus élémentaire, il ajoute quelques mots-clés à C++ comme co_return, co_await, co_yield ainsi que des types de bibliothèques qui fonctionnent avec eux. Une fonction devient une coroutine en ayant une de ces fonctions dans son corps.

std::format

std::format ajoute la prise en charge des chaînes de format à la bibliothèque standard C++, y compris pour les paramètres de type sécurisé et de position. Si vous connaissez les chaînes au format Boost.Format ou POSIX, ou même simplement printf, vous saurez exactement de quoi il s'agit. Selon lui, std::format donne le meilleur de printf (commodité) et le meilleur de iostreams (sécurité et extensibilité des iostreams), mais il ne se limite pas à iostreams. Il vous permet également de formater n’importe quelle chaîne. « Cela fait longtemps que j'attends cela, de sorte que je n'aurai plus jamais à utiliser l’entête iomanip », a-t-il déclaré à propos.

Les conteneurs constexpr

Les conteneurs constexpr suivants ont été ajoutés à la norme C++ 20 : constexpr INVOKE, constexpr std::vector et constexpr std::string. Selon Sutter, cela signifie que beaucoup de code C++ ordinaire peut être exécuté à la compilation, y compris même les conteneurs std::vector et chaînes dynamiques standard. « C’était quelque chose qui aurait été difficile à imaginer il y a quelques années à peine, mais cela montre de plus en plus que nous sommes sur un chemin où nous pouvons exécuter du code C ++ simple au moment de la compilation au lieu d’essayer d’exprimer ces calculs sous forme de métaprogrammes de modèle », a-t-il précisé à propos de ces ajouts et constexpr std::string.

Au cours de cette réunion, le comité a également adopté un plan pour C ++ 23, qui inclut la hiérarchisation d'une bibliothèque standard modulaire, le support de bibliothèque pour les coroutines, les exécuteurs et la mise en réseau. Elle est prévue à Varna (en Bulgarie).


Évolution du langage

Evolution Working Group Incubator (EWGI) Progress

L'incubateur EWG s'est réuni pendant trois jours à Prague et a examiné et commenté 22 articles pour C ++ 23. 10 de ces documents ont été transmis à Evolution, éventuellement avec quelques révisions demandées. Notamment:
  • Élision de copie garantie pour les objets de retour nommés
  • Déclaration et utilisation généralisées de pack
  • Modèles de membres pour les classes locales


Plusieurs articles ont reçu beaucoup de commentaires et reviendront à l'incubateur, probablement à Varna:
  • Un opérateur pipeline-rewrite
  • Des paramètres template universels
  • Captures lambda partiellement mutables
  • C ++ devrait prendre en charge la compilation just-in-time

Concernant les paramètres template universels, imaginez-vous essayer d'écrire une métafonction pour apply :

Code C++ : Sélectionner tout
1
2
3
4
5
template <template <class...> class F, typename... Args> 
using apply = F<Args...>; 
template <typename X> 
class G { using type = X; }; 
static_assert(std::is_same<apply<G, int>, G<int>>{});// OK

Dès que G essaie de prendre n'importe quel type de NTTP (paramètre de template non-type) ou un paramètre de template-template, apply devient impossible à écrire; nous devons fournir des types de paramètres analogues pour chaque combinaison de paramètres possible:

Code C++ : Sélectionner tout
1
2
3
template <template <class> class F> 
using H = F<int>; 
apply<H, G>// error, can't pass H as arg1 of apply, and G as arg2

La solution proposée ? Un moyen de spécifier un paramètre template vraiment universel qui peut se lier à tout ce qui peut être utilisé comme argument template. Appelons le template auto. « La syntaxe est la meilleure que nous puissions trouver; mais il existe de nombreuses façons inexplorées d'orthographier un tel paramètre template ». Par exemple :

Code C++ : Sélectionner tout
1
2
3
4
5
template <template <template auto...>  
class F, template auto... Args> 
using apply = F<Args...>; 
apply<G, int>;// OK, G<int> 
apply<H, G>;// OK, G<int>

Le nouveau paramètre template universel introduit des généralisations similaires à l'universel auto NTTP ; afin de permettre le pattern-matching sur le paramètre, les classes template doivent également pouvoir être spécialisées sur le type de paramètre:

Code C++ : Sélectionner tout
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
template <template auto> 
struct X; 
  
template <typename T> 
struct X<T> { 
// T is a type 
using type = T; 
}; 
  
template <auto val> 
struct X<val>&nbsp;: std::integral_constant<decltype(val), val> { 
// val is an NTTP 
}; 
  
template <template <class> F> 
struct X<C> { 
// C is a unary metafunction 
template <typename T> 
using func = F<T>; 
};

Source : Rapport du comité C++

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de boumchalet
Nouveau membre du Club https://www.developpez.com
Le 11/09/2020 à 10:21
Bonjour,
Pour moi, après avoir travaillé avec des langage multiples (java, c#, Rust, Basic, Pyhton, ... plus de 40), c++ reste à une place particulière :
- c'est seule langage qui n'impose pas de limite entre les concepts hard et les abstractions de hauts niveaux, mais cela peut avoir un coût élevé (formation, investissement) => Il existe énormément de paradigmes de programmation c++, deux programmeurs c++ peuvent ne pas se comprendre.
- Bien qu’il soit possible d’intégrer des programmeurs de langages managés dans un projets c++, il est nécessaire de leur fixer un cadre strict (par exemple interdiction du new et delete)
- Beaucoup des langages qui ont limité les concepts pour simplifier la programmation, ils sont aujourd’hui engagés dans des impasses évolutives, par exemple : java . Ce n’est pas le cas du c++, ce qui lui permet d’évoluer vers la simplification sans coût supplémentaire.
Conclusion :
Il reste encore beaucoup de chose à faire en c++, il n’a pas atteint ces limites et reste un langage d’avenir pour manipuler notre monde. Il n’a pas d’équivalence.
6  0 
Avatar de stardeath
Expert confirmé https://www.developpez.com
Le 28/02/2020 à 16:10
en tout cas, visiblement le problème de syntaxe de c++ ne pose pas de problème qu'à moi, vu la proposition epochs : http://www.open-std.org/jtc1/sc22/wg...0/p1881r1.html
4  0 
Avatar de onilink_
Membre chevronné https://www.developpez.com
Le 07/09/2020 à 18:52
Citation Envoyé par zoonel Voir le message
Moi je suis vite passé au C# Après mes études. Justement parce que je trouve que c'est un bon langage, élégant etc... Bref en fait les mêmes arguments que toi mais pour C# au lieu de C++. Et durant mes études j'ai appris à programmer avec c++ , et j'ai du faire du c, du java et accessoirement on a également vu toute une floppée de languages "exotiques" (haskell, etc...).
Alors ça fait longtemps que j'ai plus fais de c++ et je m’intéresse pas trop aux nouveautés même si je suis l'actualité, mais quand je vois les examples de code rien que la synthaxe me fait peur et je la trouve pas élégante pour un sou.
Néanmoins ça m’intéresse d'avoir un avis de quelqu'un qui aime le c++ et donc en quoi le trouve-tu élégant, bon, etc... ?

J'essaie de me tenir vaguement au courant sur ce qui peut se faire comme langage mais le nouveau c++ ne m'a jamais attiré, seul Rust récemment a attiré mon attention et j'ai commencé à lire le bouquin, du coup je pense complètement laisser tomber le c++ (ou du moins l'espoir que j'avais de m'y (re)mettre). (Ça me fait penser à une vidéo que j'ai vue récemment sur un top top10 des "jeux de société qu'on aurait voulu aimé", je pense qui si c'était une vidéo sur les langages de programmation alors c++ arriverait en tête pour moi. J'aurais vraiment voulu l'aimer mais non j'y arrive pas)
Pour être honnête, je pense que si je devais reprendre le dev de zéro en 2020, j'apprendrais probablement plus Rust que C++.
J'aime énormément la philosophie de C++ et le langage en lui même mais il y a quand même un point noir sur le tableau: il reste trop de choses de C et C++98 (parce qu'il faut garder une retro compatibilité, Rust n'a pas ce soucis, étant jeune) qui rendent C++ bien moins moderne que ce qu'il pourrait être.

Pour ce que j'aime du C++ moderne:
- le langage n'est pas explicitement désigné en prenant les utilisateurs pour des cons. Des choses comme les pointeurs ne sont pas cachés sous un autre nom avec moins de features juste parce que dans l'imaginaire collectif "pointeur == compliqué" (ce qui est faux bien entendu).
- sur le même principe il n'y a pas de GC, mais des pointeurs intelligents, qui IMO sont beaucoup plus pratiques (et applicables dans d'autres domaines que juste gérer la mémoire), mais surtout cela permet d'avoir une durée de vie définie sur nos objets, et la construction/destruction est bien plus simple au final.
- une grosse partie de la philosophie de C++ c'est "ce qu'on peut faire à la compilation, on le fait a la compilation", et ça permet d'avoir des objets pratiques comme unique_ptr qui vont avoir absolument zéro overhead, mais en plus ça permet aussi de voir pas mal d'erreurs a la compilation, et ne pas attendre que ça pète au runtime. Et sur ce point Rust a l'air vraiment génial avec son borrow checker.
- je trouve tout le principe des templates et ce que l'on peut en faire complètement génial. Je sais pas si tu as déjà vu les patterns genre CRTP ou encore le polymorphisme statique, je trouve juste ça très élégant en plus d'être pratique (et très performant). Les templates c'est vraiment très puissant (il y a qu'a voir la lib standard, et boost), et on à rarement vu autant de possibilités dans d'autres langages, même si j'ai cru comprendre qu'en Rust il y avait de quoi faire des choses équivalentes, peut être plus facilement.
- chaque nouveau standard nous amène des outils incroyables, toujours plus puissants, et qui réparent petit à petit tous les problèmes majeurs du langage

Après y a aussi tous les trucs obvious qui font que personnellement, je préfère un langage natif à un langage qui tourne dans une VM.
On comprend mieux ce qu'on manipule, ça consomme moins, ça permet d'utiliser des outils plus "standards"... et en C++ on profite quand même de tout l'écosystème qu'il y a déjà autour de C (outils, bibliothèques), d'autant que moi je suis sous Linux et l'OS est vraiment très adapté à ce niveau.

Néanmoins, C++ n'est vraiment pas un langage safe (même si on suit beaucoup de règles, comme les C++ core guideline etc qui permettent de grandement limiter la casse), et je considère perso que ce n'est pas du tout un bon choix dans tout domaine qui nécessite du code vraiment safe (genre serveurs). Moi je développe un jeu donc ça ne me pose pas trop de problèmes, mais dans certains domaines il faut vraiment oublier le C++.

Bon, j'oublie probablement plein de choses, mais ça te permettra de voir mon ressentis général sur la chose je pense

Par contre j'ajouterais que savoir programmer en C++, ça ne se fait pas en quelques années d'études. J'ai fait genre 4 ans de C++ a la fac, et mon niveau était vraiment lamentable (et celui de mes profs encore pire) malgré le fait que je pratiquais pas mal (j'avais l'impression d'être bon, mais la suite m'a montré que non).
Par contre quand je suis allé bosser, et que j'ai rencontré des personnes très compétentes, dont une personne qui maîtrise vraiment le langage, ça a changé beaucoup de choses et mon niveau a été propulsé d'un coup, bien plus en très peu de temps qu'en toutes mes années d'étude cumulées.
Et je pense que c'est le même problème pour la plupart des langages quand on étudie, mais a mon avis C++ est l'un des pires à ce niveau, car tout le monde pense savoir le connaître ou le maîtriser... sans savoir en faire, en fait.
C++ est un langage difficile a apprendre en profondeur, mais pas du tout pour les raisons que la plupart des étudiants pensent (pointeurs, gestion de la mémoire, bas niveau).
3  0 
Avatar de Pyramidev
Expert confirmé https://www.developpez.com
Le 11/09/2020 à 11:38
Bonjour,
Citation Envoyé par boumchalet Voir le message
Pour moi, après avoir travaillé avec des langage multiples (java, c#, Rust, Basic, Pyhton, ... plus de 40), c++ reste à une place particulière :
- c'est seule langage qui n'impose pas de limite entre les concepts hard et les abstractions de hauts niveaux
Quel sens donnes-tu à "pas de limite entre les concepts hardware et les abstractions de hauts niveaux" qui ferait que C++ respecte mieux ce principe que Rust (vu qu'il y a Rust dans ta liste) ?

Si tu fais référence au zero-overhead principle, ce dernier est mieux respecté en Rust qu'en C++. Par exemple :
  • Pour faire de la propagation d'erreur de manière lisible, on n'est pas obligé de passer par des exceptions dynamiquement typées avec du RTTI. On a du sucre syntaxique sur les types qui implémentent le trait std::ops::Try comme std::option::Option et std::result::Result.
  • Rust distingue std::sync::Arc qui est thread-safe de std::rc::Rc qui ne l'est pas et contrôle à la compilation qu'on ne passe pas à un thread un std::rc::Rc. Du côté de C++, l'équivalent est std::shared_ptr que les implémentations rendent thread-safe en pratique, même quand on ne fait pas de multithread. Le zero-overhead principle est aussi sacrifié pour les variables locales statiques dont l'initialisation doit être thread-safe depuis C++11, même si je me rappelle qu'il existe une option dans GCC pour passer outre cette règle du langage.
  • En C++, quand un objet passe dans un moved from state, il faut quand même que son destructeur puisse être appelé sans faire de dégâts. En Rust, quand on fait l'équivalent d'un move (passage par valeur d'un objet qui n'implémente pas le trait std::marker::Copy qui signifie que la copie ne coûte pas cher, par exemple une copie d'un entier), l'objet n'est plus dans la portée. Il n'y a pas d'appel à drop (l'équivalent du destructeur) sur un objet "coquille vide". Rq : au passage, cela signifie aussi que la mise en place du RAII est mieux faite en Rust qu'en C++.
3  0 
Avatar de SimonDecoline
Expert confirmé https://www.developpez.com
Le 26/02/2020 à 20:34
Ah oui, quand même. C'est un nouveau langage en fait.
1  0 
Avatar de CaptainDangeax
Membre éprouvé https://www.developpez.com
Le 10/09/2020 à 10:37
Quelle guerre de chapelle entre C++ C# et Java. Un mot sur les garbage collector. Dans garbage collector, il y a garbage, c'est à dire déchets. Dans un projet récent, le produit avait des soucis de stabilité sur sa connexion BDD. Réunion avec les développeurs, revue des specs, ils m'expliquent qu'ils laissent les sockets ouvertes tout le temps d'exécution, et que le garbage collector gère toussa toussa. Je leur ai affiné les specs en leur indiquant à quel moment les sockets doivent être ouvertes ou fermées, et idem pour les fichiers de lock et les attentes dans les pollings. Résultat : plus d'instabilité. Donc quand j'entends parler de garbage collector, je sors mon flingue !
La querelle entre ces langages objets me fait bien rigoler aussi. Ce sont des concepts très lointains pour moi parce que moi, électronicien avec d'être ingénieur système, quand on me parle de pointeur, je sais ce que ça veut dire jusqu'aux signaux RAS CAS et R/_W des chips dram. Et tout ceci est au final compilé ou exécuté dans un environnement (pour Java ou C#). Peu importe le temps de compilation, peu importe le nombre de lignes, si au final le programme s'exécute plus vite et sans bug, et sans avoir à faire appel au garbage collector parce que le développeur a pensé à détruire ses objets une fois qu'il n'en avait plus besoin.
Enfin, C# et Java ne seront jamais aussi rapides que C ou C++ dès qu'il y a une grande quantité de calculs à faire derrière, ou un grand volume de données à manipuler.
1  0 
Avatar de Aiekick
Membre extrêmement actif https://www.developpez.com
Le 07/09/2020 à 15:59
toutes ces nouvelles fonctionnalités ne vont t'elles pas compliquer un peu plus les compilateurs, voir comme l'abus des templates creer des temps de compilation hyper long ?
peut t'il y avoir un impact perf ?

la feature "module" c'est comme les imports en java ou en C# ?
0  0 
Avatar de zoonel
Membre habitué https://www.developpez.com
Le 07/09/2020 à 16:37
Citation Envoyé par onilink_ Voir le message

Mais dans l'absolu je te dirais absolument tout, pour la simple raison qu'un dev qui maîtrise C++ ne fait pas du C++ seulement parce que c'est "rapide" (j'ai toujours trouvé cet argument pour faire du C++ plutôt moisi) ou encore "léger" (pareil pour ça), mais parce que C++ est réellement un bon langage, avec une élégance et une philosophie que tu ne retrouveras pas ailleurs. Puis niveau frameworks y a de quoi faire (genre Qt).
J'ai personnellement essayé pas mal de langages, et y a rien à faire, pour rien au monde je ne changerais. Seul Rust m’intéresse a côté mais c'est pour des cas assez précis, ou encore des langages fonctionnels pour leur façon de fonctionner.
Moi je suis vite passé au C# Après mes études. Justement parce que je trouve que c'est un bon langage, élégant etc... Bref en fait les mêmes arguments que toi mais pour C# au lieu de C++. Et durant mes études j'ai appris à programmer avec c++ , et j'ai du faire du c, du java et accessoirement on a également vu toute une floppée de languages "exotiques" (haskell, etc...).
Alors ça fait longtemps que j'ai plus fais de c++ et je m’intéresse pas trop aux nouveautés même si je suis l'actualité, mais quand je vois les examples de code rien que la synthaxe me fait peur et je la trouve pas élégante pour un sou.
Néanmoins ça m’intéresse d'avoir un avis de quelqu'un qui aime le c++ et donc en quoi le trouve-tu élégant, bon, etc... ?

J'essaie de me tenir vaguement au courant sur ce qui peut se faire comme langage mais le nouveau c++ ne m'a jamais attiré, seul Rust récemment a attiré mon attention et j'ai commencé à lire le bouquin, du coup je pense complètement laisser tomber le c++ (ou du moins l'espoir que j'avais de m'y (re)mettre). (Ça me fait penser à une vidéo que j'ai vue récemment sur un top top10 des "jeux de société qu'on aurait voulu aimé", je pense qui si c'était une vidéo sur les langages de programmation alors c++ arriverait en tête pour moi. J'aurais vraiment voulu l'aimer mais non j'y arrive pas)

Citation Envoyé par kilroyFR Voir le message

De nos jours dans ma boite, hormis les devs +40 ans personne ne veut developper en C++ (on est d'ailleurs regardé comme des extra terrestres; des has been) - meme pire que ca ils n'arrivent pas lire le code CPP pour la maintenance; quand on parle d'API pour eux ca veut dire exclusivement WEB API (la notion d'API/Librairie leur echappe completement).
Je vois pas en quoi ne pas savoir lire du code CPP est une tare, surtout si c'est pas le langage de programmation pro !(vous êtes passé c# d'après ce que j'ai compris)

Sinon je vois pas en quoi il faut absolument passer par le c/c++ (qui sont en fait 2 langages très différent faut le rappeler) pour comprendre les notions de mémoire etc... On peut très bien le faire en c# également, y'a pas forcément besoin de pointeurs et de leur syntaxe c++. Je trouve le discours condescendant envers les nouveaux dev qui ne font pas du c++ et qui du coup seraient automatiquement des "sous-développeurs" justement sous le seul prétextes qu'ils n'ont pas fait de c++.
Le truc que je remarque par contre, c'est vrai, bcp de devs (c#) n'ont pas fait d'études d'info mais viennent d'autres filières avec parfois une formation courte en dev. Et là effectivement il y a beaucoup de notions sur ce qu'est un ordi, un langage de prog et comment le tout fonctionne qui sont passé à la trappe. Mais rien qui ne peut pas être apris par la suite, et donc à vous d'apprendre aux nouveaux les concepts si ils ne les ont pas.

ps: en bonus pour ceux qui font du c#, je vous recommande l'excellent Jamie King sur youtube qui justement explique bien les notions de c# et décortique certaines syntaxes pour montrer que rien n'est magique mais plutot bien pensé .
1  1 
Avatar de air-dex
Membre expert https://www.developpez.com
Le 07/09/2020 à 23:11
@VDD : le hic est que Rust ne nourrit pas encore son homme. Ce ne sont pas les technos sympas qui manquent. Par contre elles sont rarement présentes en masse dans les offres d'emploi.

Pour prendre un autre exemple, plus axé GUI. J'adore QML, mais si je devais recommencer je le laisserai complètement de côté au profit de CSS que je n'aime pas et que je trouve archaïque au possible. Je ferai cela uniquement parce qu'il ne faut généralement pas compter sur QML pour trouver un boulot permettant de vivre du développement. Par contre CSS c'est pourri, mais ce ne sont pas les offres qui manquent. Heureusement que Sass ("SCSS" est digeste et peut ainsi représenter un bon compromis.
0  0 
Avatar de boumchalet
Nouveau membre du Club https://www.developpez.com
Le 11/09/2020 à 20:50
J'adore Rust et il a plein de qualité notamment pour la concurrence, le problème n'est pas là.
Des choix de conception ont été faits à juste raison (par exemple: match ,Valeur et mutabilité,Possession et emprunt).
Ces choix limiteront dans le futur son évolution, car c'est des contraintes. Ce qui en fait plus un DSL qu'un langage universel.
Pour l'instant les gains sont plus importants que les contraintes, mais je pense que cela ne sera pas toujours le cas.

NOTA Rust utilise LLVM c++ en backend
0  0