IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

C++ Discussion :

C++ doit-il moderniser son mécanisme d’inclusion ?


Sujet :

C++

  1. #1
    Expert éminent sénior

    Homme Profil pro
    Développeur informatique
    Inscrit en
    Septembre 2014
    Messages
    194
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Algérie

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : Septembre 2014
    Messages : 194
    Points : 12 291
    Points
    12 291
    Par défaut C++ doit-il moderniser son mécanisme d’inclusion ?
    C++ doit-il moderniser son mécanisme d’inclusion ?
    CoderGears estime que c’est nécessaire pour qu’il devienne un langage vraiment moderne

    Il y a 3 ans, les développeurs C++ avaient accueilli la nouvelle standardisation du langage avec beaucoup d'enthousiasme. Avec ce nouveau standard, plusieurs fonctionnalités avaient été ajoutées ou mises à jour pour faire du C++ un langage plus moderne et efficace, tout en conservant les anciens avantages tels que l'accès bas niveau à la mémoire par exemple.

    Cependant, d'autres améliorations ont été reportées, car il aura fallu quand même 13 ans pour finir cette normalisation!
    Une des améliorations possibles, qui restent toujours intéressantes, c'est de repenser le système d'inclusion de fichiers. C'est en tout cas ce que propose l’équipe CoderGears dans un billet de blog. Ils sont même allés plus loin en proclamant que « le C++ doit moderniser son mécanisme d’inclusion pour devenir vraiment un langage moderne ».

    Jusqu'à présent, lorsqu'un fichier d'entête est inclus grâce à la directive #include, le préprocesseur analyse le contenu du fichier ainsi que tous les autres fichiers qu'il inclut lui-même. Et ceci est répété à chaque #include rencontré. Ce qui conduit parfois à un grand volume de travail redondant lorsque deux fichiers incluent la même bibliothèque, et que celle-ci n’est pas entourée de #ifndef et #endif. Mais ce n'est pas le seul problème, car lors de l’analyse, si une macro par exemple porte le même nom qu'un autre composant dans cette bibliothèque, c'est toute la compilation qui échoue. « Des problèmes se produisent dans des projets réels lorsque les entêtes pour deux bibliothèques différentes interagissent en raison de collisions macro, et les utilisateurs sont obligés de réorganiser les directives #include ou introduire des #undef pour briser le lien », explique CoderGears.


    Certains programmeurs, avec le temps, ont développé de nouvelles habitudes pour éviter ça. Dans la documentation de Clang, on peut lire que « les programmeurs C++ ont adopté un certain nombre de conventions pour travailler autour de la fragilité du modèle de préprocesseur […] Les noms de macros sont écrits avec de LONG_PREFIXES_EN_MAJUSCULES pour éviter les collisions, et certains développeurs de bibliothèques utilisent même un double tiret dans les en-têtes pour éviter les collisions avec des noms "normaux"». Cette pratique, qui ne respecte pas les conventions du langage, est apparemment utilisée par certains pour contourner le problème.

    Heureusement, une solution existe depuis la proposition de la norme C++ox, mais elle n'a pas été implémentée et a été retardée pour la norme C++11, puis renvoyée une nouvelle fois à une prochaine standardisation du langage de programmation.

    Cette solution devrait alléger grandement le code des entêtes ainsi que leur traitement, puisqu'elle propose de ne plus inclure les fichiers d'une bibliothèque séparément. Par exemple : au lieu de charger les fichiers de la bibliothèque standard du C++ un à un, un simple import std suffira. L'entête gagnera donc beaucoup en clarté. De plus, cela inclura directement le fichier binaire de la bibliothèque (en tant que module déjà prêt), ce qui évitera au préprocesseur de le réanalyser à chaque fois, et évitera en même temps de tomber sur des conflits lors de la compilation.

    « L’introduction de modules en C ++ ne sera pas une tâche facile », avoue l’équipe CoderGears. « Nous espérons que ce ne sera pas comme jisgaw (le système modulaire de Java) qui a été reportée de nombreuses années ».

    Source : CoderGears Blog, Clang Documentation

    Et vous?

    Partagez-vous le point de vue de l’équipe de CoderGears ?

  2. #2
    Membre chevronné

    Homme Profil pro
    Appui fonctionnel senior
    Inscrit en
    Juin 2007
    Messages
    461
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Appui fonctionnel senior
    Secteur : Industrie

    Informations forums :
    Inscription : Juin 2007
    Messages : 461
    Points : 2 211
    Points
    2 211
    Par défaut
    Ce système d'inclusion préhistorique est certainement la principale raison qui m'a fait abandonné le C++ au profit du C#. Du coup, cela fait quelques années que j'attends de pieds fermes ces modules afin de m'y remettre un peu !

  3. #3
    Expert éminent sénior Avatar de Uther
    Homme Profil pro
    Tourneur Fraiseur
    Inscrit en
    Avril 2002
    Messages
    4 569
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Pyrénées Orientales (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Tourneur Fraiseur

    Informations forums :
    Inscription : Avril 2002
    Messages : 4 569
    Points : 15 527
    Points
    15 527
    Par défaut
    Article bizarre qui enfonce des portes grandes ouvertes.

    Toute personne qui a fait un minimum de C++ sait bien qu'on doit moderniser son mécanisme d'inclusion. Tout le monde le sait, tout le monde l'attend avec impatience a chaque nouvelle évolution du langage, mais on comprend également qu'un tel changement n'est pas anodin et qu'il prend du temps.

  4. #4
    Inactif  


    Homme Profil pro
    Doctorant sécurité informatique — Diplômé master Droit/Économie/Gestion
    Inscrit en
    Décembre 2011
    Messages
    9 012
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Doctorant sécurité informatique — Diplômé master Droit/Économie/Gestion
    Secteur : Enseignement

    Informations forums :
    Inscription : Décembre 2011
    Messages : 9 012
    Points : 23 145
    Points
    23 145
    Par défaut
    Bonjour,

    Inclure directement le binaire de la bibliothèque.
    Et on fait comment pour les macro, les templates ou les fonctions inlines .

    Pourquoi ne pas tout simplement utiliser des fichiers d'en-têtes "pré-compilés" ?

    lorsque deux fichiers incluent la même bibliothèque, et que celle-ci n’est pas entourée de #ifndef et #endif.
    Je doute que ceci soit si fréquent que ça, et il existe aussi des solutions (pas géniales, mais qui existent).

    Après il existe bien #pragma include_once qui ne fait pas parti de la norme mais, il me semble qu'il marche pas trop mal.

    un simple import std suffira
    Importer tout std ? Pour chaque fichier source utilisant la std ? Ceci me semble un peu lourd.
    Importer uniquement les modules dont on a besoin ?
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    #import std.iostream
    #import std.vector
    Je ne vois pas trop ce que ceci apporterait de plus que :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    #include <iostream>
    #include <vector>
    Je n'aime pas trop le système proposé, je pense qu'elle induit trop de changements sur les étapes de la chaîne de compilation.
    Alors que je pense qu'on pourrait trouver des solutions plus simples et plus efficaces.

  5. #5
    En attente de confirmation mail

    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Août 2004
    Messages
    1 391
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France, Doubs (Franche Comté)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Août 2004
    Messages : 1 391
    Points : 3 311
    Points
    3 311
    Par défaut
    Bonjour,

    Tout d'abord la proposition actuel : http://www.open-std.org/JTC1/SC22/WG...2014/n4214.pdf et la précédente : http://www.open-std.org/JTC1/SC22/WG...2012/n3347.pdf (je ne l'ai pas encore lu, donc je me base plus sur le premier).

    @Neckara: Il n'est pas question de "binaire" en réalité, donc aucun problème pour fonctions inlines et templates. De plus dans l'idée, les modules ne doivent pas changer les règles actuelles.

    Pour les import, ne t'inquiète pas, des sous-modules sont bien prévus, on ne va pas importer std en entier à chaque fois.

    En effet le but est bien de changer en profondeur le système de compilation tout en permettant d'encore utiliser l'ancien. Le système actuel est basé sur du copier/coller, l'intérêt des modules c'est de dire : "voila, d'un côté les éléments suivants de cette unité sont importables par d'autre unité au sein de tel module, et de l'autre j'aimerais bien utilisé les éléments de tel module". On évite ainsi les copier/coller. Niveau implémentation, il faudrait regarder ce que clang avait proposé, mais je suppose que ça implique de générer des données supplémentaire (après le passage du préprocesseur) qui permet de savoir ce qu'il y a dans chaque module.

    Niveau avantage, la limitation des violations de l'ODR (ie les erreurs "truc déjà définie") est celle qui m'attire le plus personnellement.

  6. #6
    Inactif  


    Homme Profil pro
    Doctorant sécurité informatique — Diplômé master Droit/Économie/Gestion
    Inscrit en
    Décembre 2011
    Messages
    9 012
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Doctorant sécurité informatique — Diplômé master Droit/Économie/Gestion
    Secteur : Enseignement

    Informations forums :
    Inscription : Décembre 2011
    Messages : 9 012
    Points : 23 145
    Points
    23 145
    Par défaut
    D'accord, donc on ne fait pas réellement "d'inclusion" (au sens copié/collé) et il n'est pas questions du fichier "binaire de la bibliothèques".

    En lisant l'actualité, je comprenais "on prend le .so/.dll et on le 'copie-colle'"... Je ne dirais rien, mais j'en pense pas moins .

    Si je comprend bien, à partir des fichiers .cpp, on va générer une sorte de "header précompilé" qui ne sera plus utilisée par le préprocesseur (pour copier/coller le code) mais après.

    Par contre, est-ce qu'il est prévu que ces "header précompilé" soient distribuées à l'intérieur des .so/.dll ou ils pourront encore être distribués séparément ?


    C'est une idée intéressante, à voir ce que cela donnera. Mais ce que j'attends avec plus d'impatience, c'est une normalisation de tout ce qui est "plugin" et chargement dynamique de bibliothèques dynamiques.

  7. #7
    Invité
    Invité(e)
    Par défaut
    Mais ce que j'attends avec plus d'impatience, c'est une normalisation de tout ce qui est "plugin" et chargement dynamique de bibliothèques dynamiques.

    Il existe divers façon de le faire pour linux, mac/osX et windows mais, en effet, ce n'est pas encore normalisé. :/

    En attendant il faut faire sans, mais, je me demande si un jour il y aura une méthode standard.

    PS : Les "include" pour le moment ça ne me gêne pas tellement, à part peut être, les problèmes dû à la double définition des macros cité plus haut.

  8. #8
    Inactif  


    Homme Profil pro
    Doctorant sécurité informatique — Diplômé master Droit/Économie/Gestion
    Inscrit en
    Décembre 2011
    Messages
    9 012
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Doctorant sécurité informatique — Diplômé master Droit/Économie/Gestion
    Secteur : Enseignement

    Informations forums :
    Inscription : Décembre 2011
    Messages : 9 012
    Points : 23 145
    Points
    23 145
    Par défaut
    Je pensais à quelque chose de plus orienté objet et sans casts de void * .
    Quelque chose qui permettrait aussi d'utiliser les exceptions.

    Une gestion de la mémoire pensée avec les plugins (pour ne pas faire planter les std::function/pointeurs intelligents), etc.

  9. #9
    Invité
    Invité(e)
    Par défaut
    Oui c'est du C plutôt en effet (d'ou les extern "C") mais, je ne connais pas de manière pour le faire en c++. :/

    Et j'en recherche une depuis, un bon bail déjà maintenant.

    Les casts en void* c'est assez crade. :/

    Petit message au chroniqueur d'actualité : si tu pouvais être un peu plus clair ça serait bien, merci.

  10. #10
    Rédacteur/Modérateur
    Avatar de JolyLoic
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Août 2004
    Messages
    5 463
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 49
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Août 2004
    Messages : 5 463
    Points : 16 213
    Points
    16 213
    Par défaut
    Citation Envoyé par Neckara Voir le message
    Mais ce que j'attends avec plus d'impatience, c'est une normalisation de tout ce qui est "plugin" et chargement dynamique de bibliothèques dynamiques.
    Je n'ai pas vu beaucoup de discussions autour de ce sujet, probablement car :
    - Ça demande énormément de travail de spécification difficile à écrire, en plus de la notion de modules (car la norme est aujourd'hui pudiquement silencieuse sur tout un tas de sujets qu'il faudrait expliciter pour définir ça)
    - Il existe des pratiques un peu partout, mais qui sont divergentes sur tout un tas de points. Ce qui laisse présager des guerres de religion.

    Je pense que le point de vue actuel est "attendons d'avoir les modules dans une version un peu près stable, et à ce moment là on regardera comment faire des modules chargés dynamiquement".

    Citation Envoyé par Amine Horseman Voir le message
    Heureusement, une solution existe depuis la proposition de la norme C++ox, mais elle n'a pas été implémentée et a été retardée pour la norme C++11, puis renvoyée une nouvelle fois à une prochaine standardisation du langage de programmation.
    C'est un peu optimiste comme vision... Il n'y a pas vraiment une solution dans la norme C++0x, juste une proposition d'évolution comme tant d'autres, qu'une personne a tenté d'implémenter pour Clang afin de la valider un peu. Ce qui est récent sur le sujet, c'est que d'autre compilateurs que Clang ont manifesté un intérêt pour le sujet (les dernières propositions sont de Microsoft), ce qui j'espère va fortement booster ce sujet qui était un peu au point mort après une première implémentation Clang.

    Pour ce qui est du format de fichier, rien n'est précisé dans les dernières propositions. Ce sera probablement un format binaire (pour des raisons de performances), mais pas exécutable. Il n'est pas prévu d'imposer une compatibilité entre compilateurs sur ce format, même si on peut imaginer que des compilateurs se voulant compatibles (gcc et clang) vont avoir intérêt à se mettre d'accord pour un format commun.

    On peut le voir comme un super PCH, qui apporterait une grande nouveauté par rapport aux PCH : La composabilité. Aujourd'hui, on fait un PCH pour un programme qui utilise libA et libB. Le but est de pouvoir faire un PCH pour libA, un autre pour libB, et de pouvoir dire qu'on utilise les deux pour notre programme.
    Ma session aux Microsoft TechDays 2013 : Développer en natif avec C++11.
    Celle des Microsoft TechDays 2014 : Bonnes pratiques pour apprivoiser le C++11 avec Visual C++
    Et celle des Microsoft TechDays 2015 : Visual C++ 2015 : voyage à la découverte d'un nouveau monde
    Je donne des formations au C++ en entreprise, n'hésitez pas à me contacter.

  11. #11
    Membre éprouvé
    Avatar de octal
    Profil pro
    Inscrit en
    Septembre 2004
    Messages
    441
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2004
    Messages : 441
    Points : 957
    Points
    957
    Par défaut
    la solution radicale au problème des includes a déjà été proposée à maintes reprise par Apple et ça n'a jamais été retenu (http://llvm.org/devmtg/2012-11/Gregor-Modules.pdf). Il s'agit de l'utilisation des "module". Le mécanisme date des années où un certain Monsieur Wirth a proposé le mécanisme de module dans Modula-2 puis Oberon. Il ne s'agit pas d'utiliser le binaire, il s'agit tout simplement de charger et analyser le module une seule fois, et d'avoir un référentiel de modules chargés. Chaque nouvelle inclusion ne fera que référencer le module en question (donc plus d'analyse redondante et plus de recompilation). Cela marche très bien pour Modula-2 et Oberon, mais l'organisme qui gère la standardisation du langage C++ est monopolisé par les intégristes tout aussi bornés les uns que les autres. On préfère rajouter des bizarreries comme la possiblité d'utiliser l'opérateur sizeof() sans les parenthèses quand il est appliqué à une variable, ce qui ne fait que rendre le langage encore plus m......que qu'autre chose, au lieu de reprendre les mécanismes des autres langages qui pourraient rendre le C++ bien plus clean et plus productif.
    http://www.pocketmt.com GLCD Font Creator home site.

  12. #12
    En attente de confirmation mail

    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Août 2004
    Messages
    1 391
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France, Doubs (Franche Comté)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Août 2004
    Messages : 1 391
    Points : 3 311
    Points
    3 311
    Par défaut
    Citation Envoyé par octal Voir le message
    la solution radicale au problème des includes a déjà été proposée à maintes reprise par Apple et ça n'a jamais été retenu (http://llvm.org/devmtg/2012-11/Gregor-Modules.pdf). Il s'agit de l'utilisation des "module". Le mécanisme date des années où un certain Monsieur Wirth a proposé le mécanisme de module dans Modula-2 puis Oberon. Il ne s'agit pas d'utiliser le binaire, il s'agit tout simplement de charger et analyser le module une seule fois, et d'avoir un référentiel de modules chargés. Chaque nouvelle inclusion ne fera que référencer le module en question (donc plus d'analyse redondante et plus de recompilation). Cela marche très bien pour Modula-2 et Oberon, mais l'organisme qui gère la standardisation du langage C++ est monopolisé par les intégristes tout aussi bornés les uns que les autres. On préfère rajouter des bizarreries comme la possiblité d'utiliser l'opérateur sizeof() sans les parenthèses quand il est appliqué à une variable, ce qui ne fait que rendre le langage encore plus m......que qu'autre chose, au lieu de reprendre les mécanismes des autres langages qui pourraient rendre le C++ bien plus clean et plus productif.
    Il ne faut pas dire tout et n'importe quoi ... L'idée des modules est bien retenu par le comité de standardisation, d'où la mise en place d'un groupe de travail sur cette thématique. Le comité sait regarder vers les autres quand il s'agit de fournir de nouvelles fonctionnalités, les lambdas en sont un bel exemple. De plus entre permettre une grammaire de plus pour un opérateur déjà existant et intégrer une nouvelle fonctionnalité, il y a un monde, la comparaison module/sizeof me semble totalement hors sujet. (voir message suivant de gl)

    Edit: Edition pour renvoyer au message de gl.

  13. #13
    gl
    gl est déconnecté
    Rédacteur

    Homme Profil pro
    Inscrit en
    Juin 2002
    Messages
    2 165
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : France, Isère (Rhône Alpes)

    Informations forums :
    Inscription : Juin 2002
    Messages : 2 165
    Points : 4 637
    Points
    4 637
    Par défaut
    Citation Envoyé par Flob90 Voir le message
    De plus entre permettre une grammaire de plus pour un opérateur déjà existant et intégrer une nouvelle fonctionnalité, il y a un monde, la comparaison module/sizeof me semble totalement hors sujet.
    D'autant que "le sizeof sans parenthèse" n'est pas une nouvelle syntaxe mais un comportement historique hérité du C (et plutôt logique vu qu'il s'agit d'un opérateur et qu'il s'utilise ainsi comme tous les autres opérateurs - dont return -). Bref, il n'y a pas eu de travail du comité la-dessus.

  14. #14
    Membre chevronné
    Avatar de lilington
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Juin 2005
    Messages
    681
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : Chine

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Juin 2005
    Messages : 681
    Points : 1 800
    Points
    1 800
    Par défaut
    Bonjour,
    excusez moi mais je comprend pas trop le probleme, que reproche t-on au juste au #include?
    je fais pas de C++ seulement du C. mais j'ai deja entendu des gens dire qu'il ne supportait pas le C juste a cause de ca sans vraiment m'avoir fait comprendre le probleme.

    Merci de m'eclairer un peu.
    Petit lien vers mon premier jeux SDL2/C
    http://store.steampowered.com/app/72..._Soul_Of_Mask/
    la suite? ca vient,ca vient!

  15. #15
    Rédacteur/Modérateur
    Avatar de JolyLoic
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Août 2004
    Messages
    5 463
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 49
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Août 2004
    Messages : 5 463
    Points : 16 213
    Points
    16 213
    Par défaut
    On reproche globalement 3 choses au #include :
    - C'est compliqué à enseigner (cette histoire d'inclusion textuelle de déclaration pour avoir moyen de se linker avec les définitions n'est pas si simple)
    - Ce n'est pas composable : Il n'est pas possible de dire : "voilà une description de l'interface de ma bibliothèque, utilise là sans soucis", car suivant l'ordre d'inclusion, une macro dans un header peut, volontairement ou pas, déteindre sur un autre header. Exemple concret : Windows a défini tout un tas de macro pour que ses fonctions manipulant des chaînes existe en 2 versions, une finissant par A, une par W, et qu'on bascule de manière transparente de l'une à l'autre selon des options de compilation. J'avais une classe avec une fonction membre nommée par exemple Toto, mais ce nom correspondait à une fonction de l'API windows, et donc si j'incluais <windows.h> avant mon code, une macro faisait que ma fonction était silencieusement renommée TotoW. Si j'incluais directement ma classe, elle s'appelait bien Toto. Et donc, ce qui pour moi n'était qu'une fonction était en fait un truc schizophrène, qui ne marchait pas au moment du link.
    - Ce n'est pas efficace (par exemple, si 50 fichiers de code source #incluent <windows.h>, qui récursivement fait plusieurs centaines de milliers de lignes, et bien le compilateur va devoir analyser 50 fois ces centaines de millier de lignes). Et ce n'est pas possible de totalement rationaliser ça, en ne les ayant analysées qu'une seule fois et en réutilisant le résultat, car la manière d'analyser ces lignes dépend de tous les headers qui ont été inclus auparavant (on ne sais jamais, si une macro modifiait le sens d'un identifieur).

    Les modules ont pour objectif de définir une frontière où les macros ne se propagent pas (les détails restent à définir), afin de permettre une définition plus clair et moins corruptible de l'interface, tout en améliorant les possibilités d'optimisation des compilateurs.
    Ma session aux Microsoft TechDays 2013 : Développer en natif avec C++11.
    Celle des Microsoft TechDays 2014 : Bonnes pratiques pour apprivoiser le C++11 avec Visual C++
    Et celle des Microsoft TechDays 2015 : Visual C++ 2015 : voyage à la découverte d'un nouveau monde
    Je donne des formations au C++ en entreprise, n'hésitez pas à me contacter.

  16. #16
    Membre chevronné
    Avatar de lilington
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Juin 2005
    Messages
    681
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : Chine

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Juin 2005
    Messages : 681
    Points : 1 800
    Points
    1 800
    Par défaut
    Merci pour la reponse.
    sinon un peu HS pour le C il y a t'il aussi un debat du genre?
    Petit lien vers mon premier jeux SDL2/C
    http://store.steampowered.com/app/72..._Soul_Of_Mask/
    la suite? ca vient,ca vient!

  17. #17
    Expert éminent sénior
    Avatar de Luc Hermitte
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Août 2003
    Messages
    5 279
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Août 2003
    Messages : 5 279
    Points : 11 011
    Points
    11 011
    Par défaut
    Il n'y a pas de telles discussions pour le C à ma connaissance.
    Mais je ne serais pas surpris que si les modules intègrent le C++, le C pourra en profiter indirectement via les compilateurs qui sont relativement agnostiques sur ces sujets. Une fois le boulot fait pour le C++, au pire le C pourra le supporter avec une syntaxe qui lui sera propre (cf ce qui a été fait pour la atomics ou d'autres petites choses qui sont arrivées dans le C11 depuis le C++)
    Blog|FAQ C++|FAQ fclc++|FAQ Comeau|FAQ C++lite|FAQ BS|Bons livres sur le C++
    Les MP ne sont pas une hotline. Je ne réponds à aucune question technique par le biais de ce média. Et de toutes façons, ma BAL sur dvpz est pleine...

  18. #18
    Membre chevronné
    Avatar de lilington
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Juin 2005
    Messages
    681
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : Chine

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Juin 2005
    Messages : 681
    Points : 1 800
    Points
    1 800
    Par défaut
    Merci merci, c'est bien tout ca, personnellement les seuls ennuis que j'ai avec les includes pour l'instant c'est quand je gere mal extern et que j'ai des redefinitions de variables global c'est chiant.
    sinon ca serait une bonne chose de perdre les includes. j'espere que GCC fait partie des compilots dont tu parles (j'ai un doute pour gcc)
    Petit lien vers mon premier jeux SDL2/C
    http://store.steampowered.com/app/72..._Soul_Of_Mask/
    la suite? ca vient,ca vient!

Discussions similaires

  1. A 113 ans, elle doit tricher sur son âge pour s'inscrire sur Facebook
    Par Escapetiger dans le forum La taverne du Club : Humour et divers
    Réponses: 0
    Dernier message: 13/11/2014, 22h48
  2. [e-mailing] Doit-on utiliser son vrai nom de domaine
    Par OnTheRoad2014 dans le forum E-Mailing
    Réponses: 1
    Dernier message: 05/06/2014, 10h24
  3. Triangle qui doit tourner en son milieu
    Par info.si.2014 dans le forum Débuter
    Réponses: 8
    Dernier message: 04/03/2014, 23h44
  4. utilisateur ne doit voir que son schema
    Par stawen dans le forum Administration
    Réponses: 2
    Dernier message: 25/11/2009, 14h22
  5. Réponses: 5
    Dernier message: 17/11/2009, 23h59

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo