Firwen a écrit 562 commentaires

À ma connaissance Apple impose l'utilisation de leur technique de gestion de mémoire automatique, ARC (qui est bien une forme de gestion automatique de la mémoire, quoi que tu sembles dire

J'assimile plus ARC à une technique de RAII qu'a un Garbage Collector pure jus.

ARC en Swift est en tout point commun à une utilisation de shared_ptr en C++, juste intégré directement au lanuage au lieu d'être templatée.

Elle nécessite également une certaine gestion manuelle pour éviter les dépendances cycliques potentielles.

mais comment s'assure-t-on que notre base de code est bien passé à ces pratiques ?

Static analyzer et adresse sanitizer sur chaque build en continuous integration.

Plus banissement de tout utilisation des raw pointers si pas explicitement justifiée via les coding guidelines.

Les plus grosses sources de buffer overflow en C sont généralement : les manipulations de string, l'utilisation de buffer pour I/O.

En C++, std::string est heap-alloué et "safe". L'utilisation de buffet se fait via std::Vector qui est lui aussi heap-allocated

avec une toute petite place pour les langages de plus haut niveau, à l'inverse de iOS, Android etc.

Il en vas de même avec iOS et Android.

Android a un core en C++, La plupart des ses libs systèmes ont un backend en natif… C'est encore plus vrai avec l'OS Android "next-gen" Fushia de Google qui lui est entièrement en C++, incluant même le Kernel.

Android est un bel exemple de ce que je disais je pense. Quand Android est apparu, la majorité des Apps était effectivement quasiment intégralement dans un Java maison Google, L'OS étant également principalement en Java.

Aujourd'hui Android a vu une grosse parti de ses deps systèmes re-codés en natif, et la grosse majorité des Apps sont maintenant purement des WebApp en JS, avec un petit frontend en Java… se basant sur les libs native et le browser d'Android… qui lui est en C++.

iOS quand a lui a toujours été en langage relativement bas niveau (Objective-C) et sans garbage collector.

Je me sentirais beaucoup mieux si mon userland était écrit dans un langage sûr par défaut, même un langage aussi verbeux et peu tentant que Java

Suivant la définition de sûreté que tu utilises, Java n'est pas plus sûr qu'un programme en C++ moderne.

Je n'appelle pas un programme qui crash avec un null pointer exception plus "sur" qu'un programme qui segfault.

Java n'offre pas non plus d'avantage de sûreté en environnement multi-threadé ou une race condition et un crash y ait tout aussi simple à faire qu'en c++.

Son seul "gain" en terme de sûreté face à C++ concerned l'absence theorique de memory leak… Au prix d'un GC aux latences linéaire au nombre d'objets…. Problème qui est par ailleurs pratiquement éliminé en C++ avec la RAII

il faut du C++ parce qu'il y a actuellement du C++, donc demain il faudra du C++ car hier on avait du C++

Tu peux dénigrer l'argument autant que tu veux, mais fait est que dans le monde de l'entreprise, la taille de l'écosystème et la pérennité d'un language sont des arguments prépondérant, que tu le veuilles ou non, car ton manager décidera pour toi.

Si c'était vendredi, je dirai Et heureusement pour Java sinon il serait mort depuis longtemps.

Ça a l'air d'être un framework réactif avec une event loop en c++.

C'est beaucoup plus que ça si tu regardes en détail. C'est un mélange de ce que tu peux faire avec boost.Fibers, un système d'I/O a la boost.Asio mais zero sharing et message passing. Ca see rapproche de ce que fait CAF ( c++ actor framework ) mais très orienté performance ( et pas mal bloated )

Seul hic, Beast n'a pas encore de parseur URL mais le développeur principal a dit que c'était prévu.

Si ça peut te servir :

https://github.com/adevress/hadoken/blob/master/include/hadoken/network/uri.hpp

C'est header-only et sous License Boost.

Et si on parlait aussi du nombre de crash sans stacktrace et du temps de développement lors de la création de votre programme C++ ?

Un snippet de 50 lignes de code que tu trouves dans un peu prêt tous les lib utilities C++ digne de ce nom peut te donner les stack trace en C++ si tu les veux.

Mais un programme C/C++ qui crash, il "stack-trace" pas… Il coredump… C'est différent…. Ce qui te donne ta "trace".

