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

Normalisation C++ Discussion :

Rencontre avec le comité C++ : posez vos questions !


Sujet :

Normalisation C++

  1. #1
    Expert éminent sénior

    Homme Profil pro
    pdg
    Inscrit en
    Juin 2003
    Messages
    5 752
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : pdg

    Informations forums :
    Inscription : Juin 2003
    Messages : 5 752
    Points : 10 682
    Points
    10 682
    Billets dans le blog
    3
    Par défaut Rencontre avec le comité C++ : posez vos questions !
    Bonjour à tous!

    Dans 10 jours (du 19 au 24), aura lieu une rencontre du comité de normalisation, ce qui est une étape importante vers la prochaine norme (C++17). Chose intéressante, cela se passe quasiment 30 ans, jour pour jour, après la mise sur le marché du premier compilateur C++!

    A cette occasion, je vais participer à ce meeting en tant que simple spectateur. Mon but est de suivre l'avancement des travaux et réaliser des interviews (video!) de membres du comité. L'idée est de célébrer 30 ans de travail d'une part, et améliorer les échanges entre le comité et la communauté, c'est-à-dire vous et moi!

    Et je vous propose de partager ici vos questions à propos du C++ : quelles questions aimeriez-vous poser au comité ? Quels sujets aimeriez-vous voir être abordés ?

    A ce jour j'ai prévu de faire de mon mieux pour obtenir des détails sur :

    • le processus de normalisation ISO : pourquoi faire ? Comment ça fonctionne ? Comment participer ?
    • les travaux en cours, tant au niveau de C++17, qu'au niveau des différents Study Groups, en particulier:
      • Concurrency and parallelism ;
      • Modules (remplacement des hearders!);
      • File System ;
      • Networking (ASIO) ;
      • Compile-time reflection ;
      • Concepts ;
      • STL Ranges ;
      • Database-related library interfaces ;
      • Undefined and Unspecified Behavior (simplification du langage) ;
      • Travaux sur un lib graphique 2D.
    • une ABI standardisée
    • la simplification du langage via la dépréciation de fonctionalités


    J'espère aussi pouvoir échanger autour des travaux en cours sur le développement de guidelines "officielles" et autres efforts qui vont dans ce sens. Et je compte partager mon sentiment qu'une meilleure présentation et exposition des travaux du comité est nécessaire, afin que les non experts puissent se faire une idée de ce qui se passe.

    Enfin, et c'est pas rien : je souhaite mettre des visages sur ces hommes et femmes qui font évoluer le langage, et recueillir leur vision sur cette aventure qui dure depuis plus de 30 ans !

    Et vous ?

    Qu'est-ce qui vous intéresse en particulier ?

  2. #2
    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 015
    Points
    11 015
    Par défaut
    Bonne initiative.
    Pas vraiment des questions. Mais je suis fort intéressé par le support de la PpC. Et pas juste à coup d'asserts, même si c'est déjà un début. Ce que j'avais vu passer au sujet d'un éventuel support par le compilateur était alléchant. Dans les personnes impliquées, il y a Gaby, John Lakos.et quelques autres. Si j'ai bien suivi une conf de Gaby lors de la CppCon2015 devait traiter le sujet, mais la video n'est pas encore sortie, ni les slides.

    Après, j'imagine que ce n'est pas l'endroit pour des questions mineures comme à quand un <stringfwd> ? (NB: je n'ai pas regardé si entre temps c'était dans le C++17, vu qu'il y a déjà des surprises comme std::size())
    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...

  3. #3
    Membre régulier
    Inscrit en
    Décembre 2007
    Messages
    59
    Détails du profil
    Informations forums :
    Inscription : Décembre 2007
    Messages : 59
    Points : 95
    Points
    95
    Par défaut
    Un static if est il prévu pour la métaprogrammation ?

  4. #4
    Membre émérite
    Profil pro
    retraité
    Inscrit en
    Décembre 2010
    Messages
    814
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : retraité

    Informations forums :
    Inscription : Décembre 2010
    Messages : 814
    Points : 2 334
    Points
    2 334
    Par défaut
    Citation Envoyé par Luc Hermitte Voir le message
    Bonne initiative.
    Pas vraiment des questions. Mais je suis fort intéressé par le support de la PpC. Et pas juste à coup d'asserts, même si c'est déjà un début. Ce que j'avais vu passer au sujet d'un éventuel support par le compilateur était alléchant. Dans les personnes impliquées, il y a Gaby, John Lakos.et quelques autres. Si j'ai bien suivi une conf de Gaby lors de la CppCon2015 devait traiter le sujet, mais la video n'est pas encore sortie, ni les slides.

    Après, j'imagine que ce n'est pas l'endroit pour des questions mineures comme à quand un <stringfwd> ? (NB: je n'ai pas regardé si entre temps c'était dans le C++17, vu qu'il y a déjà des surprises comme std::size())
    PpC c'est quoi ? Merci

  5. #5
    Membre chevronné Avatar de Ehonn
    Homme Profil pro
    Étudiant
    Inscrit en
    Février 2012
    Messages
    788
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Février 2012
    Messages : 788
    Points : 2 160
    Points
    2 160
    Par défaut
    Programmation par Contrat (?)

  6. #6
    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
    C'est l'endroit pour toutes les questions, majeures comme mineures. Les questions majeures font l'objet de papiers spécifiques, les mineures entrent dans la catégorie "issue" comme par exemple http://www.open-std.org/jtc1/sc22/wg...wg-active.html, mais les deux sont discutées lors des réunions (même si sur certains sujets, des réunions spécifiques existent pour avancer le travail, ce n'est que lors des réunions officielles que les décisions sont prises).

    Maintenant, sur <stringfwd>, je ne suis pas certain que ce soit un point entièrement mineur. Il pose la question d'un <vectorfwd>, d'un <memoryfwd>, voire d'un <stdfwd> ainsi que le retour du <std> (globalement, tout le monde était d'accord d'avoir un header <std> avec les éléments essentiels de la bibliothèque, mais personne n'était d'accord quant à son contenu).

    Je me pose en particulier une question : Souvent, mes strings ne se retrouvent pas uniquement comme paramètres de fonction, mais aussi comme données membre. Du coup, je ne crois pas que j'aurais beaucoup d'utilités à un <stringfwd>, même si j'en avais un à ma disposition.
    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.

  7. #7
    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 Aurelien.Regat-Barrel Voir le message
    A cette occasion, je vais participer à ce meeting en tant que simple spectateur. Mon but est de suivre l'avancement des travaux et réaliser des interviews (video!) de membres du comité. L'idée est de célébrer 30 ans de travail d'une part, et améliorer les échanges entre le comité et la communauté, c'est-à-dire vous et moi!
    Pour information, il est interdit de filmer les discussions elles-mêmes, afin de préserver la liberté de parole de chacun pendant ces discussions. Maintenant réaliser des interviews à côté est toujours possible, mais les semaines de réunions sont généralement très chargées. As-tu déjà contacté des personnes pour leur demander s'ils acceptaient ? As-tu des noms en tête ?
    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.

  8. #8
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Septembre 2007
    Messages
    30
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2007
    Messages : 30
    Points : 31
    Points
    31
    Par défaut
    Lors de la cppcon 2014 (il me semble) il avait été mentionné (par Herb Sutter ou Stroustrup, je ne sais plus) la volonté d'impliquer plus les entreprises dans l'évolution de la bibliothèque standard, en particulier l'ajout de nouveaux domaines fonctionnels. Il me semblait avoir compris que l'objectif était de faire proposer des bibliothèques complètes par des entreprises pour normalisation, dans le but d'étendre plus rapidement la portée de la bibliothèque standard (ça, c'est pour le contexte de la question mais il faudra que je retrouve la source...).
    Ma question : qu'en est-il de cette initiative? Des propositions ont-elles vues le jour? La proposition de librairies "complètes" fait-elle partie du processus de standardisation?

  9. #9
    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 015
    Points
    11 015
    Par défaut
    Citation Envoyé par archqt Voir le message
    PpC c'est quoi ? Merci
    Oui. C'est bien la programmation par contrat. J'y ai consacré trois billets dans mon blog -- le dernier (des snippets essentiellement) a été accouché il y a peu.
    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...

  10. #10
    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 015
    Points
    11 015
    Par défaut
    Ensemble d'autres points mineurs auxquels je peux penser:
    - Un support prévu pour des named parameters ? (NB: il y a eu plein de feintes de type bibliothèque depuis le C++11)
    - stoi, stod, etc sont intéressants, mais pourquoi n'a-t-on pas vu un sto<T> ?
    - Qu'en est-il de std::is_contiguous ? (J'avais vu passer une proposition pour sa définition, mais plus rien depuis)
    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...

  11. #11
    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 015
    Points
    11 015
    Par défaut
    final, corrigez-moi si je me trompe, s'applique à tous les héritages.
    Pour les classes à sémantique de valeurs, il pourrait être extrêmement pertinent vu qu'elles se combinent très mal avec l'héritage public et le LSP d'une certaine façon. Tant au niveau sémantique, qu'au niveau syntaxico-technique (cf le slicing). Seulement, le C++ a cette étrange bête qu'est l'héritage privé : un héritage qui ne permet que d'importer du code, vu qu'il ne permet pas la substituabilité syntaxique. Un héritage qui nous permet, nous développeurs fainéants, de dériver une sorted_list d'une list sans encourir d'écrire des aberrations. Seulement voilà, alors qu'il serait intéressant de flagguer std::list comme finale, on ne peut pas le faire sans interdire "class sorted_list : /*private*/ list".

    Quid d'un final qui autoriserait l'héritage privé ?
    (Oui, des fois, j'ai des idées tordues.)
    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...

  12. #12
    Expert éminent sénior

    Homme Profil pro
    pdg
    Inscrit en
    Juin 2003
    Messages
    5 752
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : pdg

    Informations forums :
    Inscription : Juin 2003
    Messages : 5 752
    Points : 10 682
    Points
    10 682
    Billets dans le blog
    3
    Par défaut
    Bonjour !

    Citation Envoyé par Luc Hermitte Voir le message
    Bonne initiative.
    Pas vraiment des questions. Mais je suis fort intéressé par le support de la PpC. Et pas juste à coup d'asserts, même si c'est déjà un début.
    Ca me surprend pas de toi Ironiquement, je crois que les premières versions de C++ avaient un tel mécanisme (des fonctions membres appelées automatiquement pour valider les invariants), mais B. S. les a retiré car... il était le seul à les utiliser

    Citation Envoyé par alecool Voir le message
    Lors de la cppcon 2014 (il me semble) il avait été mentionné (par Herb Sutter ou Stroustrup, je ne sais plus) la volonté d'impliquer plus les entreprises dans l'évolution de la bibliothèque standard, en particulier l'ajout de nouveaux domaines fonctionnels. Il me semblait avoir compris que l'objectif était de faire proposer des bibliothèques complètes par des entreprises pour normalisation, dans le but d'étendre plus rapidement la portée de la bibliothèque standard (ça, c'est pour le contexte de la question mais il faudra que je retrouve la source...).
    Ma question : qu'en est-il de cette initiative? Des propositions ont-elles vues le jour? La proposition de librairies "complètes" fait-elle partie du processus de standardisation?
    Cela va tout à fait dans le sens des questions que je veux poser sur comment donner plus de possibilité à la communauté (et plus spécifiquement les entreprises) pour soutenir le langage sans avoir à s'impliquer dans un processus aussi lourd que l'ISO. J'ai ma propre idée à suggérer.

    Citation Envoyé par JolyLoic Voir le message
    Pour information, il est interdit de filmer les discussions elles-mêmes, afin de préserver la liberté de parole de chacun pendant ces discussions. Maintenant réaliser des interviews à côté est toujours possible, mais les semaines de réunions sont généralement très chargées. As-tu déjà contacté des personnes pour leur demander s'ils acceptaient ? As-tu des noms en tête ?
    je sais J'ai déjà assisté un à rencontre "informelle" en février à Cologne, où j'ai pu me roder, prendre des contacts et même faire 2 d'interview (pour me chauffer). Là j'ai un meilleur matos et suis mieux préparé... et je suis en contact avec pas mal de monde, à commencer par B. Stroustrup, H. Sutter, et d'autres moins connus. Car mon idée c'est aussi de montrer les "anonymes" qui sont derrière C++ (ils sont nombreux!)

    Citation Envoyé par Luc Hermitte Voir le message
    Ensemble d'autres points mineurs auxquels je peux penser:
    - Un support prévu pour des named parameters ? (NB: il y a eu plein de feintes de type bibliothèque depuis le C++11)
    - stoi, stod, etc sont intéressants, mais pourquoi n'a-t-on pas vu un sto<T> ?
    - Qu'en est-il de std::is_contiguous ? (J'avais vu passer une proposition pour sa définition, mais plus rien depuis)
    Les named parameters intéressent pas mal de monde semble-t-il, car c'est dans ma liste de questions recueillies sur un forum anglophone. Il semblerait que ça ait déjà été débattu et + ou - rejeté. Je vais essayé d'en savoir plus. Pour les autres points aussi précis, je vous promets rien... mais je vais voir !

    Citation Envoyé par Luc Hermitte Voir le message
    final, corrigez-moi si je me trompe, s'applique à tous les héritages.
    Pour les classes à sémantique de valeurs, il pourrait être extrêmement pertinent vu qu'elles se combinent très mal avec l'héritage public et le LSP d'une certaine façon. Tant au niveau sémantique, qu'au niveau syntaxico-technique (cf le slicing). Seulement, le C++ a cette étrange bête qu'est l'héritage privé : un héritage qui ne permet que d'importer du code, vu qu'il ne permet pas la substituabilité syntaxique. Un héritage qui nous permet, nous développeurs fainéants, de dériver une sorted_list d'une list sans encourir d'écrire des aberrations. Seulement voilà, alors qu'il serait intéressant de flagguer std::list comme finale, on ne peut pas le faire sans interdire "class sorted_list : /*private*/ list".

    Quid d'un final qui autoriserait l'héritage privé ?
    (Oui, des fois, j'ai des idées tordues.)
    Ben je crois que y'a un GOTW qui dit que ce genre d'héritage privé est à éviter au profit de la composition... On m'a suggéré aussi de demander la possibilité de facilement créer des décorateurs à la python, apparemment adapté à la fois à ce genre de chose mais aussi pour la PPC. Mais moi je connais pas assez python...

  13. #13
    r0d
    r0d est déconnecté
    Expert éminent

    Homme Profil pro
    Développeur informatique
    Inscrit en
    Août 2004
    Messages
    4 264
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Août 2004
    Messages : 4 264
    Points : 6 683
    Points
    6 683
    Billets dans le blog
    2
    Par défaut
    Bonjour,

    je ne suis plus vraiment l'actualité du C++ depuis C++11 donc je vais probabement dire une bêtise, mais qu'en est-il des conteneurs thread safe (list, vector, queue, ...)?
    Car j'ai vendu mon âme au diable et je pratique actuellement plus le C# que le C++, et j'avoue que les conteneurs thread safe du C# apportent un confort tout à fait acceptable pour un développeur fainéant de mon espèce.
    « L'effort par lequel toute chose tend à persévérer dans son être n'est rien de plus que l'essence actuelle de cette chose. »
    Spinoza — Éthique III, Proposition VII

  14. #14
    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 015
    Points
    11 015
    Par défaut
    Plus je réfléchis à la question, plus je me dis que la notion de conteneur thread safe ne tient pas la route car notre besoin sera toujours subtilement différent. Et que l'on ne veut certainement pas locker chaque accès en R ou W sur un conteneur -- la contention, c'est mal. Sans parler de la granularité (peut-on écrire v[0] pendant qu'on lit v[1] et v.back().). Et quid de l'ajout, des invalidations? C'est plutôt des mécanismes de synchronisation plus précis dont on a besoin -> patterns Objet Actif et Queues de Messages. D'ailleurs, l'implémentation de queue (de messages) en standard serait un plus (on en a vu fleurir plus d'une suite au C++11, dont par Anthony Williams), mais côté standardisation il me semble n'avoir rien vu.


    Pour en revenir à l'héritage privé, bien sûr que la composition offre plus de souplesse. Mais elle nécessite l'écriture de boiler plate code pour les cas où un couplage fort est tolérable (mon exemple de list et sorted_list n'était pas innocent). Ou alors, il nous faudrait des moyens pour faire de la délégation sans valeur ajoutée. Genre:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    template <typename T>
    class sorted_list final
    {
    public:
    ...
       using m_list.size() const; // ou m_list::size;
       using m_list.cbegin() const;
       using m_list.begin() const;
       ... 
       using m_list.empty() const;
    ...
    private:
       list<T> m_list;
    };
    EDIT:
    Bon, on pourrait imaginer ce genre de choses :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    #define DELEGATE_TO(fname, attribute)                          \
        auto fname() const noexcept(noexcept(attribute.fname())) { \
            return attribute.fname();                              \
        }
     
     
    template <typename T>
    class sorted_vector final
    {
    public:
        sorted_vector() = default;
        sorted_vector(std::initializer_list<T> init)
            : m_vector(init)
            {
                std::sort(m_vector.begin(),m_vector.end());
            }
     
        DELEGATE_TO(cbegin, m_vector);
        DELEGATE_TO(cend  , m_vector);
        DELEGATE_TO(begin , m_vector);
        DELEGATE_TO(end   , m_vector);
        DELEGATE_TO(size  , m_vector);
        DELEGATE_TO(empty , m_vector);
     
    private:
        std::vector<T> m_vector;
    };
    Mais bon. C'est tout pourri. Et cela ne gère pas la délégation de fonctions à paramètres -- sans rajouter des arguments à la macro, déléguez donc à m_vector.swap(), ou à m_vector[i]. Ou alors, il faut tout templatiser, ce qui n'est pas trop top pour les messages d'erreurs qui seront produits.
    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...

  15. #15
    Membre émérite
    Avatar de white_tentacle
    Profil pro
    Inscrit en
    Novembre 2008
    Messages
    1 505
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2008
    Messages : 1 505
    Points : 2 799
    Points
    2 799
    Par défaut
    Citation Envoyé par Luc Hermitte Voir le message
    Pour en revenir à l'héritage privé, bien sûr que la composition offre plus de souplesse. Mais elle nécessite l'écriture de boiler plate code pour les cas où un couplage fort est tolérable (mon exemple de list et sorted_list n'était pas innocent). Ou alors, il nous faudrait des moyens pour faire de la délégation sans valeur ajoutée. Genre:
    Eiffel a introduit la notion de « non-conforming inheritance ». On hérite de l’interface publique, mais on n’est pas substituable (ça évite par exemple le problème du destructeur virtuel). En ce qui me concerne, j’ai quelques cas où j’aurais une utilité pour ça (typiquement, classes paramétrable héritant de leur type paramétré pour y ajouter des comportements). C’est à ce genre de choses que tu penses toi aussi ?

    Sinon, comme toi, j’ai de grosses attentes sur la PpC, et les vérifications statiques qui vont avec. La présentation d’Herb Sutter donnait un très bon avant-goût, j’attends aussi celle de Gabriel Dos Reis.

  16. #16
    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 015
    Points
    11 015
    Par défaut
    Je ne connaissais pas (/avait oublié?) la notion de « non-conforming inheritance ». J'aime. Merci pour l'info.

    Sinon, oui on va retrouver le même genre d'idées même si mes cas d'utilisation sont plus dans la lignée de "la délégation marcherait aussi, mais je n'ai pas envie d'écrire du code inintéressant et facile à foirer".
    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...

  17. #17
    Futur Membre du Club
    Profil pro
    Inscrit en
    Janvier 2006
    Messages
    8
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Janvier 2006
    Messages : 8
    Points : 7
    Points
    7
    Par défaut
    Bonjour,
    C'est sans doute trop tard pour la question, mais comme beaucoup, j'aimerais voir apparaître des choses vraiment pratiques, plutôt que des abstractions hyper complexes.
    - Définir des types de variables standards:
    int16, int32, int64, int128 avec bien entendu, le pendant unsigned (au choix, byte, uchar, uint32, etc).
    Oui je sais, on peut les définir, mais cela passe par des méandres (assez) complexes, parceque les machines n'ont pas la même longueur de mot. Dans les codes sources, on se ramasse avec des stupidités genre "long long"..
    Pouquoi ne pas définir des types standards! J'aimerais aussi des grands nombres (entiers, flottants, réels).
    - De la même façon qu'on a eu: #include<stdio> et la série des printf(..) et autres scanf(..) etc. à l'époque où les ordis ne faisaient que du texte, il faudrait:
    #include<interface> permettant de gérer des fenêtres et des composants de base: case à cocher, etc.
    #include<graphics> permettant de faire des draw_rect(..) et autres line(..) etc. sur écran/fenêtres, et imprimante graphique.
    #include<networks> permettant de faire du réseau. Autres idées: support de utf8 etc.
    Les termes #include ne sont que des exemples; on pourrait avoir aussi "using graphics;" ou "uses" ou "module" ou autre plus approprié.

    Bien entendu, je ne dis pas qu'on ne peut pas déjà le faire avec C/C++, mais on doit passer par des bibliothèques/installs, et on devrait pouvoir le faire de base, à un certain niveau. Cela n'empêche pas le développeur d'utiliser autre chose s'il veut des outils plus performants/adaptés à son besoin. Le succès de java est dû en grosse partie au fait qu'il vient avec ce type de bibliothèque ou possibilité. Si C/C++ vient aussi avec cela, il y aura un nouvel engouement pour notre langage. Il faudrait que les autorités comprennent que les abstractions c'est bien, mais les développeurs sont encore plus intéressés par des nouveautés vraiment pratiques et qui les aident, plutôt que des abstractions qui ne servent qu'à une minorité.
    Voilà, scusez le retard.

  18. #18
    Rédacteur/Modérateur


    Homme Profil pro
    Network game programmer
    Inscrit en
    Juin 2010
    Messages
    7 125
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : Canada

    Informations professionnelles :
    Activité : Network game programmer

    Informations forums :
    Inscription : Juin 2010
    Messages : 7 125
    Points : 33 029
    Points
    33 029
    Billets dans le blog
    4
    Par défaut
    Citation Envoyé par huguesacker Voir le message
    Bonjour,
    C'est sans doute trop tard pour la question, mais comme beaucoup, j'aimerais voir apparaître des choses vraiment pratiques, plutôt que des abstractions hyper complexes.
    - Définir des types de variables standards:
    int16, int32, int64, int128 avec bien entendu, le pendant unsigned (au choix, byte, uchar, uint32, etc).
    Oui je sais, on peut les définir, mais cela passe par des méandres (assez) complexes, parceque les machines n'ont pas la même longueur de mot. Dans les codes sources, on se ramasse avec des stupidités genre "long long"..
    Pouquoi ne pas définir des types standards! J'aimerais aussi des grands nombres (entiers, flottants, réels).
    Et cstdint ?
    Pensez à consulter la FAQ ou les cours et tutoriels de la section C++.
    Un peu de programmation réseau ?
    Aucune aide via MP ne sera dispensée. Merci d'utiliser les forums prévus à cet effet.

  19. #19
    Futur Membre du Club
    Profil pro
    Inscrit en
    Janvier 2006
    Messages
    8
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Janvier 2006
    Messages : 8
    Points : 7
    Points
    7
    Par défaut
    Et cstdint ?
    Oui, c'est ce que je disais: on peut faire mais en passant par des inclusions et autres arcanes. Me semble que cela devrait être dans les types standards (de chez standard, avec des longueurs standardisées sur les divers compilateurs), tout comme les grands nombres, ainsi que les matrices. Pour moi, int64 est plus parlant que "long long" qui ne veut rien dire, sans parler des "LL" après les valeurs données.. (de même que 'L' d'ailleurs); pourquoi ça ? Tout cela donne de la lourdeur, pénalisante pour rien. Il serait bien de régler le problème des printf etc. qui sont soi-disant unsafe.
    Et une fois qu'on aura une vraie interface, une bib graphique et du réseau, beaucoup de monde abandonnera java pour C++.

  20. #20
    Membre émérite
    Avatar de white_tentacle
    Profil pro
    Inscrit en
    Novembre 2008
    Messages
    1 505
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2008
    Messages : 1 505
    Points : 2 799
    Points
    2 799
    Par défaut
    Citation Envoyé par huguesacker Voir le message
    Oui, c'est ce que je disais: on peut faire mais en passant par des inclusions et autres arcanes. Me semble que cela devrait être dans les types standards (de chez standard, avec des longueurs standardisées sur les divers compilateurs), tout comme les grands nombres, ainsi que les matrices. Pour moi, int64 est plus parlant que "long long" qui ne veut rien dire, sans parler des "LL" après les valeurs données.. (de même que 'L' d'ailleurs); pourquoi ça ? Tout cela donne de la lourdeur, pénalisante pour rien. Il serait bien de régler le problème des printf etc. qui sont soi-disant unsafe.
    Et une fois qu'on aura une vraie interface, une bib graphique et du réseau, beaucoup de monde abandonnera java pour C++.
    Tu as lu le lien qui est donné ?

    std::int64_t c’est pas parlant ?

    cstdint ce sont des arcanes ?

    Faudrait voir à pas exagérer...

    Voilà, scusez le retard.
    Je crois qu’effectivement, tu as un retard de version assez important à rattraper en c++. La dernière version c’est C++14 .

Discussions similaires

  1. [Exclu] Posez vos questions à Steve Ballmer
    Par Louis-Guillaume Morand dans le forum C#
    Réponses: 24
    Dernier message: 14/05/2010, 15h02
  2. [Exclu] Posez vos questions à Steve Ballmer
    Par Louis-Guillaume Morand dans le forum Général Dotnet
    Réponses: 25
    Dernier message: 08/10/2009, 15h04
  3. [Exclu] Posez vos questions à Steve Balmer
    Par Louis-Guillaume Morand dans le forum Microsoft Office
    Réponses: 0
    Dernier message: 22/09/2009, 08h43
  4. [Humour] Posez vos questions
    Par pc75 dans le forum La taverne du Club : Humour et divers
    Réponses: 72
    Dernier message: 11/10/2007, 00h48

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