C ++ vs C #



Tout le monde sait qu'il n'y a rien de plus stupide que de discuter «quelle langue est meilleure». Par exemple, mieux pour quoi? Différentes langues réussissent dans des créneaux différents - et il est inutile de tirer des conclusions définitives sans en tenir compte.

Mais que se passe-t-il si vous vous adressez à des spécialistes expérimentés qui comprennent eux-mêmes tout cela et leur demandez d'organiser l'holivar C ++ vs C #? Il s'avère que vous pouvez découvrir de nombreux détails intéressants. Le mot «multiplateforme» peut être appliqué dans les deux sens aux deux langues, mais qu'est-ce que cela signifie dans la pratique? Le C ++ se développe-t-il activement maintenant? C # a-t-il déjà rompu la compatibilité descendante? Les réponses peuvent être évidentes pour ceux qui sont déjà profondément immergés dans les deux langues à la fois, mais il y en a peu - et tout le monde apprendra quelque chose de nouveau.

Du C ++, Sergey sermp Platonov , président du comité de programme de la conférence C ++ Russie , a participé. Le côté C # était représenté par Anatoly Kulakov - il est inclus dans le PC de la conférence DotNext , et parmi les dirigeants de DotNetRu . Et le leader de la discussion, dans la vie de laquelle ces deux mondes coexistent, était Dmitry mezastel Nesteruk .




Dmitry: Bonjour, chers collègues. Bienvenue aux rencontres informelles sur le thème des langages de programmation. Sur Internet, il nous est constamment rappelé que les langues ne sont pas comparables. Et aujourd'hui, nous ferons exactement ce que vous ne pouvez pas faire: comparer C ++ avec C # et .NET, leurs avantages et leurs inconvénients. Présentez-vous s'il vous plaît.

Anatoly: Je m'appelle Anatoly, et aujourd'hui je vais me noyer pour C #, car j'ai étudié ce langage depuis ses premières versions et, semble-t-il, je sais tout à son sujet.

Sergey: Salut, je m'appelle Sergey, je vais me noyer pour C ++ aujourd'hui. Dima a correctement dit que nous comparerons les avantages et les inconvénients. Tout le monde l'appelle "Pros", on sait que, il s'avère que C # dans cette discussion sera un inconvénient. Est-ce vrai, Anatoly?

Anatoly: C # a deux autres avantages! Par conséquent, je pense qu'il s'agit d'un développement évolutif des avantages qui sont déjà obsolètes et ne sont pas en mesure de rivaliser presque partout.



L'éducation


Dmitry: J'ai le premier sujet de notre discussion. Imaginez que de nouveaux étudiants viennent à l'université, ils ont besoin de la première langue. Selon vous, quel devrait être le premier langage que les gens obtiennent au cours de leur première année: C ++, C # ou assembleur en général?

Sergey: J'ai enseigné pendant un certain temps, donc j'ai une opinion bien établie. Je comprends qu'ici nous allons discuter du langage qui est le meilleur, et je représente C ++ ... Mais pour apprendre le C ++, vous devez comprendre l'architecture de l'ordinateur. Et avec cela, le gros problème de l'enseignement aux étudiants (du moins dans l'université où j'ai enseigné). Et pour enseigner les algorithmes et autres choses, vous avez probablement besoin de quelque chose qui ne se concentre pas sur l'infrastructure, dans le langage lui-même. Ici, Eiffel a tenté de le faire, mais il y a aussi beaucoup de magie. Par conséquent, je dirais qu'aucune de nos deux langues ne convient.

La programmation est différente, et ce n'est pas la «programmation» qui enseigne, mais les algorithmes, les structures de données, etc. Il est possible qu'il soit judicieux de choisir votre propre instrument sur chaque sujet. Comprendre une sorte de structures de données Lisp. Et le C ++, en conséquence, devrait être donné après que les étudiants ont compris quelque chose sur l'architecture. Et puis il sera possible de comprendre pourquoi toute cette douleur et cette souffrance. Je ne dirai même pas que les avantages concernent la douleur.

Anatoly: Oui, je suis tout à fait d'accord pour dire qu'il faut séparer les objets, ne pas les mettre en «programmation» et tout marteler dans une langue. Mais si vous arrivez au point où vous avez appris les bases, les principes de base, les algorithmes et commencez à choisir une sorte de langage industriel, alors, bien sûr, C # sera bien meilleur. Parce que cela ne vous oblige pas à apprendre toutes ces lies au niveau des architectures, des octets de mémoire et autres «couchers de soleil à la main». Il donne un langage immédiatement compréhensible, une syntaxe simple, et dans cette langue dès la première ou la deuxième année, vous pouvez gagner de l'argent assez tangible.

Dmitry: Il y a un argument selon lequel ne pas donner aux étudiants débutants des choses comme des pointeurs est une sorte de sacrilège. Ils auront un énorme trou si une personne ne comprend pas que, par exemple, un lien n'est en fait que l'adresse d'une variable en mémoire. Qu'en pensez-vous?

Anatoly: il y a 20 ans, c'était vrai lorsque les ordinateurs n'avaient pas assez de mémoire, pas assez de disques et d'autres choses. Regardez maintenant ces javascripts, ils font glisser 500 mégaoctets de bibliothèques dans chaque "bonjour". Combien prennent-ils en mémoire? Quelle est leur performance? Quels sont les liens là-bas? Oui, personne ne s'en soucie. L'essentiel est de rouler rapidement et de sortir quelque chose en production. Je ne prétends pas que c'est une bonne ou une bonne façon, je soutiens qu'il est nécessaire de changer avec les réalités. Peut-être que maintenant, le montant de votre lien n'est plus si important.

Sergey: Probablement selon où. Autant que je sache, Dmitry était intéressé par le trading algorithmique - je peux imaginer clairement comment il récupère les bibliothèques sur JS pour envoyer une commande à la bourse.

Dmitry: Eh bien, oui, bien sûr, dans la pratique, personne n'y utilise des langues de ce type. Bien que cela soit théoriquement possible: n'oublions pas que de l'argent non faible est injecté dans l'infrastructure JS. Des moteurs qui font de la compilation JS n'importe quoi et n'importe quoi. Beaucoup considèrent cette langue comme la langue de première classe pour tout en général.

Naturellement, le trading algo est désormais une discipline éloignée d'une telle discipline, mais le trading algo et les mathématiques financières dans leur ensemble sont généralement un domaine spécifique. Il prédomine juste en C ++. Et il prédomine en partie à cause de l'inertie, simplement pour des raisons historiques: au début, tout le monde était en C ++, et ce domaine est conservateur.

Sergey: Je ne suis pas d'accord. Je travaille maintenant dans la fintech, et des collègues qui sont ici depuis le tout début du trading algorithmique parlent des grandes entreprises qui ont écrit pour la première fois en Java. Au début, Java a fait face au trading algorithmique, mais lorsque le marché a commencé à croître et que les concurrents avec C ++ sont apparus, à un moment donné, ils ne pouvaient tout simplement pas le faire, ils n'ont pas réussi à tout faire efficacement ... Donc, tout le monde dans le trading algorithmique n'a pas commencé avec C ++. Seuls ceux qui n'y ont pas écrit sont morts. Une telle sélection naturelle.

Dmitry: En fait, vous pouvez l'élargir. Il existe de nombreux exemples où même les grandes banques conservent leurs algorithmes dans un document Excel. Ils utilisent ensuite Excel également comme serveur pour calculer tout cela. Il y a des freins infernaux, mais tout dépend si vous faites du trading à haute fréquence (ou généralement quelque chose de haute fréquence). Si vous êtes un market maker, il est naturel que vous ayez besoin de hautes performances, et là-bas, l'entreprise ne se limite même pas au C ++, on passe au matériel et aux langages HDL.

Mais notre discussion ne porte pas seulement sur le trading algorithmique, mais aussi sur des choses simples. Ici, je donne un exemple. Dans le cadre de la construction, j'avais besoin d'écrire plusieurs petites applications calculant différentes choses: par exemple, comment poser des briques autour du contour d'une maison. Et je peux à peine imaginer comment faire de telles choses en C ++, car tout ce qui concerne l'interface utilisateur y est plus faible. Il n'y a qu'un seul framework, Qt, et même écrire dessus est très difficile. Et si je m'assois pour C #, pour WinForms, alors je fais juste instantanément l'application.

Anatoly: Eh bien, la partie visuelle a toujours été une force de C #. Microsoft a beaucoup investi dans les moules, et même dans les moules multiplateformes, et en général dans la visualisation. Par conséquent, si nous parlons d'applications de bureau visuelles, il me semble que les avantages sont généralement loin derrière.

Sergey: Eh bien, cela dépend, comme toujours. Je n'aime vraiment pas l'interface utilisateur, mais sur les points positifs, je dois constamment le faire. Il semblerait apporter JS et simplement interagir avec les pros. Mais j'ai travaillé avec embarqué, et là c'est difficile. Les gens ont acheté une sorte de moteur rapide et cher, mais il ne pouvait toujours pas faire face au rendu normal de l'interface utilisateur écrite en JS. Et après avoir réécrit tout cela sur Qt, il s'est avéré overclocker. Histoire ordinaire.



Multiplateforme vs multiplateforme


Sergey: Je voulais clarifier ici. Je ne connais pas grand-chose au C #, je l'ai touché moi-même il y a très longtemps, dans les toutes premières versions (à l'époque j'étais en rupture de compatibilité descendante). La question est donc la suivante: est-il toujours développé uniquement par Microsoft?

Anatoly: Non, il est maintenant multiplateforme, ouvert et vérifié sous ISO (ECMA-334 et ISO / IEC 23270). Soit dit en passant, pour autant que je sache, C ++ n'a toujours pas de spécification ISO ouverte, seulement payé. Et C #, en revanche, est complètement ouvert. Développé par de nombreuses entreprises (dont Google, Amazon et Samsung), nous avons la Fondation .NET . Je ne connais même plus de langage plus ouvert que C # et sa plate-forme .NET.

Sergey: Eh bien, Haskell.

Anatoly: Au fait, l'auteur de Haskell travaille chez Microsoft Research et a fait beaucoup d'efforts pour faire apparaître toutes sortes de choses sympas en C # - par exemple, un contrôle statique, une sorte de réflexion, dont vous ne pouvez probablement même pas rêver.

Sergey: Ils peuvent rêver, et même le travail se poursuit dans ce sens. Mais il est clair que tout a son propre prix. En C ++, ils refusent simplement de payer ce prix.

Anatoly: Lequel? Ils sont compilés pendant deux heures, quel pourrait être le prix d'autre?

Sergey: En C ++, le principe de l'abstraction à coût nul. Eh bien, c'est-à-dire qu'une machine virtuelle n'est pas une abstraction à coût nul, non? Nous devons accepter cela.

Dmitry: Eh bien, mais une machine virtuelle peut, par exemple, masquer du code pour une architecture particulière. Alors qu'en C ++, si j'utilise l'instruction AVX sur un ordinateur sans AVX, mon processus s'arrête simplement. Je dirais que cet argument n'est pas tout à fait correct, car théoriquement - j'insiste, théoriquement - JIT peut faire ce que le C ++ n'est pas disponible. A savoir, l'optimisation au moment du lancement.

Sergey: Mais en C ++, lors de la compilation, vous pouvez contrôler complètement les instructions dont vous avez besoin. Dans ce cas, vous ne le contrôlez pas avec vos mains, mais vous abandonnez l'instrument (compilateur). Regardez, quelles instructions sont sur cette architecture, quel ensemble d'instructions ...

Dmitry: C'est compréhensible. Mais vous pouvez le formuler de cette façon: puisqu'il y a un million de plateformes, nous n'obtiendrons jamais aucune sorte d'idéal, car nous ne pouvons pas publier un million de versions avec des drapeaux de compilation différents. Non? Nous publions généralement x86 et x64, mais ne les décomposons pas tous en certains sous-groupes.

Sergey: Pourquoi ne pouvons-nous pas? XXI siècle. Tenez Docker avec différents paramètres, c'est tout.

Dmitry: Quand nous avons un client final qui télécharge notre application, il veut télécharger un binaire spécifique. Et dans ce binaire, le mieux que nous puissions faire est de rester partout si. Comme "si cpuid est tel ou tel et que le support avx est tel ou tel, alors nous utilisons l'algorithme version 25". Par conséquent, nous avons besoin de 25 versions différentes du même algorithme, car l'accélération dépend des plates-formes, elle dépend de la plate-forme.

Sergey: Je suis probablement d'accord. C'est juste que, pour être honnête, je n'ai jamais créé de produit non interne. Je travaille principalement dans des entreprises qui utilisent elles-mêmes leur produit.

Dmitry: Eh bien, bien sûr, la meilleure option est lorsque vous connaissez de façon prévisible l'architecture. Dans ce cas, à strictement parler, personne ne vous oblige à utiliser des instructions x86 du tout. Vous pouvez prendre une carte spécifique (par exemple, Nvidia Tesla) et faire ce que vous voulez. C'est aussi mon approche, je contrôle mon architecture. Mais lorsque vous prenez des décisions de marché de masse pour l'utilisateur ... Si vous prenez du ReSharper conditionnel, il ne peut pas simplement prendre et utiliser l'accélération GPU pour des indices arbitraires. Parce que l'accélération GPU n'est pas une chose portable.

Sergey: En fait, il y a des approches (maintenant vous n'avez probablement pas besoin d'entrer dans les détails), il y a des gars intéressants (l'auteur de l'approche, semble-t-il, est maintenant également passé à Microsoft). Lors de notre conférence de l'année dernière, il y avait un rapport sur la façon d'écrire un tel programme, qui lui-même comprendra où il se trouve (relativement facile, encore une fois, des abstractions à coût nul). Pour que vous puissiez choisir à la volée et, le cas échéant, reconstruire correctement le code dans un style CUDA ...

Dmitry: En fait, CUDA lui-même essaie de résoudre ce problème, car dans CUDA, il existe une certaine couche intermédiaire de PTX qui s'occupe de cela. Mais cela reste très difficile, car le fer change radicalement évolutivement, et il est très difficile de le suivre du tout. Et si nous examinons l'utilisation de l'accélération GPU, par exemple, dans les produits Adobe, ils utilisent une section très étroite des technologies disponibles. Si votre carte est correcte - alors oui, tout le sera. Mais si c'est un peu exotique, rien n'est garanti à cet égard.

Anatoly: Dans cette discussion, nous avons abordé un sujet assez important, un tel mythe: C ++ a été déclaré il y a de nombreuses années comme un langage multiplateforme, mais pour le moment, la multiplateforme est beaucoup plus en C #. Un seul et unique binaire fonctionne partout où .NET est pris en charge, et c'est presque partout.

Sergey: Eh bien, c'est aussi assez infondé. En tant que personne qui a passé la majeure partie de ma vie dans le domaine de l'intégration, j'ai rarement vu .NET être pris en charge par la chaîne d'outils du fabricant de matériel. Les entreprises qui produisent du fer prennent le même G ++ ou Clang ou lui font commencer à générer du code pour leur plate-forme.

Dmitry: Oui, mais le problème est que chaque fois qu'ils font cela, ils perdent quelque chose de C ++. Par exemple, Nokia a utilisé une variante de C ++, mais leur C ++ était avec des rebondissements et des API folles qui ont rendu tout le monde furieux. Autrement dit, ce n'est pas seulement C ++, mais C ++ pour l'une ou l'autre plate-forme. Et puis les problèmes commencent. Par exemple, prenez le même CUDA. C'est comme si elle devait simplement laisser passer les pros elle-même; ce n'est pas du tout un compilateur, mais juste un pilote. Mais malgré cela, elle a des problèmes avec le fait qu'elle utilise toujours une sorte de cadre pour déchirer les fichiers CUDA en parties GPU et CPU. Et parfois, elle ne réussit pas.

Sergey: Je ne voulais pas dire ça un peu. C'est juste que lorsque j'entends «.NET s'exécute partout», la plupart de ma biographie de travail se détend. Lorsque vous achetez un matériel avec un processeur personnalisé, il est livré avec la livraison G ++. Et il y a le C ++ ordinaire, que G ++ peut convertir de la chaîne d'outils en code machine pris en charge par ce processeur particulier.

Dmitry: Mais encore une fois, cela doit être remonté ...

Sergey: Bien sûr.

Dmitry: Et l'idée que nous prenons un code plus existant et le faisons glisser sur un morceau de fer - cette idée ne fonctionne pas non plus, car tout à coup, vous avez fait glisser votre x86 normal quelque part, où vous avez 8 gigaoctets de mémoire pour tout sur tout, et ce n'est pas développer: par exemple, il n'y a pas d'échange sur le disque, car il n'y a pas de disque et n'y accédez pas. C'est si nous parlons de portabilité. Cela dépend des objectifs, naturellement.

Anatoly: les pros travaillent sur plus d'appareils et, bien sûr, l'embarqué est l'une des parties les plus solides. Mais généralement, vous devez en quelque sorte adapter votre code à la plate-forme. C'est mauvais. Je peux couvrir un grand nombre de plateformes, architectures, modèles avec un seul code. Sur les points positifs, je devais penser à chaque plate-forme individuelle: où elle commencerait là, et dans quelles conditions. Et c'est très mauvais, c'est très retenu.



Stabilité, compatibilité, développement du langage


Dmitry: Des abstractions à coût nul ont également été mentionnées, mais le problème est que cela a un prix énorme. Par exemple, dans .NET, il existe un concept de type énuméré et une interface IEnumerable. Et pour chaque type, par exemple, un tableau, vous pouvez prendre et parcourir un itérateur. Mais en C ++, une telle idée n'existe pas. En raison de l'abstraction à coût nul, pour contourner la collection, il y a un couple de début () et de fin (), il y a des règles pour leur travail, et tout cela est beaucoup plus compliqué (surtout pour ceux qui commencent à programmer). C'est un problème direct: comment contourner un tableau de A à Z.

Sergey: Si je comprends bien de quoi vous parlez ... Si vous avez juste besoin de faire le tour d'un conteneur du début à la fin, il vous suffit maintenant d'écrire, comme dans certains Python.

Dmitry: Tout cela est merveilleux. Mais vous, par exemple, n'utilisez pas le polymorphisme pour cela. On ne peut pas dire qu'ici j'ai une fonction qui reçoit une certaine valeur, qui est énumérée a priori. Vous ne pouvez pas dire que j'ai une valeur qui implémente l'interface, et cette interface a un itérateur, par exemple.

Sergey: Nous parlons de quel C ++? À propos de C ++ en général, C ++ du futur, C ++, qui sont maintenant acceptés comme standard?

Dmitry: Eh bien, si dans le futur, ce sera ...

Sergey: En C ++ 20, c'est déjà là. Vous pouvez déjà dire, vous pouvez même vous déclarer. Ce ne sont pas des interfaces, mais, comment le dire correctement ... En général, vous pouvez déclarer que votre type doit remplir telle ou telle condition. Par exemple, il a début et fin, qui renvoient un itérateur. Et un itérateur est un tel concept préparé dans la bibliothèque standard. Il dit ce que c'est, décrit. Les itérateurs sont également différents. En général, nous essayons, nous le rendons plus pratique pour les gens.

Dmitry: Il me semble que cela est né du fait que les gens viennent de réaliser qu'il est difficile de vivre sans les concepts d'itérable d'un objet. Parce qu'il n'est pas clair comment écrire des choses généralisées. Oui, l'abstraction à coût nul signifie que nous n'avons pas le coût de parcourir la v-table lors de la recherche ... Dans .NET, il n'y a qu'une méthode spécifique, par exemple. Et nous, pour le trouver, naturellement, devons dépenser des efforts, ce que les avantages refusent. Mais du point de vue de l'utilisabilité, le résultat final n'est pas si bon, je dirais.

Sergey: Naturellement, il doit y avoir un équilibre. Vous ne pouvez pas tout avoir à la fois.

Anatoly: Cela vous fait vous demander combien d'années se sont écoulées. Les langages alternatifs évoluent, et en eux de telles choses fondamentales apparaissent dès le début. Maintenant, ils rattrapent quelque chose de plus substantiel et intéressant. Et les avantages reposent pendant dix ans avec la même syntaxe incompréhensible, des abstractions obscures, des béquilles incompréhensibles et sous-développées. Vous pouvez mettre cela comme l'un des inconvénients.

Sergey: Eh bien, allez! Que signifie «peu développé»?

Vous avez mentionné un comité - C ++ a également un comité ISO qui le développe. Il y a des représentants, y compris Microsoft, qui se noient fortement du fait que "vous ne pouvez pas faire cela, car nous avons beaucoup d'héritage que nous devons soutenir." Seul C ++ est le langage déjà utilisé. Et, bien sûr, il marche très prudemment. L'une des tâches principales (qui avait déjà été déclarée par Straustrup lors de la création) est la compatibilité avec C. Mais maintenant C a même évolué assez loin, vous devez désigner avec quel C est compatible.

Et à mon avis, maintenant C ++ se développe à un rythme formidable. En ce qui concerne les concepts et ainsi de suite - en fait, tout naît, bien sûr, pas de l'itérabilité. En fait, le développement suit ce que Alexander Stepanov a également décrit - l'un des auteurs de ce que nous appelons maintenant la «programmation généralisée», la personne qui a réellement fait glisser des modèles, des génériques, etc. en C ++. Pour être honnête, je ne sais pas à quel point le comité s’inspire de ces idées, mais il me semble qu’il y a certainement une certaine intersection avec elles.

Anatoly: Il semble que toutes ces métaclasses, itérateurs sont vraiment une inspiration, ce qui était déjà il y a plusieurs décennies. Même si vous prenez la métaprogrammation, les modèles, les macros - toutes ces personnes ont longtemps expérimenté, moudre, et il existe des concepts beaucoup plus simples, évidents et compréhensibles. Dans d'autres langues, tout cela est fait un million de fois mieux et plus rapidement, avec la sécurité des types, la vérification du temps de compilation, etc.

Sergey: Attendez, vous parlez déjà de quelque chose que tout le monde n'est pas prêt à payer. Je ne veux pas que mon programme vérifie quelque chose lors de la compilation à mon insu. Tu comprends?

Anatoly: Je pense que tout cela avec des drapeaux peut être configuré. Vous définissez le niveau d'optimisation et il vous vérifie ou non. Ce n'est pas un problème.

Sergey: Souvent, vous devez tout contrôler avec vos mains. Sachez exactement ce qui se passe. Parce que les outils - enfin, ça.

Dmitry: Il ne s'agit même pas d'outils. Voici le fait que des langages comme D et Rust, disent, disent: eh bien, oui, il y a une telle chose que lorsque vous accédez à un élément de tableau, vous pouvez le vérifier, mais vous ne pouvez pas le vérifier. Et ils le donnent juste à l'utilisateur, c'est-à-dire que vous pouvez dire «mais désactivons les vérifications de tableau», «mais activons-le». Autrement dit, une sorte de contrôle à cet égard.

Sergey: Ce n'est pas clair quand vous avez dangereux et dangereux, comme dans Rust, je ne vois pas la différence avec C, par exemple, dans ce cas.

Anatoly: La différence est que vous pouvez écrire en toute sécurité et que vous pouvez écrire rapidement. Et en C, vous devez écrire dangereusement. Eh bien, oui, peut-être vite. La stabilité est parfois plus importante que la vitesse.

Dmitry: En fait, si nous commençons à creuser ce sujet avec de nouveaux langages, en C ++ il y a des choses qui sont généralement très difficiles à transmettre aux gens. Une question simple: quelle taille est int? Dans la plupart des langues, vous connaissez la réponse à cette question. Vous dites: int est 32 bits. Mais vous ne connaissez pas les pros. Vous connaissez la taille de votre ordinateur en particulier parce que vous vous en souvenez, mais à strictement parler, vous ne voulez même pas utiliser les types de base car ils ne sont pas déterministes. Et de telles choses me rendent furieux quand il existe un ensemble d'approches héritées comme l'int. Sera différent sur différentes plates-formes. Et maintenant, nous comprenons déjà que cela ne peut pas être fait. Pourquoi ne pas aller plus loin et résoudre ce problème?

Sergey: Eh bien, c'est décidé. Il existe des MST , les types requis avec une longueur fixe. Maintenant, le représentant de la Russie au comité fait glisser un entier de longueur variable (enfin, encore une fois, avec une abstraction à coût nul).

Anatoly: Est-ce que je me souviens bien qu'il existe même une taille non déterministe d'un pointeur vers une méthode? Autrement dit, sous différents compilateurs et différentes plates-formes, les pointeurs sont différents?

Sergey: Naturellement, c'est de l'architecture. Lorsque vous êtes proche du matériel, comment pouvez-vous garantir la taille du pointeur, si vous êtes sur 8 bits, puis sur 64 bits?

Anatoly: Et comment peut-on faire de l'arithmétique sur des pointeurs après ça? C'est fou.

Sergey: Je veux dire? Eh bien, soigneusement.

