Version imprimable
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).Citation:
Envoy� par Niark13
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 :
Utilisation :Code:
2
3
4
5
6
7
Code:
2
3
4
Edit : En bonus, de l'optimisme ! :mrgreen: Commentaire trouv� sur reddit :
Citation:
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.
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 :)Citation:
Envoy� par Gugelhupf
Citation:
Envoy� par Gugelhupf
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.
1. a ne plus avoir besoin de headers separe du code sourceCitation:
A quoi serviront les modules en C++ ?
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.
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.Citation:
Est-ce que �a permet juste d'importer des sources en se passant des #ifndef / #define / #endif ?
Donc oui dans le principe, non dans la pratique.
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.Citation:
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).
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.
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.Citation:
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).
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...
L'id�e serait plut�t d'avoir un processus de compilation plus rapide pour l'utilisateur d'une biblioth�que.Citation:
Envoy� par Gugelhupf
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 ;)
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 ?Citation:
Envoy� par Klaim
@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 ?
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).
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.Citation:
Envoy� par gbdivers
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:
et � l'utilisateur de savoir "ce qu'il peut trouver" dans le module ou ses sous modules.
- 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
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
ouCode:
2
3
4
5
6
7
8
9
10
11
12
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.Code:
2
3
4
5
6
7
8
9
10
11
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 :D) 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 ;)
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.Citation:
Envoy� par gbdivers
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 solution21.
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.