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 !

Visual Studio 2015 Update 1 RC est disponible
Avec des améliorations du compilateur

Le , par Stéphane le calme

41PARTAGES

5  0 
Microsoft annonce la disponibilité de Visual Studio Update 1 RC.

Améliorations du compilateur : le compilateur C ++ et la bibliothèque standard ont été mis à jour avec un support plus prononcé des fonctionnalités C ++ 11 et C ++ 14. Il intègre également un support préliminaire à certaines fonctionnalités qui devraient être embarquées dans C ++ 17. Cependant, Microsoft précise que le changement le plus notable que vous remarquerez sur le sujet est l'amélioration de la qualité de constexpr ainsi que le support de l’expression partielle SFINAE. L’acronyme SFiNAE (Substitution Failure Is Not An Error) est utilisé en C++ dans un contexte de surcharge de modèles de fonction. Lorsque le compilateur évalue chacun des templates de fonctions surchargés, il ne va pas générer une erreur si utiliser un modèle de paramètre sur une fonction candidat potentiel pouvait générer une erreur. En voici un exemple :

Code : Sélectionner tout
1
2
3
4
5
6
7
8
9
10
11
12
template<typename T>
class IsClassT {
  private:
    typedef char One;
    typedef struct { char a[2]; } Two;
    template<typename C> static One test(int C::*);
    // Sera choisi si T est tout sauf une classe.
    template<typename C> static Two test(...);
  public:
    enum { Yes = sizeof(IsClassT<T>::template test<T>(0)) == 1 };
    enum { No = !Yes };
};
Si T est une classe, alors IsClassT <T> :: Yes sera vrai parce que la fonction première test () sera choisie par le compilateur.

Cross-Platform C ++ mobile : les développeurs Android vont maintenant être en mesure de déboguer le code Java tandis qu’ils conçoivent leurs applications Android. Ils peuvent également profiter d'une bonne expérience de l'édition de langage Java via un téléchargement depuis la vitrine VSGallery. Le support apporté aux architectures x64 et arm64 a également été introduit pour les développements sur les plateformes iOS et Android. Les développeurs Android bénéficient désormais de la compilation parallèle ainsi que de la possibilité d'importer leurs projets Eclipse facilement dans Visual Studio.

Code Authoring : un certain nombre de nouvelles fonctionnalités expérimentales ont été ajoutées pour améliorer l'expérience de la création de code, comme un nouveau moteur de base de données (pour améliorer la vitesse d’exécution de certaines instructions comme Go To Definition ou Find All References), une fonction d’extraction, une meilleure utilisation du GPU. L’historique Thread qui a été ajouté récemment vous permet d'enquêter sur les flux CPU et GPU par tâches.

Diagnostics de la mémoire : il est possible de prendre des captures d’écran pendant le débogage de votre application à l'aide de l'outil Utilisation de la Mémoire à l'intérieur qui se trouve dans la fenêtre Outils de Diagnostic (Ctrl + Alt + F2). Les vues en pile vous permettent de voir l'arbre d'appel où sera explicité l’appelant et l'appelé avec la possibilité de faire des recherches dans ces piles.

Microsoft précise que l'émulateur Visual Studio pour Android et Microsoft Test Manager ne sera pas en mesure d'acquérir des licences en ligne quand ils sont utilisés avec Visual Studio Update 1 2 015 RC. Par conséquent, l’entreprise recommande d'éviter l'installation de mise à jour 1 RC sur un ordinateur où l'un de ces produits est nécessaire.

Source : blog MSDN, blog Olivier Langlois

Et vous ?

Quel est l'ajout ou l'amélioration qui vous intéresse le plus ?

Voir Aussi :

Microsoft active par défaut Edit and Continue dans la RTM de Visual Studio 2015 pour le développement de vos applications C++

L'équipe Visual C++ donne des détails sur certaines étapes de la refonte du compilateur C/C++ et parle également de ses perspectives d'avenir

Que pensez-vous de Visual Studio 2015 ? Avez-vous adopté la dernière version de l'EDI de Microsoft ?

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

Avatar de JolyLoic
Rédacteur/Modérateur https://www.developpez.com
Le 06/04/2016 à 20:40
Le problèmes des PCH, c'est qu'ils ne sont pas composables. Tu ne peux pas dire je prend le PCH lié à la lib A, et celui de la lib B, et je les fait tourner ensemble. Tu es obligé de faire un PCH spécifique qui ne marche que quand tu utilises A puis B.

