Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #1
    Chroniqueur Actualités

    Homme Profil pro
    Rédacteur technique
    Inscrit en
    mars 2017
    Messages
    1 019
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Madagascar

    Informations professionnelles :
    Activité : Rédacteur technique
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : mars 2017
    Messages : 1 019
    Points : 27 989
    Points
    27 989
    Par défaut Microsoft évoque le futur de C++/CLI et de .NET Core
    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.

    Nom : core.PNG
Affichages : 18023
Taille : 9,9 Ko

    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.

    Nom : images.jpg
Affichages : 1506
Taille : 5,6 Ko

    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
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Membre averti
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    mars 2011
    Messages
    100
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : mars 2011
    Messages : 100
    Points : 370
    Points
    370
    Par défaut
    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.

  3. #3
    Expert éminent sénior

    Homme Profil pro
    pdg
    Inscrit en
    juin 2003
    Messages
    5 687
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : pdg

    Informations forums :
    Inscription : juin 2003
    Messages : 5 687
    Points : 10 255
    Points
    10 255
    Billets dans le blog
    3
    Par défaut
    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.

  4. #4
    Nouveau membre du Club
    Femme Profil pro
    Étudiant
    Inscrit en
    novembre 2018
    Messages
    13
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Âge : 23
    Localisation : Autre

    Informations professionnelles :
    Activité : Étudiant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : novembre 2018
    Messages : 13
    Points : 27
    Points
    27
    Par défaut
    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.

  5. #5
    Membre actif
    Homme Profil pro
    Technicien de maintenance / Developpeur PHP
    Inscrit en
    mai 2015
    Messages
    79
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Technicien de maintenance / Developpeur PHP
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : mai 2015
    Messages : 79
    Points : 220
    Points
    220
    Par défaut
    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.

  6. #6
    gl
    gl est déconnecté
    Rédacteur

    Homme Profil pro
    Inscrit en
    juin 2002
    Messages
    2 162
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Isère (Rhône Alpes)

    Informations forums :
    Inscription : juin 2002
    Messages : 2 162
    Points : 4 467
    Points
    4 467
    Par défaut
    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.

  7. #7
    Membre confirmé
    Inscrit en
    juin 2010
    Messages
    610
    Détails du profil
    Informations forums :
    Inscription : juin 2010
    Messages : 610
    Points : 622
    Points
    622
    Par défaut
    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.

  8. #8
    Membre confirmé
    Inscrit en
    juin 2010
    Messages
    610
    Détails du profil
    Informations forums :
    Inscription : juin 2010
    Messages : 610
    Points : 622
    Points
    622
    Par défaut
    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 ^^

  9. #9
    Membre confirmé
    Inscrit en
    juin 2010
    Messages
    610
    Détails du profil
    Informations forums :
    Inscription : juin 2010
    Messages : 610
    Points : 622
    Points
    622
    Par défaut
    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.

  10. #10
    Expert éminent sénior

    Homme Profil pro
    pdg
    Inscrit en
    juin 2003
    Messages
    5 687
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : pdg

    Informations forums :
    Inscription : juin 2003
    Messages : 5 687
    Points : 10 255
    Points
    10 255
    Billets dans le blog
    3
    Par défaut
    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

  11. #11
    Membre actif
    Homme Profil pro
    Technicien de maintenance / Developpeur PHP
    Inscrit en
    mai 2015
    Messages
    79
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Technicien de maintenance / Developpeur PHP
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : mai 2015
    Messages : 79
    Points : 220
    Points
    220
    Par défaut
    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

Discussions similaires

  1. Microsoft intègre la compilation native PGO dans sa plateforme .Net Core 2.0
    Par Olivier Famien dans le forum Général Dotnet
    Réponses: 0
    Dernier message: 22/07/2017, 18h27
  2. Réponses: 1
    Dernier message: 19/01/2015, 14h23
  3. Réponses: 0
    Dernier message: 18/01/2011, 23h12

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo