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

Contribuez C++ Discussion :

[futur] L'après C++11


Sujet :

Contribuez C++

  1. #1
    Membre émérite

    Inscrit en
    mai 2008
    Messages
    1 014
    Détails du profil
    Informations forums :
    Inscription : mai 2008
    Messages : 1 014
    Points : 2 252
    Points
    2 252
    Par défaut [futur] L'après C++11
    L'après C++11 : Quels sont les features ou lib que vous souhaiteriez dans la future norme ?
    le premier document des propositions publié

    Le comité C++ vient de publier son premier mailing post-C++11 !

    Du coup, on sent bien que tous les features et lib qui avaient été mis de coté depuis quelques années pour se concentrer sur le C++11 refont surface et on a droit à une déferlante de papier tous plus foufou les uns que les autres !

    En vrac :

    concepts, module, filesystem, range, date, coroutine, mémoire transactionnelle, string_ref, Fixed-point arithmetic, digit seperator, concurrent queue, stream mutex !

    Et pour le spectaculaire :
    static_if : W. Bright (Concepteur du D) et A. Alexandrescu (grand promoteur du D) reviennent faire un tour en terre cplusplussienne et nous proposent une construction issue du D !!
    Rich_pointer : Permet de l'introspection/reflection au runtime via un smart pointer étrange.

    Bon, je suppose que les 3/4 de ces propositions n'auront aucune chance de finir dans le standard, mais ce petit vent de folie sur la planète C++ est assez plaisant.
    Et vous ? Quels sont les features ou lib que vous souhaiteriez absolument avoir pour C++1x ( C++2x ) ?

  2. #2
    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 : 31
    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
    Pour les avoir testé avec boost, le concept de range serait vraiment une bonne chose à intégrer à la STL, à première vue ca ressemble juste à une paire d'itérateur, mais à l'utilisation c'est vraiment plaisant.

    string_ref/array_ref, j'ai regardé en diagonale le papier, ca à l'air sympa, mais j'y crois pas trop pour être dans le prochain standard. Et l'idée des rich pointer me semble vraiment farfelus (c'est un ajout à la syntaxe du langague qui me semble un peu surfait).

    static_if est surment une bonne idée, même si sur le fond ce n'est (à première vue, il y a peut-être des subtilités que je n'ai pas vu) que du sucre syntaxique. Mais si la complexité de mise en place est faible et que ca ne coûte pas grand chose niveau perf, ca peut être un ajout ayant quelques utilités.

    Il y a aussi un papier concernant l'adaptation de la STL (IO/string) pour la gestion Unicode qui serait intéressant, comme filesystem et date.

  3. #3
    Expert confirmé

    Homme Profil pro
    Développeur informatique
    Inscrit en
    septembre 2007
    Messages
    1 895
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    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 895
    Points : 4 545
    Points
    4 545
    Par défaut
    Le proposal qui me parait le plus intéressant, ce sont les resumable functions. Elles devraient aider à écrire du code async de manière relativement simple. Dans un registre similaire, la proposition qui permettrait l'écriture de code transactionnel pourrait, elle aussi, simplifier très nettement l'écriture de code concurrent - on sait tous que le code consurrent est difficile à écrire et encore plus difficile à maintenir.

    Un autre proposal digne d'intérêt selon moi, c'est le "Modules in C++", qui devrait - à terme - permettre l'écriture de modules largement indépendant des autres, et donc limiter très nettement les temps de compilation (imaginez que les headers de la C++SL soient accessibles via un module déjà pré-compilé. Le rêve, non ?)

    L'essai sur les implémentations possibles d'une classe std::date est aussi très largement intéressant (au niveau lecture). Au niveau de la solution préconisée, j'ai l'impression qu'il manque une certaine finesse. Personnellement, ma classe date serait un template prenant en types paramètres un date_storage, un date_storage_traits et un calendar_traits (au moins). Le papier tente trop (à mon goût) de forcer une implémentation spécifique (l'idée, par exemple, de forcer l'utilisation d'un calendrier grégorien proleptique est à mon sens une mauvaise idée. D'abord parce que mes objets std::date, je voudrais pouvoir les transformer en une autre représentation (calendrier julien, grégorien (invalide avant son instauration, ou dérivant sur le julien si nécessaire), voire chinois (puisque c'est le moment) ou musulman), ensuite parce que la culture de mon pays n'est pas nécessairement très occidentale, et que j'en ai peut-être pas grand chose à faire de ce calendrier grégorien proleptique).

    N3336 (Adapting Standard Library Strings and I/O to a Unicode World) est quelque chose qui me tiens à coeur. Aujourd'hui, devoir écrire ses propres routines de traitement/conversion des chaines unicode est quelque chose qui me dépasse un peu. Même remarque sur N3335 (Filesystem Library for C++11/TR2 (Revision 1)) ; ces deux proposals tentent de limiter les difficultés dans deux domaines importants : le portage et l'internationalisation.

    Enfin, le retour des concepts ne peut être qu'une bonne chose
    [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.

  4. #4
    Rédacteur/Modérateur
    Avatar de JolyLoic
    Homme Profil pro
    Développeur informatique
    Inscrit en
    août 2004
    Messages
    5 460
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    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 460
    Points : 16 192
    Points
    16 192
    Par défaut
    Pour moi, modules, modules et modules ! (mais à priori, vue la volonté de réduire le temps entre deux version, ça ne sera probablement dans le prochain standard, peut-être le suivant).

    Ensuite, concepts puis systèmes facilitant la métaprogrammation (je ne suis pas encore fixé sur ce que je pense des différentes propositions dans ce sens).
    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.

  5. #5
    Membre émérite
    Homme Profil pro
    Développeur informatique
    Inscrit en
    décembre 2008
    Messages
    831
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : décembre 2008
    Messages : 831
    Points : 2 619
    Points
    2 619
    Par défaut
    Je n'ai pas (encore) lu ces papiers, en tout cas, une chose me paraît assez évidente: presque tous les programmes manipulent des fichiers. Donc filesystem serait vraiment une grande aide.

    Pareil, la manipulation de date est très commune, et très infernale en C++. En fait, aussi infernale qu'en C, puisqu'il n'y a pas (a ma connaissance) de différences :'(
    J'aimerai qu'un jour, il n'y ait plus besoin d'apprendre une API différente de gestion des dates/heures à chaque fois que l'on tape dans un SGBD différent, notamment.

    Dernière chose, l'unicode, universellement encensé, est effectivement une faiblesse du C++. Je crois qu'il y a déjà les w_char & co, mais j'admets ne pas savoir comment tout ça marche. (en fait, je devrais plutôt admettre ne pas connaître grand choses des fonctionnalités avancées du C++, il faudrait vraiment que je trouve une sorte de "cheatsheet" à ce sujet un jour, qui les décrive brièvement... Ca me serait d'une grande aide pour améliorer ma connaissance de ce langage!)

    Ce sont surtout des modifications qui impacteraient la bibliothèque, mais qui manquent cruellement, à mon humble avis.
    Ce sont aussi des modifications qui amélioreraient l'une des forces du C++: la portabilité de ce langage. (L'internationalisation est, somme toute, une forme de portabilité)

    Static_if, dis comme ça, je vois pas? Un if vérifié à la compilation? Comme #if non?
    Mais c'est sûr que le système de précompilation gagnerait à être enrichi, les templates pourraient gagner en puissance encore plus si on pouvait générer du code vraiment dynamiquement à la compilation.

    Les autres trucs, de base, je vois pas trop à quoi ça se rapporte, faudra que j'aille lire les papiers...

    [edit]
    Et pour la C++SL, il y a au moins la STL qui ne pourra pas rejoindre les modules, si je comprend pas tout de travers, vu que l'implémentation est générée à la compilation
    Et la STL est une grosse part de la SL j'ai l'impression...

    Et il y à une volonté de réduire le temps entre deux standards? Ce serait une excellente chose. Quelqu'un a un lien à lire à ce sujet, svp?

  6. #6
    Membre émérite
    Profil pro
    Inscrit en
    novembre 2004
    Messages
    2 750
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : novembre 2004
    Messages : 2 750
    Points : 2 660
    Points
    2 660
    Par défaut
    Citation Envoyé par Freem Voir le message
    Dernière chose, l'unicode, universellement encensé, est effectivement une faiblesse du C++. Je crois qu'il y a déjà les w_char & co, mais j'admets ne pas savoir comment tout ça marche. (en fait, je devrais plutôt admettre ne pas connaître grand choses des fonctionnalités avancées du C++, il faudrait vraiment que je trouve une sorte de "cheatsheet" à ce sujet un jour, qui les décrive brièvement... Ca me serait d'une grande aide pour améliorer ma connaissance de ce langage!)
    Il y a semble-t-il une référence sur ces sujets, mais je en connais pas ce bouquin.

  7. #7
    Membre émérite
    Homme Profil pro
    Développeur informatique
    Inscrit en
    décembre 2008
    Messages
    831
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : décembre 2008
    Messages : 831
    Points : 2 619
    Points
    2 619
    Par défaut
    Citation Envoyé par oodini Voir le message
    Il y a semble-t-il une référence sur ces sujets, mais je en connais pas ce bouquin.
    Il a l'air intéressant sur le papier (si j'ose dire) mais... Il date de l'an 2000 je ne savais même pas programmer à cette époque xD
    Pour le coup, il a 2 standards C++ de retard, si je ne me plante pas: 2003 et 2011... (bon, il semble que 2003 soit une 'simple' correction de 1999, mais quand même, C++ et ses pratiques ont dû évoluer depuis j'espère?)

    Et mon commentaire sur la "cheatsheet" concerne en fait le C++ de manière générale. J'ai bien l'impression que ma connaissance des possibilités de ce langage est quasi-nulle, alors qu'il s'agit de mon langage préféré et sûrement celui que je connaît le mieux! Pour le coup j'ai un peu honte quand même... Mais je me dis que c'est peut-être l'un des plus complets en terme de possibilités, histoire de pas trop pourrir mon égo

  8. #8
    Rédacteur/Modérateur
    Avatar de JolyLoic
    Homme Profil pro
    Développeur informatique
    Inscrit en
    août 2004
    Messages
    5 460
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    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 460
    Points : 16 192
    Points
    16 192
    Par défaut
    Citation Envoyé par Freem Voir le message
    [edit]
    Et pour la C++SL, il y a au moins la STL qui ne pourra pas rejoindre les modules, si je comprend pas tout de travers, vu que l'implémentation est générée à la compilation
    Et la STL est une grosse part de la SL j'ai l'impression...
    Les modules n'empêcheraient pas les templates, le but n'est pas de mimer les bibliothèques dynamiques (mêmes s'ils peuvent servir de base pour des bibliothèques dynamiques), mais plus de modifier la chaîne de compilation pour avoir quelques frontières bien isolées qui permettent de raisonner sur des bouts de code sans être pollués par d'autres bouts, et donc d'assembler un programme de manière plus simple. Accessoirement, mais c'est un accessoire crucial, cette séparation permettrait de pré-compiler plein de choses, et donc d'accélérer drastiquement le temps de compilation.

    Citation Envoyé par Freem Voir le message
    Et il y à une volonté de réduire le temps entre deux standards? Ce serait une excellente chose. Quelqu'un a un lien à lire à ce sujet, svp?
    Pas de lien, non, juste des mails sur les mailing lists du comité. Mais ce sera assurément discuté lors de cette réunion. Le consensus actuel semble être autour de quelques modifications simples pour la prochaine version, et en parallèle on commence à travailler sur celle d'après, de manière à pouvoir y introduire des modification de plus grosse envergure.
    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.

  9. #9
    Membre émérite
    Profil pro
    Inscrit en
    novembre 2004
    Messages
    2 750
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : novembre 2004
    Messages : 2 750
    Points : 2 660
    Points
    2 660
    Par défaut
    Citation Envoyé par Freem Voir le message
    Il a l'air intéressant sur le papier (si j'ose dire) mais... Il date de l'an 2000 je ne savais même pas programmer à cette époque xD
    Pour le coup, il a 2 standards C++ de retard, si je ne me plante pas: 2003 et 2011... (bon, il semble que 2003 soit une 'simple' correction de 1999, mais quand même, C++ et ses pratiques ont dû évoluer depuis j'espère?):
    Le bouquin de référence sur la STL date de 1999 (même s'il y a eu quelques mises à jour depuis,), celui sur les templates de 2002, celui d'Alexandrescu de 2001...

  10. #10
    Membre expert
    Avatar de Klaim
    Homme Profil pro
    Développeur de jeux vidéo
    Inscrit en
    août 2004
    Messages
    1 717
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    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 290
    Points
    3 290
    Par défaut
    Si ils pouvaient se concentrer sur les modules et les concepts et faire une version rapidement, ça serait mieu que de les repousser... mais bon ya plein de paramettres en jeux aussi.

  11. #11
    Membre émérite

    Inscrit en
    mai 2008
    Messages
    1 014
    Détails du profil
    Informations forums :
    Inscription : mai 2008
    Messages : 1 014
    Points : 2 252
    Points
    2 252
    Par défaut
    Pour ma part, je ne demande pas grand chose, si le comité pouvait sortir une release intermédiaire contenant uniquement filesystem et module, alors je serais parfaitement heureux.

    Du coup ça m'attriste de lire :
    Citation Envoyé par JolyLoic
    (mais à priori, vue la volonté de réduire le temps entre deux version, [les modules] ne seront probablement pas dans le prochain standard, peut-être le suivant).
    Pas le prochain mais le suivant... il faut tabler sur quoi 10 ans ? 15 ans ?

    Citation Envoyé par Emmanuel Deloget
    "Modules in C++", qui devrait - à terme - permettre l'écriture de modules largement indépendant des autres
    Pour info, de ce que j'ai pu voir des commits récents sur clang, Douglas Gregor travaille à toute vapeur depuis environ deux mois pour implémenter les modules dans clang. Et vu que c'est un génie doublé d'un bourreau de travail on devrait pouvoir commencer à tester les modules d'ici peu.

  12. #12
    Membre régulier
    Homme Profil pro
    Dev C/C++
    Inscrit en
    octobre 2011
    Messages
    19
    Détails du profil
    Informations personnelles :
    Sexe : Homme

    Informations professionnelles :
    Activité : Dev C/C++

    Informations forums :
    Inscription : octobre 2011
    Messages : 19
    Points : 90
    Points
    90
    Par défaut
    Les date (en fait la gestion du temps en standard serais pas mal, coté boost on a chrono qui a reussi a faire quelque chose de pratique).
    L'unicode, parce que de toute façon c'est l'avenir.
    Le static_if (sucre syntaxique certe), qui permet de faire un jolie chose avec constexp.
    Les concept pour debug facilement la metaprog.
    J'aimerais bien voir des implémentation standard de pool et d'allocator (je pense a boost object_pool et pool_allocator), c'est quelque chose qui est absolument nécessaire pour faire du code propre et pourtant il n'y a rien dans la stl.

  13. #13
    Membre expert
    Avatar de Klaim
    Homme Profil pro
    Développeur de jeux vidéo
    Inscrit en
    août 2004
    Messages
    1 717
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    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 290
    Points
    3 290
    Par défaut
    *prie pour que les modules arrivent rapidement*

    J'ai dit aussi concepts parceque visiblement ça peut aussi aider à réduire les temps de compilation si on utilise bien les axiomes.

    Sinon je viens de parcourir la proposition du Rich pointer, effectivement c'est ... osé. Ce que je ne comprends pas c'est pourquoi c'est un pointeur et pas par exemple une décoration de déclaration de classe

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    reflect class MaClass  { ...}
    Mais bon j'ai pas encore tout lu...

  14. #14
    Membre expert Avatar de air-dex
    Homme Profil pro
    Inscrit en
    août 2010
    Messages
    1 630
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France

    Informations forums :
    Inscription : août 2010
    Messages : 1 630
    Points : 3 685
    Points
    3 685
    Par défaut
    Pour ma part, ça sera deux choses sur les templates :
    template <typename T>
    • Conversion implicite entre T et const T. Mais cette feature doit plus dépendre des compilateurs. Qui ne s'est jamais arraché les cheveux dessus ?
    • Dans le cas où T est une classe, pouvoir apporter des informations sur T comme en Java avec des trucs du style <T : public UneClasse> pour dire que la classe "UneClasse" hérite de la classse template ou <UneClasse : public T> si c'est le paramètre template qui hérite de "UneClasse".
    "Ils ne savaient pas que c'était impossible alors ils l'ont fait." Mark Twain

    Mon client Twitter Qt cross-platform Windows et Linux. (en cours de développement).

  15. #15
    Membre émérite
    Homme Profil pro
    Développeur informatique
    Inscrit en
    décembre 2008
    Messages
    831
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : décembre 2008
    Messages : 831
    Points : 2 619
    Points
    2 619
    Par défaut
    Citation Envoyé par JolyLoic Voir le message
    Les modules n'empêcheraient pas les templates, le but n'est pas de mimer les bibliothèques dynamiques (mêmes s'ils peuvent servir de base pour des bibliothèques dynamiques), mais plus de modifier la chaîne de compilation pour avoir quelques frontières bien isolées qui permettent de raisonner sur des bouts de code sans être pollués par d'autres bouts, et donc d'assembler un programme de manière plus simple. Accessoirement, mais c'est un accessoire crucial, cette séparation permettrait de pré-compiler plein de choses, et donc d'accélérer drastiquement le temps de compilation.


    Pas de lien, non, juste des mails sur les mailing lists du comité. Mais ce sera assurément discuté lors de cette réunion. Le consensus actuel semble être autour de quelques modifications simples pour la prochaine version, et en parallèle on commence à travailler sur celle d'après, de manière à pouvoir y introduire des modification de plus grosse envergure.
    Le souci de la STL, c'est que, dans une certaine mesure, on ne peut pas vraiment séparer l'implémentation du template lui-même je dirai. Ou dans une faible mesure seulement...

    (Je ne cherche pas juste à contredire, juste à comprendre ce que vous entendez par modules... J'ai l'impression de rater un train la xD)

    @air-dex:
    Plutôt le contraire non?
    Sinon, je pense que tu peux déjà vérifier à la compilation qu'un paramètre template hérite d'une classe en utilisant typeinfo et quelques directives de précomp pour éviter de polluer le code release... Ca resterai du bricolage par contre, et je suis même pas sûr que ça marche puisque jamais essayé... (je tenterai ce soir tiens c'est une bonne question)

  16. #16
    Expert éminent

    Inscrit en
    novembre 2005
    Messages
    5 145
    Détails du profil
    Informations forums :
    Inscription : novembre 2005
    Messages : 5 145
    Points : 6 863
    Points
    6 863
    Par défaut
    Citation Envoyé par Arzar Voir le message
    Pas le prochain mais le suivant... il faut tabler sur quoi 10 ans ? 15 ans ?
    Pour le moment il n'y a pas de plan, juste des idees de plan plus ou moins bien formulees.

    Pour info, de ce que j'ai pu voir des commits récents sur clang, Douglas Gregor travaille à toute vapeur depuis environ deux mois pour implémenter les modules dans clang. Et vu que c'est un génie doublé d'un bourreau de travail on devrait pouvoir commencer à tester les modules d'ici peu.
    J'espere que ca ne va pas finir comme les concepts.

    Citation Envoyé par Freem Voir le message
    (Je ne cherche pas juste à contredire, juste à comprendre ce que vous entendez par modules... J'ai l'impression de rater un train la xD)
    La proposition de David VdV (je n'ai aucune idee de ce que DG fait) est une notion purement front-end. En gros des .h automatiquement generes et dont l'inclusion aurait un effet garanti independant de ce qui a ete inclu avant. Oui, on pourrait y mettre les definitions des templates sans problemes (et en tout cas sans une serie de problemes qu'export avait a regler, David VdV etant celui qui a implemente export, il les connait bien).
    Les MP ne sont pas là pour les questions techniques, les forums sont là pour ça.

  17. #17
    Membre expert
    Avatar de Klaim
    Homme Profil pro
    Développeur de jeux vidéo
    Inscrit en
    août 2004
    Messages
    1 717
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    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 290
    Points
    3 290
    Par défaut
    Bon j'ai fini de lire la nouvelle version de la proposition des Modules.

    C'est plus clair que la précédente, mais j'ai deux remarques :

    1. La syntaxe proposée pour les fichiers interface me semble inutilement difficile à lire. Je ne comprends pas bien pourquoi il faut que les noms aient des numéros pour les rendre uniques, ils ne sont pas censés être uniques de toutes façon? Le module est répété dans le fichier donc je ne vois pas pourquoi c'est nécessaire.

    2. Je préférerai de loin qu'un module ne compile pas si on a une fonction publique qui retourne un objet d'un type privé plutot que de rendre ce type publique. De cette manière celui qui implémente le module doit savoir et définir clairement ce qui est publique et ce qui ne l'est pas. Si il déclare une fonction qui retourne un type privé, il doit être notifié de ce qu'il fait, et pas juste avec un warning...

    Sinon vivement qu'on ai les modules!

  18. #18
    Expert éminent

    Inscrit en
    novembre 2005
    Messages
    5 145
    Détails du profil
    Informations forums :
    Inscription : novembre 2005
    Messages : 5 145
    Points : 6 863
    Points
    6 863
    Par défaut
    Citation Envoyé par Klaim Voir le message
    1. La syntaxe proposée pour les fichiers interface me semble inutilement difficile à lire. Je ne comprends pas bien pourquoi il faut que les noms aient des numéros pour les rendre uniques, ils ne sont pas censés être uniques de toutes façon? Le module est répété dans le fichier donc je ne vois pas pourquoi c'est nécessaire.
    Le fichier interface est généré à partir du module, et a pour consommateurs prévus les compilateurs qui compilent qqch important le module et des outils divers. L'ajout de numéro permets à ces derniers de pouvoir faire qqch sans devoir implémenter la résolution des noms.

    2. Je préférerai de loin qu'un module ne compile pas si on a une fonction publique qui retourne un objet d'un type privé plutot que de rendre ce type publique. De cette manière celui qui implémente le module doit savoir et définir clairement ce qui est publique et ce qui ne l'est pas. Si il déclare une fonction qui retourne un type privé, il doit être notifié de ce qu'il fait, et pas juste avec un warning...
    Ça ne change pas du comportement qu'on a actuellement avec des classes imbriquées privées.
    Les MP ne sont pas là pour les questions techniques, les forums sont là pour ça.

  19. #19
    Membre expert
    Avatar de Klaim
    Homme Profil pro
    Développeur de jeux vidéo
    Inscrit en
    août 2004
    Messages
    1 717
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    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 290
    Points
    3 290
    Par défaut
    Citation Envoyé par Jean-Marc.Bourguet Voir le message
    Le fichier interface est généré à partir du module, et a pour consommateurs prévus les compilateurs qui compilent qqch important le module et des outils divers. L'ajout de numéro permets à ces derniers de pouvoir faire qqch sans devoir implémenter la résolution des noms.
    Donc, que se passe-t-il pour l'utilisateur d'une bibliothèque, qui n'a qu'un fichier d'interface et un binaire, et qui n'a pas accès à un IDE? (comme moi dans mon boulot actuel)

    Pour connaitre l'interface (du code) il doit soit lire le fichier un peu cryptique d'interface qu'il a, soit lire une doc externe (qui n'est pas forcément fournie).

    Soit avoir des headers...


    Donc, si le fichier d'interface pouvait être lisible directement, ça serait plus pratique...

    ...et je vois pas bien le problème avec le compilateur, il va de toutes façon faire une représentation intermédiaire optimizée séparée de ce fichier...

    Ça ne change pas du comportement qu'on a actuellement avec des classes imbriquées privées.
    Oui mais ça change du comportement des types non définis retournés par des fonctions. Là tout ce qui est privé est censé être non-définis, donc une erreur dans ce genre de cas éviterai beaucoup de potentielles "fuites d'accès"...

  20. #20
    Membre éprouvé

    Profil pro
    Inscrit en
    décembre 2008
    Messages
    533
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : décembre 2008
    Messages : 533
    Points : 1 086
    Points
    1 086
    Par défaut
    Si filesystem et date pouvaient être présents, ce serait déjà bien. La STL ressemblerait enfin à quelque chose ; on pourrait enfin croiser un dev Java sans baisser les yeux.


    Citation Envoyé par air-dex Voir le message
    Tout ça doit bien pouvoir se résoudre avec les type_traits de C++11, non ?
    std::remove_const<T> pour le premier point et std::is_base_of<B,D> pour le reste ?

Discussions similaires

  1. Réponses: 30
    Dernier message: 29/01/2019, 17h08
  2. Réponses: 12
    Dernier message: 20/05/2010, 11h27
  3. Réponses: 60
    Dernier message: 15/01/2010, 16h28
  4. Réponses: 46
    Dernier message: 29/07/2009, 03h43
  5. action APRES chargement complet ...
    Par PinGuy dans le forum Delphi
    Réponses: 7
    Dernier message: 06/07/2006, 18h16

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