ScyllaDb ? Je ne sais pas où ça en est mais au début ils avaient des problèmes de résilience (ce qui est dommage pour une base de données sont c'est le principal intérêt). Mais c'était il y a 3 ans ça a pu évoluer.

Pour l'avoir utilisé, ScyllaDB est un monstre de qualité et de complexité designé par des programmeurs C++ dans le top 0.5% des meilleurs disponibles au monde je dirai….. Ce genre de code n'est pas accessible au premier venu.

Mais le résultat parle de lui même, ScyllaDB démonte littéralement Cassendra en terme de performance sur tous les points de vues ( Latence, Throughtput, Scalabilité ).

Ce qui n'est pas forcément étonnant quand tu vois qu'ils ont réimplémenter leur propre stack TCP en user-space et leur propre model de threading….

Et que je te met un new à la place d'une variable locale

Ça c'est mon test niveau 0 pour détecter un programmeur Java qui a touché à mon code C++. Malheureusement, que je vois validé beaucoup trop souvent.

et que je ne fait que du shared_ptr parce que c'est trop compliqué de réfléchir un minimum

Te plains pas, c'est déja mieux que ceux qui te passe uniquement des raw pointeurs C, parce que "les smart pointeurs j'ai pas confiance" :D

Go quand on vient de Python ou comme premier langage

Personnellement, avec du recul, je déconseillerais franchement Go pour un programmeur débutant. Les choix fait pour le design Go sont tellement peu orthodoxes que c'est un peu comme s'isoler sur une ile déserte dés le début de son apprentissage.

Beaucoup trop de paradigmes dans un seul langage : impératif, objet, fonctionnel, méta-programmation avec les templates, etc. Du coup tu as une syntaxe très lourde et riche ce qui rend difficile sa maitrise ;

J'aurais tendance à penser qu'un langage multi-paradigme pour apprendre la programmation est mieux qu'un language "pure", car il permet de toucher plus de concepts.

C++ est déclaré vieux et obsolète depuis au moins 10ans. Pourquoi serait-ce plus crédible ce coup-ci?

Bjarne Stroustrup à la CPPCON2017 : "C'est très dur de concurrencé C++, beaucoup ont essayé, personne n'y ait parvenu "

Bon courage pour faire ça en C++ :)

Y a une 50ène de solutions qui existent pour remote débugger un programme en C++, ou même le profiler en temps réel sur un serveur en prod.

Incluant des softs qui fonctionne du supercalculateur, ou cluster trés large scale avec GUI & co ….

Et oui, il n'a pas la maturité de C++… est-ce réellement une bonne raison pour ne pas le choisir, je suis pas sûr. Tout langage sorti après C++ est forcément moins mature. Et pas que je sois un prosélyte de Rust, mais il a déjà fait parlé de lui en bien dans des projets de très grande ampleur, notamment parce qu'il est mieux pensé que C++ sur pas mal d'aspects.

Pour ton projet perso, problablement "Non", car tu recherches le fun.

Pour un projet Pro, c'est une autre histoire. Dans la majorité des boites, si tu vas voir ton boss en lui disant: "J'ai ce nouveau projet, je voudrais le faire en Rust", la réponse sera "Non". Et pour de trés bonne raison: pérénité, maintanabilité, expertise.

Recruter quelqu'un qui a une expertise C ou C++, c'est trivial… Les programmeurs C++ sont chers et trés bien payés, mais ils existent… Trouver quelqu'un qui a un niveau réel d'expertise en Rust, c'est autre chose.

Allouer des objets par millions, c'est contre productif en C++ tout comme avec les langages avec GC (Java, C#, etc…) l'allocation mémoire est très pénalisante en C++

C++ ainsi que la plupart des languages à allocation manuel te donne un contrôle très fin sur ton layout mémoire.

Allouer un million d'objet en C++ ne pose aucun problème si c'est fait de manière intelligente… dans un vecteur ou avec ta propre pool… Ça sera même dans ce cas une seule et unique allocation.

Ce qui est souvent non-trivial, ignoré par la majorité des programmeurs, ou totalement impossible dans les languages à GC / de trés haut niveau.

Je le mentionnais dans mon message pour expliquer que le nombre de domaines applicatifs perçus comme "ne tolérant pas un GC" diminue, longtemps les jeux vidéos ont été cités en exemple, ce n'est plus pertinent aujourd'hui.

Je ne suis pas d'accord. Les jeux vidéos ont, sont toujours, et seront toujours en C++ ( du moins à court terme ). Ce qui est en C# c'est l'interface de scripting des jeux pour Unity, ce qui est normale et n'a rien de révolutionnaire. Elle était en Lua, python ou home made script ( Unreal script ) pendant très longtemps.

Le C# ne remplacera jamais le core même de l'Engine car critique. Il rend juste l'interface externe plus "accessible". Tout comme le calcul scientifique ne sera jamais entièrement fait en python…. Il rend juste l'interfaçage à BLAS plus accessible. Tout comme la plupart des frameworks de machine learning ne seront jamais fait entièrement en Lua / Python / JS…. ils wrappent simplement des libs systèmes existante.

