Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

Le , par Christian Olivier

10PARTAGES

8  1 
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

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de Aurelien.Regat-Barrel
Expert éminent sénior https://www.developpez.com
Le 04/10/2019 à 16:18
Citation Envoyé par ParseCoder Voir le message
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.
2  0 
Avatar de redcurve
Membre confirmé https://www.developpez.com
Le 05/10/2019 à 11:35
Citation Envoyé par gl Voir le message
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 ^^
2  0 
Avatar de redcurve
Membre confirmé https://www.developpez.com
Le 05/10/2019 à 11:37
Citation Envoyé par defZero Voir le message
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.
2  0 
Avatar de gl
Rédacteur https://www.developpez.com
Le 05/10/2019 à 0:54
Citation Envoyé par defZero Voir le message
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.
1  0 
Avatar de redcurve
Membre confirmé https://www.developpez.com
Le 05/10/2019 à 11:33
Citation Envoyé par defZero Voir le message
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.
1  0 
Avatar de Aurelien.Regat-Barrel
Expert éminent sénior https://www.developpez.com
Le 07/10/2019 à 10:36
Citation Envoyé par defZero Voir le message
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
1  0 
Avatar de defZero
Membre actif https://www.developpez.com
Le 10/10/2019 à 23:00
Citation Envoyé par redcurve Voir le message
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
1  0 
Avatar de ParseCoder
Membre averti https://www.developpez.com
Le 04/10/2019 à 15:39
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.
0  0 
Avatar de Kianii
Nouveau membre du Club https://www.developpez.com
Le 04/10/2019 à 17:12
Citation Envoyé par Aurelien.Regat-Barrel Voir le message
En tous cas ça va leur demander pas mal de taf.
C'est clairement pas une de leur priorité à mon avis.
0  0 
Avatar de defZero
Membre actif https://www.developpez.com
Le 04/10/2019 à 22:24
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.
1  1