Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Contribuez C++ Discussion :

[ISOC++] Mailing pre-Bristol


Sujet :

Contribuez C++

  1. #1
    Community Manager

    Inscrit en
    avril 2014
    Messages
    661
    Détails du profil
    Informations forums :
    Inscription : avril 2014
    Messages : 661
    Points : 2 544
    Points
    2 544
    Par défaut [ISOC++] Mailing pre-Bristol
    Hop, les papiers pour la réunion de Bristol du comité ISO sont tombés :

    http://open-std.org/jtc1/sc22/wg21/d...mailing2013-03

    Enjoy !
    Pour contacter les différents services du club (publications, partenariats, publicité, ...) : Contacts

  2. #2
    Membre émérite

    Inscrit en
    mai 2008
    Messages
    1 014
    Détails du profil
    Informations forums :
    Inscription : mai 2008
    Messages : 1 014
    Points : 2 251
    Points
    2 251
    Par défaut

    C'est quoi ce tsunami de papiers !?
    Il y a en plus de 100 dans ce mailing, c'est du jamais vu, d'habitude ça tourne autour de 20-50.
    Ils vont avoir du pain sur la planche à Britstol pour éplucher tout ça.

  3. #3
    Expert confirmé

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

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

    Informations forums :
    Inscription : septembre 2007
    Messages : 1 895
    Points : 4 536
    Points
    4 536
    Par défaut
    Citation Envoyé par Joel F Voir le message
    Hop, les papiers pour la réunion de Bristol du comité ISO sont tombés :

    http://open-std.org/jtc1/sc22/wg21/d...mailing2013-03

    Enjoy !
    Ah ! De la lecture ! Je m'ennuyais fermement moi !

    J'ai déjà repéré des trucs intéressants (std::integer, par exemple ; même si dans ce cas spécifique, je trouve le design de la classe étrange, et pour certains points contre-productif).

    Je vais jeter un coup d'oeil à tout ça rapidement
    [FAQ des forums][FAQ Développement 2D, 3D et Jeux][Si vous ne savez pas ou vous en êtes...]
    Essayez d'écrire clairement (c'est à dire avec des mots français complets). SMS est votre ennemi.
    Evitez les arguments inutiles - DirectMachin vs. OpenTruc ou G++ vs. Café. C'est dépassé tout ça.
    Et si vous êtes sages, vous aurez peut être vous aussi la chance de passer à la télé. Ou pas.

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

  4. #4
    Membre expert

    Avatar de germinolegrand
    Homme Profil pro
    Développeur de jeux vidéo
    Inscrit en
    octobre 2010
    Messages
    738
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : Développeur de jeux vidéo
    Secteur : Tourisme - Loisirs

    Informations forums :
    Inscription : octobre 2010
    Messages : 738
    Points : 3 756
    Points
    3 756
    Par défaut
    Depuis une semaine ça ne cesse de pleuvoir, j'ai eu du mal à tout éplucher

  5. #5
    Expert confirmé

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

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

    Informations forums :
    Inscription : septembre 2007
    Messages : 1 895
    Points : 4 536
    Points
    4 536
    Par défaut
    Citation Envoyé par germinolegrand Voir le message
    Depuis une semaine ça ne cesse de pleuvoir, j'ai eu du mal à tout éplucher
    Je t'aide :

    • "Proposal for Unbounded-Precision Integer Types" : (types entiers de taille arbitraire) l'idée est bonne, mais la réalisation est à revoir (malgré tout le respect que j'ai pour Pete Becker). Un des points qui me pose problème est le fait que le type std::integer proposé n'est pas liée à un allocateur. Du coup, impossible de contrôler la manière dont la mémoire est allouée. Hors, tel que je le vois, c'est un point nécessaire qui, en outre, ne pose pas de difficulté majeure (Pete Becker semble penser que si). En outre, la présence d'une fonction std::integer::compare() ne me plait pas trop - notamment sur son fonctionnement à la strcmp().
    • "C++ Latches & barriers" : plutôt une bonne chose ; me fait penser au fait que la librairie C++ n'a pas de classe semaphore<>, plus générique des ces deux classes.
    • "Pass by Const Reference or Value" : le point soulevé est intéressant (en gros, problème en cas d'aliasing - si une fonction prends deux argument, un en ref, l'autre en const ref, l'argument en ref peut en fait pointer sur le const ref ou sur une partie de celui-ci. Exemple:

    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
     
    struct A 
    { 
      int a, b; 
      int sum() const { return a + b; }
      int product() const { return a * b; }
    };
    int func(int& out, const A& in)
    {
       out = in.product();
       return out + in.sum();
    }
    // ...
    A a = { 2, 5 };
    int& aa = a.a;
    std::cout << func(aa, a); // meh ?
    .

    • "s/bound/extent/": clarification de la sémantique du texte de la norme. Toujours bon.
    • "Introducing Object Aliases" : il y a définitivement quelque chose à creuser de ce coté. L'idée est de pouvoir créer des constantes template grâce à la syntaxe using.


    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
     
    template< class T = double >
    struct pi_constant {
        static constexpr T value = static_cast<T>(3.141592653589793L);
    };
     
    template< class T = double >
        using auto pi = pi_constant<T>::value;
    • "A Parallel Algorithms Library": [codeinline]std::sort(std::par, v.begin(), v.end())[codeinline], c'est plutôt une bonne idée. Je comprends le principe et l'exécution. Ceci dit, ça fait dépendre la librairie standard non pas du coeur du langage, mais d'une technologie proposée ou non par le compilateur (en l'occurence, OpenMP, vu la proposition). A proposer sous la forme d'une feature optionnelle ? Par contre, sur la version vectorisée, je suis encore plus circonspect - la vectorisation dépends non seulement d'une technologie de compilation, mais aussi de features du processeur. La, ça me semble vraiment hasardeux (sans compter que les points comme l'alignement, l'aliasing... ne sont pas suffisament traités).
    • "Proposing a C++1Y Swap Operator" : meh ? ça, ça me semble tiré par les cheveux. Autant std::swap est lisible, autant operator:=: me semble peu lisible. Peut être sous une autre forme (operator>< ? cet opérateur a l'avantage d'être symétrique, comme le premier, et d'indiquer un mouvement).
    • "Conditionally-supported Special Math Functions for C++14" : sur l'utilisation d'une tournure particulière pour réintégréer les fonctions de math spéciales dans C++14 en les rendant optionnelles. Me parait être un bon compromis.
    • "Unicode Support in the Standard Library" : non ; selon moi, la vrai solution au problème de l'unicode est un type de donnée spécialisé représentant un code point (en UTF8, un u8 ; en UTF16, un u18, en UTF32, un u32), et des classes std::basic_string<> spécialisées. L'introduction d'une classe std::encoded_string ne va faire que compliquer les programmes, en multipliant le nombre de types "chaines" alors qu'un seul est nécessaire (d'autant plus qu'il existe déjà, et est largement utilisé).
    • "Proposing the Rule of Five" : les développeurs C++ partent du principe que certaines fonctions membre spéciales sont automatiquement générées par le compilateur. Cette proposition veut empêcher ce fonctionnement dès lors qu'un des big five est déclaré. C'est à mon sens une erreur (et un cauchemar en terme de maintenance). Un nouveau standard C++ ne doit pas être incompatible à ce point avec les standards existants (même si, effectivement, il y a des incompatibilités entre C++98 et C++11 ; mais celles-ci ne sont pas si courante que ça).
    • "Return type deduction for normal functions" : dans le principe, je suis tout à fait d'accord. Il s'agirait de laisser le compilateur décider du type de retour d'une fonction lorsque le programmeur spécifie que ce type est auto. Aujourd'hui, on est obligé d'utiliser decltype à la suite pour que le compilateur connaisse le type de retour, et l'auteur montre que le compilateur peut tout à fait le détecter lui-même dans de nombreux cas.
    • "make_unique" : oui ; ça parait même évident, une fois formulé.
    • "std::split(): An algorithm for splitting strings" : moui. Peut-être.
    • "std::join(): An algorithm for joining a range of elements" : c'est déjà plus intéressant.
    • "A Three-Class IP Address Proposal" : ce sont les classes IP de Asio. Leur design a été longuement refléchi, et il est plutôt correct selon moi. Un seul point noir : je ne peux pas écrire le code suivant


    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
     
    void func(const ip::address_v4& ipv4)
    { ... } 
    void func(const ip::address_v6& ipv4)
    { ... } 
     
    // ...
    ip::address ip = "::1";
    func(ip); // erreur de compilation
    • ""Static If" Considered". Bjarne ne veut pas de static if dans son langage. Ses arguments (enfin, pas que les siens) sont clairs. Entièrement d'accord avec lui.
    • "Network byte order conversion" : htons, ntohs et consort (plus deux fonctions template hton<> et ntoh<>). Dès lors qu'on ajoute un support réseau, cette proposition devient nécessaire. Il y a quelques petits points à revoir (pourquoi ajoute-t-on des spécialisation pour les unsigned-integral uniquement ? Les signed-integral n'ont pas le droit de passer par le réseau ?). Aussi, une fonction hton<T> quelque soit T, c'est un peu osé (que se passe-t-il si T == std::vector<std::map<std::string, void*>> ?). La proposition ne dit rien sur le sujet (la solution évidente est d'interdire toute instanciation à partir d'un type non scalaire (je ne vois pas pourquoi je ne pourrais pas faire un ntoh<float>() ; après tout, on transfère des données sur le réseau).
    • "Extending std::search to use Additional Searching Algorithms" : je suis pour. Le proposal est clair, et son bénéfice immédiat - le tout pour 4 fonctions ajoutées dans la librairie standard + un overload de std::search. Tout est ensuite dans la balance mémoire/rapidité, et le choix final reviens au programmeur. C'est brillant.
    • "Literal operator templates for strings" : a du sens. Certains exemples sont plus forts que d'autres (notamment l'exemple Qt ou l'exemple d'obfuscation). Oui, les user litteral doivent pouvoir être définis sous la forme d'operateurs template (ce n'est pas le cas à l'heure actuelle).
    • "Wording for Accessing Tuple Fields by Type" : oui. Ok. Peut-être.


    Bien évidemment, ce n'est qu'un première réflexion, avec une lecture en diagonale.
    [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.

  6. #6
    Membre chevronné
    Avatar de Joel F
    Homme Profil pro
    Chercheur en informatique
    Inscrit en
    septembre 2002
    Messages
    918
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Chercheur en informatique
    Secteur : Service public

    Informations forums :
    Inscription : septembre 2002
    Messages : 918
    Points : 1 923
    Points
    1 923
    Par défaut
    Citation Envoyé par Emmanuel Deloget Voir le message
    Je t'aide :

    • "A Parallel Algorithms Library": Par contre, sur la version vectorisée, je suis encore plus circonspect - la vectorisation dépends non seulement d'une technologie de compilation, mais aussi de features du processeur. La, ça me semble vraiment hasardeux (sans compter que les points comme l'alignement, l'aliasing... ne sont pas suffisament traités).
    C'est la raison pour laquelle on a proposé N3571

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

    Informations forums :
    Inscription : novembre 2004
    Messages : 2 740
    Points : 2 652
    Points
    2 652
    Par défaut
    Merci pour ton retour, Emmanuel Deloget.

    Ça ma motivé pour mettre le nez dans ces propositions.

  8. #8
    Expert confirmé

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

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

    Informations forums :
    Inscription : septembre 2007
    Messages : 1 895
    Points : 4 536
    Points
    4 536
    Par défaut
    Citation Envoyé par Joel F Voir le message
    C'est la raison pour laquelle on a proposé N3571
    Qui est une belle proposition, vu qu'elle ne fait pas dire au programmeur "cher compilateur, fait quelque chose que tu ne sais pas faire" si le compilateur ne supporte pas la vectorisation. De plus, en passant par un simd::pack<>, tu peux forcer l'alignement comme tu le souhaite (attention aux vecteurs de simd::pack<> : il faut continuer à garantir l'alignement, même lorsque les données sont dans un conteneur qui n'alloue pas nécessairement des zones de mémoire alignées sur 128 bits ; remarque, une spécialisation partielle de allocator<> devrait pouvoir aider).

    Un bémol quand même sur les fonctions mathématiques : que se passe-t-il si le hardware ne gère pas toutes les fonctions proposées ? (je pense notamment au jeu d'instruction NEON). Autre point: pas de swizzling ?
    [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
    Membre chevronné
    Avatar de Joel F
    Homme Profil pro
    Chercheur en informatique
    Inscrit en
    septembre 2002
    Messages
    918
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Chercheur en informatique
    Secteur : Service public

    Informations forums :
    Inscription : septembre 2002
    Messages : 918
    Points : 1 923
    Points
    1 923
    Par défaut
    Citation Envoyé par Emmanuel Deloget Voir le message
    Qui est une belle proposition, vu qu'elle ne fait pas dire au programmeur "cher compilateur, fait quelque chose que tu ne sais pas faire" si le compilateur ne supporte pas la vectorisation. De plus, en passant par un simd::pack<>, tu peux forcer l'alignement comme tu le souhaite (attention aux vecteurs de simd::pack<> : il faut continuer à garantir l'alignement, même lorsque les données sont dans un conteneur qui n'alloue pas nécessairement des zones de mémoire alignées sur 128 bits ; remarque, une spécialisation partielle de allocator<> devrait pouvoir aider).
    C'est prevu

    Citation Envoyé par Emmanuel Deloget Voir le message
    Un bémol quand même sur les fonctions mathématiques : que se passe-t-il si le hardware ne gère pas toutes les fonctions proposées ? (je pense notamment au jeu d'instruction NEON).
    on a deja fait ce travail mille fois. Boost.SIMD a genre 400+ fonctions

    Citation Envoyé par Emmanuel Deloget Voir le message
    Autre point: pas de swizzling ?
    c'est shuffle

  10. #10
    Membre expert
    Avatar de Klaim
    Homme Profil pro
    Développeur de jeux vidéo
    Inscrit en
    août 2004
    Messages
    1 717
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

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

    Informations forums :
    Inscription : août 2004
    Messages : 1 717
    Points : 3 285
    Points
    3 285
    Par défaut
    Je n'ai pas encore tout lu mais ces derniers jours c'est ma lecture du soir. J'en suis au document sur les executor, sujet qui me touche particulierement. J'espere qu'ils ne vont pas mettre trop de temps a poser les outils pour tout ce qui est parallelisme de taches, parceque pour l'instant c'est pas encore top top sans ITBB et meme avec.

  11. #11
    Expert confirmé
    Homme Profil pro
    Étudiant
    Inscrit en
    juin 2012
    Messages
    1 707
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : juin 2012
    Messages : 1 707
    Points : 4 385
    Points
    4 385
    Par défaut
    Citation Envoyé par Joel F Voir le message
    c'est shuffle
    Un lien ? Une référence ? J'ai déjà cherché parce que j'en avait besoin une fois, et rien trouvé, c'est existant ou ça va arriver (probablement) avec une prochaine maj du langage ?

    Sinon pour savoir, a propos de toutes ces discussions, qui peut faire une proposition (tout le monde ?), qui vote ces propositions ?

  12. #12
    Membre chevronné
    Avatar de Joel F
    Homme Profil pro
    Chercheur en informatique
    Inscrit en
    septembre 2002
    Messages
    918
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Chercheur en informatique
    Secteur : Service public

    Informations forums :
    Inscription : septembre 2002
    Messages : 918
    Points : 1 923
    Points
    1 923
    Par défaut
    Citation Envoyé par Joel F Voir le message
    C'est prevu
    apres reflexion un vector de pack n'a pas de sens. si tu fait ca c'est plutot un vector de T parcouru via simd::transform

  13. #13
    Expert confirmé

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

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

    Informations forums :
    Inscription : septembre 2007
    Messages : 1 895
    Points : 4 536
    Points
    4 536
    Par défaut
    Citation Envoyé par Joel F Voir le message
    c'est shuffle
    Arf. J'avais vu shuffle, et je n'avais même pas capté. Désolé

    Citation Envoyé par Joel F Voir le message
    apres reflexion un vector de pack n'a pas de sens. si tu fait ca c'est plutot un vector de T parcouru via simd::transform
    La, j'ai un doute. Selon moi (mais je peux me tromper) un vector de pack a un sens - si, par exemple, je veux faire la même multiplication matricielle sur un grand nombre de vecteurs. Dans ce cas,

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
     
    typedef std::simd::pack<float> pack_type;
    std::vector<pack_type, std::simd::allocator<pack_type>> v;
    matrix_type mat; // encapsule 4 pack<float>. 
    std::transform(v.begin(), v.end(), v.begin(), [mat](const pack_type& p) -> pack_type {
        return mat * v; // 4 * operator*(pack,pack)
    });
    Je trouve ça un poil plus élégant (et plus naturel à écrire) que d'utiliser simd::transform(). (à ce propos, ça vaudrait peut-être le coup de rajouter à votre proposition

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
     
    #include <simd>
    namespace std {
      template <class T, class N>
      class allocator<simd::pack<T, N>>;
    }
    Ceci dit, ce n'est que mon avis Vous avez réfléchi plus longtemps que moi à la question (mais dans le contexte de boost ; dans le contexte de la librairie standard, il y a d'autres interactions intéressantes à prévoir).

    Au fait, tu (ou l'un des autres co-auteur) vas y aller à Portland pour défendre votre proposition ?
    [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.

  14. #14
    Membre chevronné
    Avatar de Joel F
    Homme Profil pro
    Chercheur en informatique
    Inscrit en
    septembre 2002
    Messages
    918
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Chercheur en informatique
    Secteur : Service public

    Informations forums :
    Inscription : septembre 2002
    Messages : 918
    Points : 1 923
    Points
    1 923
    Par défaut
    Citation Envoyé par Emmanuel Deloget Voir le message
    La, j'ai un doute. Selon moi (mais je peux me tromper) un vector de pack a un sens - si, par exemple, je veux faire la même multiplication matricielle sur un grand nombre de vecteurs. Dans ce cas,
    A voir, pack c'ets une abstraction de registre SIMD et avoir un vector de registre ca semble awkward.

    Citation Envoyé par Emmanuel Deloget Voir le message
    Ceci dit, ce n'est que mon avis Vous avez réfléchi plus longtemps que moi à la question (mais dans le contexte de boost ; dans le contexte de la librairie standard, il y a d'autres interactions intéressantes à prévoir).
    En pratique on en a jamais eu besoin, donc apres a voir ce que sorte d'autre gens.

    Citation Envoyé par Emmanuel Deloget Voir le message
    Au fait, tu (ou l'un des autres co-auteur) vas y aller à Portland pour défendre votre proposition ?
    Moi non mais mathias oui.

  15. #15
    Membre émérite

    Inscrit en
    mai 2008
    Messages
    1 014
    Détails du profil
    Informations forums :
    Inscription : mai 2008
    Messages : 1 014
    Points : 2 251
    Points
    2 251
    Par défaut
    Citation Envoyé par Emmanuel Deloget Voir le message
    [*]"std::split(): An algorithm for splitting strings" : moui. Peut-être.
    Comment ça "moui" Moi je serais bien content d'avoir enfin un moyen standard, facile d'utilisation et efficace pour de la tokenisation basique de strings en C++. (C'est quand même plus important que de rajouter de la recherche par Boyer-Moore que personne n'utilisera jamais ) Perso, j'ai toujours trouvé un peu honteux que l'on est pas d'équivalent à strtok et la honte atteint son sommet en lisant cette question sur stack overflow : What's the most elegant way to split a string in C++? : Là ou dans quasiment tous les les langages splitter une string se fait en une ligne ou deux apparement les solutions "élégantes" en C++ sont des horreurs à base de istream_iterator/stringstream/getline ou alors nécessite boost/plus de vingt lignes de code etc...

    Je remarque d'ailleurs que ce papier est lié à un petit paquet d'autres papiers : range(N3513)/string_view(N3609)/split(N3593)/join(N3594) qui passent un peu sous le radar par rapport à la déferlante de feature majeures (parallèlisme et asynchronisme à gogo, lambda générique, concept etc) mais je serais prêt à parierque ces quatres là s'ils sont acceptés auront plus d'impact sur l'écriture du code au jour le jour que tous les autres réunis.

    C'est pareil avec le C++11, c'est toujours les lambda/auto/rvalue reference/smart pointer etc qui sont évoqués en premier dans les articles ou les présentations sur les nouveautés du langage alors qu'en pratique AHMA c'est de très loin le foreach (range based for) dont on parle relativement peu qui a un impact le plus important sur l'écriture de code C++.

    Bien évidemment, ce n'est qu'un première réflexion, avec une lecture en diagonale.
    Merci pour cette première passe c'est vraiment très utile.
    Plus qu'à commenter les ~ 60 autres papiers restant maintenant

  16. #16
    Membre expert
    Avatar de Klaim
    Homme Profil pro
    Développeur de jeux vidéo
    Inscrit en
    août 2004
    Messages
    1 717
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

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

    Informations forums :
    Inscription : août 2004
    Messages : 1 717
    Points : 3 285
    Points
    3 285
    Par défaut
    Citation Envoyé par Arzar Voir le message

    C'est pareil avec le C++11, c'est toujours les lambda/auto/rvalue reference/smart pointer etc qui sont évoqués en premier dans les articles ou les présentations sur les nouveautés du langage alors qu'en pratique AHMA c'est de très loin le foreach (range based for) dont on parle relativement peu qui a un impact le plus important sur l'écriture de code C++.
    Mon experience a ete diffrente jusqu'ici mais peut etre parceque depuis un peu plus d'un an je ne fais quasimment que du nouveau code. C'est la disponibilite des lambda qui a change pas mal la maniere dont j'organise le code.

  17. #17
    Inactif  


    Homme Profil pro
    Inscrit en
    novembre 2008
    Messages
    5 295
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Secteur : Santé

    Informations forums :
    Inscription : novembre 2008
    Messages : 5 295
    Points : 15 129
    Points
    15 129
    Par défaut
    Pareil, j'ai une préférence pour les algo+lambda que les range for (que j'utilise pratiquement pas)

    auto et smart ptr, c'est probablement un tort que cela ne soit pas plus utilisé

    la feature la plus utilisée est probablement la move semantic, mais de manière cachée dans la stl

  18. #18
    Membre émérite

    Inscrit en
    mai 2008
    Messages
    1 014
    Détails du profil
    Informations forums :
    Inscription : mai 2008
    Messages : 1 014
    Points : 2 251
    Points
    2 251
    Par défaut
    Hum bon, joker, peut être qu'avec une base de code entièrement neuve les lambdas permettent en effet une modification significative dans la manière de coder.

    En fait le code C++ typique qui me tombe sous les yeux (ou que j'ai pu voir dans des boulots précédents) ressemblent plutôt à du code de ce genre :

    http://llvm.org/svn/llvm-project/cfe.../Sema/Sema.cpp

    Et dans cet exemple, sur 1300 lignes je vois à peu près 10/15 boucles qui pourraient être remplacés avantageusement par des foreach, par contre je ne vois pas bien où utiliser des lambdas.

  19. #19
    Inactif  


    Homme Profil pro
    Inscrit en
    novembre 2008
    Messages
    5 295
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Secteur : Santé

    Informations forums :
    Inscription : novembre 2008
    Messages : 5 295
    Points : 15 129
    Points
    15 129
    Par défaut
    Il parait que la prochaine norme interdira les boucles for et qu'il faudra utiliser uniquement les algos de la STL à la place...

  20. #20
    Membre émérite

    Inscrit en
    mai 2008
    Messages
    1 014
    Détails du profil
    Informations forums :
    Inscription : mai 2008
    Messages : 1 014
    Points : 2 251
    Points
    2 251
    Par défaut
    Citation Envoyé par gbdivers Voir le message
    Il parait que la prochaine norme interdira les boucles for et qu'il faudra utiliser uniquement les algos de la STL à la place...
    Raté, dans la prochaine norme on aura des boucles for encore plus compliquées, voir le papier n3587 dans le mailing pre-bristol : For Loop Exit Strategies

Discussions similaires

  1. envoyer un mail avec texte pre-rempli
    Par monlou dans le forum Langage
    Réponses: 10
    Dernier message: 25/08/2010, 04h59
  2. ouvrir mail pre rempli sur linkedLabel composant
    Par skunkies dans le forum Windows Forms
    Réponses: 3
    Dernier message: 17/11/2008, 02h21
  3. envoi de mail, protocol SMTP langage C
    Par Heimdall dans le forum Développement
    Réponses: 2
    Dernier message: 23/05/2003, 12h22
  4. Scanner des mails et récupérer le fichier attaché
    Par delphim dans le forum Composants VCL
    Réponses: 2
    Dernier message: 24/04/2003, 10h35
  5. [VB6] [Outlook] Imprimer un mail en VB
    Par der dans le forum VB 6 et antérieur
    Réponses: 4
    Dernier message: 12/09/2002, 15h20

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