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

  1. #1
    Chroniqueur Actualités

    Homme Profil pro
    Administrateur systèmes et réseaux
    Inscrit en
    juin 2016
    Messages
    660
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Bénin

    Informations professionnelles :
    Activité : Administrateur systèmes et réseaux
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : juin 2016
    Messages : 660
    Points : 20 558
    Points
    20 558

    Par défaut La conception de C++ 20 est achevée et le premier brouillon sera publié en juillet 2019

    La conception de C++ 20 est achevée et le premier brouillon sera publié en juillet 2019,
    les Modules et les Coroutines y sont présents

    La toute dernière réunion du comité ISO C++ pour approuver les nouvelles fonctionnalités à venir dans C++ 20 s’est tenu la semaine passée à Kona, à Hawaii. À l’issu de cette réunion, le comité a annoncé que les fonctionnalités du prochain standard international (SI) du langage de programmation C++, le C++ 20 sont maintenant finalisées. Il a également indiqué qu’une prochaine réunion, prévue pour juillet prochain, mettra fin à la spécification et verra la publication d’un brouillon pour examen. Le président du comité de normalisation ISO C++, Herb Sutter, (également auteur, conférencier et architecte logiciel chez Microsoft) a déclaré ce qui suit : « Nous connaissons ainsi la plupart des fonctionnalités finales de C++ 20 ! Lors de notre prochaine réunion en juillet, nous prévoyons d’adopter officiellement quelques fonctionnalités supplémentaires qui ont été approuvées par la conception lors de cette réunion, mais qui n’ont pas encore été révisées dans leur intégralité. À la fin de la réunion de juillet, nous lancerons ensuite le premier bulletin de commentaires pour C++ 20 pour d’examen ».

    Parmi les nombreuses nouvelles fonctionnalités approuvées pour le C++ 20, deux fonctionnalités majeures sont à noter. Il s’agit des fonctionnalités dénommées Modules et celles dénommées Coroutines. Comme l’explique Herb Sutter, les Modules constituent une nouvelle alternative aux fichiers d’en-tête et apportent un certain nombre d’améliorations clés notamment en isolant les effets des macros et en permettant des générations évolutives. Cette fonctionnalité permet aux utilisateurs du langage de définir une limite d’encapsulation nommée, une première depuis ses 35 ans d’âge selon Sutter. Il existait jusque-là trois fonctionnalités de ce type qui permettent aux programmeurs de créer leurs propres mots de pouvoir en (a) donnant un nom défini par l'utilisateur en (b) quelque chose dont l'implémentation est cachée, explique Sutter. Ce sont : la variable (qui encapsule la valeur actuelle), la fonction (qui encapsule le code et le comportement) et la classe (qui encapsule les deux pour délivrer un ensemble d’états et de fonctions).

    Même des fonctionnalités majeures telles que les Modèles constituent des moyens de décorer ou de paramétrer ces trois fonctionnalités fondamentales. À ces trois, est ajoutée maintenant une quatrième, les Modules qui encapsulent les trois pour en livrer un ensemble. Les Coroutines quant à eux, sont des fonctions qui peuvent suspendre et reprendre leur exécution tout en conservant leur état. L'évolution en C++ 20 va encore plus loin. Le terme Coroutines est inventé par Melvin Conway, un informaticien. Il l'a utilisé dans sa publication pour la construction d'un compilateur en 1963. Cette fonctionnalité existe également dans les langages comme Python. L'implémentation spécifique de Coroutines en C++ est un peu intéressant. Au niveau le plus élémentaire, il ajoute quelques mots-clés à C++ comme co_return, co_await, co_yield ainsi que des types de bibliothèques qui fonctionnent avec eux. Une fonction devient une coroutine en ayant une de ces fonctions dans son corps.

    Nom : titleShadow-1024x341.png
