À la base, les modules étaient censés remplacer les headers et apporter plein d'avantages (dont des temps de compilation plus rapides). Déjà, dès le début, ça s'est mal passé parce qu'il y a eu un consensus pour conserver le préprocesseur (même s'il est isolé au sein d'un module, ça a aboutit à une absurdité, voir plus loin). Ensuite, il y a eu la question des headers déjà existants qu'il fallait gérer. Et puis Google est arrivé avec sa propre solution (dite Atom) concurrente de la solution déjà en place et implémentées par certains compilateurs. Au final, il y a eu des réunions à l'arrache juste avant la deadline pour que tout le monde se mette d'accord sur un truc commun. Ce qui en sort est, de mon point de vue, très bancal. Et surtout, aucune implémentation n'existe, ce qui veut dire qu'on a absolument zéro retour sur une utilisation concrète de cette fonctionnalité fondamentale (alors que généralement, même pour un truc trivial, le comité de normalisation souhaite une implémentation).
Les concepteurs d'outils (build, IDE, etc) ont alerté le comité que la proposition finale allait sans doute poser des problèmes. En particulier, quand on fait un import foo, on n'a aucune information sur où pourrait se situer ce module foo. Et il pourrait très bien être n'importe où parce que la norme n'impose aucun schéma de nommage. Et même si on scanne tous les fichiers, il peut être très compliqué de savoir qu'on a trouvé le bon module puisque la directive module peut très bien être le résultat du préprocesseur. Ce qui veut dire que pour détecter de manière sûre l'emplacement d'un module, il faut 1) scanner tous les fichiers, 2) parser les fichiers comme le ferait le préprocesseur. Bref, on nage en plein délire.
Les concepteurs d'outils ont aussi alerté sur le fait que la compilation des modules allaient être beaucoup moins parallèle que celle des fichiers actuels. En effet, les modules forment un DAG et il est nécessaire de compiler dans l'ordre topologique, alors qu'avec les fichiers actuels, on peut tout compiler en parallèle et ça passe. Donc, adieu les temps de compilation améliorés. Les concepteurs d'outils ont monté un groupe de travail pour essayer de résoudre tous ces problèmes.
Et cerise sur le gâteau, comme la proposition est arrivée très tardivement, la bibliothèque standard n'a pas été modularisée. Donc en C++20, on fera import <vector> à la place de #include <vector>, mais concrètement, ça ne changera rien. De toute façon, pour les templates, il faudra toujours lire la définition quelque part pour l'instancier. Là encore, pour l'instant, il n'y a pas d'amélioration prévue.
Sur ce blog, on trouve aussi une sorte de tuto pour expliquer comment ça va s'utiliser (et ça ne va pas améliorer la réputation de C++ sur sa complexité).
[^] # Re: Mon avis (professionnel)
Posté par rewind (Mastodon) . En réponse au journal Moi, expert C++, j'abandonne le C++. Évalué à 10.
À la base, les modules étaient censés remplacer les headers et apporter plein d'avantages (dont des temps de compilation plus rapides). Déjà, dès le début, ça s'est mal passé parce qu'il y a eu un consensus pour conserver le préprocesseur (même s'il est isolé au sein d'un module, ça a aboutit à une absurdité, voir plus loin). Ensuite, il y a eu la question des headers déjà existants qu'il fallait gérer. Et puis Google est arrivé avec sa propre solution (dite Atom) concurrente de la solution déjà en place et implémentées par certains compilateurs. Au final, il y a eu des réunions à l'arrache juste avant la deadline pour que tout le monde se mette d'accord sur un truc commun. Ce qui en sort est, de mon point de vue, très bancal. Et surtout, aucune implémentation n'existe, ce qui veut dire qu'on a absolument zéro retour sur une utilisation concrète de cette fonctionnalité fondamentale (alors que généralement, même pour un truc trivial, le comité de normalisation souhaite une implémentation).
Les concepteurs d'outils (build, IDE, etc) ont alerté le comité que la proposition finale allait sans doute poser des problèmes. En particulier, quand on fait un
import foo, on n'a aucune information sur où pourrait se situer ce modulefoo. Et il pourrait très bien être n'importe où parce que la norme n'impose aucun schéma de nommage. Et même si on scanne tous les fichiers, il peut être très compliqué de savoir qu'on a trouvé le bon module puisque la directivemodulepeut très bien être le résultat du préprocesseur. Ce qui veut dire que pour détecter de manière sûre l'emplacement d'un module, il faut 1) scanner tous les fichiers, 2) parser les fichiers comme le ferait le préprocesseur. Bref, on nage en plein délire.Les concepteurs d'outils ont aussi alerté sur le fait que la compilation des modules allaient être beaucoup moins parallèle que celle des fichiers actuels. En effet, les modules forment un DAG et il est nécessaire de compiler dans l'ordre topologique, alors qu'avec les fichiers actuels, on peut tout compiler en parallèle et ça passe. Donc, adieu les temps de compilation améliorés. Les concepteurs d'outils ont monté un groupe de travail pour essayer de résoudre tous ces problèmes.
Et cerise sur le gâteau, comme la proposition est arrivée très tardivement, la bibliothèque standard n'a pas été modularisée. Donc en C++20, on fera
import <vector>à la place de#include <vector>, mais concrètement, ça ne changera rien. De toute façon, pour les templates, il faudra toujours lire la définition quelque part pour l'instancier. Là encore, pour l'instant, il n'y a pas d'amélioration prévue.Pour en savoir plus:
Sur ce blog, on trouve aussi une sorte de tuto pour expliquer comment ça va s'utiliser (et ça ne va pas améliorer la réputation de C++ sur sa complexité).