Discussion :

[Christian Olivier]

Microsoft évoque le futur de C++/CLI avec .NET Core :
C++ sera disponible sur .NET Core 3.1 pour Windows

NET Core 3.0 est disponible depuis peu avec le support du développement d’applications Windows Desktop, C# 8.0, ARM64, la prise en charge native de JSON et de nombreuses autres améliorations.

Microsoft vient de confirmer que .NET Core, le « reboot » complet, entièrement open source (licence MIT) et multiplateforme de l’environnement .NET distribué via NuGet, va à l’avenir prendre en charge C++/CLI pour faciliter l’interopérabilité entre les bases de code C++ et les technologies .NET telles que WPF ou Windows Forms. Ce support ne sera pas immédiatement disponible sur .NET Core 3.0, mais il le sera à compter de .NET Core 3.1, qui devrait être livré avec Visual Studio 2019 16.4.

C++/CLI aura un support complet dans l'EDI à partir de .NET Core 3.1, incluant projets, IntelliSense et débogage en mode mixte (IJW) sous Windows. La firme de Redmond précise que la compilation avec « /clr:pure » et « /clr:safe » ne sera pas supportée sur .NET Core et que, pour le moment, elle n’a rien prévu concernant C++/CLI pour les plateformes macOS ou Linux.

Les premières préversions publiques pour C++/CLI sortiront bientôt. Comme Visual Studio 2019 16.3 avant lui, Visual Studio 2019 16.4 Preview 1 prendra en charge la création d’applications WPF qui ciblent .NET Core. Cela inclut de nouveaux templates, un concepteur XAML (similaire au concepteur XAML existant qui cible .NET Framework) et XAML Hot Reload. Il inclura en outre un compilateur mis à jour avec « /clr:netcore » si vous voulez l’essayer avec un support complet de l’EDI. Enfin, Microsoft a indiqué travailler sur l’intégration de MSBuild et IDE : « Dès qu'elle sera disponible, probablement avec 16.4 Preview 2 ou 3, nous publierons une mise à jour ».

Source : Microsoft

Et vous ?

Qu’en pensez-vous ?

Voir aussi

Microsoft confirme que la version générale de .NET Core 3.0 sera disponible durant la .NET Conf 2019 et en profite pour publier .NET Core 3.0 RC1
Bing.com tourne désormais sur .NET Core 2.1, un choix technique qui lui a permis de gagner en performance, mais aussi en agilité
Microsoft annonce la diffusion de mises à jour cumulatives pour .NET Framework à compter de la mise à jour Windows 10 octobre 2018
PowerShell Core 6.1 est disponible : support de .NET Core 2.1, compatibilité avec les modules Windows, cmdlets et rendu Markdown et plus

[ParseCoder]

We don’t currently have plans for C++/CLI for targeting macOS or Linux.

Donc ça viendra peut-être un jour. En tout cas pour une vrai portabilité de .NET Core ça serait mieux, parce que reverse P/Invoke c'est franchement immonde.

[Aurelien.Regat-Barrel]

Donc ça viendra peut-être un jour.

Je pense que la difficulté vient du fait que C++/CLI est une extension supportée par VC++ (Windows only), et que pour qua ça fonctionne sous Mac/Linux il faudrait recoder une deuxième implémentation sur clang... non seulement le front-end (parseur C++/CLI) mais aussi le backend. Sur ce dernier point je sais pas ce qu'il en est au niveau de LLVM : il y a un projet LLILC mais est-ce opérationnel ?

En tous cas ça va leur demander pas mal de taf.

[Kianii]

En tous cas ça va leur demander pas mal de taf.

C'est clairement pas une de leur priorité à mon avis.

[defZero]

Vrai question : Est-ce qu'il y a beaucoup de développeurs pro, ici, qui ont volontairement choisit .NET pour faire du multiplateforme ?

Personnellement j'ai un très gros reproche à faire à MS côté outilles de développement, c'est qu'ils ont choisit depuis le début de ne pas ce reposer sur des standard ISO/ANSI.
Avec MS on ne fait pas de C ou C++, on fait du VisualC++, ...etc, ça rajoute une couche pas forcement essentiel mais qui finit par limiter grandement la portabilité.
De plus, en admettant que MS veuille vraiment faire des efforts pour supporté le libre et faire du multiplateforme (comme il l'on tant clamé), je pense que le premier pas devrait être, pour eux, de passer à des langages standard ISO/ANSI.
Surtout au vue du niveau atteins par les standards actuels.

[gl]

Personnellement j'ai un très gros reproche à faire à MS côté outilles de développement, c'est qu'ils ont choisit depuis le début de ne pas ce reposer sur des standard ISO/ANSI.
Avec MS on ne fait pas de C ou C++, on fait du VisualC++, ...etc, ça rajoute une couche pas forcement essentiel mais qui finit par limiter grandement la portabilité.

Pourtant, Visual C++ supporte assez bien le C++ standard (il supporte même des choses qui ne le sont pas par GCC ou Clang).

Certes il propose un certain nombre d'extension standard, mais d'une part c'est le cas des alternatives (même si, pour une raison que j'ignore, un nombre important de personnes pensent que les extensions de GCC sont standard) et d'autre part rien n'oblige à les utiliser, il est tout à fait possible de rester dans du C++ standard. En outre, c'est lié, en partie, au fonctionnement même de la normalisation en C++ où il est généralement préférable d'avoir une implémentation comme preuve de concept avant de prétendre à intégrer qqch dans la norme (boost est un bon incubateur de nouveautés, mais les compilateurs, dont Visual, aussi).


Pour le C, j'ai moins suivi les évolutions de son support dans Visual. Mais à une époque ce n'était effectivement clairement pas un objectif et il fallait se contenter de C90 et ne pas espérer utiliser les nouveautés des standards suivants.

[redcurve]

Vrai question : Est-ce qu'il y a beaucoup de développeurs pro, ici, qui ont volontairement choisit .NET pour faire du multiplateforme ?

Personnellement j'ai un très gros reproche à faire à MS côté outilles de développement, c'est qu'ils ont choisit depuis le début de ne pas ce reposer sur des standard ISO/ANSI.
Avec MS on ne fait pas de C ou C++, on fait du VisualC++, ...etc, ça rajoute une couche pas forcement essentiel mais qui finit par limiter grandement la portabilité.
De plus, en admettant que MS veuille vraiment faire des efforts pour supporté le libre et faire du multiplateforme (comme il l'on tant clamé), je pense que le premier pas devrait être, pour eux, de passer à des langages standard ISO/ANSI.
Surtout au vue du niveau atteins par les standards actuels.

Comme si Clang et GCC respectaient le standard ISO ^^ elle est bien bonne celle la. Concernant C++/CLI il faut bien comprendre que ça demande un support niveau OS, Windows est actuellement le seul à savoir charger deux images simultanément comme étant un tout.

[redcurve]

Pourtant, Visual C++ supporte assez bien le C++ standard (il supporte même des choses qui ne le sont pas par GCC ou Clang).

Certes il propose un certain nombre d'extension standard, mais d'une part c'est le cas des alternatives (même si, pour une raison que j'ignore, un nombre important de personnes pensent que les extensions de GCC sont standard) et d'autre part rien n'oblige à les utiliser, il est tout à fait possible de rester dans du C++ standard. En outre, c'est lié, en partie, au fonctionnement même de la normalisation en C++ où il est généralement préférable d'avoir une implémentation comme preuve de concept avant de prétendre à intégrer qqch dans la norme (boost est un bon incubateur de nouveautés, mais les compilateurs, dont Visual, aussi).


Pour le C, j'ai moins suivi les évolutions de son support dans Visual. Mais à une époque ce n'était effectivement clairement pas un objectif et il fallait se contenter de C90 et ne pas espérer utiliser les nouveautés des standards suivants.

Je trouve ça toujours étrange les gens pensent que si c'est dans Clang ou GCC alors s'est standard mais pas pour VC++ parce que Microsoft est trop trop méchant ^^

[redcurve]

Vrai question : Est-ce qu'il y a beaucoup de développeurs pro, ici, qui ont volontairement choisit .NET pour faire du multiplateforme ?

