brokensoul a écrit :



avec des lambdas et la std, c’est trivial





C’était déjà trivial avant ça, le problème c’est que c’est verbeux. Moins depuis l’introduction les lambdas, mais c’est toujours verbeux, la faute à la gestion manuelle de la mémoire qui fait obstacle aux modèles fonctionnels et à l’interface des itérateurs.



Aujourd’hui ta solution reposera sur la création d’une liste puis sa mutation. Et elle fera cinq fois plus de caractères. Et pour ces raisons en C++ on optera plutôt pour des boucles. Dommage : un programmeur passe pourtant des heures par semaine à écrire ce genre de boucles.

• compilation > super rapide avec clang, sinon un petit ccache est bien efficace. Pas un problème en pratique
  
  
  
  Déni de réalité. Va dire ça aux grands noms de l’industrie qui exposent à la cppcon les efforts qu’ils doivent déployer pour garder le temps de compilation sous contrôle et le pourquoi des modules.
  
  
  
  
  


• inférence de type > jette un oeil sur c++ d’après 1995, tu as le droit de te renseigner sur ce que tu commentes. “auto”, c’est pour la poubelle ?
  
  
  
  
  
  • gestion mémoire ‘semi automatisée’ : la gestion des pointeurs est quand même super simple maintenant, et ca te donne des gains en perfs dont d’autres langages peuvent encore rêver
    
    
    
    (…)Maintenant si tu dis que tel ou tel langage super exotique fait ‘évidemment’ beaucoup mieux, reste :
    
  
  
  • à le prouver
    
    
    
    J’ai déjà répondu à cela dans ce fil, je t’invite à cliquer sur mon nom pour voir mes messages récents si cela t’intéresse.
    
    
    
    
    
  
  


• la plupart de tes critiques sur du code trop verbeux concerne les templates. Tu as le droit de ne pas les utiliser..
  
  
  
  Le problème ne réside pas dans les templates, le problème réside dans le fait de devoir avoir recours à des templates pour émuler des comportements qui sont bien mieux pris en charge autrement par d’autres langages. Ces langages ont pourtant des équivalents aux templates.
  
  
  
  
  
  (reste) à avoir un écosystème qui le rend utilisable (l’inconvénient de partir de zéro, on ne gagne pas à tous les coups)
  
  
  
  J’ai moi-même dénoncé les limites de la solution Rust à l’heure actuelle.

lysbleu a écrit :



Une gestion mémoire semi-automatisée ? Avec les shared_ptr, elle est totalement automatique.





Bien sûr que non :

Tu dois écrire shared_ptr partout au lieu de Actor (ou Actor en D).



* Si jamais tu as un cycle dans ton graphe, ton shared_ptr va créer une fuite mémoire. Or le compilateur est incapable de détecter pour toi cette fuite et rien n’est fait pour t’aider à la détecter.



* Tu ne vas pas écrire partout shared_ptr pour des raisons de perfs, tu vas continuer à considérer systématiquement comment ta variable sera utilisée et choisir un unique_ptr, un shared_ptr, un weak_ptr, un pointeur, une référence ou une allocation in-situ. Puis tu vas décider de définir ou non la constante de compilation spécifiant l’utilisation d’un compteur non-atomique, sachant que ça a toutes les chances de te rentrer dedans à l’avenir. Autant de choses que le compilateur pourraient faire pour toi.



Ce n’est pas ce que j’appelle complètement automatisé !





Des itérateurs de 50 caractères ? “auto” : 4 lettres.



Et personne n’utilise auto. Pourquoi ? Tout simplement parce que le putain de modèle de compilation de C++ rend extrêmement difficile son analyse, ce qui fait que tous les putains d’outils sont pourris et qu’aucun putain d’IDE n’est foutu de t’afficher correctement une putain de tooltip par-dessus “auto” pour te dire quel est le vrai type de cette putain de variable. En 2015 !



Quand je code dans un langage moderne avec un IDE fonctionnel j’utilise l’inférence de types a tout bout de champ. Quand je code en C++ je n’utilise jamais “auto” parce que sur les dix plus gros IDE du marché il n’y en a aucun qui soit bon avec le C++ (seul celui de QT fait un bon boulot décent sur l’analyse).





Pour le reste, ce n’est pas très clair de quoi tu veux parler, mais je suis sûr que le C++ le fait très bien. Bref, tu ne sais pas de quoi tu parles.



" />

white_tentacle a écrit :



Rust est fait pour être un compromis entre sûreté, performance, facilité d’écrire du code. Donc quelque soit un aspect, tu trouveras à critiquer : c’est le principe d’un compromis.





Et personne ne veut de compromis, c’est bien là le problème. L’industrie du JV et d’autres ne veulent pas d’un langage deux fois plus lent et MS et d’autres ne veulent pas d’un langage un peu plus sûr pour leurs OS.



Quant au C++ il ne fait pas de compromis : il ne s’encombre pas de la sécurité, il lui crache au visage. Ce qui est une démarche acceptable dans bien des cas. Son seul problème c’est qu’il est vieux et improductif, et qu’on peut quand même faire plus vérifiable sans empiéter sur les perfs.





C’est nettement mieux que tout ce qu’on nous a vendu comme alternatives à C++ pour l’instant…



Je suis bien d’accord. Mais pour l’heure ça ne suffit pas encore. Mais comme je l’ai dit plus tôt, ce langage a le potentiel pour devenir un remplaçant au C++ avec un autre compilateur. Malheureusement cet avenir n’est pas compatible avec les objectifs actuels de Mozilla pour ce langage, qui font passer la sécurité d’abord.

sr17 a écrit :



Mais au fond, peut être aussi que beaucoup de programmeurs C/C++ ne cherchent justement pas à élever le niveau d’abstraction parce qu’ils se servent surtout de ce langage comme d’un langage de bas niveau. Ils ne veulent pas plus d’abstraction, mais moins d’abstraction et plus de contrôle.





C’est une remarque intéressante à laquelle je réfléchirai.



Mais peut-être qu’il leur faut simplement des abstractions prévisibles et vérifiables, comme le modèle objet qu’ils utilisent à longueur de journée. Plus simplement je pense que c’est un problème d’expérience utilisateur (l’utilisateur étant le programmeur) plutôt que d’abstraction.





L’exemple, c’est le noyau Linux qui est écrit en c. Demandez à Linus ce qu’il pense de c++, vous ne serez pas déçu du voyage…



Je ne suis pas sûr que ce soit une bonne référence. ;)



Cela dit le C++ n’est pas fait pour travailler en mode kernel, il faut quelque chose de très primitif du fait de l’absence de mémoire virtuelle et du risque de page fault. A à ce niveau je ne vois que le C.



Cela dit le code en mode kernel devrait être le plus petit possible et pour tout le reste je ne vois vraiment aucune raison d’utiliser le C à part la religion.





En même temps, dans ce langage, quand on l’exploite pour ses performances, on privilégie souvent une gestion fine et personnalisée de la mémoire. Cela peut aboutir à des gains de performances importants, donc des choses qu’on cherche à maîtriser.



Comme je l’ai expliqué dans mon précédent message, je ne voulais pas dire que le langage devrait gérer la mémoire.

white_tentacle a écrit :



C’est tout le problème de faire face à un standard établi. Si Rust et C++ avaient le même niveau de maturité / développement, en ce qui me concerne le choix serait vite fait et en faveur de Rust : les quelques avantages de C++ ne se justifient pas face à la sûreté de Rust.





C’est vite dit mais par exemple dans le JV un rapport de performances du simple au double ça veut dire laisser ton super modèle d’illumination de côté et rester sur les technos de la génération PS2-PS3.

lysbleu a écrit :



substitutions de chaîne, le pattern matching : Présent en C++ de manière standard, donc je ne vois pas de quoi il parle lorsqu’il sous-entend que c’est inexistant en C++.

Type algébrique : je ne vois pas ce qui empêche de le faire en C++.





Voici un exemple de type algébrique couplé à du pattern matching (qui, non, n’est pas présent en C++).



enum expr = Number | Addition(x, y) | Mutliplication (x,y)



def factoriseEquation(expr) match expr

 case Addition(Multiplication(a, x), Multiplication(b, x)) => Multiplication(x, Addition(a, b))   


 case \_ => expr   

Amuse-toi à écrire ça en C++. Et pas seulement un pauvre bidouillage, quelque chose qui pourrait comme ici servir de fondation à quelque chose de plus vaste. ;)



NB : l’indentation a été virée par PCI/NXI, désolé.





Linq : Apparemment c’est spécifique VS / C#, donc effectivement je ne connais pas.



Linq ou les continuations de listes dans bien d’autres langages (list continuations) permettent par exemple d’écrire :



// Parmi les étudiants ayant assisté à 90% des cours on retient les 20 avec la meilleure note moyenne

var étudiantsSélectionnés = étudiants

  where présenceAuCours > 90    


  order by notes.Average()   


  take 20   

Amuse-toi à écrire ça en C++.





types structurels anonymes



Besoin de faire une requête SQL pour ne récupérer que deux pauvres champs de la ligne ? Dans certains langages tu peux écrire :

var rows = select (name, address) from table where age > 50   

Un type anonyme est alors créé avec deux champs name et address. Tout ça est inféré à la compilation et intellisense pourra compléter.



Amuse-toi à écrire ça en C++. Pardon à faire tourner ton outil de génération de code ORM après avoir cliqué sur des boutons pour lui dire que tu as besoin de faire telle requête.





cela consiste à remettre en cause la crédibilité de l’adversaire en ignorant totalement ses arguments, ce que je n’ai pas fait.



“Pour le reste, ce n’est pas très clair de quoi tu veux parler (…) Bref, tu ne sais pas de quoi tu parles.”.

white_tentacle a écrit :



C’est une légende urbaine et une négation de la genèse de C++ que de dire ça. En fait, Stroustrup a conçu le langage C++ pour l’écriture d’un système d’exploitation.





Ce n’est pas une légende urbaine : quand tu réalises un appel de méthode virtuelle, que tu lèves une exception ou que tu utilises les RTTI tu demandes implicitement au processeur de lire une zone mémoire distante, généralement située dans une autre page mémoire.



