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 :

La spécification du C++17 n'intègrera pas les concepts


Sujet :

C++

  1. #1
    Responsable 2D/3D/Jeux


    Avatar de LittleWhite
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Mai 2008
    Messages
    26 815
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

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

    Informations forums :
    Inscription : Mai 2008
    Messages : 26 815
    Points : 218 179
    Points
    218 179
    Billets dans le blog
    117
    Par défaut La spécification du C++17 n'intègrera pas les concepts
    La spécification du C++17 n'intègrera pas les concepts
    Découvrez les raisons logiques et techniques de son absence

    La nouvelle spécification du C++, nommée C++17 approche à grands pas. Toutefois, la fonctionnalité des concepts n'intègrera pas la future spécification. Tom Honermann explique sur son blog les raisons faisant que c'était improbable, voire impossible.
    Toutefois, avant de décrire ces raisons, rappelons ce que sont les concepts.

    Prenons le concept suivant :
    Code c++ : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    auto concept LessThanComparable<typename T> {
        bool operator<(T, T);
    }
    Celui-ci indique que n’importe quel type ayant un operator< et qui prend en paramètre deux objets et retournant un booléen sera considéré comme un LessThanComparable. Ensuite, il est possible d’utiliser le concept pour restreindre les types pouvant être passés à un template.

    Le but des concepts est d'apporter une solution à un manque du C++. En effet, même s'il est possible de contourner le manque, il est impossible d'apporter une solution propre. Grâce aux concepts il devient possible :
    • de contraindre les arguments d'une fonction sans pour autant désactiver la déduction de ceux-ci et sans gêner la meta arity des fonctions templates ainsi contraintes. Prenons l’exemple suivant :
      Code c++ : Sélectionner tout - Visualiser dans une fenêtre à part
      template <class T> void f(T);
      L’exemple est plutôt simple. Toutefois, nous aimerions ajouter une interface. Pour ce faire, nous voudrions contraindre les paramètres de la fonction :
      Code c++ : Sélectionner tout - Visualiser dans une fenêtre à part
      template <class T> void f(enable_if_t<my_trait_v<T>, T>);
      Mais ce faisant, nous avons perdu la déduction des arguments. Aussi, cela ne fonctionnera pas pour les constructeurs templates. Une seconde approche serait :
      Code c++ : Sélectionner tout - Visualiser dans une fenêtre à part
      template <class T> auto f(T) -> enable_if_t<my_trait_v<T>, void>;
      La contrainte du paramètre se situe dans le type de retour. Toutefois, cela ne marche toujours pas pour les constructeurs templates. Ce que nous pouvons corriger en ajoutant une contrainte sur l’argument template :
      Code c++ : Sélectionner tout - Visualiser dans une fenêtre à part
      template <class T, typename = enable_if_t<my_trait_v<T>>> void f(T);
      Malheureusement, la meta arity est passée de 1 à 2. De plus, ce n’était que des contournements alors qu’avec les concepts nous pourrions faire :
    • d’écrire plus facilement des surcharges tout en ayant des contraintes exclusives mutuellement. Il est souvent souhaité de pouvoir utiliser telle ou telle surcharge suivant certaines conditions sur les templates. Pour réussir, on pourrait écrire :
      Code c++ : Sélectionner tout - Visualiser dans une fenêtre à part
      template <class T> void f(T, decltype(declval<T>().f())* = 0);
      Ce code est dangereux. On peut facilement en arriver à ce point si on ne souhaite pas créer de trait (car c’est l’unique utilisation). De plus, les références ne sont pas gérées, la contrainte peut être ignorée en passant deux arguments à la fonction. Avec les concepts, nous pourrions écrire :
      Code c++ : Sélectionner tout - Visualiser dans une fenêtre à part
      1
      2
      template <class T> void f(T) requires requires (T t) {t.f();};
            template <class T> void f(T);
      Les surcharges sont mutuellement exclusives.
    • d’écrire des contraintes aussi originales que nécessaires.


    Malgré tout l’intérêt que peuvent avoir les concepts, ceux-ci n'intégreront pas le prochain standard. En effet, plusieurs choses ne sont pas encore claires :
    • la spécification des concepts a été publiée le 15 novembre 2015, laissant peu de temps pour un retour efficace et fiable ;
    • la seule implémentation est dans une version non publiée de GCC ;
    • l’implémentation réalisée dans GCC a été réalisée par l’auteur de la spécification. Il n’y a donc pas eu d’avis externe sur la question de l’implémentation dans GCC ou dans les autres compilateurs ;
    • seuls quelques projets utilisent les concepts, mais la spécification n’a pas été assez mise à l’épreuve dans des cas réels ;
    • la spécification ne fournit pas de bibliothèque de définitions de concepts. Donc il n’est pas possible de savoir si l’écriture d’une telle bibliothèque est possible.


    Toutefois, même si tous ces points avaient été réglés, Tom Honermann doute de l’intégration des concepts à la spécification du langage. En effet :
    • les concepts apportent une nouvelle écriture pour les templates. Toutefois, une fonction template abrégée peut être identique à une fonction non template. Le type serait le seul indicateur pour savoir si la fonction est non template ou si elle est template :
    • la proposition définit une nouvelle syntaxe pour déclarer des templates respectant une contrainte :
      Code c++ : Sélectionner tout - Visualiser dans une fenêtre à part
      C{A,B} void f(A a, B b);
      toutefois, cette syntaxe n’est pas appréciée ;
    • l’utilisation d’un concept nécessite de connaître comment il a été défini (fonction ou variable). Cela apporte confusion et est source d’erreurs ;
    • les concepts sont attendus pour améliorer les messages d’erreur. Toutefois, l’utilisation erronée des concepts peut apporter des erreurs encore plus denses qu’à l’accoutumée liées à la surcharge des fonctions ;
    • de nombreuses autres questions ont été soulevées et ne pourront être répondues qu’à travers des tentatives d’utilisation.


    Même si ce constat est malheureux pour tout utilisateur du langage souhaitant les concepts au plus tôt, ces derniers devraient arriver dans la prochaine spécification. De plus, il y a de grandes chances pour que chaque compilateur propose une implémentation bien avant la complétion du futur standard. Finalement, ce retard permet d’affiner l’implémentation et ainsi, au comité de proposer une meilleure fonctionnalité.


    Votre opinion

    Aviez-vous déjà imaginé des cas d’utilisation pour les concepts ? Quels sont-ils ?
    Quelles autres fonctionnalités du C++ attendez-vous ?


    Source

    Blog de Tom Honermann
    IsoCPP
    Vous souhaitez participer à la rubrique 2D/3D/Jeux ? Contactez-moi

    Ma page sur DVP
    Mon Portfolio

    Qui connaît l'erreur, connaît la solution.

  2. #2
    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
    Je suis assez en désaccord avec ce post qui présente pour moi une vue biaisée de la situation. Même si je n'étais pas à la dernière réunion, j'ai suivi d'assez près son contenu.

    la spécification des Concepts a été publiée le 15 novembre 2015, laissant peu de temps pour un retour efficace et fiable
    La spécification des concepts existe depuis longtemps... C'est le fait que cette spécification soit sous forme de TS qui est récent. Même si le design a commencé bien avant, la première spécification existe depuis janvier 2014. Elle a évolué, certes, mais si on va par là, toutes les propositions évoluent, c'est leur objectif, et si on imposait à toute évolution une période de non évolution de plusieurs années avant d'être acceptées, on n'aurait rien dans C++17.

    la seule implémentation est dans une version non publiée de GCC ;
    Version qui ne pouvait pas être publiée, puisque les concepts ne sont pas dans le langage.... C'est l’œuf et la poule... Et c'était l'intérêt du TS que de rassurer les fabricants de compilateurs à faire l'effort d'implémentation avant la standardisation. Et il faut savori que de nombreuses fonctionnalités du langage ne sont que dans des versions non publiées avant d'être acceptées (certaines ne sont même pas implémentées dans leur forme finale...).

    l’implémentation réalisée dans GCC a été réalisée par l’auteur de la spécification. Il n’y a donc pas eu d’avis externe sur la question de l’implémentation dans GCC ou dans les autres compilateurs ;
    C'est le cas pour l'immense majorité des nouvelles fonctionnalités du langage. Et je n'ai jamais entendu cet argument utilisé pour autre chose que les concepts... Pour les autres cas, une question est récurrente est "Est-ce que ça a été implémenté?". Pour les concepts, il semblerait que la question soit "Est-ce que ca a été implémenté 3 fois par 3 équipes différentes dont aucune n'a le droit de contenir l'auteur principal de la proposition?"...

    seuls quelques projets utilisent les concepts, mais la spécification n’a pas été assez mise à l’épreuve dans des cas réels ;
    Et comment pourrait-elle l'être plus, tant que la proposition n'est pas acceptée ? Elle a été utilisée dans divers contextes, le contexte manquant le plus gênant étant la STL. Mais des grandes bibliothèques l'ont utilisée (range, par exemple)

    la spécification ne fournit pas de bibliothèque de définitions de concepts. Donc il n’est pas possible de savoir si l’écriture d’une telle bibliothèque est possible.
    C'est un point gênant mais hélas classique. Les gens qui travaillent sur le langage et ceux qui travaillent sur la bibliothèque sont différents, et tant qu'une fonctionnalité n'a pas été acceptée dans la langage, implémentée dans plusiuers compilateurs, les bibliothèques ont du mal à suivre. Par exemple, plusieurs années après la mise en place de noexcept, on ne savait toujours pas sur quelles fonctions de la bibliothèque mettre noexcept ou pas. Même chose pour constexpr qui est seulement en train d'être ajouté à la bibliothèque standard.


    les Concepts apportent une nouvelle écriture pour les templates. Toutefois, une fonction template abrégée peut être identique à une fonction non template. Le type serait le seul indicateur pour savoir si la fonction est non template ou si elle est template :
    C'est le cas depuis le début, ça a été discuté et accepté. Après, certains n’aiment pas, mais à part rouvrir sans cesse les vieux débats...
    Il est courant en C++ de ne pas pouvoir dire ce qu'est un code sans connaître le contexte. Si je dis
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    void f(double d) {};
    f(2);
    Je ne peux pas dire si cette fonction f sera appelée sans savoir s'il n'y a pas aussi visible dans le scope une autre fonction qui serait préférée. C'est la base de la surcharge, et ça ne gêne personne.
    Et bien, dans le même ordre d'idée, si je vois void f(Container const &c), je ne peux pas savoir sans un peu de contexte si je définis une fonction ou un template, mais :
    - Généralement, je connais le contexte, et je peux dire par exemple que Container est un concept, et donc que je définis un template, mais que f(vector<int> const &v) va définir une fonction.
    - Le nom lui même doit m'aider
    - Et la plupart du temps, je m'en moque totalement de savoir si une fonction est un template ou pas. J'ai sous la main en conteneur (sans savoir forcément son type exact, il est peut-être dans une variable auto initialisée par un retour de fonction, ou dans un argument template), je peux appeler f, c'est tout ce qui compte.

    les Concepts sont attendus pour améliorer les messages d’erreur. Toutefois, l’utilisation erronée des Concepts peut apporter des erreurs encore plus dense qu’à l’accoutumée lié à la surcharge des fonctions ;
    Je manque de recul sur ce point (toujours pareil, tant qu'on ne l'a pas vraiment dans un compilo qu'on utilise quotidiennement...), mais :
    - Ce n'est pas le cas le plus courant
    - Lire une longue liste de surcharge reste au niveau sémantique de l'interface. Pour les gens ayant l'habitude de plonger dans l'implémentation, peut-être que c'est un peu plus long, mais pour les gens voulant rester au niveau de l'interface, c'est mieux !
    - Je ne doute pas qu'avec le temps, les compilateurs pourront affiner les messages d'erreur liés aux concepts (par exemple, lister en premier parmi les surcharges celle qui était le plus proche de passer, et donc la plus susceptible d'être la bonne).

    de nombreuses autres questions ont été soulevées et ne pourront être répondues qu’à travers des tentatives d’utilisations.
    Et ces tentatives ne pourront avoir lieu que quand les compilateurs proposeront cette fonctionnalité. Et qu'ils la proposeront vraiment, pas avec un flag "expérimental" et d'autres joyeusetés qui empêcheraient les gens de l'utiliser dans un vrai contexte professionnel. J'espère vraiment que la présence du TS ira dans cette direction... Je ne doute pas qu'il y aura des petits problèmes avec les concepts... Il y en a eu avec toutes les grosses fonctionnalités du langage. La move sémantic était totalement bancale bien après qu'elle ait été mise dans la langage, les lambda étaient incomplets...

    Le problème, c'est qu'il y a un risque à ne pas livrer les concepts qui est pour moi plus important que le risque actuel de livrer des concepts imparfaits. Pour une autre vision sur le sujet, je vous propose de lire http://www.open-std.org/jtc1/sc22/wg...6/p0225r0.html
    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.

  3. #3
    Membre éclairé
    Homme Profil pro
    Développeur C++
    Inscrit en
    Octobre 2008
    Messages
    242
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Bas Rhin (Alsace)

    Informations professionnelles :
    Activité : Développeur C++

    Informations forums :
    Inscription : Octobre 2008
    Messages : 242
    Points : 705
    Points
    705
    Par défaut
    Rien que de voir ça je me demande ce qu'il se passe dans la tête du commité parfois.

  4. #4
    Membre habitué
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Avril 2009
    Messages
    391
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Avril 2009
    Messages : 391
    Points : 185
    Points
    185
    Par défaut Trop compliqué
    C'est pas plus mal. Y'en a marre de ces standards qui s'enrichissent de fonctionnalités trop compliqués (tout langages confondus).
    "auto concept"...ils peuvent pas choisir déjà des termes moins compliqués ?

  5. #5
    Expert éminent sénior

    Femme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Juin 2007
    Messages
    5 184
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : France, Essonne (Île de France)

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

    Informations forums :
    Inscription : Juin 2007
    Messages : 5 184
    Points : 17 118
    Points
    17 118
    Par défaut
    auto, car tant qu'a faire, utiliser la déduction de type.
    Il aurait pu écrire bool concept LessThanComparable<typename T> {bool operator<(T, T);}.

    Cela dit, je crois que la syntaxe proposée était plutot:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    template<typename T>
    concept bool LessThanComparable = requires(T a, T b) {
        { a < b } -> bool;
    };
    les deux mots clés sont requires et concept. la fonction est nécessairement bool.

    Regardez par exemple sur cppreference.com pour la proposition actuelle de Concepts Technical Specification ISO/IEC TS 19217:2015.

    La proposition est suffisamment intéressante à mon gout, elle permet de spécifier des attentes plus complexes, telles que "dispose de begin et end", "dispose de size()", ou encore est un appelable avec tels arguments.
    Je dois dire que j'ai récemment écrit une bibliothèque de manipulation de fonctions mathématiques (somme, produit, composition, etc) et qu'un concept tel que callable_as<arg1, arg2> m'aurait grandement arrangé.
    La moitié du code de cette bibliothèque consiste précisément à me donner cette capacité, au prix d'appel de deux classes de traits (et sept spécialisations chacune), de pleins de static_assert.

    Avec les concepts, je n'aurai eu qu'a écrire une template de concept, et c'est tout.
    Mes principes de bases du codeur qui veut pouvoir dormir:
    • Une variable de moins est une source d'erreur en moins.
    • Un pointeur de moins est une montagne d'erreurs en moins.
    • Un copier-coller, ça doit se justifier... Deux, c'est un de trop.
    • jamais signifie "sauf si j'ai passé trois jours à prouver que je peux".
    • La plus sotte des questions est celle qu'on ne pose pas.
    Pour faire des graphes, essayez yEd.
    le ter nel est le titre porté par un de mes personnages de jeu de rôle

  6. #6
    Expert éminent sénior

    Homme Profil pro
    pdg
    Inscrit en
    Juin 2003
    Messages
    5 749
    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 749
    Points : 10 666
    Points
    10 666
    Billets dans le blog
    3
    Par défaut
    Tiens, on en a parlé un peu hier à la rencontre C++ de Montpellier:
    C++17 sera vraissemblablement une version mineure:
    • pas de Modules
    • pas de Concepts
    • pas de Range (dépendance sur les concepts)
    • pas de Coroutines
    • pas de *uniform call syntax*

    Rendez-vous en 2020 ou peut-être même 2019 pour ces points là.
    Pas de concepts ça implique aussi pas de range... Dommage pour le uniform call syntax aussi... Mais malgré tout, C++17 devrait quand même pas mal changer notre style:

    Ce qui sera inclus dans C++17:
    • STL parallèle / vectorisée
    • Library Fundamentals TS (any, optional, string_view, ...)
    • File System TS
    • Beaucoup de petits ajouts et améliorations qui vont faire évoluer notre style de programmation:
      • if constexpr
      • lambdas constexpr
      • operator. (smart references)
      • génération de comparateurs par défaut (==, !=, <, <=, >, >=)
      • attributs [[fallthrough]], [[nodiscard]], [[maybe_unused]]

    Les mart reference en particulier, je suis curieux de voir ce que ça va donner!

  7. #7
    Membre extrêmement actif Avatar de nikau6
    Homme Profil pro
    Inscrit en
    Février 2008
    Messages
    390
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Etats-Unis

    Informations forums :
    Inscription : Février 2008
    Messages : 390
    Points : 704
    Points
    704
    Par défaut
    Citation Envoyé par paladice Voir le message
    C'est pas plus mal. Y'en a marre de ces standards qui s'enrichissent de fonctionnalités trop compliqués (tout langages confondus).
    Je pense également que le C++ est en train de devenir un langage de plus en plus compliqué, de plus en plus élitiste. Et d'ailleurs, pourquoi pas ! Le problème, c'est qu'ils prétendent le simplifier, et dans une certaine mesure on peut effectivement dire qu'il se simplifie, mais seulement pour ceux qui maitrisent déjà l'ensemble du langage. Pour les débutants par contre, ça va être de plus en plus hard-core de l'apprendre.

  8. #8
    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
    Oui, le langage devient de plus en plus complet / complexe.
    Mais du coup son utilisation devient plus simple (et l'apprentissage de son utilisation aussi).

    Les débutants n'ont pas / plus besoin d'apprendre les choses compliquées.
    Pour donner un exemple avec les concepts : l'apprentissage et l'utilisation des concepts est beaucoup plus simple que celles de SFINAE.
    Certains programmes qui étaient compliqués peuvent être réécrits en programmes relativement simples (même pour les débutants).

  9. #9
    Membre extrêmement actif Avatar de nikau6
    Homme Profil pro
    Inscrit en
    Février 2008
    Messages
    390
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Etats-Unis

    Informations forums :
    Inscription : Février 2008
    Messages : 390
    Points : 704
    Points
    704
    Par défaut
    On ne peut prétendre maitriser un langage que si l'on maitrise l' ENSEMBLE de ses fonctionnalités, et pas simplement les plus récentes, qui viennent en générale réparer les problemes de la spécification précédente.
    Donc, en fait, d;une certaine manière, tu abondes en mon sens. Pour celui qui a conscience des problème liés aux SFINAE, les concepts paraissent simple, mais pour celui qui par de zéro, il va devoir tout comprendre, les SFINAE et les concepts.

  10. #10
    Expert confirmé Avatar de AoCannaille
    Inscrit en
    Juin 2009
    Messages
    1 409
    Détails du profil
    Informations forums :
    Inscription : Juin 2009
    Messages : 1 409
    Points : 4 713
    Points
    4 713
    Par défaut
    Citation Envoyé par nikau6 Voir le message
    On ne peut prétendre maitriser un langage que si l'on maitrise l'ENSEMBLE de ses fonctionnalités, et pas simplement la plus récente, qui vient en générale réparer les problemes de la spécification précédente.
    Tout dépend de la définition de "maîtriser" un langage. Mais en mon sens, si tu maitrise l'orienté objet, l'utilisation des fonctions, des boucles et des conditions en C++, tu sais déjà te débrouiller dans énormément de cas.

    C++11 a introduit les boucle de type foreach en se basant sur les itérateurs. On peut sans aucun problème continuer à se contenter des boucles for classique sans se sentir limité. Est-ce qu'ignorer cette fonctionnalité empêche de maîtriser le reste?

    Car au final, on ne maîtrise que ce qu'on utilise, et quand la boite à outils est si grande, on ne peut pas tout maîtriser. Seuls les gourous peuvent dirent qu'il maîtrisent le langage dans ce cas. Et ça représente quoi? entre 1000 et 5000 personnes sur Terre...

    Un peu comme Excel où un utilisateur normal utilise 1% des fonctionnalités et un power-user 10%.

  11. #11
    Membre extrêmement actif Avatar de nikau6
    Homme Profil pro
    Inscrit en
    Février 2008
    Messages
    390
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Etats-Unis

    Informations forums :
    Inscription : Février 2008
    Messages : 390
    Points : 704
    Points
    704
    Par défaut
    Si on ne maitrise pas l'ensemble d'un langage on est forcement très limité pour comprendre le code écrit par d'autres. Il est la le problème. Si tu te limite á la lecture de ton propre code alors pas de problèmes et je te donne raison.

  12. #12
    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
    Citation Envoyé par nikau6 Voir le message
    On ne peut prétendre maitriser un langage que si l'on maitrise l' ENSEMBLE de ses fonctionnalités, et pas simplement les plus récentes, qui viennent en générale réparer les problemes de la spécification précédente.
    Donc, en fait, d;une certaine manière, tu abondes en mon sens. Pour celui qui a conscience des problème liés aux SFINAE, les concepts paraissent simple, mais pour celui qui par de zéro, il va devoir tout comprendre, les SFINAE et les concepts.
    (Il y a une différence entre l'apprentissage / l'utilisation du langage par un débutant et sa maîtrise.)

    Je n'aime pas trop parler de maîtrise d'un langage. C'est une notion un peu flou pour moi.
    Même si on connaît toutes les règles et la syntaxe, il est possible de ne pas "comprendre" un code (pour des questions d'algo par exemple) ou ne pas savoir l'écrire de la façon la plus propre. Programmer n'est pas qu'une histoire de langage mais aussi de combinaison de différents techniques / patterns.

    À l'inverse je pense que l'on peux connaître la sous partie du langage qui me permet de comprendre / d'écrire l'ensemble des codes que je rencontre / souhaite développer.
    Est-ce vraiment grave de ne pas tout connaître ?

  13. #13
    Membre extrêmement actif
    Homme Profil pro
    Graphic Programmer
    Inscrit en
    Mars 2006
    Messages
    1 532
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Graphic Programmer
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Mars 2006
    Messages : 1 532
    Points : 3 881
    Points
    3 881
    Par défaut
    je sais pas si on peut dire que le c++ pour les débutant est hard-core. disons que oui si c'est le 1er langage qu’on apprend.

    personnellement j'ai toujours regretté d’avoir appris le c++ comme 1er langage avant le c.

  14. #14
    Membre extrêmement actif Avatar de nikau6
    Homme Profil pro
    Inscrit en
    Février 2008
    Messages
    390
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Etats-Unis

    Informations forums :
    Inscription : Février 2008
    Messages : 390
    Points : 704
    Points
    704
    Par défaut
    J'ajouterai qu si beaucoup des nouvelles fonctionnalités rendent l'écriture plus simple, elles rendent également la lecture plus compliqué. Bientôt, ne pourront comprendre un code écrit en C++ que ceux qui l'auront écris, et encore ..

  15. #15
    Expert éminent sénior
    Avatar de Luc Hermitte
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Août 2003
    Messages
    5 275
    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 275
    Points : 10 985
    Points
    10 985
    Par défaut
    Citation Envoyé par nikau6 Voir le message
    On ne peut prétendre maitriser un langage que si l'on maitrise l' ENSEMBLE de ses fonctionnalités, et pas simplement les plus récentes, qui viennent en générale réparer les problemes de la spécification précédente.
    Donc, en fait, d;une certaine manière, tu abondes en mon sens. Pour celui qui a conscience des problème liés aux SFINAE, les concepts paraissent simple, mais pour celui qui par de zéro, il va devoir tout comprendre, les SFINAE et les concepts.
    A ce compte là, personne ne maitrise rien. Tout langage confondu. Combien maitrisent vraiment la notion d'objets ? Les bonnes pratiques de SOLID ? Combien comprennent que l'OO n'est pas une question d'organiser les données, mais les comportements ?
    Pour maitriser un langage OO, il faut maitriser cela.

    De plus, on est conscient qu'il y a plusieurs niveaux d'utilisation. Entre celui qui va juste enchainer des briques et celui qui va les écrire, il va y avoir des différences dans l'utilisation du langage. Pas besoin de connaitre la méta-prog pour enchainer des opérations.
    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...

  16. #16
    Expert éminent sénior
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Février 2005
    Messages
    5 047
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : France, Val de Marne (Île de France)

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

    Informations forums :
    Inscription : Février 2005
    Messages : 5 047
    Points : 12 074
    Points
    12 074
    Par défaut
    Citation Envoyé par Aiekick Voir le message
    personnellement j'ai toujours regretté d’avoir appris le c++ comme 1er langage avant le c.
    Pour avoir subit l'inverse, je peux te garantir que C puis C++ c'est la combo maudite pour faire de la merde sans le savoir.

    Arrêtez de pendre vos lunettes de vieux cons, comment pouvez-vous regretter l'utilisation systématique de pointeurs nus dans un langage à exception ?
    Les smart pointeurs, c'est irremplaçable, jusqu'à trouver encore mieux.

    La normalisation du C++ a une démarche proche des framework progressifs, rendre simple les cas courants, faire en sorte que les cas courants couvre le plus de cas possible et faire en sorte que les cas rares et complexes soient
    Et oui, la programmation générique (template simple), le code fonctionnel à base de lambda, la programmation parallèle ou concurrente sont des cas maintenant des plus courants ou en passe de l'être. Et que les normalisateurs me tracent une autoroute pour m'en servir le plus simplement du monde, je leur en suis profondément reconnaissant.

    Moi, je ne maitrise pas le C++, même après plus de 20ans d'utilisation, mais tant que j'arrive à faire ce que je veux et qu'en cherchant un peu je trouve de super trucs qui me simplifient la vie, bibliothèque ou nouvelles normes, je suis content.

    Avoir l'illusion de maitriser un machin et bien plus dévastatrice que de savoir qu'on ne sait rien.

    Désolé les gars, mais les seules personnes qui peuvent dire que le C++ est trop compliqué, c'est les vrais débutants, pas ceux qui se paluchent les intrinsics des compilateurs en assembleur x64 ou Itanium.

  17. #17
    Expert éminent sénior

    Femme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Juin 2007
    Messages
    5 184
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : France, Essonne (Île de France)

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

    Informations forums :
    Inscription : Juin 2007
    Messages : 5 184
    Points : 17 118
    Points
    17 118
    Par défaut
    Parmi les changements en préparation pour la réunion de juin, il y a des choses sympas, comme la déduction des types templates dans les constructeurs.
    C'est à dire la suppression du besoin de toutes les fonctions make_bidule (que ce soit unique, shared, pair, tuple, optional...).

    Il y a aussi if constexpr (...) qui réduira le nombre de spécialisation de template à écrire.

    Puis viens l'incroyable T& operator . ()
    Mes principes de bases du codeur qui veut pouvoir dormir:
    • Une variable de moins est une source d'erreur en moins.
    • Un pointeur de moins est une montagne d'erreurs en moins.
    • Un copier-coller, ça doit se justifier... Deux, c'est un de trop.
    • jamais signifie "sauf si j'ai passé trois jours à prouver que je peux".
    • La plus sotte des questions est celle qu'on ne pose pas.
    Pour faire des graphes, essayez yEd.
    le ter nel est le titre porté par un de mes personnages de jeu de rôle

  18. #18
    Membre extrêmement actif Avatar de nikau6
    Homme Profil pro
    Inscrit en
    Février 2008
    Messages
    390
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Etats-Unis

    Informations forums :
    Inscription : Février 2008
    Messages : 390
    Points : 704
    Points
    704
    Par défaut
    Citation Envoyé par Luc Hermitte Voir le message
    A ce compte là, personne ne maitrise rien. Tout langage confondu. Combien maitrisent vraiment la notion d'objets ? Les bonnes pratiques de SOLID ? Combien comprennent que l'OO n'est pas une question d'organiser les données, mais les comportements ?
    Pour maitriser un langage OO, il faut maitriser cela.

    De plus, on est conscient qu'il y a plusieurs niveaux d'utilisation. Entre celui qui va juste enchainer des briques et celui qui va les écrire, il va y avoir des différences dans l'utilisation du langage. Pas besoin de connaitre la méta-prog pour enchainer des opérations.
    Je suis d'accord pas besoin de connaitre la méta-prog et en parlant de maitriser complétement un langage j’exagère un peu. Je ne suis pas un expert du C++, loin s'en faut.. Je maitrise peut être 30% du langage, et encore.. Mais il n’empêche que plus un langage se complexifie, se complète diront certain, et plus il devient difficile de lire du code écrit par d'autres. En tous les cas moi ça me cause des problèmes.

    EDIT: Par exemple, j'ai récemment jeté un œil au code du moteur Doom3. Un vrai régal. Du C with class. Pas d'utilisation excessive des templates, de l'héritage multiple, etc.. Juste ce qu'il faut. Et bien le code est clair, limpide..

  19. #19
    Expert éminent sénior
    Avatar de Luc Hermitte
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Août 2003
    Messages
    5 275
    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 275
    Points : 10 985
    Points
    10 985
    Par défaut
    Ceci est le genre de code que l'on écrit dans un langage dénué de quantité de "nouvelles" (ici constructeurs et références) façon d'organiser nos traitements.

    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
    28
    enum class Code { OK, NOK };
     
    struct Image
    {
        double *    pixels;
        std::size_t nb_pixels;
    };
     
    Code get_size(Image const* im, std::size_t * size)
    {
        if (!im || !size)
            return Code::NOK;
        *size = im->nb_pixels;
        return Code::OK;
    }
     
    Code get_pixel(Image const* im, std::size_t idx, double * pixel)
    {
        if (!im || !im->pixels || !pixel)  return Code::NOK;
        std::size_t size;
        Code c = get_size(im, &size);
        if (c != Code::OK)                 return c;
        else if (idx >= size)              return Code::NOK;
        else {
            *pixel = im->pixels[idx];
            return Code::OK;
        }
    }
    Ce n'est que la version du code d'accès à un pixel. Chose que l'on fera dans une boucle.

    Personnellement, j'ai le plus grand mal à lire ce genre de code -- imaginez la couche englobante qui va tester ou non le succès des opérations.
    (Le enum class est un détail, s'il vous gêne remplacez juste par un simple enum)
    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...

  20. #20
    Membre extrêmement actif Avatar de nikau6
    Homme Profil pro
    Inscrit en
    Février 2008
    Messages
    390
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Etats-Unis

    Informations forums :
    Inscription : Février 2008
    Messages : 390
    Points : 704
    Points
    704
    Par défaut
    Citation Envoyé par Luc Hermitte Voir le message
    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
    28
    enum class Code { OK, NOK };
     
    struct Image
    {
        double *    pixels;
        std::size_t nb_pixels;
    };
     
    Code get_size(Image const* im, std::size_t * size)
    {
        if (!im || !size)
            return Code::NOK;
        *size = im->nb_pixels;
        return Code::OK;
    }
     
    Code get_pixel(Image const* im, std::size_t idx, double * pixel)
    {
        if (!im || !im->pixels || !pixel)  return Code::NOK;
        std::size_t size;
        Code c = get_size(im, &size);
        if (c != Code::OK)                 return c;
        else if (idx >= size)              return Code::NOK;
        else {
            *pixel = im->pixels[idx];
            return Code::OK;
        }
    }
    Du code comme je l'aime :-)

Discussions similaires

  1. [Debutant(e)]Eclipse ne voit pas les sources
    Par uliss dans le forum Eclipse Java
    Réponses: 3
    Dernier message: 04/08/2004, 10h34
  2. probleme avec requete sql aime pas les strings
    Par lil_jam63 dans le forum Bases de données
    Réponses: 3
    Dernier message: 24/02/2004, 15h45
  3. TASM ne connaît pas les registres FS et GS
    Par forthx dans le forum Assembleur
    Réponses: 4
    Dernier message: 07/06/2003, 01h56

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