Publicité
+ Répondre à la discussion Actualité déjà publiée
Page 1 sur 4 1234 DernièreDernière
Affichage des résultats 1 à 20 sur 66
  1. #1
    Community Manager

    Inscrit en
    avril 2014
    Messages
    28
    Détails du profil
    Informations forums :
    Inscription : avril 2014
    Messages : 28
    Points : 97
    Points
    97

    Par défaut Le draft de la prochaine norme C++14 est disponible !

    Le draft de la prochaine norme C++14 est disponible !
    sous le doux nom de N3690

    C++14 est la prochaine norme prévue pour le C++ en 2014, ce depuis l'annonce du planning en novembre 2012.

    La norme C++14 ne sera qu'une modification mineure du langage, visant essentiellement à combler les défauts et les lacunes de la norme C++11 (avec tout de même quelques ajouts de fonctionnalités). Aussi ne contient-elle pas de modifications majeures du langage, pour lesquelles il faudra attendre C++17.

    Le nouveau draft est consultable au format PDF sur isocpp.org : N3690.pdf.

    Il a été approuvé lors du meeting de Bristol durant laquelle les membres du comité ont voté un à un les ajouts faits à ce CD (Committee Draft).

    Les derniers ajouts votés sont notamment :


    Et maintenant ? Le CD va maintenant passer au ballotage des NB (National Bodies, soit les représentants nationaux) qui durera trois mois.

    Le prochain meeting aura lieu fin septembre à Chicago, où si tout se passe bien le CD deviendra un Draft International Standard (DIS), autrement dit le brouillon du prochain standard. Après le DIS vient le ballotage du JTC qui durera 5 mois, puis 2 mois supplémentaires si le ballotage est approuvé, ce qui conduit à la signature de l'International Standard (IS), prévue en été 2014. En cas d'échec lors d'une de ces étapes il sera nécessaire de produire un nouveau CD, ce qui repousse à fin 2014 voir plus loin la signature de l'IS final.

    En parallèle se poursuivent les Technical Specifications (TS - filesystem, networking, concurrency, etc.) et les proposals pour C++1y qui sera cette fois une nouvelle version majeure du langage comme C++11 l'a été pour C++98.

    Votre opinion
    Suivez-vous avec intérêt l'évolution du C++ ?
    Les ajouts votés vous paraissent-t-ils intéressants ?

    Sources
    isocpp.org - le draft C++14
    isocpp.org - rapport du meeting
    Commentaire de M. Wong
    isocpp.org - ISO/IEC JTC1 Procedures

  2. #2
    Expert Confirmé Sénior


    Homme Profil pro Denis
    Étudiant
    Inscrit en
    décembre 2011
    Messages
    4 995
    Détails du profil
    Informations personnelles :
    Nom : Homme Denis
    Âge : 21
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Étudiant
    Secteur : Enseignement

    Informations forums :
    Inscription : décembre 2011
    Messages : 4 995
    Points : 14 893
    Points
    14 893

    Par défaut

    Bonjour,

    Citation Envoyé par germinolegrand Voir le message
    Suivez-vous avec intérêt l'évolution du C++ ?
    On ne peut pas vraiment dire que je suis l'évolution du C++ pourtant c'est une chose que je trouve vraiment intéressante.
    Citation Envoyé par germinolegrand Voir le message
    Les ajouts votés vous paraissent-t-ils intéressants ?
    J'ai regardé vite fait, std::quote me semble assez pratique, std::optionnal nous permettra d'éviter de jouer avec les pointeurs quand on ne veut pas transmettre de valeurs, bref, il y a pas mal de petites choses^^

    Par contre je trouve qu'il manque des fonctionnalité plus "haut niveau" dans le C++ STL comme un std::plugin (manipuler/charger des plugins) ou une fonction permettant d'avoir la liste des serveurs DNS utilisés par l'ordinateur, accéder à des bases de données en renseignant le pilote à utiliser, etc.
    Heureusement boost (loué soit-il) permet déjà de compléter pas mal le C++ ne serait-ce que pour les sockets (std::socket n'existant pas encore à ma connaissance).

    Je pense donc que le C++ n'a pas encore fini de s'améliorer.

  3. #3
    Membre expérimenté

    Homme Profil pro Linunix Inception
    Etudiant
    Inscrit en
    juillet 2012
    Messages
    108
    Détails du profil
    Informations personnelles :
    Nom : Homme Linunix Inception
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Etudiant
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : juillet 2012
    Messages : 108
    Points : 548
    Points
    548

    Par défaut

    "Suivez-vous avec intérêt l'évolution du C++ ?"
    Tout Neckara, je ne suis pas vraiment, j'essaye juste de me mettre à la page, et utiliser ce qui me sert...

    "Heureusement boost (loué soit-il) permet déjà de compléter pas mal le C++ ne serait-ce que pour les sockets (std::socket n'existant pas encore à ma connaissance"

    Oui, en effet, heureusement que Boost est la pour completer la STL, Mais nous savons toi, comme moi, que la STL va intégrér std::socket lors du C++17
    Tout comme ce qui s'est passé avec les threads les threads de boost, sont devenus les threads de la STL

    "Je pense donc, que le C++ n'a pas fini de s'ameliorer"

    Mhhh, disons que les changements entre le C++11 et la prochaine norme ne seront pas énormissimes, tout comme ce qui s'est passé avec la norme 98, et 2003
    Je pense donc, qu'on pourra réelement parler d'une evolution majeure avec la Norme du C++17

    Cela dit, j'attendais peut être un peu le "std::process"
    Le paradigme de chacun ne dépend pas de lui, mais de son éducation...

    Le mot donne à la pensée son existence la plus haute et la plus noble.
    Spinoza

    Quiconque n'est pas choqué par la théorie quantique ne la comprend pas.
    Niels Bohr

    http://isocpp.org/

  4. #4
    Inactif


    Homme Profil pro Guillaume Belz
    Biochimiste
    Inscrit en
    novembre 2008
    Messages
    5 317
    Détails du profil
    Informations personnelles :
    Nom : Homme Guillaume Belz
    Âge : 38
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Biochimiste
    Secteur : Santé

    Informations forums :
    Inscription : novembre 2008
    Messages : 5 317
    Points : 18 047
    Points
    18 047

    Par défaut

    Suivez-vous avec intérêt l'évolution du C++ ?
    Avec beaucoup d'attention (ne serait-ce que pour informer les lecteurs du forum)

    On avait déjà discuter sur le forum de l'absence de certaines fonctionnalités du C++11, comme make_unique (pour supprimer définitive new et par symétrie avec make_shared), optional (pour une gestion plus fine des erreurs dans les retour de fonctions) ou des lambdas génériques.
    J'aime beaucoup aussi les améliorations permettant de simplifier l'écriture du code, comme l'utilisation de auto en retour de fonction ou la simplification de l'utilisation des traits.
    Pour shared_mutex et exchange, Emmanuel Deloget va peut être nous écrire un article là dessus ? (maintenant qu'il a commencé une série d'articles sur les theads en C++ )


    Finalement, ce qui me plait le plus dans ce "C++ moderne", c'est le fait d'avoir des cycles de mise à jour plus courts ! Et de voir que le comité va (peut être ?) réussir à tenir le planning.

  5. #5
    Membre habitué
    Homme Profil pro Jérôme Leclercq
    Développeur de jeux vidéo
    Inscrit en
    février 2009
    Messages
    132
    Détails du profil
    Informations personnelles :
    Nom : Homme Jérôme Leclercq
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur de jeux vidéo
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2009
    Messages : 132
    Points : 114
    Points
    114

    Par défaut

    Très intéressant, mais j'espère qu'ils vont inclure quelque chose dans cette norme (Ou au pire dans le C++17): le static_if

  6. #6
    Expert Confirmé
    Avatar de Klaim
    Homme Profil pro Joel Lamotte
    Développeur de jeux vidéo
    Inscrit en
    août 2004
    Messages
    1 717
    Détails du profil
    Informations personnelles :
    Nom : Homme Joel Lamotte
    Localisation : France

    Informations professionnelles :
    Activité : Développeur de jeux vidéo
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : août 2004
    Messages : 1 717
    Points : 3 334
    Points
    3 334

    Par défaut

    Citation Envoyé par Lynix Voir le message
    Très intéressant, mais j'espère qu'ils vont inclure quelque chose dans cette norme (Ou au pire dans le C++17): le static_if
    Nope, il a ete ecarte. Voir ce papier: http://isocpp.org/blog/2013/03/n3613...-if-considered

    En gros, ils ont des arguments comme quoi ca marchera pas bien pour le C++ et sera meme dangereux. C'est partiellement discutable, mais ce document a ete suivi d'un rdv ou ils ont decide qu'ils feraient mieu de se concentrer sur les concepts d'abord et de peut etre reconsiderer plus tard, meme si ya peu de chances si quelqu'un les relance pas sur le sujet. Donc le sujet est clos au moins temporairement.

  7. #7
    Modérateur
    Avatar de koala01
    Profil pro Philippe Dunski
    Inscrit en
    octobre 2004
    Messages
    9 733
    Détails du profil
    Informations personnelles :
    Nom : Philippe Dunski
    Âge : 42

    Informations forums :
    Inscription : octobre 2004
    Messages : 9 733
    Points : 17 209
    Points
    17 209

    Par défaut

    Salut,
    Citation Envoyé par germinolegrand Voir le message
    Suivez-vous avec intérêt l'évolution du C++ ?
    Avec beaucoup d'intérêt, comme sans doute toute personne qui préfère vraiment C++ aux autres langages mais qui apprécie d'avoir un langage "moderne"
    Les ajouts votés vous paraissent-t-ils intéressants ?
    Très


    Citation Envoyé par Neckara Voir le message
    Bonjour,

    Par contre je trouve qu'il manque des fonctionnalité plus "haut niveau" dans le C++ STL comme un std::plugin (manipuler/charger des plugins) ou une fonction permettant d'avoir la liste des serveurs DNS utilisés par l'ordinateur, accéder à des bases de données en renseignant le pilote à utiliser, etc.
    Cela finira surement par arriver, patience
    Heureusement boost (loué soit-il) permet déjà de compléter pas mal le C++
    J'ai souvent tendance à considérer boost comme représentatif de ce que pourrait être C++, car il ajoute un tas de fonctionnalités portables et intéressantes.

    L'énorme avantage de boost est, justement, qu'il s'agit d'un projet "personnel" (même si l'équipe est importante) et qu'il n'est pas soumis aux mêmes impératifs que la norme.

    Il peut donc évoluer beaucoup plus vite que la norme
    ne serait-ce que pour les sockets (std::socket n'existant pas encore à ma connaissance).
    Les sockets, les threads sont de parfaits exemple de ce qu'une bibliothèque "tierce" peut faire beaucoup plus rapidement que la norme.

    Il existe déjà certaines normes qui présentent les threads et les socket (comme la norme posix, il me semble), mais les systèmes qui ont décidé (à tord ou à raison) de ne pas la respecter n'ont, a priori, aucune raison de s'y contraindre.

    S'il est *relativement* "facile" pour une bibliothèque tierce de décider d'une interface pour des threads ou des sockets qui permette la portabilité, la norme nécessite un certain corum quant à son acceptation et regroupe des décideurs ayant, parfois, des divergences importantes d'opinion.

    Comme boost a, de plus, l'énorme avantage de disposer d'un très large publique, de nombreux utilisateurs, son utilisation est relativement "naturelle" dés qu'un besoin n'est pas satisfait par ce que propose la norme.

    Les "us et coutumes" induits par boost deviennent donc assez rapidement une "norme de fait", et il est donc relativement "logique" que la norme se base fortement sur boost lorsqu'il s'agit de décider d'ajouter quelque chose au standard.

    Seulement, la norme doit aussi apporter un formalisme beaucoup plus important que ce que n'importe quel bibliothèque tierce ne doit le faire, et c'est sans doute pour cela que l'intégration est susceptible de prendre du temps

    Je pense donc que le C++ n'a pas encore fini de s'améliorer.
    Je le pense aussi, et je l'espère de tout coeur
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  8. #8
    Expert Confirmé Sénior

    Homme Profil pro Emmanuel Deloget
    Développeur informatique
    Inscrit en
    septembre 2007
    Messages
    1 894
    Détails du profil
    Informations personnelles :
    Nom : Homme Emmanuel Deloget
    Âge : 38
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : septembre 2007
    Messages : 1 894
    Points : 4 448
    Points
    4 448

    Par défaut

    Citation Envoyé par Neckara Voir le message
    Bonjour,

    On ne peut pas vraiment dire que je suis l'évolution du C++ pourtant c'est une chose que je trouve vraiment intéressante.

    J'ai regardé vite fait, std::quote me semble assez pratique, std::optionnal nous permettra d'éviter de jouer avec les pointeurs quand on ne veut pas transmettre de valeurs, bref, il y a pas mal de petites choses^^
    J'ai vraiment du mal à voir l'intérêt de std::optional, dans le sens où les alternatives (pointeur, valeur par défaut...) ne manquent pas - et qu'au niveau architectural, un std:optional n'a pas beaucoup de sens.

    Je vais donc regarder ça d'un oeil nouveau, histoire de peser le pour et le contre.

    Citation Envoyé par Neckara Voir le message
    Par contre je trouve qu'il manque des fonctionnalité plus "haut niveau" dans le C++ STL comme un std::plugin (manipuler/charger des plugins)
    Ah... A la limite, un système de chargement déchargement de librairies dynamiques, je suis pour. Appeler ça std::plugin, ça reviendrait à imposer aux applications un système qui ne peut pas être générique (et n'est d'ailleurs pas souhaitable). Un plugin peut prendre différentes formes - code natif, code interprété... Bref : la fonctionnalité de base : oui ; un std::plugin: non.

    Citation Envoyé par Neckara Voir le message
    ou une fonction permettant d'avoir la liste des serveurs DNS utilisés par l'ordinateur,
    Pour autant que je me le rappelle, c'est en cours. Et la solution viendra à priori de la librairie asio.

    Citation Envoyé par Neckara Voir le message
    accéder à des bases de données en renseignant le pilote à utiliser, etc.
    A l'heure actuelle il n'existe aucun standard pour permettre l'accès aux base de données. Il y a autant de systèmes que d'OS et de DB différents. Si on rajoute à ça les différents types de SGBD (relationnel, objet, nosql...) on arrive à quelque chose qui, mon avis, n'est pas normalisable.

    Ce qui peut être normalisé, par contre, c'est une extension du langage genre linq (voire une extension de la librairie qui fournit des services similaires). L'idée est de travailler sur des collections (i.e. des conteneurs). Il devrait être possible d'écrire :

    Code :
    1
    2
    3
    4
    5
    6
     
    from(collection1, collection 2).select([](const col1type::value_type&a, const col2type::value_type& b) {
        return std::make_tuple(a.id, b.info1, b.info2);
    }).where([](const col1type::value_type&a, const col2type::value_type& b) {
         return a.somevalue == b.othervalue;
    });
    Ce code peut déjà être écrit en C++11. Une extension de ce type peut fournir l'essentiel des services qui sont généralement utilisés sur un SGBD. De plus, il peut être écrit de manière à spécialiser l'accès à un SGBD particulier (tout en continuant de fonctionner sur les conteneurs de la librairie standard).
    [FAQ des forums][FAQ Développement 2D, 3D et Jeux][Si vous ne savez pas ou vous en êtes...]
    Essayez d'écrire clairement (c'est à dire avec des mots français complets). SMS est votre ennemi.
    Evitez les arguments inutiles - DirectMachin vs. OpenTruc ou G++ vs. Café. C'est dépassé tout ça.
    Et si vous êtes sages, vous aurez peut être vous aussi la chance de passer à la télé. Ou pas.

    Ce site contient un forum d'entraide gratuit. Il ne s'use que si l'on ne s'en sert pas.

  9. #9
    Modérateur
    Avatar de koala01
    Profil pro Philippe Dunski
    Inscrit en
    octobre 2004
    Messages
    9 733
    Détails du profil
    Informations personnelles :
    Nom : Philippe Dunski
    Âge : 42

    Informations forums :
    Inscription : octobre 2004
    Messages : 9 733
    Points : 17 209
    Points
    17 209

    Par défaut

    Citation Envoyé par Emmanuel Deloget Voir le message
    J'ai vraiment du mal à voir l'intérêt de std::optional, dans le sens où les alternatives (pointeur, valeur par défaut...) ne manquent pas - et qu'au niveau architectural, un std:optional n'a pas beaucoup de sens.
    Et pourtant, il me semble qu'il en est peut etre question pour "plus tard" (2017 )

    Ceci dit, je ne suis pas particulièrement d'accord avec toi sur ce coup:

    Les valeurs par défaut, c'est bien, mais cela implique de définir une valeur qui puisse être considérée comme "invalide" (est-ce -1 , std::numeric_limits<>::max() , autre chose ) et les pointeurs... Bah, on est tous conscients des problèmes qu'ils peuvent occasionner

    Indépendamment de la manière dont std:: optionnal serait implémenté, le fait de pouvoir dire explicitement qu'une valeur peut ne pas exister et de pouvoir déterminer si elle existe ou non aurait de nombreux avantages.

    Regardes "simplement" toutes les parties optionnelles que l'on peut retrouver dans la simple déclaration d'une fonction membre:
    1. accessibilité -->optionnel
    2. static | virtual --> optionnel
    3. type de retour --> requis
    4. constant | volatile -->optionnel
    5. pointeur | référence --> optionnel
    6. array -->optionnel
    7. nom -->requis
    8. parenthèse ouvrante -->requis
    9. liste d'arguments --> optionnel
    10. parenthèse fermante -->requis
    11. const qualifier -->optionnel
    12. end of statment -->requis
    Sur douze éléments susceptibles d'apparaitre dans une "simple" déclaration de fonction, plus de la moitié sont des éléments optionnels, dont l'absence a une signification propre.

    Le fait de pouvoir dire que quelque chose peut ne pas exister et de pouvoir donner une signification à cette non existence peut faciliter grandement la vie, et pas seulement au niveau des AST
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  10. #10
    Inactif


    Homme Profil pro Guillaume Belz
    Biochimiste
    Inscrit en
    novembre 2008
    Messages
    5 317
    Détails du profil
    Informations personnelles :
    Nom : Homme Guillaume Belz
    Âge : 38
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Biochimiste
    Secteur : Santé

    Informations forums :
    Inscription : novembre 2008
    Messages : 5 317
    Points : 18 047
    Points
    18 047

    Par défaut

    On en avait parlé lors des traductions des articles sur les retours d'erreur, il me semble.
    Pour moi, finalement ce n'est rien d'autre qu'un pair<bool, T> avec un sémantique adapté et sécurisé. C'est que l'on a par exemple avec map::find, qui retourne un pair<iterator, bool>.

  11. #11
    Membre émérite Avatar de jmnicolas
    Homme Profil pro
    Développeur informatique
    Inscrit en
    juin 2007
    Messages
    408
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France

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

    Informations forums :
    Inscription : juin 2007
    Messages : 408
    Points : 908
    Points
    908

    Par défaut

    <troll>
    Vu qu'ils ont mis 8 ans pour sortir la précédente révision on peut estimer que C++14 s’appellera C++19, voir C++2x
    </troll>
    The greatest shortcoming of the human race is our inability to understand the exponential function. Albert A. Bartlett

    La plus grande lacune de la race humaine c'est notre incapacité à comprendre la fonction exponentielle.

  12. #12
    Membre Expert Avatar de Gugelhupf
    Homme Profil pro
    Développeur informatique
    Inscrit en
    décembre 2011
    Messages
    604
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : décembre 2011
    Messages : 604
    Points : 1 031
    Points
    1 031

    Par défaut

    Parmis tous les points cités je n'en ai compris que 3 (les 2 premiers et la syntaxe sucrée pour les user-defined literals dans la STL ).
    Le C++ est un langage riche, trop riche !

    Pour ma part j'attends plutôt des concepts qui simplifient le développement, ou rend le code source multiplateforme comme :
    • les modules ! (l'équivalent des package/import en Java ou namespace/using en C#).
    • les dates
    • filesystem
    • networking
    • concurrency

  13. #13
    Expert Confirmé
    Avatar de Klaim
    Homme Profil pro Joel Lamotte
    Développeur de jeux vidéo
    Inscrit en
    août 2004
    Messages
    1 717
    Détails du profil
    Informations personnelles :
    Nom : Homme Joel Lamotte
    Localisation : France

    Informations professionnelles :
    Activité : Développeur de jeux vidéo
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : août 2004
    Messages : 1 717
    Points : 3 334
    Points
    3 334

    Par défaut

    Citation Envoyé par Emmanuel Deloget Voir le message
    J'ai vraiment du mal à voir l'intérêt de std::optional, dans le sens où les alternatives (pointeur, valeur par défaut...) ne manquent pas - et qu'au niveau architectural, un std:optional n'a pas beaucoup de sens.
    Aucune des dites alternatives ne travailllent exclusivement qu'avec avec le tas. Soit elles forcent a une allocation sur la pile (les pointeurs intelligents), soient elles empechent l'expression explicite de l'ownership (les pointeurs), soient elles empechent de ne pas avoir de construction du type quand on ne veut pas d'instances (valeurs par defaut).

    Optional est une solution si un de ces cas est un probleme. Ca reste un racourcis pour une sorte d'union a semantique claire.
    De la meme facon que boost::variant est un racourcis "type-safe" de 'void*'.

    Mais, pour rejoindre un poil ce que tu dis, mon experience avec boost::optional est qu'on a pas mal de cas ou on pense que c'est une bonne idee de le retourner plutot qu'autre chose, et ou on a tord sur le long terme.

    Autrement dis, on en a besoin, mais je pense que ca va etre pas mal abuse au debut. Le tout est que la bibliotheque standard n'en abuse pas et donne de bons exemples, et surtout que d'autres developeurs de bibliotheques beaucoup utilisees sachent ne pas l'utiliser a tout bout de champs, par exemple juste pour eviter d'avoir a penser aux exceptions ou aux strategies d'echec des utilisateurs (tout un programme).

  14. #14
    Expert Confirmé
    Avatar de Klaim
    Homme Profil pro Joel Lamotte
    Développeur de jeux vidéo
    Inscrit en
    août 2004
    Messages
    1 717
    Détails du profil
    Informations personnelles :
    Nom : Homme Joel Lamotte
    Localisation : France

    Informations professionnelles :
    Activité : Développeur de jeux vidéo
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : août 2004
    Messages : 1 717
    Points : 3 334
    Points
    3 334

    Par défaut

    Citation Envoyé par gbdivers Voir le message
    On en avait parlé lors des traductions des articles sur les retours d'erreur, il me semble.
    Pour moi, finalement ce n'est rien d'autre qu'un pair<bool, T> avec un sémantique adapté et sécurisé. C'est que l'on a par exemple avec map::find, qui retourne un pair<iterator, bool>.
    Oui et l'important c'est surtout que le comportement soit normalise/standardise et que l'intention soit claire a la lecture.

  15. #15
    Expert Confirmé
    Avatar de Klaim
    Homme Profil pro Joel Lamotte
    Développeur de jeux vidéo
    Inscrit en
    août 2004
    Messages
    1 717
    Détails du profil
    Informations personnelles :
    Nom : Homme Joel Lamotte
    Localisation : France

    Informations professionnelles :
    Activité : Développeur de jeux vidéo
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : août 2004
    Messages : 1 717
    Points : 3 334
    Points
    3 334

    Par défaut

    Pour le troll: ce qui est positif c'est qu'ils ont un exemple de standard qui a pris 13 ans a se faire et qu'ils peuvent utiliser cet exemple pour forcer le bordel a avancer vite, d'ou la mise en place d'une nouvelle version c++14 qui aurait pu ne pas voir le jour puisqu'a l'origine il n'y aurait eu que C++17 de prevu.

    Citation Envoyé par Gugelhupf Voir le message
    Le C++ est un langage riche, trop riche !
    Je suis en train de m'interesser a D et il est plus riche que le C++ actuel.
    Il est aussi plus simple/rapide a utiliser/lire/comprendre.

    Donc "trop riche", non, je ne suis pas d'accord.

    Pour ma part j'attends plutôt des concepts qui simplifient le développement, ou rend le code source multiplateforme comme :
    [LIST][*]les modules ! (l'équivalent des package/import en Java ou namespace/using en C#).
    Avec l'implementation dans clang, je pense qu'il y a des chances pour qu'on ai un TS (ou autre nom pour dire une extension optionelle pas encore standard mais quand meme standardisee si on l'implemente dans un compilateur) avant C++17.

    [*]les dates
    Il me semble que c'est en cours mais c'est pas un sujet facile. Tout le monde a tendance a oublier que le calendrier Gregorien est pas forcement utilise partout. Ils utilisent un autre calendrier au Japon pour les documents officiels par exemple. Je parle meme pas des pays que je connais mal comme au moyen orient.
    Bref je doute que ca arrive vite.

    [*]filesystem
    Il me semble que c'est prevu pour un TS pour la fin de l'annee ou le debut de la suivante, mais qu'il y a peu de chances pour c++14.

    [*]networking
    Visiblement ils sont en train de se mettre d'accord pour le type std::uri, ce qui est deja pas mal, et puis ya boost::asio qui est regarde de pret mais j'ai pas bien compris ou ils en sont parceque std::asio aurait besoin d'une interface sacrement plus lisible que boost::asio...

    [*]concurrency
    Ya eu plein de proposals, quasimment tous rejetes visiblement. Ca necessite encore pas mal de boulot. J'attends les std::future<>::then() avec impatience mais heureusement il y a une implementation en cours dans boost. Pour le reste, les executor sont super interessant comme concept, et aussi tout ce qui est queues concurrentes.

    J'aimerai bien voir async/await en pratique. Peut etre que je devrais regarder voir comment C# marche avec.

  16. #16
    Nouveau Membre du Club
    Inscrit en
    mai 2009
    Messages
    48
    Détails du profil
    Informations forums :
    Inscription : mai 2009
    Messages : 48
    Points : 30
    Points
    30

    Par défaut

    Citation Envoyé par Neckara Voir le message
    Bonjour,

    On ne peut pas vraiment dire que je suis l'évolution du C++ pourtant c'est une chose que je trouve vraiment intéressante.

    J'ai regardé vite fait, std::quote me semble assez pratique, std::optionnal nous permettra d'éviter de jouer avec les pointeurs quand on ne veut pas transmettre de valeurs, bref, il y a pas mal de petites choses^^

    Par contre je trouve qu'il manque des fonctionnalité plus "haut niveau" dans le C++ STL comme un std::plugin (manipuler/charger des plugins) ou une fonction permettant d'avoir la liste des serveurs DNS utilisés par l'ordinateur, accéder à des bases de données en renseignant le pilote à utiliser, etc.
    Heureusement boost (loué soit-il) permet déjà de compléter pas mal le C++ ne serait-ce que pour les sockets (std::socket n'existant pas encore à ma connaissance).

    Je pense donc que le C++ n'a pas encore fini de s'améliorer.
    Concernant les base de données relationnel, je travaille avec plusieurs membres du comité sur l'implémentation et on a déja un mini prototype, qui a été montré à Bristol, utilisant ODBC en backend et ça envoie du bois , je te conseille de lire le paper pre-Bristol datant de mars, trouvable sur google, évidemment.
    Concernant les sockets, j'ai entendu dire que ça sera une simple surcouche aux sockets de Berkeley, à la manière de SFML avec peut être une implémentation de select() / poll() mais rien d'aussi complet et performant qu'asio donc très nettement, il y a peu à attendre d'une impl socket en standard C++.

  17. #17
    Membre Expert Avatar de Gugelhupf
    Homme Profil pro
    Développeur informatique
    Inscrit en
    décembre 2011
    Messages
    604
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : décembre 2011
    Messages : 604
    Points : 1 031
    Points
    1 031

    Par défaut

    @Emmanuel Deloget
    from(collection1, collection 2).select([](const col1type::value_type&a, const col2type::value_type& b) {
    return std::make_tuple(a.id, b.info1, b.info2);
    }).where([](const col1type::value_type&a, const col2type::value_type& b) {
    return a.somevalue == b.othervalue;
    });
    Pourquoi essayer d'imiter LINQ comme C# ? Pourquoi ne pas directement inclure le SQL dans le langage comme le fait PowerBuilder ? (attention je n'ai pas dis que c'est simple à faire ).

    Code :
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
     
    vector<int> myVector;
    myVector.push_back(100);
    // etc...
     
    ResultSet donnees := SELECT *
    FROM myVector
    WHERE value > 3000;
     
    // ou
    sgbd_configuration(instancepostgresql, "chaine de connexion");
     
    ResultSet donnees := SELECT t1.a, t2.b 
    FROM table1 t1
    INNER JOIN table2 t2
    WHERE t1.a < 100;

    @Klaim
    Je suis en train de m'interesser a D et il est plus riche que le C++ actuel.
    Il est aussi plus simple/rapide a utiliser/lire/comprendre.
    Je n'ai pas voulu utiliser le mot complexe. Je fais du C++ depuis 5 ans, et je trouve que c'est le langage avec lequel j'en apprends tous jours.
    Prenons un exemple tout bête :
    Code :
    1
    2
    3
    4
    monObjet.maMethode(); // objet stack
    monObjet->maMethode(); // pointeur
    MaClasse::maMethode(); // méthode statique
    std::vector monVector; // utilisation du namespace
    En Java : On n'utilise que le symbole "." pour tous ces concepts, un IDE comme Eclipse ou Netbeans t'indique en temps réel la signature au passage du curseur.

    Après y a tout plein de petit pièges comme la création d'un objet stack dans le paramètre d'une méthode :
    maMethode(MaClasse()); // Interdit par la norme, autorisée par Visual Studio

    Les pointeurs intelligents... si seulement les mécanismes des pointeurs intelligents étaient automatiquement présent avec les pointeurs nus.

    J'ai pris entre 2 et 3 ans pour faire le tour du standard des langages C, PHP et Java... En C++ non, impossible de faire le tour du standard, même si le standard ne possède pas énormément d'API (pas de connexion BDD, pas de création d'interface graphique, pas de gestion du son et image, pas de socket/date pour le moment etc...), la syntaxe du langage est tout simplement trop riche (pour moi).


    Il me semble que c'est en cours mais c'est pas un sujet facile. Tout le monde a tendance a oublier que le calendrier Gregorien est pas forcement utilise partout. Ils utilisent un autre calendrier au Japon pour les documents officiels par exemple. Je parle meme pas des pays que je connais mal comme au moyen orient.
    Bref je doute que ca arrive vite.
    • Japon : Le calendrier grégorien fut introduit en supplément du calendrier traditionnel le 1er janvier 1873
    • Turquie : Passage du calendrier musulman et Rumî au calendrier grégorien le 1er janvier 1927.

    Source.
    Bon après je ne connais pas tout les pays du Moyen Orient etc mais bon...

    Ce qui serait bien, ce serait d'avoir des dates... mais aussi des dates relatives comme en PHP :
    Code :
    1
    2
    3
    $d = new DateTime("last day of +2 month"); // Date basée sur le dernier jour du +2 mois
    $d = new DateTime("first Wednesday of next month"); // Premier Mercredi du moins prochain
    // Et toutes les variantes !

  18. #18
    Modérateur
    Avatar de koala01
    Profil pro Philippe Dunski
    Inscrit en
    octobre 2004
    Messages
    9 733
    Détails du profil
    Informations personnelles :
    Nom : Philippe Dunski
    Âge : 42

    Informations forums :
    Inscription : octobre 2004
    Messages : 9 733
    Points : 17 209
    Points
    17 209

    Par défaut

    Citation Envoyé par Gugelhupf Voir le message
    Pourquoi essayer d'imiter LINQ comme C# ?
    Emmanuel prenait linq comme exemple, surement pas comme quelque chose à "imiter"
    Pourquoi ne pas directement inclure le SQL dans le langage comme le fait PowerBuilder ? (attention je n'ai pas dis que c'est simple à faire ).
    Heu... d'accord, on prend quel SGBDR comme référence

    Tu n'imagines pas les différences qui peuvent exister au niveau du langage ne serait-ce qu'entre oracle, MsSql et MySql (pour ne citer que ceux là)

    Je ne parle pas de la syntaxe des requête "simples" comme un select sur une seule table (voir meme sur plusieurs), mais de la syntaxe de certaines requêtes avancée

    Je n'ai pas voulu utiliser le mot complexe.
    Tu peux clairement utiliser le mot complexe

    C'est un mot parfaitement assumé, qui vient en complément indissociable de la liberté que le langage offre
    Je fais du C++ depuis 5 ans, et je trouve que c'est le langage avec lequel j'en apprends tous jours.
    Prenons un exemple tout bête :
    Code :
    1
    2
    3
    4
    monObjet.maMethode(); // objet stack
    monObjet->maMethode(); // pointeur
    MaClasse::maMethode(); // méthode statique
    std::vector monVector; // utilisation du namespace
    En Java : On n'utilise que le symbole "." pour tous ces concepts, un IDE comme Eclipse ou Netbeans t'indique en temps réel la signature au passage du curseur.
    Et en java, on fini par ne plus savoir ce qui est une classe, une classe imbriquée, un espace de noms (pardon : un module ) ou si c'est une fonction statique ou non

    D'autant plus que, même si on a tendance à l'oublier, C++ essaye de garder un minimum de compatibilité avec C

    Si l'on venait à décider de n'utiliser que le point comme accesseur, tout en autorisant (pour la compatibilité d'avec C) d'avoir ->, tu imagines un peu le b...l sans nom que cela foutrait
    Après y a tout plein de petit pièges comme la création d'un objet stack dans le paramètre d'une méthode :
    maMethode(MaClasse()); // Interdit par la norme, autorisée par Visual Studio
    Tout à fait autorisé : cela s'appelle une variable temporaire anonyme
    Les pointeurs intelligents... si seulement les mécanismes des pointeurs intelligents étaient automatiquement présent avec les pointeurs nus.
    Cela poserait sans doute plus de problème que cela n'apporterait de solution.

    Une habitude que j'ai prise est d'utiliser les pointeurs intelligents (surtout std::unique_ptr d'ailleurs ) pour les classes qui doivent s'occuper de la gestion de la durée de vie des objets sous-jascents et d'estimer que, lorsque j'ai un pointeur nu, c'est que je n'ai pas à m'inquiéter de le détruire.

    Mais ce n'est qu'une habitude strictement personnelle

    Si l'on fait en sorte que les pointeurs nu soient d'office intelligent, doit on les considérer comme des shared_ptr comme des unique_ptr comme autre chose

    Quel que soit le choix fait, comment fait on pour assurer la compatibilité envers C

    Une fois que le choix est fixé, comment fait on pour s'assurer que tout continue à fonctionner correctement

    Si on choisi que ces des unique_ptr, comment fait on si on veut que ce soit une classe particulière qui s'occupe de leur durée de vie

    J'ai pris entre 2 et 3 ans pour faire le tour du standard des langages C, PHP et Java... En C++ non, impossible de faire le tour du standard, même si le standard ne possède pas énormément d'API (pas de connexion BDD, pas de création d'interface graphique, pas de gestion du son et image, pas de socket/date pour le moment etc...), la syntaxe du langage est tout simplement trop riche (pour moi).
    Je peux te rassurer sur un point : je fais du C++ depuis maintenant plusieurs années et je n'en ai pas encore fait le tour
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  19. #19
    Expert Confirmé
    Avatar de Klaim
    Homme Profil pro Joel Lamotte
    Développeur de jeux vidéo
    Inscrit en
    août 2004
    Messages
    1 717
    Détails du profil
    Informations personnelles :
    Nom : Homme Joel Lamotte
    Localisation : France

    Informations professionnelles :
    Activité : Développeur de jeux vidéo
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : août 2004
    Messages : 1 717
    Points : 3 334
    Points
    3 334

    Par défaut

    Tout pareil que koala1.

    Citation Envoyé par Gugelhupf Voir le message
    • Japon : Le calendrier grégorien fut introduit en supplément du calendrier traditionnel le 1er janvier 1873
    • Turquie : Passage du calendrier musulman et Rumî au calendrier grégorien le 1er janvier 1927.

    Source.
    Bon après je ne connais pas tout les pays du Moyen Orient etc mais bon...
    Oui, et donc le probleme, comme tu peux le voir avec Boost.DateTime c'est tout simplement que ca implique qu'il faut soit:
    - faire une interface commune a tous les calendriers, basee sur des types communs - mais dans ce cas tu perds tous les avantages des verifications a la compilations;
    - faire une interface differente pour chacun des calendriers (avec une partie commune pour faire les conversions de l'un a l'autre, a savoir std::chrono puisque le temps base autour des secondes est tout simplement standard);

    Autrement dis la seconde solution est preferable mais pourrait s'averer etre un boulot titanesque sauf si on ne fournis que le calendrier gregorien au moins au debut. Et meme comme ca ca reste un gros ajout.

    Beaucoup de boulot quoi.

    Ce qui serait bien, ce serait d'avoir des dates... mais aussi des dates relatives comme en PHP :
    Code :
    1
    2
    3
    $d = new DateTime("last day of +2 month"); // Date basée sur le dernier jour du +2 mois
    $d = new DateTime("first Wednesday of next month"); // Premier Mercredi du moins prochain
    // Et toutes les variantes !
    Non ca ne serait pas bien puisque dans ce cas le compilateur ne peut pas verifier que tu fais des conversions absurdes. C'est pour cette raison qu'il y a des types differents pour heure, minute et seconde et miliseconde, etc dans std::chrono, pour que le compilateur t'arrete si tu tente de convertir 190 secondes en minutes (parceque tu perds les virgules par defaut, sauf si tu fais un cast explicit).

    Bref, mieu vaut qu'un maximum d'info soit verifee en amont et ca suppose que les differents types de durees doivent avoir des types fixes. Heureusement, std::chrono (tire de la partie Time de boost:ateTime) est apparement une bone base pour construire le reste.

  20. #20
    Expert Confirmé Avatar de Flob90
    Homme Profil pro Florian Blanchet
    Etudiant en Optique
    Inscrit en
    août 2004
    Messages
    1 317
    Détails du profil
    Informations personnelles :
    Nom : Homme Florian Blanchet
    Âge : 24
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Etudiant en Optique

    Informations forums :
    Inscription : août 2004
    Messages : 1 317
    Points : 2 903
    Points
    2 903

    Par défaut

    Citation Envoyé par germinolegrand Voir le message
    Enfin des lambdas plus simple à utiliser.

    Citation Envoyé par germinolegrand Voir le message
    Très pratique ça, écriture plus courte sans perte d'informations.

    Citation Envoyé par germinolegrand Voir le message
    L'article de Sutter sur le sujet est plus que parlant, j'espère juste que ça sera rapidement mis en place par les compilateurs.

    Citation Envoyé par germinolegrand Voir le message
    • les std::dynarray et Runtime-Sized Arrays (N3662 et N3639) qui permettent de créer des tableaux dont la taille est fixée mais définie à l'exécution, contrairement à std::array et T a[11] qui sont entièrement fixés à la compilation ;
    Ça peut être sympa à utiliser comme conteneur.

    Citation Envoyé par germinolegrand Voir le message
    Rien de neuf, ça peut présenter de l'intérêt dans certains cas, mais moins que dans un langage comme Haskell où il est à la base du système de gestion des erreurs AMA.

    Citation Envoyé par germinolegrand Voir le message
    Idée très pratique pour les cas d'utilisation simple des traits, surtout quand il y en a plusieurs à la suite.

    Citation Envoyé par germinolegrand Voir le message
    [LIST][*]des contraintes moindres pour les fonctions constexpr (N3652) notamment l'utilisation possible de if et for ainsi que la déclaration de variables ; les fonctions constexpr ne sont plus implicitement const ;
    Sympa ça.

    Citation Envoyé par germinolegrand Voir le message
    • les std::shared_mutex (N3659) qui peuvent être bloquées soit de façon exclusive, soit de façon partagée ;
    Rien de nouveau non plus, quelqu'un sait pourquoi ils avaient été écarté lors de l'ajout des thread en C++11 ?

    Citation Envoyé par germinolegrand Voir le message
    • std::exchange (N3668) qui à l'instar des std::atomic_exchange affecte une variable avec une nouvelle valeur et retourne l'ancienne valeur.
    Je vois bien l'intérêt des CAS atomique pour faire de la synchronisation dans les algo lock-free, par contre j'ai plus de mal à voir l'intérêt d'un CAS "normal". Je veux bien qu'on puisse avoir besoin de faire un CAS dans une situation banale, mais c'est une besoin si récurrent qui justifie l'ajout à la bibliothèque standard ?
    "We can solve any problem by introducing an extra level of indirection" Butler Lampson

    "N'importe quel problème peut être résolu en introduisant un niveau d'indirection supplémentaire" Butler Lampson (traduction libre)

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •