IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
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

C++/CLI Discussion :

Microsoft évoque le futur de C++/CLI et de .NET Core


Sujet :

C++/CLI

  1. #1
    Expert éminent sénior

    Homme Profil pro
    Rédacteur technique
    Inscrit en
    mars 2017
    Messages
    1 177
    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 177
    Points : 78 723
    Points
    78 723
    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 : 30995
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 : 2910
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
    126
    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 : 126
    Points : 350
    Points
    350
    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 735
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : pdg

    Informations forums :
    Inscription : juin 2003
    Messages : 5 735
    Points : 10 558
    Points
    10 558
    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
    Membre du Club
    Femme Profil pro
    Étudiant
    Inscrit en
    novembre 2018
    Messages
    20
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Âge : 25
    Localisation : Autre

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

    Informations forums :
    Inscription : novembre 2018
    Messages : 20
    Points : 47
    Points
    47
    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 extrêmement actif
    Homme Profil pro
    Technicien de maintenance / Developpeur PHP
    Inscrit en
    mai 2015
    Messages
    361
    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 : 361
    Points : 1 331
    Points
    1 331
    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 165
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Isère (Rhône Alpes)

    Informations forums :
    Inscription : juin 2002
    Messages : 2 165
    Points : 4 605
    Points
    4 605
    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 extrêmement actif
    Profil pro
    Inscrit en
    juin 2010
    Messages
    764
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juin 2010
    Messages : 764
    Points : 898
    Points
    898
    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 extrêmement actif
    Profil pro
    Inscrit en
    juin 2010
    Messages
    764
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juin 2010
    Messages : 764
    Points : 898
    Points
    898
    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 extrêmement actif
    Profil pro
    Inscrit en
    juin 2010
    Messages
    764
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juin 2010
    Messages : 764
    Points : 898
    Points
    898
    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 735
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : pdg

    Informations forums :
    Inscription : juin 2003
    Messages : 5 735
    Points : 10 558
    Points
    10 558
    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 extrêmement actif
    Homme Profil pro
    Technicien de maintenance / Developpeur PHP
    Inscrit en
    mai 2015
    Messages
    361
    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 : 361
    Points : 1 331
    Points
    1 331
    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

  12. #12
    Membre extrêmement actif
    Profil pro
    Inscrit en
    juin 2010
    Messages
    764
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juin 2010
    Messages : 764
    Points : 898
    Points
    898
    Par défaut
    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 ^^

  13. #13
    Membre chevronné
    Avatar de poukill
    Profil pro
    Inscrit en
    février 2006
    Messages
    2 155
    Détails du profil
    Informations personnelles :
    Âge : 38
    Localisation : France

    Informations forums :
    Inscription : février 2006
    Messages : 2 155
    Points : 2 107
    Points
    2 107
    Par défaut
    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.

  14. #14
    Expert éminent sénior
    Avatar de Médinoc
    Homme Profil pro
    Développeur informatique
    Inscrit en
    septembre 2005
    Messages
    27 233
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : septembre 2005
    Messages : 27 233
    Points : 40 967
    Points
    40 967
    Par défaut
    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...
    SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.

    "Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
    Apparently everyone.
    -- Raymond Chen.
    Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.

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, 19h27
  2. Réponses: 1
    Dernier message: 19/01/2015, 15h23
  3. Réponses: 0
    Dernier message: 19/01/2011, 00h12

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