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...