Discussion :

[Klaim]

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).

[Arzar]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[Gugelhupf]

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

[Emmanuel Deloget]

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

[Klaim]

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...

[koala01]

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

[gbdivers]

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 ?

[germinolegrand]

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).

[koala01]

@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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[Klaim]

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.

[Klaim]

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.