Personnellement j'ai un très gros reproche à faire à MS côté outilles de développement, c'est qu'ils ont choisit depuis le début de ne pas ce reposer sur des standard ISO/ANSI.
Avec MS on ne fait pas de C ou C++, on fait du VisualC++, ...etc, ça rajoute une couche pas forcement essentiel mais qui finit par limiter grandement la portabilité.
De plus, en admettant que MS veuille vraiment faire des efforts pour supporté le libre et faire du multiplateforme (comme il l'on tant clamé), je pense que le premier pas devrait être, pour eux, de passer à des langages standard ISO/ANSI.
Surtout au vue du niveau atteins par les standards actuels.

Pour réponse à ta question actuellement nous faisons du multiplateforme avec .net core et ce depuis la v1, ça fonctionne extrêmement bien.

[Aurelien.Regat-Barrel]

Personnellement j'ai un très gros reproche à faire à MS côté outilles de développement, c'est qu'ils ont choisit depuis le début de ne pas ce reposer sur des standard ISO/ANSI.
Avec MS on ne fait pas de C ou C++, on fait du VisualC++, ...etc, ça rajoute une couche pas forcement essentiel mais qui finit par limiter grandement la portabilité.

Je crois qu'il y a un petit mélange des genres

Microsoft est un acteur très actif au sein du comité ISO pour la standardisation de C++, et a fait un travail très important de mise en conformité de leur compilateur qui porte ses fruits depuis plusieurs années maintenant. De même au niveau portabilité ils font beaucoup d'effort dans la bonne direction : support natif de cmake, développement de vcpkg, intégration de clang à VC++, support du sous système Linux dans Windows, support de Mac pour Visual Studio... Concernant .Net, au début le support dans C++ était sous forme d'extensions mais depuis longtemps ça a été changé pour un langage à part entière : C++/CLI standardisé chez l'Ecma (le même organisme qui standardise Javascript). Donc la séparation est assez propre avec le C++ ISO.

Pour en revenir à VC++ le flag /permissive- permet d'assurer une bonne portabilité du code. Il suffit de l'activer

[defZero]

Pour réponse à ta question actuellement nous faisons du multiplateforme avec .net core et ce depuis la v1, ça fonctionne extrêmement bien.

Merci de ta réponse, mais en effet .NET Core est multiplateforme depuis ça conception, donc je pense avoir mal formulé ma question d'origine.
Je reformule en : Est-ce qu'il y a beaucoup de développeurs pro, ici, qui ont volontairement choisit .NET Framework pour faire du multiplateforme ?

Concernant les standard C/C++, j'ai plusieurs remarque concernant les commentaire :
Concernant la conformité des compilateurs je n'est jamais écrit que GCC ou LLVM/Clang étaient plus respectueux que VisualC++, chacun à ses horreurs/features.
Je parlais des outils autour, est c'est là que je me rend compte que je me suis mal exprimé, ma faute .

- Pour ce qui est des outils :
@Aurelien.Regat-Barrel

... De même au niveau portabilité ils font beaucoup d'effort dans la bonne direction :
support natif de cmake,
développement de vcpkg,
intégration de clang à VC++,
support du sous système Linux dans Windows,
support de Mac pour Visual Studio...
Concernant .Net, au début le support dans C++ était sous forme d'extensions mais depuis longtemps ça a été changé pour un langage à part entière : C++/CLI standardisé chez l'Ecma (le même organisme qui standardise Javascript).
Donc la séparation est assez propre avec le C++ ISO.

Pour en revenir à VC++ le flag /permissive- permet d'assurer une bonne portabilité du code. Il suffit de l'activer

En ce qui concerne :
- Le "support natif" () de cmake, je présume que tu veux dire dans Visual Studio, parce-que le support de la génération de MSBuild/make/xcodeproj/...etc par CMake est principalement du fait de Kitware (qui développe CMake, indépendamment de MS) & de la communautée.

- VCPkg est heureusement du faite de MS puisqu'il n'était utilisable que sur Windows/Visual Studio à l’origine, donc niveau outillage standard et multiplateforme, bof.
Notez que je ne dénigre pas et qu'en effet désormais l'outille est utilisable sous Mac et Linux, après je ne suis pas convaincu que beaucoup de dev Linux ou Mac distribue des packages c++ sous ce format, dotant qu'en sous main il utilise CMake pour versionner sous ces plateformes.
P.S. : Vivement C++2x est la mise en place des modules, peut-être qu'ils comprendrons le versioning dedans.

- Clang dans VC++ ? Tu est bien sur de toi, ce ne serait pas plutôt dans Visual Studio IDE ?

- Le support WSL (Windows Subsystem for Linux) dans Windows était juste une obligation pour MS, pas vraiment un choix altruiste, étant donné que la quasi totalité des VM/Container tournant sur Azure (Cloud public de MS) fait tourner du Linux/BSD.
Ça devenez compliquer à justifier pour MS, d'un pont de vue des développeurs.

- Le support de Visual Studio sur Mac, c'est la même chose.
Comment expliquer aux développeurs (gros utilisateurs de Mac au demeurant) que pour développer sur XCode pour OS X ou iOS, ils doivent ouvrir une session OS X et qu'ils doivent coder sur une VM/autre machine pour dev sur Visual Studio pour du Windows.

- C++/CLI est normalisé cher ECMA ? OK, donc comme C# 4 ou 5, je sais plus, en tout cas une ancienne version plus mis à jours.
Toujours est il que le CLI (Common Language Interface) n'existe que sous Windows qui est le seule à le développer et pour cause il s’agit de C++ Managed propre a Windows/.NET .
Donc le coté c'est standard donc multiplateforme, mouaif.
MS est le premier à faire standardiser (en générale chez ECMA, pas chez ISO) ses technos pour tenter de répandre leur usage, mais la certification est rarement MàJ après plusieurs années ou de façon très sporadique.

Vous commencez à voir avec ces exemples ce que j'essayais d'expliquer, maladroitement, dans mon 1er poste.
Pourquoi MS a choisit sont propre outillage pour faire exactement ce que des standard de fait permettaient déjà sous toutes les autres plateformes ?
Leur propre format binaire PE (générer par leur seul compilateur, au lieu de COFF/ELF/MachO), leur propre Build System, leurs propre API incompatible POSIX ...etc
Ce sont leurs choix, mais ne venez pas dire qu'ils ont fait ça pour le bien de tout le monde et pour améliorer la compatibilité.
Si MS voulait viser la compatibilité maximum, ils leur suffirait d'offrir une API POSIX et une chaine de compilation compatible.
Là, en l'occurrence, il ne font que répondre aux demandent de leurs plus gros clients Azure qui ne veulent pas passer à Windows Server, alors le "MS fait des effort" n'as pas de sens, puisque ce sont les clients de MS qui paye ces outils à leur propre demande.

P.S. : Je note tout de même, qu'à ma connaissance, les personne qui travail avec VisualC++, ne font pas d' ISO/C++ mais bien du MS/VisualC++.
C'est normale, la plateforme Windows et/ou .NET les y contrains de toute façon, c'est ce que je regrette de la part de MS.
P.S. bis : Apple fait les même choses dans ce domaine.
C'est donc chacun sa gueule

[redcurve]

Je reformule en : Est-ce qu'il y a beaucoup de développeurs pro, ici, qui ont volontairement choisit .NET Framework pour faire du multiplateforme ?

=> Non .net framework est un framework comme son nom l'indique et il n'est pas multiplate-forme car il embarque du code spécifique à Windows genre Registry. .Net Core n'embarque pas ce type de code, il existe des paquets nuget pour faire ça mais du tout ça rend l'application non portable logique le code en question étant lié spécifiquement aux Apis d'un système particulier.

Vous mélangez plusieurs choses d'une toute l'infrastructure de COM3 (Aka .net) est standardisé, secondement la standardisation est bien actualisée régulièrement.
Concernant la CLI elle n'a rien de spécifique à Windows vous confondez l'interface et son implémentation. La JVM sous linux contient des tas de trucs spécifique à ce système. Il existe depuis toujours une implémentation complète de COM3 (Aka .net) sous linux et osx qui est Mono, qui est utilisé par Xamarin par exemple ou par Banshee.

- Le support de Visual Studio sur Mac, c'est la même chose. Alors la dernière maj de Visual studio for Mac partage le même code base que la version Windows, (Et macos est une horreur pour travailler la moindre chose un peu touchy devient un enfer car on est en taule sur sa propre machine).

- C++/CLI est normalisé cher ECMA ? Il ne peut pas l'être pour le moment seul Windows permet d'avoir deux images dans le même executable fonctionnant comme un tout. Il y'a de l'infra à faire sur Linux et Macos pour ce genre de chose. Sauf si MS trouve un moyen de gérer ça au niveau CLR sur ces os.

Vous commencez à voir avec ces exemples ce que j'essayais d'expliquer, maladroitement, dans mon 1er poste.
Pourquoi MS a choisit sont propre outillage pour faire exactement ce que des standard de fait permettaient déjà sous toutes les autres plateformes ?
Leur propre format binaire PE (générer par leur seul compilateur, au lieu de COFF/ELF/MachO), leur propre Build System, leurs propre API incompatible POSIX ...etc
Ce sont leurs choix, mais ne venez pas dire qu'ils ont fait ça pour le bien de tout le monde et pour améliorer la compatibilité.
Si MS voulait viser la compatibilité maximum, ils leur suffirait d'offrir une API POSIX et une chaine de compilation compatible.

La vraie question est pourquoi on devrait ce farcir Posix ? Ce truc est une horreur absolu, secondement MachO est une passoire le plus fun est de mettre des scripts pythons après EOF et de mettre un JUMP pour lancer directement dans les exécutables comment dire ... laissez MachO crever.

En plus vous confondez PE et COFF alors que PE utilise COFF mais pour ça vous avoir lu la spécification et pas juste débiter des termes technique sans en comprendre le sens. Le format PE a été créé car Windows NT fonctionne sur autre chose que Intel x86 à l'origine COFF a été spécifiquement conçu pour Unix System V et pour éviter d'avoir à gérer plusieurs formats d'images pour chaque architecture Microsoft a repris COFF et a modifié ce qui était spécifique lié à x86/SystemV (en ajoutant un niveau d'abstraction) pour en faire un format Portable d'ou le Portable Executable c-a-d portable sur différentes architectures ce qui n'était pas le cas de COFF. Ceci explique pourquoi les exécutables UEFI utilisent aussi le format PE et non des monstruosités comme COFF/ELF/MACHO. Par ailleurs, Windows 95,98,ME utilisaient le format NE de mémoire.

