Publicité
+ Répondre à la discussion Actualité déjà publiée
Page 3 sur 3 PremièrePremière 123
Affichage des résultats 41 à 51 sur 51

Discussion: Le futur du C++

  1. #41
    Expert Confirmé
    Avatar de Klaim
    Homme Profil pro Joel Lamotte
    Développeur de jeux vidéo
    Inscrit en
    août 2004
    Messages
    1 717
    Détails du profil
    Informations personnelles :
    Nom : Homme Joel Lamotte
    Localisation : France

    Informations professionnelles :
    Activité : Développeur de jeux vidéo
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : août 2004
    Messages : 1 717
    Points : 3 026
    Points
    3 026

    Par défaut

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

  2. #42
    Membre Expert

    Inscrit en
    mai 2008
    Messages
    1 007
    Détails du profil
    Informations forums :
    Inscription : mai 2008
    Messages : 1 007
    Points : 1 958
    Points
    1 958

    Par défaut

    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.

  3. #43
    Membre émérite Avatar de Gugelhupf
    Homme Profil pro
    Développeur informatique
    Inscrit en
    décembre 2011
    Messages
    579
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : décembre 2011
    Messages : 579
    Points : 890
    Points
    890

    Par défaut

    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

  4. #44
    Expert Confirmé Sénior

    Homme Profil pro Emmanuel Deloget
    Développeur informatique
    Inscrit en
    septembre 2007
    Messages
    1 894
    Détails du profil
    Informations personnelles :
    Nom : Homme Emmanuel Deloget
    Âge : 38
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : septembre 2007
    Messages : 1 894
    Points : 4 140
    Points
    4 140

    Par défaut

    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
    [FAQ des forums][FAQ Développement 2D, 3D et Jeux][Si vous ne savez pas ou vous en êtes...]
    Essayez d'écrire clairement (c'est à dire avec des mots français complets). SMS est votre ennemi.
    Evitez les arguments inutiles - DirectMachin vs. OpenTruc ou G++ vs. Café. C'est dépassé tout ça.
    Et si vous êtes sages, vous aurez peut être vous aussi la chance de passer à la télé. Ou pas.

    Ce site contient un forum d'entraide gratuit. Il ne s'use que si l'on ne s'en sert pas.

  5. #45
    Expert Confirmé
    Avatar de Klaim
    Homme Profil pro Joel Lamotte
    Développeur de jeux vidéo
    Inscrit en
    août 2004
    Messages
    1 717
    Détails du profil
    Informations personnelles :
    Nom : Homme Joel Lamotte
    Localisation : France

    Informations professionnelles :
    Activité : Développeur de jeux vidéo
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : août 2004
    Messages : 1 717
    Points : 3 026
    Points
    3 026

    Par défaut

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

  6. #46
    Modérateur
    Avatar de koala01
    Profil pro Philippe Dunski
    Inscrit en
    octobre 2004
    Messages
    9 691
    Détails du profil
    Informations personnelles :
    Nom : Philippe Dunski
    Âge : 42

    Informations forums :
    Inscription : octobre 2004
    Messages : 9 691
    Points : 15 768
    Points
    15 768

    Par défaut

    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
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  7. #47
    Inactif


    Homme Profil pro Guillaume Belz
    Biochimiste
    Inscrit en
    novembre 2008
    Messages
    5 318
    Détails du profil
    Informations personnelles :
    Nom : Homme Guillaume Belz
    Âge : 38
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Biochimiste
    Secteur : Santé

    Informations forums :
    Inscription : novembre 2008
    Messages : 5 318
    Points : 17 319
    Points
    17 319

    Par défaut

    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 ?

  8. #48
    Expert Confirmé

    Avatar de germinolegrand
    Homme Profil pro Germino Legrand
    Développeur de jeux vidéo
    Inscrit en
    octobre 2010
    Messages
    731
    Détails du profil
    Informations personnelles :
    Nom : Homme Germino Legrand
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : Développeur de jeux vidéo
    Secteur : Tourisme - Loisirs

    Informations forums :
    Inscription : octobre 2010
    Messages : 731
    Points : 3 939
    Points
    3 939

    Par défaut

    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).
    Choisis un travail que tu aimes et tu n'auras pas à travailler un seul jour de ta vie.

    N'oubliez pas de marquer votre sujet comme et de mettre des aux messages apportant un plus à votre discussion.

    Si vous souhaitez participer à la rubrique C++, ne me contactez plus !

  9. #49
    Modérateur
    Avatar de koala01
    Profil pro Philippe Dunski
    Inscrit en
    octobre 2004
    Messages
    9 691
    Détails du profil
    Informations personnelles :
    Nom : Philippe Dunski
    Âge : 42

    Informations forums :
    Inscription : octobre 2004
    Messages : 9 691
    Points : 15 768
    Points
    15 768

    Par défaut

    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
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  10. #50
    Expert Confirmé
    Avatar de Klaim
    Homme Profil pro Joel Lamotte
    Développeur de jeux vidéo
    Inscrit en
    août 2004
    Messages
    1 717
    Détails du profil
    Informations personnelles :
    Nom : Homme Joel Lamotte
    Localisation : France

    Informations professionnelles :
    Activité : Développeur de jeux vidéo
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : août 2004
    Messages : 1 717
    Points : 3 026
    Points
    3 026

    Par défaut

    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.

  11. #51
    Expert Confirmé
    Avatar de Klaim
    Homme Profil pro Joel Lamotte
    Développeur de jeux vidéo
    Inscrit en
    août 2004
    Messages
    1 717
    Détails du profil
    Informations personnelles :
    Nom : Homme Joel Lamotte
    Localisation : France

    Informations professionnelles :
    Activité : Développeur de jeux vidéo
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : août 2004
    Messages : 1 717
    Points : 3 026
    Points
    3 026

    Par défaut

    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.

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •