Soutenez-nous

Le futur du C++
Présenté dans une vidéo de Herb Sutter

Les rubriques (actu, forums, tutos) de Développez
Réseaux sociaux


 Discussion forum

Le , par germinolegrand, Expert Confirmé Sénior
Le futur du C++

Hier, Herb Sutter a dévoilé plusieurs annonces importantes pour l’avenir du C++.
Notamment les dates des prochains standards, qui ont finalement été décidées.

Il a tout d’abord présenté de façon simple l’organisation du processus de standardisation :


Chaque SG est un groupe de travail qui peut comprendre jusqu’à quarante personnes. Ils étudient les besoins spécifiques à leur domaine afin de proposer la conception d’une fonctionnalité majeure. La conception est ensuite améliorée et mise au point par les groupes Evolution et Library : Evolution est responsable de l’évolution du langage tandis que Library traitera de l’impact de cette fonctionnalité dans la STL. Les groupes Evolution et Library peuvent également proposer des fonctionnalités mineures.
Puis chaque fonctionnalité passe par le Core qui en fera un « draft » détaillé capable d’intégrer le standard. Enfin, ce « draft » passera au vote général du WG21 – qui est le nom du comité international qui traite du C++ - , afin de décider de son intégration au prochain standard, ce qui en fait un traité international.

Cette introduction permet de présenter le calendrier des dates décidées par le comité :


On note bien évidemment deux dates importantes qui correspondent à deux nouveaux standards : C++17 qui sera un nouveau standard majeur, autrement dit de même importance que la norme C++11 ; mais également C++14 qui sera un standard mineur, c’est-à-dire qu’il ne comportera que des ajouts mineurs, mais aussi toutes les fonctionnalités majeures votées à cette date.
Ces fonctionnalités majeures feront l’objet de TS – Technical Specification est le nouveau nom donné aux TR alias Technical Report – indépendants, ce qui permettra de profiter des ajouts majeurs sans attendre 2017.
Le SG4 a d'ores et déjà annoncé qu’il publierait un TS Network tous les ans, mais le TS le plus proche concerne FileSystem qui est la 3e révision de cet ajout tiré de boost. Le TS sur la mémoire transactionnelle est plus flou dans les dates puisque le SG5 doit pour cela travailler de concert avec le consortium industriel.

Mais ce n’est pas tout, les annonces ne sont pas terminées. La suivante concerne l’ouverture officielle de isocpp.org, qui sera le site officiel du comité de standardisation. On pourra y trouver des informations sur l’avancement de la norme, des annonces importantes concernant le C++, et beaucoup d’autres choses. Le but de ce site est de promouvoir un style de programmation C++ moderne ainsi que l’expansion des bibliothèques C++ portables.

La dernière annonce concerne la création d’une association indépendante, la Standard C++ Foundation – à noter qu’elle est financée par 17 grandes entreprises à ce jour ayant un intérêt commun à la standardisation du C++. Son but est de promouvoir la compréhension et l’utilisation du C++ standard sur tous les compilateurs et toutes les plateformes – les entreprises qui financent ne contrôlent pas l’association. Les six directeurs de cette association sont C. Carruth, B. Stroustrup, B. Dawes, H. Sutter, S. Du Toit et M. Wong.

Toutes ces annonces promettent un bel avenir pour le C++, l’utilisation et la propagation de ces normes internationales ne tiennent qu’à vous tous, développeurs C++.

Comment suivez-vous l’actualité du C++ ?
Connaissiez-vous le fonctionnement du comité de standardisation du C++ ?
Utilisez-vous le dernier standard (C++11) en production ? À titre personnel ?
Comment vous formez-vous à l’utilisation de la dernière norme (C++11) ?


Voir également Microsoft renforce le support de C++ 11 dans Visual Studio 2012

Source : The Future of C++


 Poster une réponse

Avatar de Klaim Klaim
Expert Confirmé
le 08/11/2012 11:17
Citation Envoyé par Niark13  Voir le message
Ce qui risque d'être plus difficile, ça va être que tout le monde se mette d'accord sur les formats de ces fichiers (on me glisse dans l'oreillette qu'il y a un peu plus de couples système/compilateur dans le monde C++ que dans le monde D)...

Oui exactement, surtout que je crois pas qu'on puisse echaper à des fichiers lisible par l'homme, essentiellement parceque si on livre une bibliothèque sans les déclarations, ça va être moche...les déclaratoins sont la seule documentation qui ne peut pas être fausse ou obsolete (hors mauvais nommage).
Avatar de Arzar Arzar
Membre Expert
le 26/11/2012 16:32
Les slides de la présentation de Doug Gregor à la LLVM Developper's Meeting 2012 exposant les travaux effectués dans Clang ainsi que la direction que va prendre Clang pour les modules en C/C++ sont disponibles !

http://llvm.org/devmtg/2012-11/Gregor-Modules.pdf

Proposal très intéressant car il explore une voie un peu différente que celle explorée par le proposal existant N3347.

Dans cette incarnation des modules, le .h reste la pièce centrale. Le but avoué est d'obtenir une transition vers les modules la plus simple possible. il n'y a pas de génération de fichier d'interface standardisés et distribuables et aucune réécriture des .h existants n'est nécessaire : L'idée c'est qu'un module représente un package d'un .h ou de groupe de .h. Pour établir la correspondance module <-> .h on écrit une module.map, par exemple :

Code :
1
2
3
4
5
6
7
 
// /usr/include/module.map 
module std { 
  module stdio { header “stdio.h” } 
  module stdlib { header “stdlib.h” } 
  module math { header “math.h” } 
}
Utilisation :
Code :
1
2
3
4
import std.stdio; 
int main() { 
  printf(“Hello, World!\n”); 
}

Edit : En bonus, de l'optimisme ! Commentaire trouvé sur reddit :
I had a chance to talk with Doug Gregor about modules, after he gave this talk. First, Doug is on the core language committee; and, second, up to bike shedding arguments, there are no (fundamental) objections to his proposal. The technical work for Clang is substantively done, and he expects final wording to be done by as early as 2014. Most major compilers will have support before 2017, the next standard date.

Avatar de Gugelhupf Gugelhupf
Membre émérite
le 05/12/2012 10:42
Bonjour,

Est-ce que les modules sont censés faire parti du standard C++ ou est-ce que c'est spécifique à un compilateur ?

A quoi serviront les modules en C++ ?
Est-ce que ça permet juste d'importer des sources en se passant des #ifndef / #define / #endif ?

Est-ce que c'est la même chose que les packages en Java ?
C'est-à-dire : à partir d'un ensemble de dossier (et sous-dossier), importer des classes sans avoir à utiliser le nom du fichier (nom du fichier = nom de la classe).
Intérêt : dans un fichier, au sein d'un même "module/package", plus besoin de faire un import en en-tête (ça fait des lignes en moins à écrire en gros).

Merci
Avatar de Emmanuel Deloget Emmanuel Deloget
Expert Confirmé Sénior
le 05/12/2012 14:16
Citation Envoyé par Gugelhupf  Voir le message
Bonjour,

Est-ce que les modules sont censés faire parti du standard C++ ou est-ce que c'est spécifique à un compilateur ?

A quoi serviront les modules en C++ ?
Est-ce que ça permet juste d'importer des sources en se passant des #ifndef / #define / #endif ?

Est-ce que c'est la même chose que les packages en Java ?
C'est-à-dire : à partir d'un ensemble de dossier (et sous-dossier), importer des classes sans avoir à utiliser le nom du fichier (nom du fichier = nom de la classe).
Intérêt : dans un fichier, au sein d'un même "module/package", plus besoin de faire un import en en-tête (ça fait des lignes en moins à écrire en gros).

Merci

La réponse précédente te donne un exemple d'utilisation - et réponds par conséquent à toutes tes questions
Avatar de Klaim Klaim
Expert Confirmé
le 05/12/2012 14:17
Citation Envoyé par Gugelhupf  Voir le message
Bonjour,

Est-ce que les modules sont censés faire parti du standard C++ ou est-ce que c'est spécifique à un compilateur ?


C'est une fonctionalite que le commitee etudie actuellement pour le prochain standard du language (pas de la library) qui pour l'instant viserai 2017, meme si theoriquement ca pourrait etre implemente avant par divers compilateurs.

La personne qui s'occupe de faire la premiere implementation est aussi celle qui s'occupe de la proposition et il le fait en ajouter la fonctionalite au compilateur Clang.

A quoi serviront les modules en C++ ?

1. a ne plus avoir besoin de headers separe du code source
2. a ne plus avoir besoin de savoir ou se trouvent les headers
3. a ameliorer (drastiquement?) les temps de compilation en pre-compilant une seule fois chaque module, puis en reutilisant les donnes precompiles pour compiler le code qui utilise le module. En gros, ca permettrais de ne plus avoir une compilation multipliee par toutes les inclusions de headers.

Voir http://isocpp.org/blog/2012/11/modul...ss-doug-gregor pour plus d'infos.

Est-ce que ça permet juste d'importer des sources en se passant des #ifndef / #define / #endif ?

Oui mais de maniere a ce qu'un module soit pre-compile une seule fois pour tous les modules qui vont l'importer. En gros, c'est different du copier/coller du #include parceque le compilateur sait a l'avance les symboles disponible parcequ'il a precompile les modules, et a donc possibilite d'accelerer la compilation en extractant et utilisant que les symboles du module utilise par le code.

Donc oui dans le principe, non dans la pratique.

Est-ce que c'est la même chose que les packages en Java ?
C'est-à-dire : à partir d'un ensemble de dossier (et sous-dossier), importer des classes sans avoir à utiliser le nom du fichier (nom du fichier = nom de la classe).

Oui et non: java associe la position du fichier module dans le systeme de fichier a son namespace, tandis que pour les future module c++ ca serait plutot le module qui dis son nom.
Dans tous les cas ca ressemble a comment marche java mais c'est un peu different. Pense juste qu'un sous module n'est pas forcement dans un sous dossier, la position du fichier et son nom n'ont strictement rien a voir avec le nom du module.

Intérêt : dans un fichier, au sein d'un même "module/package", plus besoin de faire un import en en-tête (ça fait des lignes en moins à écrire en gros).

Je ne suis pas sur d'avoir compris. Si tu veux dire qu'on aura moins de headers a importer, effectivement ca serait un effet de bord.

Au passage, je me demande justement si il est possible de specifier le meme nom de module depuis plusieurs fichiers cpp. Je ne me souviens pas avoir lu de specification la dessus...
Avatar de koala01 koala01
Modérateur
le 05/12/2012 14:22
Citation Envoyé par Gugelhupf  Voir le message
Bonjour,

Est-ce que les modules sont censés faire parti du standard C++ ou est-ce que c'est spécifique à un compilateur ?

A quoi serviront les modules en C++ ?
Est-ce que ça permet juste d'importer des sources en se passant des #ifndef / #define / #endif ?

Est-ce que c'est la même chose que les packages en Java ?
C'est-à-dire : à partir d'un ensemble de dossier (et sous-dossier), importer des classes sans avoir à utiliser le nom du fichier (nom du fichier = nom de la classe).
Intérêt : dans un fichier, au sein d'un même "module/package", plus besoin de faire un import en en-tête (ça fait des lignes en moins à écrire en gros).

Merci

L'idée serait plutôt d'avoir un processus de compilation plus rapide pour l'utilisateur d'une bibliothèque.

Les fichiers d'en-tête tels qu'ils sont pour l'instant devront rester exactement sous la même forme, compatibilité avec le C oblige.

Mais il faut savoir comment fonctionne la directive #include pour comprendre tout le problème :

Quand le préprocesseur rencontre une directive #include, il copie littéralement tout le fichier indiqué à la place de la directive, puis il continue à parser en partant de la première ligne du contenu qu'il vient de remplacer.

A cause du jeu des inclusions en cascade, l'inclusion d'un seul fichier d'en-tête peut donc résulter en la copie de plusieurs dizaines de fichiers différents, qui devront tous être parsés par le compilateur.

Et comme le compilateur "oublie" à chaque fichier qu'il compile ce qu'il a fait pour le fichier précédent, ce travail lui prend un temps bête car, si deux fichiers *.cpp incluent le même fichier d'en-tête, il va devoir en lire le contenu (récursif) les deux fois, et donc créer deux fois son arbre de symboles.

Or, cet arbre de symboles ne change, fatalement, absolument pas d'une utilisation à l'autre du fichier d'en-tête car c'est à partir de cet arbre qu'il peut savoir si un symbole existe et, de manière indirecte, grâce à cet arbre de symboles que l'éditeur de liens est capable de faire le lien entre les symboles qui sont définis dans les différents fichiers objets.

L'idée des modules est donc de faire en sorte de "sauvegarder" cet arbre de symboles de manière à ce qu'il soit "réutilisable" "directement" (comprends: sans que le préprocesseur ne doive passer par là, et sans que le compilateur n'ait autre chose à faire que le charger en mémoire, dans sa forme utilisable en interne)

De cette manière, au lieu d'avoir N processus de lecture du fichier d'en-tête + remplacement des directives #include + création de l'arbre de symboles, nous aurions une fois ce processus + "sauvegarde" de l'arbre de symboles et N-1 processus de chargement de l'arbre de symboles.

Au final, cela devrait pouvoir accélérer énormément le processus de compilation, car il est beaucoup plus rapide de charger l'arbre de symboles que de passer par tout le processus actuel pour l'obtenir

Le tout, comme il s'agit de rajouter une fonctionnalité au langage et qu'il n'est pas question de casser la base de code existante, c'est qu'il faut trouver un moyen pour indiquer quel fichier fait partie de quel (sous) module
Avatar de gbdivers gbdivers
Inactif
le 05/12/2012 14:40
Citation Envoyé par Klaim
1. a ne plus avoir besoin de headers separe du code source

J'ai toujours eu du mal à comprendre ce point. Actuellement, rien nous oblige à séparer le header du code source (on met tous dans le header), c'est un choix volontaire de séparer l'interface et le code source. Quel intérêt à revenir à un système qui ne permet plus cette séparation ? On perd l'avantage de séparer la partie "stable" d'un classe (son interface) de la partie "moins stable" (son implémentation), non ?

@koala01
J'ai du mal à voir en quoi l'utilisation d'une table de symbole dépend des modules. C'est plutôt une limitation des compilateurs actuels (je croyais d'ailleur de clang utilisait justement un table des symboles pour éviter de relire plusieurs fois les fichiers d'en-tête), non ? Les modules sont juste une réorganisation/regroupement différents/supplémentaires des fichiers ou j'ai loupé une chose ?

EDIT : ok, j'ai pris le temps de regarder la présentation des modules pour clang. Ca ne supprime pas les headers en fait, tout va bien de ce coté. EDIT2 : ah si, ça supprime bien les headers dans la création des modules.
Pour l'histoire de la table des symboles, je me demande si le problème ne vient pas de la norme qui dirait "avec include, faut copier-coller le code" et que donc utiliser une table des symbole avec include irait à l'encontre de la norme. Pour des raisons de rétro compatibiltié, la norme ne peut pas alors modifier la règle "avec include, faut copier-coller le code" et il faut alors une nouvelle fonctionnalité (les modules) pour autoriser l'utilisation de la table des symboles.
C'est plus comme ça qu'il faut comprendre pourquoi on a besoin des modules pour passer à une compilation utilisant une table des symboles ?
Avatar de germinolegrand germinolegrand
Expert Confirmé Sénior
le 05/12/2012 14:53
D'accord avec gbdivers, je vois ça plutôt comme une régression pour être plus "simple"... et encore non ça risque de complexifier la syntaxe...

Par contre oui, il est certain que la mémorisation de l'arbre des symboles lors d'un rebuild peut faire gagner un temps fou. Mais le problème est que ceci interdirait l'utilisation de macros dans les .h, ce que je considère comme étant une mauvaise chose (à noter que l'équivalent standard du pragma once ne serait pas une mauvaise idée, s'il se contente d'ajouter un guard simple au fichier).
Avatar de koala01 koala01
Modérateur
le 05/12/2012 15:41
Citation Envoyé par gbdivers  Voir le message
@koala01
J'ai du mal à voir en quoi l'utilisation d'une table de symbole dépend des modules. C'est plutôt une limitation des compilateurs actuels (je croyais d'ailleur de clang utilisait justement un table des symboles pour éviter de relire plusieurs fois les fichiers d'en-tête), non ? Les modules sont juste une réorganisation/regroupement différents/supplémentaires des fichiers ou j'ai loupé une chose ?