En mode utilisateur ça ne pose pas de problème : si la page en question n’est pas chargée dans la mémoire le noyau intercepte la faute de page et procède au chargement. Mais il ne peut pas en faire de même pour son propre code, tout doit être chargé explicitement, ce qui ne sera pas forcément le cas lors de la réponse à un IRQ. Et là c’est le BSOD.



Donc, oui, tu peux utiliser le C++ si en substance tu n’utilises pas ce qui le différencie du C.









francois-battail a écrit :



Quand tu as une volumétrie monstrueuse (vraiment monstrueuse), quand des portions de code sont exécutées des centaines de milliard de fois, que gratter 100ns à un endroit se traduit par un gain de 10 minutes au total, j’ai plutôt tendance à penser que choisir autre chose que le C (et l’assembleur) relèverait du dogmatisme (ou de la religion d’ailleurs).





Faire du procédural en C++ donne exactement le même résultat. Et rien n’interdit de mixer de l’assembleur. Ce n’est pas un pêché (pour rester dans la métaphore religieuse) !



L’essentiel c’est quand même que pour toutes les parties de ton code où tu n’as pas à gratter sur les performances tu pourras bénéficier des avantages du C++ par rapport au C.



Mais bon, la formulation était sans doute abusive. D’ailleurs je vois au moins une bonne raison d’utiliser le C plutôt que le C++ : les plateformes dénuées de compilo C++.







Herbefol a écrit :



Pas vraiment, la loi de Moore a toujours cours à l’heure actuelle et devrait survivre encore quelques années. Elle ne porte pas sur la vitesse d’horloge des processeurs mais sur le nombre de transistors qu’ils contiennent et de ce côté là, ça continue toujours d’augmenter à toute vitesse. :p





Ces dernières années le nombre de transistors n’a doublé que tous les 3 ans environ. Tout comme la consommation électrique en pointe (joules par opération) qui elle aussi a souvent suivi la loi de Moore et a bien ralenti.



C’est fini.

Khalev a écrit :



Un benchmark datant des alentours du 24 avril (donc ça a pu s’amélioré depuis):

http://www.viva64.com/media/images/content/b/0324_Criticizing-Rust-Language-Why-…





A terme il n’y a aucune raison pour que Rust soit plus lent que le C++ : ses abstractions ont un coût nul par rapport à ce qu’écrirait un dév C++ : toute la question de la gestion mémoire est résolue à la compilation.



Bon, pour l’instant cela dit le compilateur conserve certains sécurités à l’exécution (boundaries checks par exemple), du fait de l’orientation sécurité de ce langage, mais on trouvera bien des compilateurs pour les désactiver à l’avenir.









brokensoul a écrit :



intéressé, un peu curieux de voir à quel point c’est rapide et sûr. C++ c’est quand même bien amélioré question rapidité de codage avec les derniers /11 et /14, mais j’imagine bien qu’il est possible de faire mieux. Un peu surpris qu’il soit possible de faire aussi rapide que c++ sans jouer avec les pointeurs, j’attends des benchmarks :) (quelqu’un a testé ?)





Le principe sous-jacent du système de types de Rust est de générer un code de gestion de la mémoire aussi efficace que celui que tu aurais pu écrire manuellement.









TexMex a écrit :



C’est quand même utile pour un compilateur de savoir si tu traite du nombre et / ou autre chose.

Mais tant qu’on aura pas de vrais solution d’accompagnement (Tu sélectionnes tes 10 lignes et tu les tagges “integer”) et pas seulement un editeur de texte, bin voila.





Les types sont inférés à la compilation. Le compilateur sait parfaitement qu’il traite des entiers parce qu’à un moment tu lui as fourni une entrée qui, elle, était typée comme entier, et tout le reste a été inféré correctement.









Oryzon a écrit :



ça ressemble fortement à ce qu’à présenter MS il y a quelques temps…





Au niveau système MS travaille sur deux approches, l’une ressemblant un peu à Rust pour la sécurité de la concurrence (mais avec de grosses différences quand même, chercher Joe Duffy et M#), l’autre basée sur des spécifications (spec#).









brazomyna a écrit :



Et ce problème de perf en est de moins en moins un:

 - l'impact de ce genre de pratique sur la charge CPU est constant       


 - la puissance dispo des CPU augmente régulièrement

La puissance séquentielle des CPU n’augmente plus ou quasiment plus depuis dix ans, et le ralentissement s’accélère.



Quant à la taxe elle a toujours était proportionnellement constant : n% hier, n% demain. Elle restera toujours inacceptable pour de nombreux usages et elle va le devenir de plus en plus dans un monde à la puissance CPU finie.









brice.wernet a écrit :



Les langages managés ont l’avantage énorme de permettre des choses comme le déploiement sur architectures hétérogènes, la génération de code à la volée, l’envoi de données et de morceaux de programme à d’autres process/ordis.

Il leur manque en général les SIMD/la vectorisation, ce qui est dommage.





Question de priorités. Mais le nouveau compilo C# supporte la vectorisation et JS va bientôt gagner ça dans ses standards.