Pourquoi leur propre outillage et pourquoi pas en fait ? Je veux dire aux dernières nouvelles on a encore le droit de proposer des choses différentes, et de voir les problèmes sont d'autres angles. Sauf si s'est interdit pour le bien de tous bien évidement dans votre délire Stalinien (le délire de libriste de base, vous être libre de faire ce que JE VEUX).

Je note tout de même, qu'à ma connaissance, les personne qui travail avec VisualC++, ne font pas d' ISO/C++ mais bien du MS/VisualC++.

De la même façon que les gens qui font du GCC ne font pas de l'iso/c++ ... pareil pour CLANG le problème vient du langage C++ lui même. Le temps inouïe nécessaire pour valider la moindre fonctionnalité fait que les concepteurs de compilateurs compensent en créant leur propre extensions, sinon y'a la solution de foutre du boost partout en attendant éventuellement que dans 100 ans C++ permette de faire nativement des trucs basique. Heureusement de Microsoft propose des choses différentes on a enfin des lambdas en C++, merci les specs de .NET .

Ce que je trouve drôle pour ne pas parfaitement hilarant est que quand MS utilise des standards tout le monde s'en plaint exemple simple le standard HID, ou encore CGI qui fait que tout le monde se plaignait que Php marchiant mal sous IIS alors que le problème vient de Php lui même qui s'est éloigné du standard. Ce qui veut donc dire qu'apache n'est pas standard ^^

[poukill]

Dans mon équipe de développeur temps-réel, on utilise le C++ depuis 20 ans, en suivant les normes petit à petit. En ce moment, C++11 est celle en vigueur chez nous. Je pense que C++17 rentrera d'ici la fin de l'année.
C'est clair qu'on choisira pas du .NET pour du cross-platform, trop de facteurs qui font que ça peut tourner vinaigre.
Le développement sous Visual Studio de MS est quand même sacrément confortable, que ce soit pour écrire du code ou bien débugger. Le support de CMake et de git en natif est un plus. Franchement rien à reprocher à MS pour ça. On utilise une base CMake pour Linux + Windows.

[Médinoc]

Récemment à mon boulot, on a dû étudier la faisabilité d'un passage de .NET Framework 4.8 à .NET 5.0 (qui est un .NET Core).
L'abandon de WCF comme une vieille chaussette après l'avoir recommandé sur tous les toits pendant des années (et aussi, la disparition de System.Web) sont ce qui fait le plus mal. Si on veut pouvoir passer à Core, il nous faut réécrire entièrement toutes nos communications entre services!

Et en faveur de quoi? Des alternatives qui ne supportent pas les sessions (OpenAPI et gRPC), dont une qui force à utiliser ses types de données persos (la seconde)*!.
Si Microsoft avait suivi la philosophie de WCF au lieu de s'en débarrasser, gRPC aurait été ajouté comme Binding, vu que WCF était extensible...