En fait, si j'ai bien compris l'esprit de la chose (ce qui reste encore à démontrer ), l'idée est que, quand tu crées ta bibliothèque, tu utiliserais les fichiers d'en-tête "classiques" pour que le compilateur connaisse les symboles dont il a besoin pour travailler.

Par contre, quand tu déploies / utilises une bibliothèque, tu fournirais la table des symboles générée lors de la création de ta bibliothèque et non les fichiers d'en-tête car ce serait "tout ce qu'il faut" pour que le compilateur puisse travailler.

le fichier map fourni en exemple par Arzar permettrait en fait une double (en fait, une triple) utilité :

Il permettrait au compilateur:
  • de créer la table de symboles pour le module et ses sous modules (au moment de la génération de la bibliothèque)
  • de savoir à quel sous module correspond quelle partie de sa table de symboles
et à l'utilisateur de savoir "ce qu'il peut trouver" dans le module ou ses sous modules.

Pour ce qui est de la (re)génération des modules, on dispose d'un processus éprouvé largement utilisé par make et ses concurrents basé sur son timestamp: si un fichier source (ou l'un des fichier qu'il inclut)best plus récent que le fichier de destination, il faut refaire le fichier de destination.

Et, comme tu l'as si bien fait remarquer, l'interface est globalement plus stable que l'implémentation.

Il est donc finalement assez facile de comparer le timestamp du fichier généré d'un coté avec ceux du fichier "map" et ceux des fichiers indiqués dans ce dernier.

Si l'un de ces fichier (map ou inclus dans map) a été modifié, il faut recréer la table de symboles avant de pouvoir l'utiliser (mais cela ne devra plus être effectué qu'une fois par compilation, dans le pire des cas), par contre, s'il n'y a pas eu de modification, on peut utiliser directement la table de symboles telle qu'elle a été générée pour la dernière fois.

Dans ton code utilisant un module donné (mettons le module std), tu pourrais créer un fichier d'en-tête proche de
Code :
1
2
3
4
5
6
7
8
9
10
11
12
import module std.string // on n'importe que les symboles issus du sous module string 
import module std.vector// et ceux issus de vector 
#ifndef MACLASSE_HPP 
#define MACLASSE_HPP 
class MaClasse 
{ 
    /*...*/ 
    private: 
        std::string str; 
        std::vector<UnType> tab; 
}; 
#endif
ou

Code :
1
2
3
4
5
6
7
8
9
10
11
import module std // on importe tout ce qui a trait au module std 
#ifndef MACLASSE_HPP 
#define MACLASSE_HPP 
class MaClasse 
{ 
    /*...*/ 
    private: 
        std::string str; 
        std::vector<UnType> tab; 
}; 
#endif
Un des avantages serait, en outre, le fait que tu pourrais avoir des dépendances circulaires au sein de ton module, qui seront gérées de manière "classique" (avec déclaration anticipée d'un coté, inclusion du fichier d'en-tête ad-hoc de l'autre), sans avoir besoin de t'en inquiéter à l'utilisation tout en pouvant veiller à ce qu'il n'y en ait pas entre tes modules.

Ainsi, tu pourrais très bien créer ton module "graphisms" qui va gérer toute la partie d'affichage de ton projet, qui dépend (qui l'aurait cru ) de ton module "business", avec peut etre des dépendances circulaire à l'intérieur de graphisms ou de business, tout en évitant les dépendances circulaires entre graphisms et business

On se rapproche donc fortement de la notion de module que l'on peut avoir en conception, en sommes
Avatar de Klaim Klaim
Expert Confirmé
le 05/12/2012 16:47
Citation Envoyé par gbdivers  Voir le message
J'ai toujours eu du mal à comprendre ce point. Actuellement, rien nous oblige à séparer le header du code source (on met tous dans le header), c'est un choix volontaire de séparer l'interface et le code source. Quel intérêt à revenir à un système qui ne permet plus cette séparation ? On perd l'avantage de séparer la partie "stable" d'un classe (son interface) de la partie "moins stable" (son implémentation), non ?

Non, parcequ'un module a une partie publique et une partie privee. Ce n'est pas explique dans la presentation parceque ce n'est pas le sujet, mais dans les derniers brouillons de la specification on explique qu'il y a bien une section privee et une section public a chaque module.

Jusqu'ici nos headers servaient de section publique, essentiellement parceque la methode d'import (#include) marche comme un copier/coller d'un fichier entier. (ce qui implique tout un tas de problemes que les modules tentent de resoudre ou d'amoindrir)

Or, des le moment ou ton cpp peut etre decoupe en deux parties publiques et privees ET que tu specifies que le compilateur doit pouvoir prendre en compte lui meme cette notion, pas via de la generation de code par copier coller, alors tu n'as pas forcement besoin de separer ton interface publique dans des headers.

Le vrai probleme que tu souleves c'est au niveau de la documentation: il est plus efficace pour des programmeurs de se baser sur le code comme specification d'interface plutot que sur une documentation separee (et potentiellement fausse).
Quand on travail avec une interface dont on a pas les sources c'est effectivement un gros souci.

Je crois que ca n'a pas encore ete decide de l'orientation sur ce point. D'un cote, les #includes existeront toujours pour la retrocompatibilite, ce qui signifie qu'on peut toujours generer des modules dont la partie publique serait des headers qui seraient fournis aux clients.

Une autre possibilite serait de faire en sorte que le compilateur genere un format intermediaire qui ressemble fortement au C++ normal mais avec des parties caches. En gros on aurait des headers generes mais avec seulement les parties visibles (les membres prives d'une classe ne seraient pas visible).
Le probleme avec ca c'est que ca suppose une sorte de nouveau language a lire pour le compilateur. Il y a aussi le souci des commentaires: est-ce que le compilateur doit les garder avec le code genere? Si oui il faudrait un moyen de specifiier la documentation specific aux interfaces, comme le font C# et java et python par exemple.
En gros, beaucoup de boulot, mais est-ce que ca vaut le coup?

Difficile a dire.
A ce que je sache, tout ca est a l'etude, donc des qu'on peut tester des premieres versions stables avec clang, on aura une idee plus clair de ou ca peut aller.

edit> Le fichier map, c'est la solution 2 1.
Avatar de Klaim Klaim
Expert Confirmé
le 05/12/2012 21:52
Ouh yeah, la video associee au document sur les modules est dispo!
http://isocpp.org/blog/2012/12/modul...le-doug-gregor

Est-ce qu'il serait une bonne idee couper cette discussion a partir de la question de Gugelhupf dans un thread dedie eux modules? C'est un sujet tellement important pour les devs c++ qu'il merite bien d'etre isole.
Offres d'emploi IT
Administrateur systèmes et réseaux - 92
CDI
SCP - Ile de France - Saint Cloud (92210)
Parue le 27/03/2014
Recherche développeur(se) pcsoft windev webdev région bordelaise
CDD CDI
revoludev - Aquitaine - Mérignac (33700)
Parue le 16/04/2014
Stage developpeur Wordpress, MYSQL, PHP5...
Stage
La Vie du Rail - Ile de France - Paris 75009
Parue le 28/03/2014

Voir plus d'offres Voir la carte des offres IT
 
 
 
 
Partenaires

PlanetHoster
Ikoula