IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

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

Contribuez C++ Discussion :

[futur] L'après C++11


Sujet :

Contribuez C++

  1. #21
    Expert éminent

    Inscrit en
    Novembre 2005
    Messages
    5 145
    Détails du profil
    Informations forums :
    Inscription : Novembre 2005
    Messages : 5 145
    Points : 6 911
    Points
    6 911
    Par défaut
    Citation Envoyé par Klaim Voir le message
    Pour connaitre l'interface (du code) il doit soit lire le fichier un peu cryptique d'interface qu'il a, soit lire une doc externe (qui n'est pas forcément fournie).
    Si ça incite à avoir une doc d'utilisation, c'est pas plus mal. C'est un fichier généré, sans commentaires, il ne peut pas servir de substitut à une doc d'utilisation. Et normaliser des annotations pour transporter des commentaires me semble hors de propos.
    Les MP ne sont pas là pour les questions techniques, les forums sont là pour ça.

  2. #22
    Rédacteur/Modérateur
    Avatar de JolyLoic
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Août 2004
    Messages
    5 463
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 49
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Août 2004
    Messages : 5 463
    Points : 16 213
    Points
    16 213
    Par défaut
    C'est quand même un point problématique. Actuellement, par exemple, des environnements de développement parsent les commentaires dans les .h pour fournir une documentation (dans un tooltip) au point d'utilisation d'une fonction. Je pense que ce genre de fonctionnalité est utile, il ne faudrait pas qu'elles deviennent impossible à réaliser.
    Ma session aux Microsoft TechDays 2013 : Développer en natif avec C++11.
    Celle des Microsoft TechDays 2014 : Bonnes pratiques pour apprivoiser le C++11 avec Visual C++
    Et celle des Microsoft TechDays 2015 : Visual C++ 2015 : voyage à la découverte d'un nouveau monde
    Je donne des formations au C++ en entreprise, n'hésitez pas à me contacter.

  3. #23
    Membre éclairé

    Homme Profil pro
    Développeur informatique
    Inscrit en
    Juin 2007
    Messages
    373
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : Royaume-Uni

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

    Informations forums :
    Inscription : Juin 2007
    Messages : 373
    Points : 764
    Points
    764
    Par défaut
    En jouant avec le python, j'avais beaucoup aimé le concept de modules. Sans savoir que c'était déjà en projet pour le C++, j'avais écrit un petit bout de programme (3000-4000 lignes) qui permet, à partir d'un seul fichier (.mpp) de générer un .h et un .cpp, compilables directement avec n'importe quel compilateur. Le lien (sur ce forum) : click.

    Je n'ai pas encore lu la proposition pour les modules du C++, mais je pense que l'esprit est le même.
    Par exemple, le fichier .mpp :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    /// Nom du module (definit dans un namespace, Simple)
    module Simple::Test;
     
    /// Dependance
    using module std::string;
     
    typedef unsigned int uint;
     
    /// Variables globales (dans le namespace Simple)
    // Les commentaires avec trois slash sont consideres comme
    // de la documentation, et sont exportes dans le .h
    /** On peut aussi utiliser cette syntaxe (à la Doxygen).
    */
    uint j;
    std::string s;
     
    /// Fonctions libre
    /** Un peu de documentation ?
    */
    void TheFunction()
    {
        // Do nothing
    }
     
    uint OtherFunction(uint* p)
    {
        return 2*(*p);
    }
     
    /// Une classe
    class MyClass
    {
     
        /// Membres prives
        uint f;
        /// ... et statiques
        static uint S = 0u;
     
    public :
     
        /// Constructeur
        new(uint i, const uint j, uint* p) : f(i*j), glu(*p)
        {
        }
     
        /// Fonction membre
        uint Member(const uint& i) const
        {
            return glu*i;
        }
     
        /// Membre public
        uint glu;
    };
     
    /// Une sous namespace
    namespace Foo {
        uint z;
    }
    ... produit un fichier .hpp :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    #ifndef SIMPLE_TEST_INCLUDED
    #define SIMPLE_TEST_INCLUDED
     
    #include <string>
     
    namespace Simple {
     
        /// Dependance
        typedef unsigned int uint;
     
        /// Variables globales (dans le namespace Simple)
        /** On peut aussi utiliser cette syntaxe (à la Doxygen).
        */
        extern Simple::uint j;
        extern std::string s;
     
        /// Fonctions libre
        /** Un peu de documentation ?
        */
        void TheFunction();
     
        Simple::uint OtherFunction(Simple::uint* p);
     
        /// Une classe
        class MyClass
        {
            /// Membres prives
            Simple::uint f;
            /// ... et statiques
            static Simple::uint S;
     
        public :
     
            /// Constructeur
            MyClass(Simple::uint i, const Simple::uint j, Simple::uint* p);
     
            /// Fonction membre
            Simple::uint Member(const Simple::uint& i) const;
     
            /// Membre public
            Simple::uint glu;
        };
     
        namespace Foo {
     
            extern Simple::uint z;
        }
     
    }
     
    #endif
    ... et un fichier .cpp :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    #include "simple_test.hpp"
     
    using namespace Simple;
     
    uint Simple::j;
    std::string Simple::s;
     
    void TheFunction()
    {
        // Do nothing
    }
     
    uint OtherFunction(uint* p)
    {
        return 2*(*p);
    }
     
    uint MyClass::S = 0u;
     
    MyClass::MyClass(uint i, const uint j, uint* p) : f(i * j), glu(* p)
    {
    }
     
    uint MyClass::Member(const uint& i) const
    {
        return glu*i;
    }
     
    uint Simple::Foo::z;
    Mon code est très expérimental, et n'est pas 100% fonctionnel (j'ai dû faire une ou deux corrections à la main sur l'output ci-dessus), mais je pense que ça permet de se faire une bonne idée de ce que peuvent apporter les modules aux C++ :
    • On ne perd pas de temps à modifier à la fois le fichier .hpp et le fichier .cpp : une modification dans le module suffit.
    • Comme le fichier d'interface est généré automatiquement, on peut aussi en profiter pour le "pré-compiler", en stockant dans un coin les types et variables exposées par exemple, ce qui diminue éventuellement les temps de compilation.
    • On peut aussi en profiter pour proposer aux compilateurs d'avoir une approche de compilation "globale" et non plus fichier par fichier (réduction énorme des temps de compilation).


    Avec les concepts, les modules font partie des features qui me plaisent le plus a priori.

  4. #24
    Membre émérite
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Décembre 2008
    Messages
    832
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Décembre 2008
    Messages : 832
    Points : 2 625
    Points
    2 625
    Par défaut
    Après avoir lues quelques pages (6/ 23 + un saut la ou il parle des template) je suis moyennement convaincu.

    Les deux avantages qu'il cite semblent être:
    _ plus de problème d'inclusion multiple
    _ accélération notable de la compilation

    Je ne pense pas que l'inclusion multiple soit encore un véritable problème pour les dev C++, on à des parades bien connues contre ce genre de soucis.

    Pour l'accélération de la compilation, il semble que cette technique soit utilisée dans d'autres langages. J'aimerai savoir lesquels, histoire de pouvoir comparer?
    Parce que je reste sceptique sur le fait que les templates puissent être accélérés, parce que pour moi ils sont compilés au même moment que les macros, et il semble que les modules ne puissent gérer les macros (il indique dans le papier, vers la 3ème page, que les header ne seront pas dépréciés pour des raisons de compatibilité et à cause de la présence des macros)...


    @Kalith:
    Ca semble être très différent de ça.
    (/!\ les allégations ci dessous sont issues d'un texte lu a à peine 15% et sont donc sûrement percées de nombreux manques de précision, voire d'erreurs)
    Les déclarations seraient inclues dans le fichier d'implémentation, les macros restant dans le header.
    Le compilateur compile ce fichier, génère notre bon vieux .lib et un fichier .mpp, que le distributeur de la lib fournit ensuite.
    Le client fait l'inclusion, et le compilateur va chercher le .mpp correspondant au .lib dans un emplacement standard (sauf si précisé au compilo via un paramètre de la ligne de commande).
    Ensuite, il précompile ce fameux .mpp (le mécanisme des header précompilés qui est jusqu'ici une fonctionnalité non-standard devient donc standard) ce qui fera gagner du temps lors des compilations de projet suivantes.
    Mais à aucun moment, il ne génère à nouveau le .cpp, et encore heureux, sinon, tout les non-libristes abandonneraient définitivement ce langage!
    L'implémentation reste en fait à sa place, dans le .lib.

    Sincèrement, excepté le problème de l'inclusion multiple et parfois bordélique du C++, à coup de "#ifndef ...#endif" et de "class Foo;" je ne comprend pas ce que c'est censé apporter.
    L'accélération de la compilation, je pense qu'il suffirait de standardiser les entêtes précompilés. Parce que dans le cas ou on utilise des macros, ce ne sont plus 2 fichiers qu'il faut filer, mais 3: .cpp, .h, .mpp
    Et je trouve que beaucoup de codes utilisent des macros, l'air de rien...


    [edit]
    Les concepts seraient effectivement une excellent chose, parce que les erreurs de syntaxes avec les templates sont assez infernales à résoudre quand même. Donc un gros + pour cette fonction aussi

  5. #25
    Rédacteur/Modérateur
    Avatar de JolyLoic
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Août 2004
    Messages
    5 463
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 49
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Août 2004
    Messages : 5 463
    Points : 16 213
    Points
    16 213
    Par défaut
    Citation Envoyé par Freem Voir le message
    Après avoir lues quelques pages (6/ 23 + un saut la ou il parle des template) je suis moyennement convaincu.

    Les deux avantages qu'il cite semblent être:
    _ plus de problème d'inclusion multiple
    _ accélération notable de la compilation

    Je ne pense pas que l'inclusion multiple soit encore un véritable problème pour les dev C++, on à des parades bien connues contre ce genre de soucis.
    C'est un frein important à l'apprentissage du langage, donc ça a un impact sur la taille de la communauté des développeurs C++, donc sur les bibliothèques et outils disponibles...
    Citation Envoyé par Freem Voir le message
    L'accélération de la compilation, je pense qu'il suffirait de standardiser les entêtes précompilés. Parce que dans le cas ou on utilise des macros, ce ne sont plus 2 fichiers qu'il faut filer, mais 3: .cpp, .h, .mpp
    Et je trouve que beaucoup de codes utilisent des macros, l'air de rien...
    Ça va plus loin que les entêtes précompilées. Parce qu'aujourd'hui, à cause entre autres des macros, mais pas seulement, finalement les entêtes précompilées ne peuvent pas être si précompilées que ça. Une inclusion préalable d'un autre fichier peut totalement changer le comportement d'un fichier existant. Du coup, on doit tout laisser ouvert. L'utilité des modules est là de dire qu'on a une frontière claire et nette à laquelle on n’acceptera pas d'être perturbés par d'autres personnes. Donc on a une vraie précompilation, là où la précompilation qui respecte les règles actuelles du C++ n'est que partielle.

    Et du coup, comme on a une bibliothèque vraiment autonome, ça laisse au compilateur l'opportunité de faire du travail supplémentaire qu'autrement il ne peut faire qu'au link final (et qui est donc plus lourd), comme détecter si une fonction est pure...
    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.

  6. #26
    Membre éclairé

    Profil pro
    Inscrit en
    Mai 2005
    Messages
    264
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2005
    Messages : 264
    Points : 725
    Points
    725
    Par défaut
    Citation Envoyé par Freem Voir le message
    Pour l'accélération de la compilation, il semble que cette technique soit utilisée dans d'autres langages. J'aimerai savoir lesquels, histoire de pouvoir comparer?
    Les modules sont dans D (http://www.d-programming-language.org) et DMD, le compilo de référence, est très très très rapide. Alexandrescu a fait un comparatif avec Go, en mesurant le temps que prend chaque langage à compiler sa bibliothèque standard et en les divisant par leurs nombre de lignes de code respectives.
    Verdict : DMD est 4,2x plus rapide que le compilateur Go de Google.
    "By and large I'm trying to minimize mentions of D in C++ contexts because it's as unfair as bringing a machine gun to a knife fight." - Andrei Alexandrescu

  7. #27
    Membre éclairé
    Avatar de Ekleog
    Homme Profil pro
    Étudiant
    Inscrit en
    Janvier 2012
    Messages
    448
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Janvier 2012
    Messages : 448
    Points : 879
    Points
    879
    Par défaut
    Ou bien le D est 4,2x plus verbeux que le go ... A voir.

  8. #28
    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 344
    Points
    3 344
    Par défaut
    Plus verbeux mais plus clair, rapide et explicite.


    Alors à choisir l'un des deux, perso, je préfère de loin D


    Enfin c'est pas le sujet de toutes manières.

    Les modules tels qu'implémentés dans C#, Java, ActionScript entre autre font que la compilation est toujours de l'ordre de la seconde (notemment en C#).
    Pour un très gros programme (fait de plusieurs modules et dépendances) de complexité équivalente en C# et en C++ j'ai vu le code C# se générer en quelques secondes alors que la version C++ a mis 30 minutes.

    On arrivera certainement pas aux quelques secondes juste avec les modules en C++ parceque le language lui même complexifie aussi les choses, mais le simple fait de savoi à l'avance ce qui est dispo comme identifiants et de pouvoir récupérer leurs infos déjà préparées pour être compilés, sans avoir a recharger encore et recompiler encore des tonnes de fichiers, ben ça va quand même aider à se raprocher de la minute.


    Et évidemmment je parle de projets où toutes les possibilités d'opitmization de compilation (niveau code et niveau configuration du compilateur) ont été mise en place, maiss ou effectivement il y a beaucoup d'inclusions de fichiers puisque l'essentiel du code est template et utilise boost::mpl entre autre. Autant dire que le programme C++ n'étiat pas aussi complexe en terme d'expression que la version C# et donc été bien plus optimisée, mais restait plus lente à compiler évidemment.


    Un meilleur exemple du résultat potentiel des modules : les unity build (compiler tout le code du projet comme un seul fichier). Il y a plein de mesures qui démontrent que ça rends la compilation drastiquement plus rapide. D'un point de vue de l'organisation du compilateur en interne, avoir le modules c'est lui permettre de réorganiser son interpretation du code dnas une sorte de gros unity-build par projet et ensuite pouvoir se référer à la partie publique de cette build quand il compile d'autres projets.

  9. #29
    Membre éclairé

    Profil pro
    Inscrit en
    Mai 2005
    Messages
    264
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2005
    Messages : 264
    Points : 725
    Points
    725
    Par défaut
    Citation Envoyé par Klaim Voir le message
    Les modules tels qu'implémentés dans C#, Java, ActionScript entre autre font que la compilation est toujours de l'ordre de la seconde (notemment en C#).
    Pour un très gros programme (fait de plusieurs modules et dépendances) de complexité équivalente en C# et en C++ j'ai vu le code C# se générer en quelques secondes alors que la version C++ a mis 30 minutes.

    On arrivera certainement pas aux quelques secondes juste avec les modules en C++ parceque le language lui même complexifie aussi les choses, mais le simple fait de savoi à l'avance ce qui est dispo comme identifiants et de pouvoir récupérer leurs infos déjà préparées pour être compilés, sans avoir a recharger encore et recompiler encore des tonnes de fichiers, ben ça va quand même aider à se raprocher de la minute.


    Et évidemmment je parle de projets où toutes les possibilités d'opitmization de compilation (niveau code et niveau configuration du compilateur) ont été mise en place, maiss ou effectivement il y a beaucoup d'inclusions de fichiers puisque l'essentiel du code est template et utilise boost::mpl entre autre. Autant dire que le programme C++ n'étiat pas aussi complexe en terme d'expression que la version C# et donc été bien plus optimisée, mais restait plus lente à compiler évidemment.


    Un meilleur exemple du résultat potentiel des modules : les unity build (compiler tout le code du projet comme un seul fichier). Il y a plein de mesures qui démontrent que ça rends la compilation drastiquement plus rapide. D'un point de vue de l'organisation du compilateur en interne, avoir le modules c'est lui permettre de réorganiser son interpretation du code dnas une sorte de gros unity-build par projet et ensuite pouvoir se référer à la partie publique de cette build quand il compile d'autres projets.
    Merci de ces précisions, j'avais volontairement écarté C# et Java, pensant que le fait qu'on compile vers un bytecode intermédiaire plutôt que du code natif faussait un peu le jeu. Et puis, D possède beaucoup de points communs avec C++, notamment ses capacités de méta-programmation, qui peuvent allonger les temps de compilation.
    "By and large I'm trying to minimize mentions of D in C++ contexts because it's as unfair as bringing a machine gun to a knife fight." - Andrei Alexandrescu

  10. #30
    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 344
    Points
    3 344
    Par défaut
    Je viens de lire la courte proposition des scoped new. http://www.open-std.org/jtc1/sc22/wg...2012/n3348.pdf
    Je crois qu'ils se sont raté sur les exemples, ils n'ont pas mis de namespace...

    Pouvoir définir un new à utiliser par namespace ça serait le top (même si ça pourrait en embrouiller) surtout pour les bibliothèques.

  11. #31
    Membre régulier
    Homme Profil pro
    Développeur .NET/C/C++
    Inscrit en
    Septembre 2007
    Messages
    71
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur .NET/C/C++
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Septembre 2007
    Messages : 71
    Points : 122
    Points
    122
    Par défaut
    Pour ma part

    - concepts
    Pas mal, mais c'est pas indispensable non plus.

    - module
    j'ai lu en vitesse la proposition. J'aime pas trop le fait de devoir à la fois utiliser des .mpp et des . h. En fait, j'ai l'impression que c'est la moins mauvaise solution que l'on ai trouvé pour le moment pour résoudre les problèmes de temps de compilation & co.

    - filesystem
    Oui, ce serai bien d'avoir une lib commune pour cela. Par ailleurs, j'ajouterai qu'il serai bon aussi d'ajouter une lib capable de gérer les accès réseau (gestion de sockets, résolution de noms & co) parce qu'a ma connaissance pour le moment, on continue de devoir passer par les functions issues du C.

    - date
    Oui, ça manque aussi.

    - range, coroutine, mémoire transactionnelle,
    pas lu de quoi il s'agissait.

    - string_ref
    De ce que je comprens, l'idée est d'encapsuler les std::string& et d'en profiter pour y ajouter des méthodes qui n'existent pas pour le moment (style trim, split, ...).
    J'avoue que je vois pas trop l'intérêt.
    Par ailleurs, quelqu'un peut-il me dire pourquoi des méthodes telles que trim ou split n'ont toujours pas été ajoutées aux std::string? Y'a-t-il une raison technique à cela? Parce que perso, je trouve que cela reste une lacune.

    - Fixed-point arithmetic, digit seperator
    Doit probablement être utile à certain.

    - concurrent queue
    Je dirai même plus : avoir un equivalent thread_safe pour chacun des containers de la stl (concurent_map, concurent_list,...).

    - stream mutex
    pas lu ce que c'était, mais doit probablement amener à plus de facilité/sécurité/efficacité.

    - static_if :
    J'y ajouterai bien des static_switch, voir même un static_while et un static_for. (bon je dis ça comme, reste à voir ce que cela donnerai en pratique).

    - Rich_pointer
    pas encore lu.

    Sinon, quelques autres idées en vrac :
    * lambda class
    Un peu comme cela existe en C#. On pourrait faire des trucs du style :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
     
    auto createUser(dataRow& row)
    {
      return {
        id = row["id"].toInt(), 
        name = row["name"].toString(), 
        age = row["age"].toInt() 
      }; 
    };
    * concurent algo.
    par exemple une std::concurent_foreach qui exécuterai la fonction passée en paramètre dans un thread différent pour chaque element (avec éventuellement un paramètre qui donnerait le nombre max de thread, pour éviter de créer 10 000 threads par ex).

    * comme déjà dit plus haut, ajout dans la stl de la gestion des sockets&co + ajout de méthodes dans la classe std::string!!! (trim, split, join, format, ...).

    * Enfin, "last but not least" : ajout de capacités de reflection au compile-time

    Ainsi pour sérialiser un objet, on pourrait faire un truc du style :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
     
    template<typename T>
    serialize(std::ostream& stream, const T& obj)
    {
      static_foreach(typename fieldInfo : typeof(T)::fields) {
        stream << fieldInfo::get_value(obj);
      };
    }
    (j'avoue sur ce coup là j'me suis laché )
    L'idée est que l'operator typeof renvoie une classe générée par le compilo contenant entre autre un type fields qui est lui même une liste de type (à géré via la notion de nombre indéfini de paramètres templates j'imagine, sinon via l'introduction des typelist dans la norme), chacun étant capable par exemple de retourner la valeur du champ en question sur base de l'objet passé en paramètre.
    Au final, la méthode ci-dessus permettrai de sérialiser facilement n'importe quel type d'objet.


    Des avis?


    EDIT : Je viens de lire le document N3326 : "Sequential access to data members and base sub-objects".
    En fait, cela présente un autre moyen de faire ce que je décrivait dans mon dernier point, en permettant la représentation de n'importe quel objet sous la forme d'un tuple. Ce que j'aime là-dedans c'est que cela est géré au moment de la compilation, un peu comme mon idée.
    Là-dessus, moi je dis
    "Toujours en faire plus pour en faire moins"

  12. #32
    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 344
    Points
    3 344
    Par défaut
    Citation Envoyé par bountykiler Voir le message
    Pour ma part

    - concepts
    Pas mal, mais c'est pas indispensable non plus.
    Tu ne fais pas souvent de bibliothèques template pas vrai?

    - module
    j'ai lu en vitesse la proposition. J'aime pas trop le fait de devoir à la fois utiliser des .mpp et des . h. En fait, j'ai l'impression que c'est la moins mauvaise solution que l'on ai trouvé pour le moment pour résoudre les problèmes de temps de compilation & co.
    Tu as peut être lu de travers : l'idée c'est d'ajouter un autre système optionel mais mailleurs que les headers. Les headers restent mais c'est juste pour permettre la rétro compatibilité et aussi pour certaines manipulations sioux qui n'ont d'interet qu'avec du code qui doit partiellement transiter vers les modules.

    Les mpp sont censé être générés (et moi j'aimerai qu'ils soit lisibles par un programmeur C++...). Dans ton cpp tu auras toujours la séparation entre ce qui est pubilque (ce que tu mettais dans ton header) et ce qui est privé (ce que tu mettais exlcusivemetn dans ton cpp). Le mpp c'est un gros header pret a etre précompilé en somme. Dans ton code tu auras toujours ta séparation déclaration/définition, mais elle sera juste écrite différemment et n'impliquera pas les ouverture, parsing, re-parsing de fichiers imposés par le système actuel.

    Donc sachant que le principal goulot d'étranglement de la compilation c'est ces ouvertures + parsing répétitifs mais nécessaires de fichiers, je trouve que c'est une très bonne solution.

    Tu suggérerais quoi de meilleur?

    - filesystem
    Oui, ce serai bien d'avoir une lib commune pour cela. Par ailleurs, j'ajouterai qu'il serai bon aussi d'ajouter une lib capable de gérer les accès réseau (gestion de sockets, résolution de noms & co) parce qu'a ma connaissance pour le moment, on continue de devoir passer par les functions issues du C.
    A ce que je sache, boost::asio a été proposé au standard avant C++11 donc ça doit être dans les libs à étudier. (et c'est très loin du C)


    - range, coroutine, mémoire transactionnelle,
    pas lu de quoi il s'agissait.

    Range c'est en gros une pair d'itérateurs, de manière écrire plus facilement les manipulations de "range" de données.

    Coroutines c'est en gros simuler des threads dans un seul vrai thread : on execute du code pendant un temps puis on arrete et on passe à un autre code. Très utile pour faire des languages de scripts, mais je sais pas trop pour le reste.

    Mémoire transactionnelle, c'est tout simplement pouvoir dire qu'un bloc entier de code (de manipulations de la mémoier) doit se passer de manièer transactionnelle : quand on rentre dedans, on fait des modifs de la mémoire, mais elles ne sont toutes appliquées qu'une fois le bloc fini.
    Ca permet aussi au thread d'executer le code, de blocker a cause d'un autre thread qui l'éxecute déjà, d'annuler ses modifs de mémoire, de revenir au départ, d'attendre un peut et de retenter le coup, sans que tu ais à coder quoi que ce soit à part dire que c'est un bloc transactionel.

    En gros ça permet de faire du multithreading simple, safe, et surtout sans manipuler de lock ou de thread.


    - concurrent queue
    Je dirai même plus : avoir un equivalent thread_safe pour chacun des containers de la stl (concurent_map, concurent_list,...).
    Ce n'est juste pas très utile, ça reviendrait a ajouter un bete mutex a chacun d'entre eux. Tu peux déjà le faire et de manière bien plus optimisée à ton cas spécifique.

    Les conteneurs fait pour être concurrentiels ont des contraintes qui les rendent vraiment particulier et donc différent des conteneurs qu'on a actuellement. Voir la librarie de boost qui arrive qui fournie justement de tels conteneurs.

    - static_if :
    J'y ajouterai bien des static_switch, voir même un static_while et un static_for. (bon je dis ça comme, reste à voir ce que cela donnerai en pratique).
    Jettes un oeil aussi à la version static if d'Alexandrescu et ses amis du language D (dans un autre des documents). C'est bien plus précis.

    Static switch, il me semble qu'il y avait une bibliothèque de boost pas encore officiellement proposée qui le faisait, en tout cas oui ça serait sympas.

    Par contre les boucles statiques... je pense pas que ce soit utile, mais je suis pas sur.

  13. #33
    Membre régulier
    Homme Profil pro
    Développeur .NET/C/C++
    Inscrit en
    Septembre 2007
    Messages
    71
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur .NET/C/C++
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Septembre 2007
    Messages : 71
    Points : 122
    Points
    122
    Par défaut
    Citation Envoyé par Klaim Voir le message
    Tu ne fais pas souvent de bibliothèques template pas vrai?
    ça m'arrive, mais c'est vrai que c'est pas l'essentiel de ce que je fais.

    Tu as peut être lu de travers : l'idée c'est d'ajouter un autre système optionel mais mailleurs que les headers. Les headers restent mais c'est juste pour permettre la rétro compatibilité et aussi pour certaines manipulations sioux qui n'ont d'interet qu'avec du code qui doit partiellement transiter vers les modules.

    Les mpp sont censé être générés (et moi j'aimerai qu'ils soit lisibles par un programmeur C++...). Dans ton cpp tu auras toujours la séparation entre ce qui est pubilque (ce que tu mettais dans ton header) et ce qui est privé (ce que tu mettais exlcusivemetn dans ton cpp). Le mpp c'est un gros header pret a etre précompilé en somme. Dans ton code tu auras toujours ta séparation déclaration/définition, mais elle sera juste écrite différemment et n'impliquera pas les ouverture, parsing, re-parsing de fichiers imposés par le système actuel.

    Donc sachant que le principal goulot d'étranglement de la compilation c'est ces ouvertures + parsing répétitifs mais nécessaires de fichiers, je trouve que c'est une très bonne solution.

    Tu suggérerais quoi de meilleur?
    J'ai jamais dis que j'avais une meilleure idée . Seulement, la solution des modules ajoute de la compléxité je trouve, ce qui n'est pas top.
    Sinon, il me semble avoir lu que les .mpp serait lisibles par un programmeur (ce qui serait mieux en effet).


    A ce que je sache, boost::asio a été proposé au standard avant C++11 donc ça doit être dans les libs à étudier. (et c'est très loin du C)


    Ce n'est juste pas très utile, ça reviendrait a ajouter un bete mutex a chacun d'entre eux. Tu peux déjà le faire et de manière bien plus optimisée à ton cas spécifique.

    Les conteneurs fait pour être concurrentiels ont des contraintes qui les rendent vraiment particulier et donc différent des conteneurs qu'on a actuellement. Voir la librarie de boost qui arrive qui fournie justement de tels conteneurs.
    Ben pour une liste, tu peux mettre un verrou par element par exemple. Pour les maps, y'a surement moyen de faire le même style de chose. Après, possible que cela engendre trop de contraintes qui les rendent inutilisable en pratique.
    Je vais essayer de jeter un oeil du coté de boost.

    Jettes un oeil aussi à la version static if d'Alexandrescu et ses amis du language D (dans un autre des documents). C'est bien plus précis.

    Static switch, il me semble qu'il y avait une bibliothèque de boost pas encore officiellement proposée qui le faisait, en tout cas oui ça serait sympas.

    Par contre les boucles statiques... je pense pas que ce soit utile, mais je suis pas sur.
    Je disai cela comme ça, mais j'en pas sur non plus. En fait, je pense qu'il y a moyen de faire cela autrement, sans nécessiter l'ajout de mot clé à la norme.

    Sinon j'ai aussi lu la doc concernant les rich pointer. Je dirai bof bof. Je préfère de loin la solution des "Sequential access to data members and base sub-objects". (les 2 propositions ciblent le même problème à la base, à savoir l'introspection de type).
    "Toujours en faire plus pour en faire moins"

  14. #34
    Expert confirmé

    Homme Profil pro
    Développeur informatique
    Inscrit en
    Septembre 2007
    Messages
    1 895
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    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 551
    Points
    4 551
    Par défaut
    Citation Envoyé par cob59 Voir le message
    on pourrait enfin croiser un dev Java sans baisser les yeux.
    Bah, il suffit de lui parler de string.compare() et c'est lui qui baisse les yeux, après un soupir et une petite phrase désespérée du type "je sais...".

    Citation Envoyé par Klaim Voir le message
    A ce que je sache, boost::asio a été proposé au standard avant C++11 donc ça doit être dans les libs à étudier. (et c'est très loin du C)
    J'espère juste que si asio passe dans le standard C++, le comité reverra le design parce qu'il reste des choses insupportable.

    C++11 permet de se passer d'un grand nombre de ces horreurs, donc j'espère qu'on arrivera à quelque chose de correct.
    [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.

  15. #35
    Membre du Club
    Profil pro
    Étudiant
    Inscrit en
    Mai 2010
    Messages
    25
    Détails du profil
    Informations personnelles :
    Localisation : Canada

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Mai 2010
    Messages : 25
    Points : 41
    Points
    41
    Par défaut
    Citation Envoyé par Emmanuel Deloget Voir le message
    J'espère juste que si asio passe dans le standard C++, le comité reverra le design parce qu'il reste des choses insupportable.

    C++11 permet de se passer d'un grand nombre de ces horreurs, donc j'espère qu'on arrivera à quelque chose de correct.
    Intéressant, à quoi fais-tu allusion en particulier?

  16. #36
    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 344
    Points
    3 344
    Par défaut
    J'imagine qu'il parle de la conséquence d''avoir des lambda, move-semantic, type inférence, etc. Tout ce qui aide à mort syntactiquement parceque c'est vrai que tout le "bordel" a mettre en place en C++03 pour que asio marche rends le code un peut répulsif au premier regard.

  17. #37
    Membre éclairé

    Profil pro
    Inscrit en
    Mai 2005
    Messages
    264
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2005
    Messages : 264
    Points : 725
    Points
    725
    Par défaut
    J'apprécierais que les concepts soient écartés au profit de template constraints à la D, qui servent au final à la même chose, tout en étant beaucoup plus légers au niveau de la syntaxe et des changements à apporter au langage :

    Pour ceux qui ne connaissent pas, les templates constraints sont un simple static if à la fin d'une déclaration de template qui conditionne leur instanciation :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
     
    template Toto(T) if condition
    {
        // code...
    }
    si la condition n'est pas remplie, cette déclaration de Toto ne sera pas utilisée pour pour l'instanciation. La condition est evaluée à la compilation. Rien n'empêche d'avoir plus loin une autre déclaration d'un autre template homonyme, mais spécialisé avec des contraintes différentes.
    Si aucune condition n'est trouvée, le compilateur émet une erreur indiquant qu'il n'a plus trouver de template à instancier.

    Plus d'infos : http://erdani.com/d/new-stdio/concepts.html
    "By and large I'm trying to minimize mentions of D in C++ contexts because it's as unfair as bringing a machine gun to a knife fight." - Andrei Alexandrescu

  18. #38
    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 344
    Points
    3 344
    Par défaut
    Comme expliqué dans les propositions du commité, les concepts sont un mix de contraintes tel que dans D mais avec en plus une notion de sémantique.

    Du coup théoriquement c'est plus expressif que des contraintes (et tu peux déjà voir l'interet avec ConceptClang).

  19. #39
    Expert confirmé

    Homme Profil pro
    Développeur informatique
    Inscrit en
    Septembre 2007
    Messages
    1 895
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    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 551
    Points
    4 551
    Par défaut
    Citation Envoyé par Klaim Voir le message
    J'imagine qu'il parle de la conséquence d''avoir des lambda, move-semantic, type inférence, etc. Tout ce qui aide à mort syntactiquement parceque c'est vrai que tout le "bordel" a mettre en place en C++03 pour que asio marche rends le code un peut répulsif au premier regard.
    Il n'y a pas que le code qui soit un peu répulsif - de toute façon, si asio fait un jour partie de la librairie standard, on aura pas besoin de regarder le code. Il y a plein de choses dans le design d'asio qui ne me plaisent pas, mais alors pas du tout. En voici quelques exemples :

    * l'utilisation nécessaire de shared_ptr dès lors qu'on traite des sockets dans une thread qui ne l'a pas créé (ce qui arrive fréquemment, dès lors qu'on fait un programme multi-threadé ou les connections entrantes sont gérées par un pool de thread) . Ce point a été récemment limité avec l'arrivée d'une sémantique de déplacement dans les sockets. A noter quand même que la sémantique de déplacement existait déjà en C++ avant l'introduction des move ctor : il suffisait de créer un constructeur "par copie" dont l'argument n'était pas const. C'est ce que faisait auto_ptr<>. Le résultat n'est pas safe dans tous les cas, mais ça a toujours été possible).

    * certains objets qui n'encapsulent en fait qu'une seule fonction (avec des variantes d'implémentation). cf les classes resolver (dans ce cas précis, une fonction libre aurait été plus approprié).

    * les noms d'objet qui n'ont pas de sens (exemple : io_service ; rien qu'en lisant le nom, est-ce que quelqu'un peut me dire ce que ça fait ?), ou qui engendrent une confusion avec le nom de la fonction qu'ils encapsulent (cf. les classes acceptor, qui ne font pas que l'accept() - loin de là). Cette clase est en fait pire que ça : acceptor::listen ne fait pas de listen mais mets la socket dans un état qui lui permet d'être utilisé pour faire un listen, et acceptor::accept ne fait pas le polling (qui est en fait fait par io_service).

    * la gestion des io async/sync : les sockets ont des méthodes read et read_async, et l'une d'elle n'a pas de sens. Certains OS ne permettent pas la création de sockets utilisable simultanément dans les deux modes (par exemple, les OS POSIX l'autorise, mais pas Windows). Dans le princpipe, de toute façon, une socket async n'est pas une socket sync, et il n'y a pas de raison que le type de l'objet soit le même (ou pire, que la vérification de la possibilité du traitement se fasse au runtime).

    Il y a encore d'autres points mineurs, mais je ne vais pas faire un inventaire à la Prévert

    Après, il y a de bonnes idées : les strand, l'idée de base sur les endpoint, etc. Mais tout n'est pas bon à manger dans asio.
    [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.

  20. #40
    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 344
    Points
    3 344
    Par défaut
    Emmanuel> Merci pour les feedbacks! Donc ya pas que moi qui trouve cela étrangement difficile à comprendre, surtout à cause du nommage...


    Sinon, il y en a ici qui participent au premier rdv post-C++11 du commité. Si oui ça serait cool qu'on ai des infos sur ce qui se dit...

Discussions similaires

  1. Réponses: 30
    Dernier message: 29/01/2019, 17h08
  2. Réponses: 12
    Dernier message: 20/05/2010, 11h27
  3. Réponses: 60
    Dernier message: 15/01/2010, 16h28
  4. Réponses: 46
    Dernier message: 29/07/2009, 03h43
  5. action APRES chargement complet ...
    Par PinGuy dans le forum Delphi
    Réponses: 7
    Dernier message: 06/07/2006, 18h16

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