Affichages : 6449
Taille : 256,0 Ko

    Lorsqu'un de ces trois mots-clés est utilisé dans un corps de fonction, un examen standard obligatoire du type de retour et des arguments est produit et la fonction est transformée en une coroutine. Cet examen indique au compilateur où stocker l'état de la fonction lorsque celle-ci est suspendue. La spécification s’est portée également sur d’autres fonctionnalités et modifications telles que :

    • l’extension des liaisons structurées et la capture de référence des liaisons structurées qui permettent à un nom introduit en tant que liaison structurée d'être utilisé de manière supplémentaire, par exemple d’être capturé par référence dans des lambdas ;
    • ⇔! === qui ajoute une meilleure prise en charge linguistique pour la composabilité lors de l'écriture <=> pour les types pouvant écrire un == plus efficace que d'utiliser l'opérateur <=> seul. Par exemple, le vecteur <T> peut court-circuiter la comparaison == en vérifiant d’abord si les deux vecteurs ont la même taille ;
    • changer span pour utiliser une taille non signée et ajouter des fonctions ssize() pour obtenir les tailles signées. Cette fonctionnalité rend std::span plus pratique à utiliser avec les types STL existants, tout en permettant l’utilisation de tailles et d’index signés via ssize( ) pour bénéficier des avantages de la signature ;
    • le polymorphic allocator. Il permet à pmr::memory_resource d'être utilisée partout où des allocateurs peuvent être utilisés dans la bibliothèque standard ;
    • etc.

    Le comité à travers le reportage de Sutter, a indiqué que les processus tels que les exécuteurs et la mise en réseau continuent de progresser, les deux étant étroitement liés. « Nous espérions qu'une partie des exécuteurs serait prête pour le C++ 20, mais ils n'ont pas réussi la coupe. Ils sont tous deux sur la bonne voie pour bientôt, post C++ 20 (c'est-à-dire au début de la phase C++ 23) », a expliqué Herb Sutter, le président du comité. Beaucoup félicitent l’effort mis en œuvre par le comité pour offrir ces nouvelles fonctionnalités à la communauté C++ et l’encouragent à faire encore plus pour la prochaine standardisation du langage (C++ 23).

    Cependant, certains expriment leur mécontentement par rapport au fait que la mise en réseau soit encore laissée de côté comme il a été le cas plusieurs fois déjà. Néanmoins, pour l’effort qui est fait, plusieurs y voient une expérience très excitante et encouragent à une adoption à grande échelle du C++ 20. Les autres fonctionnalités telles que les Concepts, les Ranges, les Contrats qui avaient été introduites dans C++ 20 avant cette réunion sont présentées et expliquées sur le site de l’ISO C++. Vous y retrouverez également d’autres annonces ainsi que le calendrier des autres événements à venir pour livrer complètement le C++ 20.

    Source : Billet de blog

    Et vous ?

    Que pensez-vous de ces nouveautés de C++ 20 ?

    Voir aussi

    De C++14 à C++17, qu'est-ce qui a changé avec la nouvelle version du langage C++ : un document de la Standard C++ Foundation

    La spécification de la nouvelle version du langage C++ (C++17) est finalisée quelles sont les nouveautés introduites ?

    Le premier brouillon de la prochaine révision du standard C, le C2x, est publié et met l'accent sur la compatibilité du langage

    Internet aurait de sérieux problèmes à cause de langages comme C et C++ favorisant la survenue de failles mais peu de développeurs s'en soucieraient
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Membre averti
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    mars 2011
    Messages
    90
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : mars 2011
    Messages : 90
    Points : 337
    Points
    337

    Par défaut

    C'est une version bien pleine, très intéressante et ça promet du boulot pour maîtriser tout ça. Voilà la liste des nouveautés dans le post de Herb Sutter (en plus il précise "modulo any additional features in July"):

    modules
    coroutines
    concepts
    contracts
    <=> spaceship
    “lots more constexpr”: broad use of normal C++ for direct compile-time programming, without resorting to template metaprogramming (see last trip report)
    ranges
    calendars and time zones
    span
    and lots more

    Il a raison de dire:
    Citation Envoyé par Herb Sutter
    We understand that’s exciting, but we also understand that’s a lot for the community to absorb

  3. #3
    Membre expert
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    avril 2016
    Messages
    916
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : avril 2016
    Messages : 916
    Points : 3 929
    Points
    3 929

    Par défaut

    Enfin les modules !!!

  4. #4
    Membre extrêmement actif
    Homme Profil pro
    Inscrit en
    janvier 2014
    Messages
    627
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : janvier 2014
    Messages : 627
    Points : 2 690
    Points
    2 690

    Par défaut

    C'est pas mal, mais bon le C++ est très en retard est encore très loin de pouvoir rattraper l'énorme avance du C# qui est bien plus moderne et surtout bien mieux foutu, le C++ reste un langage désuet et ringard.

    D'ailleurs l'avenir c'est clairement le langage Julia qui n'a que des avantages, C++ est en train de se Coboliser, mais bon cela restera une bonne source de revenus pour la maintenance de l'existant pour ceux qui aiment les langages antiques compliqués ...
    « L’humour est une forme d'esprit railleuse qui s'attache à souligner le caractère comique, ridicule, absurde ou insolite de certains aspects de la réalité »

  5. #5
    Membre expert
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    avril 2016
    Messages
    916
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : avril 2016
    Messages : 916
    Points : 3 929
    Points
    3 929

    Par défaut

    Citation Envoyé par Mingolito Voir le message
    C'est pas mal, mais bon le C++ est très en retard est encore très loin de pouvoir rattraper l'énorme avance du C# qui est bien plus moderne et surtout bien mieux foutu, le C++ reste un langage désuet et ringard.

    D'ailleurs l'avenir c'est clairement le langage Julia qui n'a que des avantages
    Comparé aux autres langages connus de haut niveau comme Java et C#, C++ est en retard sur certains points, mais il est en avance sur d'autres, surtout quand on a besoin d'avoir de bonnes performances.

    Du côté des langages émergents, peut-être que Julia s'imposera dans les applis qui n'auront pas besoin de performances aussi élevées qu'avec du C++ optimisé. Mais, tant que Julia nécessitera d'utiliser un ramasse-miettes, il ne sera pas un vrai concurrent du C++. Le futur concurrent le plus sérieux du C++ me semble être Rust.

  6. #6
    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 : 44
    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 009
    Points
    16 009

    Par défaut

    il y a eu de gros débats houleux sur les modules, les coroutines, les contrats, mais pour l'intant, les 3 sont dedans ! Et il n'y a je crois aucun mort à déplorer pendant cette réunion
    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
    Futur Membre du Club
    Homme Profil pro
    Étudiant
    Inscrit en
    février 2019
    Messages
    4
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 24
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : février 2019
    Messages : 4
    Points : 5
    Points
    5

    Par défaut

    Je suis pas d'accord avec le fait que C++ est en retard par rapport aux autres langages comme C# ou Julia sachant que C++ est complètement à part par rapport à ces langages. Déjà C++ permet de faire pas mal de choses que les autres langages ne permettent pas (alors que l'inverse n'existe pas, c'est juste que ça peut être compliqué à faire ). Surtout que maintenant avec la standardisation de C++ et la librairie STL qui va avec, c'est un langage qui est puissant, sophistiqué, et surtout performant. Après même si Julia à l'air plutôt sympa, et même avoir des performances proche de C++, je pense pas que l'on puisse envisager de migrer des projet de C++ vers Julia. Et je ne pense pas non plus que les gens vont lâcher C++ au profit de Julia ou de C# (surtout pour le C# qui est plus un concurrent pour Java). D'ailleurs, l'argument comme quoi Julia a des performances proche de C++, je pense qu'on peut assez vite s'en éloigner si on arrive sur des projets qui commence à être complexe (à condition d'utiliser correctement les mécanisme du C++ visant à optimiser son programme, et on peut aller encore plus loin si on décide d'être vraiment bas niveau, et donc d'éviter au maximum d'utiliser la librairie STL). De plus, sur certaines applications, le garbage collector ça pose vite des problèmes pour les performances. Par contre Julia sera surtout un concurrent pour Python, ce qui est une très bonne chose. D'ailleurs tu remarqueras aussi que pour faire de la programmation système C et C++ n'ont pas vraiment de concurrent

    Sinon, je voulais savoir, est ce que c'est dans C++20 qu'ils ont prévu de pouvoir restreindre les types génériques (comme en Java par exemple) ?
    Et est ce que c'est prévu qu'ils règlent le problème où l'ont doit inclure le fichier source dans le header quand on fait de la généricité ? C'est le côté moche du C++ je trouve Surtout que du coup on ne peut pas faire du using namespace dans le fichier source au quel cas cela va se répercuter dans les autres fichiers sources.

  8. #8
    Responsable Qt & Livres


    Avatar de dourouc05
    Homme Profil pro
    Ingénieur de recherche
    Inscrit en
    août 2008
    Messages
    24 336
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur de recherche
    Secteur : Enseignement

    Informations forums :
    Inscription : août 2008
    Messages : 24 336
    Points : 160 238
    Points
    160 238

    Par défaut

    Citation Envoyé par G_EREMY Voir le message
    Déjà C++ permet de faire pas mal de choses que les autres langages ne permettent pas (alors que l'inverse n'existe pas, c'est juste que ça peut être compliqué à faire ).
    Quoi, par exemple ? Je n'ai en tête que des syntaxes spécifiques que C++ autorise (merci les templates), mais pas de fonctionnalité qu'un autre langage ne saurait pas implémenter (peut-être pas avec la même performance, mais le C++ ne gagne pas non plus à tous les coups).
    Vous souhaitez participer aux rubriques Qt ou PyQt (tutoriels, FAQ, traductions), HPC ? Contactez-moi par MP.

    Créer des applications graphiques en Python avec PyQt5
    Créer des applications avec Qt 5.

    Pas de question d'ordre technique par MP !

  9. #9
    Futur Membre du Club
    Homme Profil pro
    Étudiant
    Inscrit en
    février 2019
    Messages
    4
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 24
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : février 2019
    Messages : 4
    Points : 5
    Points
    5

    Par défaut

    Citation Envoyé par dourouc05 Voir le message
    Quoi, par exemple ? Je n'ai en tête que des syntaxes spécifiques que C++ autorise (merci les templates), mais pas de fonctionnalité qu'un autre langage ne saurait pas implémenter (peut-être pas avec la même performance, mais le C++ ne gagne pas non plus à tous les coups).
    Bah déjà l'héritage multiple, l'héritage par spécialisation, le multi-thread, le multi-processus, et tout ce qui concerne le système. Après effectivement il n'y a pas de choses que C++ permet de "calculer" mais qui n'est pas calculable dans C#, Julia, etc...

  10. #10
    Expert éminent sénior

    Homme Profil pro
    Architecte technique
    Inscrit en
    juin 2003
    Messages
    5 667
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Architecte technique

    Informations forums :
    Inscription : juin 2003
    Messages : 5 667
    Points : 10 164
    Points
    10 164
    Billets dans le blog
    3

    Par défaut

    Citation Envoyé par Mingolito Voir le message
    l'avenir c'est clairement le langage xxx qui n'a que des avantages
    https://blog.daftcode.pl/hype-driven...t-3469fc2e9b22

  11. #11
    Membre émérite
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    juin 2011
    Messages
    585
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Hérault (Languedoc Roussillon)

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

    Informations forums :
    Inscription : juin 2011
    Messages : 585
    Points : 2 835
    Points
    2 835

    Par défaut

    Citation Envoyé par G_EREMY Voir le message
    Bah déjà (1) l'héritage multiple, (2) l'héritage par spécialisation, (3) le multi-thread, le multi-processus, et tout ce qui concerne le système.
    1) La plupart supportent l'héritage multiple d'interface et l’injection de trait (directement à l'intérieur d'une classe ou de manière externe).
    2) Du CRTP ? C'est vrai que de manière générale les autres langages sont plus limitants au niveau du fonctionnement des templates.
    3) Ce n'est pas du ressort du C++, mais des bibliothèques. Après, pour les quelques mots clefs comme thread_local, je pense qu'on peut trouver des équivalents.

    utiliser correctement les mécanismes du C++ visant à optimiser son programme, et on peut aller encore plus loin si on décide d'être vraiment bas niveau, et donc d'éviter au maximum d'utiliser la librairie STL)
    La STL est optimisation/bas niveau n'est pas incompatible. Il y a certaines parties qui peuvent être problématique, mais une bonne partie est censé être performant. Si ce n'est pas le cas, la meilleure chose à faire est de patcher les implémentations pour que tous le monde en profite.

    est-ce prévu de pouvoir restreindre les types génériques (comme en Java par exemple) ?
    Les concepts devraient permettre cela. Actuellement on peut le faire avec std::enable_if/SFINAE ou des static_assert.

    Et est ce que c'est prévu qu'ils règlent le problème où l'on doit inclure le fichier source dans le header quand on fait de la généricité ?
    Ce n'est pas possible pour plusieurs raisons:

    - Le prototype peut dépendre de l'implémentation, par exemple avec une fonction qui retourne auto.
    - Les instances de fonction template n'existe qu'au moment de leur utilisation. Pour les mettre dans un .cpp, il faudrait alors instancier les mêmes fonctions dans le cpp pour ne pas avoir des erreurs de link. On peut utiliser des instanciations explicite et extern(?), mais cela cause d'autre soucis pour une classe: toutes les fonctions doivent compiler, même si elles ne sont jamais utilisées.

    Pour la séparation, le plus commun reste de mettre les implémentations dans un .tpl, tcc, .inl, .whatever et de l'inclure en fin du fichier d'en-tête.

    C'est le côté moche du C++ je trouve Surtout que du coup on ne peut pas faire du using namespace dans le fichier source auquel cas cela va se répercuter dans les autres fichiers sources.
    Il doit bien y avoir moyen de le faire en jouant avec les namespaces

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
     
    namespace malib {
      namespace impl {
        using namespace std;
        namespace v1 {
          // ...
        }
      }
      using namespace impl::v1;
    }


    Après perso, je préfère écrire le namespace ou mettre un alias dessus.

  12. #12
    Membre éprouvé
    Homme Profil pro
    Ingénieur R&D
    Inscrit en
    mai 2016
    Messages
    290
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Ingénieur R&D
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : mai 2016
    Messages : 290
    Points : 1 097
    Points
    1 097

    Par défaut

    Citation Envoyé par Bill Fassinou Voir le message
    ...
    Que pensez-vous de ces nouveautés de C++ 20 ?
    ...
    Surtout intéressé par les modules (et le reste est aussi utile bien sur). On attend maintenant les compilateurs bien stabilisés qui gèrent tout ça.
    Pour le réseau, c'est un peu dommage que ce ne soit pas intégré, mais ce n'est pas bien critique non plus, même si j'en aurais vraiment l'usage, ça fait longtemps qu'on a pris l'habitude d'utiliser des bibliothèques externes.

  13. #13
    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 : 44
    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 009
    Points
    16 009

    Par défaut

    Citation Envoyé par G_EREMY Voir le message
    Sinon, je voulais savoir, est ce que c'est dans C++20 qu'ils ont prévu de pouvoir restreindre les types génériques (comme en Java par exemple) ?
    Ce sont les concepts. Mais c'estg fait en respectant le duck-typing, ce qui est une force majeure des templates par rapport aux génériques du Java qui imposant aux paramètres de se déclarer génériques.

    Citation Envoyé par G_EREMY Voir le message
    Et est ce que c'est prévu qu'ils règlent le problème où l'ont doit inclure le fichier source dans le header quand on fait de la généricité ? C'est le côté moche du C++ je trouve Surtout que du coup on ne peut pas faire du using namespace dans le fichier source au quel cas cela va se répercuter dans les autres fichiers sources.
    Header ? Qu'est-ce donc que ça ? Maintenant, il y a les modules qui permettent une organisation efficace du code source. Bon, il faut encore attendre un peu que les compilateurs les implémentent bien et que les outils autour du langage se mettent à jour (ce qui n'est pas forcément trivial), mais le chemin est ouvert.
    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.

  14. #14
    Futur Membre du Club
    Homme Profil pro
    Étudiant
    Inscrit en
    février 2019
    Messages
    4
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 24
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : février 2019
    Messages : 4
    Points : 5
    Points
    5

    Par défaut

    Citation Envoyé par jo_link_noir Voir le message
    1) La plupart supportent l'héritage multiple d'interface et l’injection de trait (directement à l'intérieur d'une classe ou de manière externe).
    Oui bien sure heureusement que tous les langages orienté objets digne de ce nom permette l'héritage multiple d'interface moi je parlais d'héritage multiple de classe (plus le fait qu'il y a l'héritage multiple "par copie" et virtuel). Après je sais que par exemple PHP implémente les traits, mais en ce qui concerne C#, Java, Julia et Pyhton je sais pas, mais ça répond pas à tous les problèmes que l'héritage multiple résolve (après le principe est plutôt pas mal).

    Citation Envoyé par jo_link_noir Voir le message
    2) Du CRTP ? C'est vrai que de manière générale les autres langages sont plus limitants au niveau du fonctionnement des templates.
    Je parlais plus de choses comme Mixin (mais c'est vrai que CRTP aussi est intéressant comme mécanisme). Plus aussi le fait qu'on est libre de faire ce que l'on veut avec des types génériques.

    Citation Envoyé par jo_link_noir Voir le message
    3) Ce n'est pas du ressort du C++, mais des bibliothèques. Après, pour les quelques mots clefs comme thread_local, je pense qu'on peut trouver des équivalents.
    J'ai pas très bien compris, justement en C++ on peut faire des choses plus puissante (parce qu'on créer des threads et des sous-processus), plus les mécanisme comme les mutex, les sémaphores, et autres IPC. Par contre c'est vrai que la bibliothèque STL pourrait implémenter des choses pour éviter de "réinventer la roue" avec des mécanisme comme RMI par exemple.

    Citation Envoyé par jo_link_noir Voir le message
    Les concepts devraient permettre cela. Actuellement on peut le faire avec std::enable_if/SFINAE ou des static_assert.
    Oui effectivement, après je pense juste que ça serais mieux que ce soit dans la déclaration du template même, comme ça la restriction du type ce fait dans le fichier d'en-tête et non pas dans le source. Après ça reste mon avis.

    Citation Envoyé par jo_link_noir Voir le message
    Ce n'est pas possible pour plusieurs raisons:

    - Le prototype peut dépendre de l'implémentation, par exemple avec une fonction qui retourne auto.
    - Les instances de fonction template n'existe qu'au moment de leur utilisation. Pour les mettre dans un .cpp, il faudrait alors instancier les mêmes fonctions dans le cpp pour ne pas avoir des erreurs de link. On peut utiliser des instanciations explicite et extern(?), mais cela cause d'autre soucis pour une classe: toutes les fonctions doivent compiler, même si elles ne sont jamais utilisées.

    Pour la séparation, le plus commun reste de mettre les implémentations dans un .tpl, tcc, .inl, .whatever et de l'inclure en fin du fichier d'en-tête.
    Je connais dans les "grandes lignes" le mécanisme qui se fait à la compilation pour les template (et que du coup un tpp n'est jamais compilé). Par contre je trouve ça dommage qu'ils aient pas trouver une solution pour remédier à ce "problème". Par exemple, on pourrait déclarer au compilateur quels sont les fichier tpp à utiliser, avec une commande du style:
    [c]g++ -o exec file1.cpp file2.cpp filen.cpp -t temp1.tpp temp2.tpp tempn.tpp


    Citation Envoyé par jo_link_noir Voir le message
    Il doit bien y avoir moyen de le faire en jouant avec les namespaces

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
     
    namespace malib {
      namespace impl {
        using namespace std;
        namespace v1 {
          // ...
        }
      }
      using namespace impl::v1;
    }


    Après perso, je préfère écrire le namespace ou mettre un alias dessus.
    Ah ouais merci pour l'astuce faudra que je teste ça. Sinon ce que je fais en temps normal c'est des using dans la déclaration de la classe mais c'est pas toujours très très pratique.

  15. #15
    Futur Membre du Club
    Homme Profil pro
    Étudiant
    Inscrit en
    février 2019
    Messages
    4
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 24
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : février 2019
    Messages : 4
    Points : 5
    Points
    5

    Par défaut

    Citation Envoyé par JolyLoic Voir le message
    Ce sont les concepts. Mais c'estg fait en respectant le duck-typing, ce qui est une force majeure des templates par rapport aux génériques du Java qui imposant aux paramètres de se déclarer génériques.
    Oui j'avais remarqué ça en C++, après pouvoir restreindre le type bah déjà ça permet d'éviter au projet de prendre une tournure où on fait "n’importe quoi", mais aussi de rendre le code plus lisible.

    Citation Envoyé par JolyLoic Voir le message
    Header ? Qu'est-ce donc que ça ? Maintenant, il y a les modules qui permettent une organisation efficace du code source. Bon, il faut encore attendre un peu que les compilateurs les implémentent bien et que les outils autour du langage se mettent à jour (ce qui n'est pas forcément trivial), mais le chemin est ouvert.
    faudra que je me renseigne sur ce sujet alors

  16. #16
    Expert éminent
    Homme Profil pro
    Analyste/ Programmeur
    Inscrit en
    juillet 2013
    Messages
    2 820
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Analyste/ Programmeur

    Informations forums :
    Inscription : juillet 2013
    Messages : 2 820
    Points : 6 228
    Points
    6 228

    Par défaut

    Citation Envoyé par G_EREMY Voir le message
    Je connais dans les "grandes lignes" le mécanisme qui se fait à la compilation pour les template (et que du coup un tpp n'est jamais compilé). Par contre je trouve ça dommage qu'ils aient pas trouver une solution pour remédier à ce "problème".
    Si la solution existe depuis 2003 ... avec l'ajout du mot-clef "export" dans la norme (<- qui fut un énorme four ou )

    Mais justement le développeur d'un compilateur C++ (Digital Mars ???) avait été le seul à le supporter et avait partagé le bouzin à coder le truc.

    Le problème c'est que si une partie d'un projet ou un projet modifie un template, il faut [répercuter les changements]/ [vérifier les autres endroits] où est utilisé le template.
    Actuellement c'est fait à chaque compilation

  17. #17
    Expert éminent sénior

    Homme Profil pro
    Architecte technique
    Inscrit en
    juin 2003
    Messages
    5 667
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Architecte technique

    Informations forums :
    Inscription : juin 2003
    Messages : 5 667
    Points : 10 164
    Points
    10 164
    Billets dans le blog
    3

    Par défaut

    Citation Envoyé par foetus Voir le message
    Si la solution existe depuis 2003 ... avec l'ajout du mot-clef "export" dans la norme (<- qui fut un énorme four ou )

    Mais justement le développeur d'un compilateur C++ (Digital Mars ???) avait été le seul à le supporter et avait partagé le bouzin à coder le truc.
    Je crois que c'est le Front-End d'EDG qui l'a implémenté. Je sais pas si les compilateurs qui l'utilisent ont suivi (Intel?). En tous cas c'est l'effort démesuré pour implémenter cette feature qui a fait qu'elle a été retirée de la norme.

    Mais sinon pour le côté "archaïque" du mécanisme d'inclusion en C++, cette norme 2020 est censée amorcer le virage vers quelque chose de plus moderne grâce aux modules. Encore un peu de patience...

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    import std.core; 
     
    int main() { 
        using namespace std; 
        vector<string> v { "Plato", "Descartes", "Bacon" }; 
        copy(v.begin(), v.end(), ostream_iterator<string>(cout, "\n")); 
    }
    https://devblogs.microsoft.com/cppbl...l-studio-2017/

  18. #18
    Membre expert

    Profil pro
    Inscrit en
    février 2006
    Messages
    2 054
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : février 2006
    Messages : 2 054
    Points : 3 273
    Points
    3 273

    Par défaut

    qu'est ce que j'aimerais qu'il y ait un nettoyage de la syntaxe du c++, le langage est bien, mais stupidement complexe à écrire, et plus ça va, plus on ajoute des syntaxes illogiques sur un socle stupide ;
    les excuses habituelles de la rétrocompatibilité et de faire évoluer son code ne tiennent pas une seule seconde.

    qu'est ce qui est passé par la tête du comité pour se dire que par exemple ça : virtual int foo() override
    c'est acceptable niveau syntaxe? (et ça c'est encore gentillet comme exemple de stupidité)

    combien de fois j'ai lu des articles de pontes du c++ qui disent que la syntaxe pour telle fonctionnalité est stupide.

    je vois souvent des moqueries sur la syntaxe de javascript, bah ça y est, on a les mêmes absurdités en c++.

    on rajoute des fonctionnalités à c++, cool, mais à quel prix en terme d'écriture...

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

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

    Informations forums :
    Inscription : juin 2002
    Messages : 2 154
    Points : 4 427
    Points
    4 427

    Par défaut

    Citation Envoyé par stardeath Voir le message
    les excuses habituelles de la rétrocompatibilité et de faire évoluer son code ne tiennent pas une seule seconde.
    Pourquoi ?

    Je ne vois pas comment on pourrais se passer, au moins à court terme (et donc sur une ou deux versions successives), de rétrocompatibilité. Et donc il n'est pas anormal de continuer à supporter des syntaxes anciennes bien que gênantes.

    Citation Envoyé par stardeath Voir le message
    qu'est ce qui est passé par la tête du comité pour se dire que par exemple ça : virtual int foo() override
    c'est acceptable niveau syntaxe? (et ça c'est encore gentillet comme exemple de stupidité)
    Autant je suis d'accord qu'il existe des syntaxes qui, au moins en partant d'une feuille blanche, pourrait être grandement améliorer, autant ici je ne vois pas vraiment de souci. Sachant en outre que le virtual est ici inutile et que le code effectivement écrit serait plus certainement int foo() override

  20. #20
    Membre expert

    Profil pro
    Inscrit en
    février 2006
    Messages
    2 054
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : février 2006
    Messages : 2 054
    Points : 3 273
    Points
    3 273

    Par défaut

    sauf que là, on est pas sur 1 ou 2 version de rétrocompatibilité, mais sur une rétrocompatibilité presque totale, sauf des fois, où le comité casse une rétro out of nowhere.
    et le pire étant une compatibilité avec le c, qui ne ce justifie pas vu la différence de langage et surtout la totale différence d'évolution du c.

    le problème de garder des syntaxes gênantes, c'est ce que j'énonce, c'est que tu vas rajouter une incohérence supplémentaire sur un truc déjà bancal pour whatever raison ;

    pour reprendre mon example, virtual int foo() override, avec le virtual devant (l'omettre est pour moi une très mauvaise pratique, vu que le override est ailleurs dans le code) les mots clés/mots clés contextuels donnant des informations sur un seul aspect du langage sont à 2 endroits différents dans le code, totalement en contradiction avec le simple fait d'écrire au même endroit les trucs qui concerne la même chose.

    de plus, selon comment le comité est luné (désolé de prendre le comité pour une seule entité, mais c'est plus court à écrire et à expliciter ma pensée), dixit les membres du comité, des fois ils vont "se résoudre" à ajouter des mots clés décorés genre "co_yield", pour n'en citer qu'un, et là pour le cas du override, ils vont en faire un mot clé contextuel à un endroit étrange dans le code. pourquoi, pour ne pas avoir de collision, avoir choisi par exemple vi_override, pour garder une cohérence ; donc avec mon exemple complet :

    virtual vi_override int foo()

    et là, je trouverai cohérent d'omettre le virtual, vu que l'autre information complétant la "virtualité" de cette fonction ce trouve au strict voisinage donc : vi_override int foo().

    pour continuer sur des exemples d'incohérences, je mets d'autres exemples :

    - final et override en mot clé contextuel, à l'opposé du placement de virtual ;
    - co_await, co_return et co_yield, décoré avec le préfix "co_" ;
    - __has_include, décoré avec le préfix "__" ;
    etc.

    le problème que ça cache selon moi, c'est qu'il n'y a personne dans le bateau pour essayer de donné au langage une cohérence d'écriture.
    autant avec les anciennes features, je peux comprendre qu'on ne puisse pas les reprendre, autant depuis c++11 on devrait avoir une instance dans le comité pour garder une cohérence dans l'écriture des nouvelles fonctionnalités, avec par exemple que les problèmes de collisions de noms avec les bases de code existantes, soit résolus en utilisant les mêmes moyens.

    non seulement au niveau du développeur, ça fait une spécification incohérente à lire/retenir/utiliser ; quand tu écris des outils d'analyses du c++, la grammaire à écrire/traiter est juste inbouffable et propice aux erreurs.

    pour moi la solution aurait été d'avoir la possibilité d'indiquer par un quelconque moyen la version de c++ à utiliser par fichier à la compilation et donc de faire évoluer son code, non pas en mettant l'ancien et le nouveau code dans un seul et même fichier, mais en les mettant dans différentes unités de compil, ça aurait selon moi été une contrainte moins gênante que l'espèce de château de carte avec lequel on est rendu.

    je dis pas que c'est une solution parfaite, loin de là, mais avec le c++ tel qu'il évolue, on est quand même de plus en plus loin d'un langage agréable à utiliser, puissant certes, mais stupidement débile à écrire.

Discussions similaires

  1. C11 : la normalisation est achevée
    Par Gordon Fowler dans le forum C
    Réponses: 64
    Dernier message: 13/11/2018, 10h16
  2. [bash] découper un fichier -> agir sur un fichier dés qu'il est achevé
    Par AnozerOne dans le forum Shell et commandes GNU
    Réponses: 5
    Dernier message: 21/06/2011, 20h31
  3. Réponses: 17
    Dernier message: 30/10/2010, 17h49
  4. [Conception] Utiliser un tableau, est-ce grave docteur?
    Par Fabrice ROUXEL 1 dans le forum Webdesign & Ergonomie
    Réponses: 6
    Dernier message: 03/04/2007, 14h43
  5. [Conception] double order by ? est-ce possible ?
    Par harlock59 dans le forum PHP & Base de données
    Réponses: 2
    Dernier message: 22/06/2006, 16h34

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