Donc les PCH sont spécifiques à chaque projet, et doivent être générés dans chaque cas. Et se pose la question de savoir ce qu'on met dedans, et ce qu'on garde sous forme de #include en dehors du PCH. Si on n'en met pas assez, on est trop lent, si on en met trop, à chaque compilation incrémentale, on va devoir re-générer l'ensemble du PCH et perdre du temps.

On peut voir les modules comme des PCH mais qui sont composables, et où tu aurais un PCH par header (ou groupe de headers étroitement liés). Tu as généré le code précompilé pour A, celui pour B, tu peux les utiliser séparément ou ensemble, dans l'ordre que tu veux. Du coup, quand tu livres ta bibliothèque, tu livres le précompilé avec qui peut directement être réutilisé. Jamais tu n'auras besoin de le code client de parser les headers de cette bibliothèque. Pourquoi peut-on faire ça avec les modules, mais pas avec les PCH ? Voir ma réponse à la seconde question.

isolation from macros = en quoi les macros posent pb ?
Ce sont elles qui empêchent toute composabilité. Quand tu inclues un .h dans ton code, la manière de l'interpréter dépend de l'ensemble des macros définies au moment où tu l'inclues. Qui n'a jamais eu sous windows un problème pour inclure un header d'une bibliothèque third party après un #include <windows.h> parce ce dernier définit une macro min... L'idée de base est qu'un module ne dépende pas des macros définies avant qu'il soit importé, et qu'en retour, il ne pollue pas l'environnement avec ses propres macros. Et là, la modularité commence à apparaître.
Je dis "l'idée de base" parce que certains aimeraient bien pouvoir dire que sélectivement, telle ou telle macro définie dans un module pourrait être visible de l'extérieur. C'est en discussion.

il y a plus de problemes non resolus que de REELS problemes resolus (pas de gestion de namespace donc conflits potentiels, pas de versioning, description des fonctions non lisibles dans les fichiers binaires de 'package').
Je ne pense pas qu'il s'agisse forcément de réels problèmes, mais d'une simple description de ce que les modules ne sont pas, pour éviter les confusions :

Namespaces : Certains langages (Java par exemple) lient structure physique du code (modules, fichiers source) et structure logique (namespaces, classes). D'autres ne le font pas (C# par exemple). La proposition de module pour le C++ choisi de ne pas le faire. Ce n'est en rien une limitation, mais un choix qui fait sens en C++ (sinon, comment ajouter une spécialisation de std::hash ?).
Versionning : On a déjà tous des outils pour gérer les versions, tu as parlé de nuget par exemple, je ne vois pas trop quel rôle les modules pourraient jouer là dedans, à part éventuellement en terme de réflexion, qui peut toujours s'ajouter.
Binary distribution : C'est un problème potentiel. Mais d'un autre côté, les autres langages ont bien réussi à résoudre ce problème. Quand on distribue une assembly .NET, c'est bien un binaire qu'on distribue, et ça fait déjà 15 ans que ça dure sans problèmes. Ce qui va être plus dur est d'avoir un format compatible entre différents vendeurs (Microsoft a proposé d'open-sourcer le sien, Clang a dit qu'il était hors de question qu'ils l'utilisent). Mais la situation ne sera pas pire que ce qu'elle est aujourd'hui : On risque de devoir quand même compiler une bibliothèque pour le compilo qu'on utilise, comme on le fait aujourd'hui. C'est juste qu'on risque aussi de ne pas avoir besoin de le faire, si le mainteneur de la bibliothèque nous fourni un module compilé pour notre compilateur, chose qui était très difficile avant, à cause des multiplicités de gestions de macros. Donc la situation ne devient pas parfaite, mais elle s'améliore quand même.

Et sinon, pour avoir expliqué à pas mal de débutants, oui, les #include, c'est compliqué. Et parfois même des professionnels aguerris galèrent pendant des heures pour faire un #include dans certains contextes...
3  0 
Avatar de The_badger_man
Rédacteur https://www.developpez.com
Le 02/12/2015 à 11:50
Citation Envoyé par MikeRowSoft Voir le message
Tiens tiens Update 1!?
Microsoft aurait-il réservé le service pack pour du support technique terminé?
Les services pack (correction de bugs) n'existent plus depuis Visual Studio 2010.

Depuis Visual Studio 2012, il s'agit de mises à jour fonctionnelles.
2  0 
Avatar de Zilpix
Membre habitué https://www.developpez.com
Le 02/12/2015 à 10:01
Good news !!

Même si ça n'est pas le plus important, j'ai l'impression que la nouvelle icône a été modifiée avec Paint en 2 minutes, vous ne trouvez pas ?
1  0 
Avatar de Aurelien.Regat-Barrel
Expert éminent sénior https://www.developpez.com
Le 06/04/2016 à 10:29
Bonjour,

Une autre nouveauté importante de l'Update 2 pour C++ concerne les modules (création de "packages" en C++ au lieu des classiques fichiers headers). Des améliorations importantes ont été faites pour les rendre utilisables (c'est ce qu'ils disent, moi j'ai pas pu tester encore!).

Citation Envoyé par Olivier Famien Voir le message
Nous rappelons que les coroutines sont similaires aux routines, mais se démarquent de ces dernières en ce sens qu’elles offrent la possibilité de suspendre et reprendre explicitement leur exécution en utilisant des opérations supplémentaires, alors que les routines s’achèvent généralement lorsque les processus parents prennent fin.
Je n'ai pas trouvé ce passage très clair, aussi je partage ma propre explication Une coroutine c'est une fonction qui peut être interrompue dans son exécution qu'elle reprendra là où elle l'avait laissé à son prochain appel. Une fonction classique termine son exécution lors d'un appel à "return". Dans le cas d'une coroutine, si elle return, alors oui c'est fini. Mais elle peut aussi rendre la main à l'appelant en plein milieu de son exécution, pour reprendre ensuite (lors de son prochain appel) là où elle s'était arrêté (au lieu de tout recommencer au début). La coroutine est en quelque sorte au thread ce que le thread est au processus.

L'intérêt concerne la programmation asynchrone. Au lieu de découper la logique du code en deux parties (par exemple : lecture des données sur une socket, puis traitement des données reçues), on simule une exécution synchrone classique. Sauf que au lieu de rester bloqué sur un opération d'E/S (lecture de la socket), on rend la main à l'appelant qui peut faire autre chose pendant ce temps. Ca évite de créer des threads à tout bout de champ (l'idée est d'avoir des milliers de coroutines) ou d'avoir un code asynchrone difficile à lire (éclaté en plein de callbacks).
1  0 
Avatar de Jonyjack
Membre averti https://www.developpez.com
Le 06/04/2016 à 14:25
Citation Envoyé par Aurelien.Regat-Barrel Voir le message
Je n'ai pas trouvé ce passage très clair, aussi je partage ma propre explication Une coroutine c'est une fonction qui peut être interrompue dans son exécution qu'elle reprendra là où elle l'avait laissé à son prochain appel. Une fonction classique termine son exécution lors d'un appel à "return". Dans le cas d'une coroutine, si elle return, alors oui c'est fini. Mais elle peut aussi rendre la main à l'appelant en plein milieu de son exécution, pour reprendre ensuite (lors de son prochain appel) là où elle s'était arrêté (au lieu de tout recommencer au début). La coroutine est en quelque sorte au thread ce que le thread est au processus.
Merci c'est plus clair en effet ! Ca me fait penser au "yield" de C#
1  0 
Avatar de Aurelien.Regat-Barrel
Expert éminent sénior https://www.developpez.com
Le 06/04/2016 à 14:46
Citation Envoyé par Jonyjack Voir le message
Merci c'est plus clair en effet ! Ca me fait penser au "yield" de C#
Et pour cause, c'est exactement ça ! Sauf qu'en C++ les mots-clés retenus sont finalement co_await, co_return et co_yield (afin d'éviter d'entrer en collision avec ces symboles dans du code existant).
1  0 
Avatar de kilroyFR
Membre éclairé https://www.developpez.com
Le 06/04/2016 à 15:18
J'avoue que concernant les MODULES en C++ je n'ai pas bien compris la reelle utilité par rapport a un .h/.lib habituel...