Anatoly: Je vois. L'approche est claire partout, contrôlant soigneusement tout avec des poignées.

Sergey: Eh bien, oui. Encore une fois, dans les normes C ++ modernes, des approches sont développées ... Si nous parlons du choix, alors dans les avantages modernes, en fait, il y a le choix d'utiliser le garbage collector. C'est juste que GC est construit là-bas sur des compteurs de référence.

En général, selon vos mots, chers collègues, je pense, désolé, que vous n'avez pas mis à jour vos connaissances sur les avantages modernes depuis longtemps.

Maintenant, des gens comme Straustrup, qui font partie du panthéon des dieux plus, viennent avec beaucoup d'appels pour comprendre comment enseigner le C ++ moderne. Le problème est ce que les gens pensent dans les catégories C ++ 2003 et enseignent dans les mêmes catégories. Et en relation avec cela, il y a de nouveaux projets et approches intéressants, il y a des cours modernes - disons que les gars de Yandex ont fait un merveilleux cours . Et maintenant, dans les avantages, il est considéré comme une mauvaise façon, par exemple, d'utiliser purement nouveau et supprimer.

Dmitry: Quant à votre commentaire sur la mise à jour des connaissances ... La nuance est que mon approche, par exemple, est d'utiliser le petit delta C ++, qui est garanti de fonctionner pour moi et avec lequel je suis "ami". Vous voyez, C ++ est étendu. Il y a une métaprogrammation de modèle, et tout irait bien, il y a beaucoup de magie, mais, malheureusement, cette magie est illisible. Il s'agit d'un code dans lequel un non-auteur ne peut pas le comprendre sans aucune connaissance particulière, dans un sens une boîte noire. Et il y a beaucoup de ces boîtes noires chez les pros, des zones d'obscurité qui ne peuvent pas être digérées ... J'aimerais, je ne sais pas, que votre option soit calculée de manière prévisible, bien et sans astuces.

L'exemple le plus simple parle de plages ( range-v3 et tout ce sujet). D'une part, tout cela est génial: il y a des choses qui sont en C # depuis plusieurs années, permettant, par exemple, de construire un calendrier par toutes les transformations de la collection standard. En revanche, la façon dont il est implémenté en C ++ est tout simplement désagréable par rapport à C #: il est lourd, non lisible.

Sergey: C'est de l'arôme. Moi, au contraire, j'aime ça. Si je comprends bien, vous en êtes au rapport Nibler et à sa présentation ...

Dmitry: Vous voyez, lorsque l'opérateur «ou» est utilisé pour filtrer une collection, j'ai immédiatement des questions à ce sujet. C # et Java ont tout fait via le point, selon les méthodes habituelles.

Sergey: Et il me semble que cela est inspiré par Bash. Autrement dit, ce n'est qu'un tuyau.

Dmitry: Eh bien, oui, cela explique probablement quelque chose dans cette approche.

Sergey: Cela explique beaucoup de choses! Parlons de PowerShell, puisque nous parlons de Bash. Qui a vu PowerShell?

Anatoly: j'écris en PowerShell, un super langage. Mais encore une fois, le tuyau doit être inséré là où il est en place, là où toute l'architecture en est imprégnée. Pas là où vous devez faire une seule action, et c'est ici une syntaxe idiomatiquement mauvaise.

Sergey: Dans la gamme pipe, c'est juste très ...

Dmitry: Dans la gamme, ils sont utilisés, à mon avis, pour la raison suivante ... Je dirai ceci: si en C ++ il y avait des méthodes d'extension ou des fonctions d'extension, vous les utiliseriez, bien sûr. Parce que la chose la plus naturelle si vous avez besoin de trier une collection est d'écrire «collection. Filter ()». Et non «collection» | view :: filter () ".

Anatoly: J'ai également eu l'impression que vous vous êtes fait tirer dans les jambes pendant 20 ans, vous avez frappé au visage, vous vous êtes cogné la tête contre le mur, puis vous avez finalement dit: «Eh bien, maintenant, nous avons tout fait à merveille dans le 20e standard, maintenant apprenons les pros ont raison. Oui, personne ne veut leur enseigner correctement! Autrement dit, c'est une douleur à long terme.

Sergey: Veuillez ne pas enseigner. Quel est le problème? Écrivez en C # - échangez dessus, écrivez intégré. Cela ne me dérange pas.

Anatoly: Eh bien, il y a des niches étroites où les pros sont toujours là.

Sergey: Embedded est une «niche étroite» ... En ce moment, en regardant autour de moi dans ma cuisine, je vois un tas d'ordinateurs.

Dmitry: Chaque fois que je prends l'avion, je pense: "Merde, j'espère que ces avantages ont bien tout écrit là-bas."

Sergey: Au fait, il y a principalement Ada, pour autant que je m'en souvienne.

Dmitry: Ada y domine, oui.

Anatoly: Au fait, j'ai récemment trouvé un excellent article où l'auteur dans différentes langues (environ 10) a écrit un pilote de bas niveau - un pilote réseau pour une carte Intel 10 gigabits. De C à Swift, JS, Python et naturellement C #. Si nous regardons ces graphiques, qu'il a obtenus, alors C # sur de gros lots (lorsque les coûts de lancement sont nivelés) va de pair avec C et Rust.



Autrement dit, si nous parlons de performances, il peut être faux de penser que C # est très inférieur quelque part. Il y a aussi un rapport génial de Federico Luis Scratched Metal , où il a montré comment il a optimisé le code C # pour les profileurs de processeur.

Sergey: Eh bien, ça recommence. Le fait est que lorsque vous commencez à optimiser Java, C #, il devient difficile de savoir pourquoi ne pas écrire sur les avantages. Parce que vous avez besoin de connaissances spécifiques. Et, comme il me semble, l'avantage de langages comme C # et Java est nivelé - pas un seuil d'entrée très élevé. Autant que je sache, juste ce dont Dmitry parlait: lisibilité du code, beaucoup d'apprentissage, difficile d'expliquer certains concepts, etc.

Anatoly: Je travaille 99% de mon temps à écrire en C # «normal» - sûr, stable et travaillant tout le temps. Et 1% du temps, je veux écrire une sorte de code rapide et de bas niveau. Et ce C # me le permet aussi. Mais mon outil principal est toujours stable, lisible, sans erreur ...

Dmitry: Tolya, permettez-moi de vous donner un exemple simple: la vectorisation. Avec la vectorisation en .NET, tout va très mal, malgré le fait que System.Numerics.Vectors se scie lentement. Et à quoi cela mène-t-il, pour ma part, par exemple? Au fait que si vous vous promenez sur le marché et achetez une bibliothèque mathématique pour .NET, elle est écrite sur les pros (avec un wrapper complet). Parce qu'en .NET, il n'y a pratiquement pas d'accès à l'accélération matérielle (AVX, etc.), il est maintenant à un stade embryonnaire.

Anatoly: Intrinsics est publié dans .NET Core 3 où vous pouvez accéder directement à AVX. Ils sont vraiment là à leurs balbutiements, mais il y a des choses basiques, et le reste est assez émouvant.

Dmitry: Vous comprenez, nous avons 2019 dans la cour. En tant qu'utilisateur de tout ce bien mathématique accéléré, je n'ai pas attendu cela. Et par conséquent, pour moi, si je veux considérer rapidement quelque chose, C # n'est plus un candidat. Parce que les bibliothèques C ++ existent déjà. Peut-être que du temps a déjà été perdu pour cela.

Anatoly: Il me semble que C # évolue dans le sens des avantages, il essaie de gagner leur marché. Mais les avantages ne bougent plus nulle part.

Sergey: D'où cela vient-il? Que signifie «les avantages ne vont nulle part»?

Anatoly: Quand ils me disent en 2019 qu'il y aura des itérateurs dans la norme, il y aura des progrès sur les lambdas, il me semble que ...

Sergey: Je ne sais pas pourquoi vous parlez d'itérateurs et de lambdas, je ne comprends pas de quelle façon était la pierre ...

Anatoly: Pas sur les itérateurs, je me trompe, je voulais dire les conteneurs énumérables dont nous avons discuté auparavant. Et en attendant, nous avons obtenu la correspondance de motifs.

Sergey: Tout dépend si c'est nécessaire ou non. Nous discutons de la correspondance de motifs. Mais jusqu'à présent, il n'y a aucun argument quant à savoir si cela est nécessaire chez les pros.

Dmitry: J'entends beaucoup de commentaires similaires des avantages, qui disent que "bien qu'il y ait déjà une présence évidente de telle ou telle approche dans d'autres langues, elle a déjà été élaborée, les gens l'adorent et y construisent des solutions, nous ne voulons toujours pas cela en plus, car ce ne sont pas des atouts idiomatiques. " Et il me semble que Java est tombé dans le même trou. Java a dit "pas de gars, nous n'aurons pas de délégués". Et en Java, il n'y a toujours pas de concept de délégués, mais en .NET tout cela fonctionne bien.

Sergey: Écoutez, les pros sont très simples. Encore une fois, je reviens au comité. Il y a une astuce - ce sont des gens qui développent des compilateurs. Et pour eux, les mots «abstraction à coût nul» sont exactement ce sur quoi ils devraient être guidés. Et le mot «héritage», malheureusement.

Dmitry: Eh bien, l'abstraction à coût nul est un assembleur. Si nous voulons une abstraction à coût nul en général, nous devons tout écrire dans l'assembleur.

Sergey: Il n'y a pas d'abstraction.

Dmitry: Assembler est une abstraction sur du code binaire. Ce n'est que la deuxième génération, pas la troisième.

Sergey: Donc, à propos de toutes sortes de «choses pratiques», il s'avère qu'il n'est pas clair comment les faire fonctionner rapidement.

Dmitry: Laissez-les travailler plus lentement. L'idée avec les itérateurs asynchrones, les coroutines, tout cela - dans .NET avec C #, le mot-clé yield ne sait plus combien de versions fonctionnent très bien. Oui, d'énormes machines d'état sont en train d'être construites dans les coulisses, juste de la magie. Mais async / wait crée également de la magie et des itérateurs. Mais tout le monde l'utilise, et c'est vraiment pratique.

Sergey: Coroutines ajouter aux avantages, bonjour.

Dmitry: Eh bien, oui, des progrès sont en cours. Mais les coroutines apparaissent maintenant, il n'y a pas 10 ans.

Sergey: Encore une fois. Les avantages sont plus anciens, et à mon avis, la vitesse de développement diminue avec l'accumulation de la base de code. De toute évidence, tout dépend de la volonté de maintenir le support Legacy. Pour les pros, c'est une position de principe. Autrement dit, le code que vous avez écrit dans les années 80 est maintenant compilé par un compilateur moderne.

Dmitry: Oui, mais vous compilez le code que vous avez écrit en C # 1.0 avec un compilateur moderne.

Sergey: Ce n'est pas vrai. Au tout début de la discussion, j'ai dit qu'une mise à jour était arrivée sur mes premières versions de .NET, et tout à coup tous les programmes ont cessé de fonctionner.

Dmitry: Peut-être que les API que vous avez utilisées viennent de changer. Ici, vous devez séparer la bibliothèque et le langage de programmation.

Sergey: Je n'avais rien, juste C #. J'étais jeune, c'était les premières années.

Dmitry: Je me souviens d'un seul changement de rupture, en C # 4 - un petit changement dans le comportement de foreach. Bien sûr, dans les versions 1.x, tout pourrait être plus turbulent, mais maintenant nous ne sommes définitivement pas dans la phase où quelqu'un casse soudainement quelque chose.

Anatoly: Eh bien, officiellement Microsoft adhère à la position qui surveille strictement la compatibilité descendante, ils testent de nouvelles versions sur un grand nombre de machines et de bases de code. Vous avez peut-être eu un bug ou quelque chose comme ça.

Dmitry: En général, .NET surveille également la compatibilité descendante, mais la vitesse de progression a bondi à la fois en C ++ et en Java.

Sergey: Il me semble que cela a joué un grand rôle, qu'au début tout cela était mené par une seule entreprise. Parce que C ++ était à l'origine au comité - et c'est de la politique, tout le monde essaie de pousser sa décision, et c'est comme une réunion du Sénat dans Star Wars.

Dmitry: Votre argument est donc que nous sommes tous les otages des comités qui ne sont pas motivés par l'innovation?

Sergey: Le problème est que vous ne choisissez pas une solution qui satisfera tout le monde. L'outil est si largement distribué qu'il est utilisé par de nombreuses entreprises. Vous vous souvenez des mêmes coroutines: pourquoi les ont-elles reçues tard? Parce que Microsoft, semble-t-il, ne pouvait pas être d'accord avec Google. Il y avait deux implémentations - je ne me souviens pas qui était derrière stackful et qui était derrière stackless, mais je ne pouvais pas être d'accord. Parce que les deux sociétés sont grandes, elles ont d'énormes bases de code qui contiennent déjà une solution et refusent de la réécrire.

Dmitry: Du point de vue du lecteur, on aura l'impression qu'ils lui ont craché dessus depuis un haut clocher, car il y a des intérêts corporatifs, ils sont engagés dans des entrelacs, et tout cela ne semble pas vous concerner - allez, laquais, «laissez-les manger du gâteau» .

Sergey: Bien au contraire. Le comité essaie de choisir pour qu'une personne ordinaire n'ait pas à souffrir. Et souvent c'est difficile.

Dmitry: Eh bien, je peux dire par moi-même que je ne souffrirai pas si le coût zéro va directement quelque part, mais il y aura une sorte de possibilité flexible de marcher le long de l'arbre binaire et d'itérer de différentes manières sans variables de temps. yield, - - — , , , , - .

: , , , , - .

: , Boost .

: , . Boost , , , … - . std::string, , . size(), length(), : , - ? - , , . , . , , , . , , , - .




: , , , . ?

: , , «», .

: .

: embedded-, include, ?

: . embedded -.

, , - ? , , . ?

: . 150 . - , . .

: , !

: , Steam, , , 64 . , 150 ?

: , , .

: , -. ? , , , — , zero cost abstractions . -?

: , , , , ?

: , . , , .

: , , , . — , . , . , , . , . -. C.

: . «». : , . , , , . . , .

: , . . , . proposal. .

: , proposal. , « »: , STL , . , - , .

: STL . STL . , , STL — , , .

: , — , ? , greenfield. brownfield development, . — , . — . ?

: , . , , . , . , , . G++ , Clang . .

: , , , . « , A, B». , .NET, . , , , , , ?

: , , . , C++ 2.0. ++C++. , C.

: , . , , . , , , , #include #import - — . , . , , , , .

. , . , , , C# C++, .

: , , 10 . , , , , , , . « », . , .

C# , C++. , C# . , , . , , , , JIT' — , , - ( int). , , , , .

: , , , C# — . , , C++ . , . ( , ) — cutting edge. , UI- C++, , . C# — . C++ , .

, . , , , C++ , , , . , .

, C# Microsoft. , .NET Foundation, , , Microsoft. , .



C++ Russia DotNext . : ?

Source: https://habr.com/ru/post/fr469467/


All Articles