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

56PARTAGES

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 éclairé 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 éclairé 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 éclairé 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 redcurve
Membre éclairé https://www.developpez.com
Le 05/12/2019 à 17:52
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 ^^
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
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 confirmé 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