faire
IMPORT myModule;
ou
#include <myModule.h>

Je suis preneur de toute explication qui me donnerait une vision sur le reel benefice de ce qui s'apparente plus a une nouvelle syntaxe (inutile ?) qu'autre chose.
1  0 
Avatar de Aurelien.Regat-Barrel
Expert éminent sénior https://www.developpez.com
Le 06/04/2016 à 16:58
Citation Envoyé par kilroyFR Voir le message
J'avoue que concernant les MODULES en C++ je n'ai pas bien compris la reelle utilité par rapport a un .h/.lib habituel...

faire
IMPORT myModule;
ou
#include <myModule.h>

Je suis preneur de toute explication qui me donnerait une vision sur le reel benefice de ce qui s'apparente plus a une nouvelle syntaxe (inutile ?) qu'autre chose.
Le premier intérêt est au niveau du temps de compilation : ton header est parsé une seule fois lorsque tu build ton projet au lieu de l'être à chaque inclusion (utilisation d'un fichier pré-parsé binaire à la place, un peu comme un PCH).

Il y a d'autres intérêts, présentés dans le papier de Microsoft (lire l'intro):
  1. componentization;
  2. isolation from macros;
  3. scalable build;
  4. support for modern semantics-aware developer tools.
  5. Furthermore, the proposal reduces opportunities for violations of the One Definition Rule (ODR), and increases practical type-safe linking. An implementation of these suggestions is ongoing in the Microsoft C++ compiler.

et aussi du côté de clang:
http://clang.llvm.org/docs/Modules.h...-current-model

Une autre façon d'aborder le sujet est qu'un langage moderne ne peut pas reposer sur un mécanisme aussi primaire que l'inclusion textuelle (qui déstabilise beaucoup de débutants).
1  0 
Avatar de kilroyFR
Membre éclairé https://www.developpez.com
Le 06/04/2016 à 19:04
ouep je suis pas vraiment convaincu - c'est compliqué pour un debutant de comprendre les inclusions de .h ?
Ca me fait penser a ceux qui ne veulent pas faire du SQL parce que c'est jugé trop compliqué mais par contre utilisent des BDD noSql type MongoDb avec des syntaxes barbares completement illisibles, non normées etc.

Pour l'optimisation des temps de compil il y a les entetes pre-compilées. Visiblement quelque chose qui va en plus encore bouger

1. componentization = comme une librairie donc ? (librairie ca fait pas moderne certainement)
2. isolation from macros = en quoi les macros posent pb en debut de fichier - ca permet d'eviter de traiter N fois le meme fichier d'entete au contraire !
3. scalable build => entetes precompilées ca sert a ca pourtant
4. support for modern semantics-aware developer tools => là on est plutot dans des "concepts" qui me paraissent tres abstraits
Furthermore, the proposal reduces opportunities for violations of the One Definition Rule (ODR), and increases practical type-safe linking => idem 4

"qu'un langage moderne ne peut pas reposer sur un mécanisme aussi primaire que l'inclusion textuelle (qui déstabilise beaucoup de débutants)."
=> alors pour ne pas comprendre les principes d'inclusion textuelles on invente autre chose encore plus illisible.
J'ai l'impression qu'il aurait ete utile de rapprocher le C++ des autres langages "modernes" L4G style C#, Java (ajouter les proprietés etc.)

J'ai plus l'impression qu'ils ont essayé de placer les mots clés a la mode du moment 'scalable', 'isolation', 'component', 'modern' ...qu'un reel gain de productivité ou d'architecture logiciel.
Par ailleurs dans le document : http://clang.llvm.org/docs/Modules.h...-current-model
il y a plus de problemes non resolus que de REELS problemes resolus (pas de gestion de namespace donc conflits potentiels, pas de versioning, description des fonctions non lisibles dans les fichiers binaires de 'package').
Autant faire des nugets de librairies + entetes precompilées et on a tous les avantages sans les inconvenients.

Merci pour le lien vers site microsoft je vais quand meme le relire dans les details.
1  0 
Avatar de kilroyFR
Membre éclairé https://www.developpez.com
Le 06/04/2016 à 22:17
Merci de tes reponses claires !

Perso je vais attendre encore quelques années que ca se stabilise tout en surveillant regulierement comment ca evolue.
1  0