Je pense au contraire l'opposé. Dans le sense où le temps des languages frameworks monolitiques géants, vivant sur leur propre ecosystème, le tout tournant sur un Garbage Collector comme Java est révolu.

Ils perdent de la vitesse et tend à disparaitres en ce faisant remplacer par des languages de scripts haut niveau ( donc souvent à GC ) associés à des libs systèmes justement codé en C, C++ ou Rust.

− C'est le cas de Python devenu le de-factor standard en Calcul Scientifique ( Même si Julia tente de se faire une place )

• C'est le cas de Python / Lua pour quasiment TOUS les frameworks de Machine learning.

• C'est le cas de Golang qui crée des binaires static, AOT tout en incluant directement des fichier objets en code C pour s'interfacé avec les libs tiers.

• C'est le cas de Swift qui a trés justement éviter les erreurs faites avec Java & Android en se basant sur une grosse stack existante en ObjectiveC.

Prends un bon 90% des logiciels que tu vois sur ton écran à l'instant ils suivent ce pattern :

• Ton Web Browser: un core en C++ et un scripting en JS

• Ton Environment GNOME SHELL ou PLASMA : Un core en C ou C++ et un language de scripting

• Ton client mail, ton file browser, Même trés certainement le GUI de l'ordinateur de bord voiture fonctionne pareillement… Le mien est en JavaScript avec un Backend en C.

Les languages système sans GC comme C++ ne disparaîtront pas, trés loin de là, ils sont derrière un peu prés tous les outils que l'ont utilise tous les jours, et encore pendant trés longtemps…. Le code "métier" par contre, le code "GLUE" entre les composants… lui ira de plus en plus vers des languages de haut niveau pour des raisons d'accessibilité…. Trés vraisemblablement.

Tu fais référence à qui au juste ? À ma connaissance les gens qui ont fait ce bench ne les auteurs d'aucun langage en particulier

Le blog post, la présentation sur le sujet et les measurement viennent directement des devs de Go et sont chez google.

Les pauses du GC sont inférieures à la milliseconde, d'après les chiffres de ce billet.

j'ai toujours des problèmes avec les benchmarks fait par les concepteurs du langage eux même.

Pour 1, à part quelques vieille application Corba, je ne connais pas de nouvelles grosses applications C++ maintenable, je serais intéressé d'en connaitre

Le C++ est surtout utilisé pour des applications systèmes, moins pour des applications métiers.

La plupart des grosses DB, File system distribué, Load balancer, Object Store & co sont.

Ça dépend aussi beaucoup de la politique de ta boite, où je travaille c'est généralement plutot backend en C++ avec des micro-services en python / node / plutot que les classiques bloatware en Java.

Par contre il y a beaucoup d'utilisateur de la JVM pour ce genre d'application (SAP, 95% des application d'IBM / Oracle / HP / Talend, tous les ETL, les ESB (qui doivent avoir une latence stable) …).

Si j'avais envie de troller, je dirai que déja SAP, JVM et latence stable dans la même phrase c'est déja une oxymore en soit.

et d'ailleurs pas mal de code à haute performance côté serveur est écrit en Java.

Tu as des noms en tête ?

J'ai souvent remarqué que dès qu'une app serveur dépasse une certaine échelle ou requiert une latence stable, elle est réécrite tôt ou tard en C++

Il existe _une manière de s'en assurer ? Parce que tant que l'on ne peux pas garantir qu'une base de code ne le fais pas il faudra pour moi évaluer le langage dans son ensemble.

Avec de bonnes guidelines et des code review… sans problèmes oui…

Le coté pragmatic de C++ est autant une force qu'une faiblesse. C'est un language qui a survécu à toutes les "fashion d'un temps" de ses 20 dernières années.

Et coté chaleur, vous avez fait quelques choses ? Les derniers cpu d'intel parte du principe qu'ils doivent ralentir au delà d'une certaine température, ce qui est forcément le cas avec un cas d'usage aussi intense.

C'est le cas sur les séries KNL en effet.

Peu d'IO alors ?

Comme quasiment tous les simulateurs, Zero I/O sauf dans une phase de reporting finale où l'intégralité des noeuds font du écrivent tous en parallèle (Burst I/O ).

Il n'utilise pas beaucoup de mémoire ?

Il utilise énormément de mémoire ( aisément0 75/80% de la capacité des noeuds ). Mais les calculs effectués ont une trés grosse localité.