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

Normalisation C++ Discussion :

Réflexion ou introspection


Sujet :

Normalisation C++

  1. #1
    Membre expérimenté Avatar de ctxnop
    Homme Profil pro
    Développeur informatique
    Inscrit en
    juillet 2007
    Messages
    858
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Morbihan (Bretagne)

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

    Informations forums :
    Inscription : juillet 2007
    Messages : 858
    Points : 1 719
    Points
    1 719
    Par défaut Réflexion ou introspection
    Bonjour,
    J'aimerai savoir pourquoi il ne semble y avoir aucun effort, quel qu'il soit, dans la direction de la reflection, ou introspection ?
    Je sais qu'il existe RTTI, mais c'est tout de même très largement insuffisant. Je sais également qu'il existe des outils ou libs pour en faire un peu plus, mais toujours insuffisant la plupart du temps, ou nécessitant une mise en place ou utilisation très complexe.

    Je trouve les solutions basées sur des libs assez inacceptables. Il faut "remplir soit même" les metadatas ce qui pose le problème de la maintenance et de l'oublie. Il faut absolument penser à mettre les metadatas à jour dès qu'on modifie une classe. Certaines libs permettent de ne pas avoir à maintenir une classe et ses metadatas, mais elles se basent alors sur énormément de préprocesseur et on perd complètement la syntaxe d'origine du C++. C'est très lourd et inélégant.
    D'autres solutions consistent en faire intervenir un outil intermédiaire dans la chaine de compilation, genre Qt et son "moc". C'est la moins pire des solutions je trouve, mais ca reste lourd, compliqué et ca introduit tout un tas de nouveaux problèmes auxquels il faut se former. Comme le fait que ca génère des fichiers qui sont injectés dans la compilation alors qu'ils n'existent pas dans la solution d'un Visual Studio (par exemple).

    Les experts n'ont eu de cesses de répéter dans toutes les conférences qu'il faut laisser faire le compilo, que le compilo sait tout à propos de votre code, qu'il faut faire du standard, etc... Bah je ne demande pas mieux, mais du coup, pourquoi ce n'est pas le compilo qui génère les metadatas ?
    Toutes les réponses que j'ai pu avoir sur le sujet jusqu'ici sont de l'ordre du "en C++ on ne paie que pour ce qu'on utilise", "c'est trop lourd/pas assez performant" et "c'est trop complexe à faire".
    Je suis d'accord avec le fait de ne pas impacter les codes qui n'en ont pas besoins, je suis d'accord pour dire que ca peut plomber les perfs ou qu'on ne peut pas faire de la reflexion sur tout.
    Mais pourquoi il n'y a pas de reflection possible dès lors qu'un certain nombre de contraintes sont respectées ? Une reflection choisie, via des attributs par exemple. Ou autre ?

    Je suis persuadé qu'il n'est pas possible que je sois le seul abruti a me poser cette question, des gens ont forcément fait des propositions sur le sujet.
    L'absence de reflection est pour moi un vrai frein pour au développement de solutions de sérialisations, ce qui a son tour est un frein au développement de solution réseau. Mais pas que.

  2. #2
    Rédacteur/Modérateur


    Homme Profil pro
    Network game programmer
    Inscrit en
    juin 2010
    Messages
    6 963
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : Canada

    Informations professionnelles :
    Activité : Network game programmer

    Informations forums :
    Inscription : juin 2010
    Messages : 6 963
    Points : 32 080
    Points
    32 080
    Billets dans le blog
    4
    Par défaut
    Perso j'en dis que si l'on a choisi de faire du C++ dans l'espoir de faire de la réflexion/introspection, alors on s'est trompé de chemin.

    L'absence de reflection est pour moi un vrai frein pour au développement de solutions de sérialisations, ce qui a son tour est un frein au développement de solution réseau.
    Bof, la sérialisation sera faite en json/xml que l'on manipulera de part et d'autre. Pas besoin de réflexion, sauf à vouloir écraser une mouche au marteau-piqueur.
    Et les cas où "je veux pouvoir tout gérer, je ne sais pas du tout à quoi vont ressembler les datas récupérées" j'en ai jamais rencontré perso. Soit les data sont les miennes, donc je les connais, soit y'a une doc qu indique dans quel état elles arrivent.
    Pensez à consulter la FAQ ou les cours et tutoriels de la section C++.
    Un peu de programmation réseau ?
    Aucune aide via MP ne sera dispensée. Merci d'utiliser les forums prévus à cet effet.

  3. #3
    Membre expérimenté Avatar de ctxnop
    Homme Profil pro
    Développeur informatique
    Inscrit en
    juillet 2007
    Messages
    858
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Morbihan (Bretagne)

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

    Informations forums :
    Inscription : juillet 2007
    Messages : 858
    Points : 1 719
    Points
    1 719
    Par défaut
    Citation Envoyé par Bousk Voir le message
    Perso j'en dis que si l'on a choisi de faire du C++ dans l'espoir de faire de la réflexion/introspection, alors on s'est trompé de chemin.
    Il ne s'agit pas du tout de "choisir C++ dans l'espoir de faire de la reflection"...
    Il s'agit plutot de "pourquoi il n'y a pas de reflection en C++ alors qu'il y en a dans quasi tous les autres langages ?". C++ est, ou du moins veut être un langage moderne. Tous les autres langages modernes ont de la reflection. Pourquoi pas C++ ? Et encore, contrairement à ce que la formulation pourrait faire croire, je ne suis pas en train de pleurer pour avoir de la reflection en C++, je souhaite juste connaitre les raisons qui font qu'il n'y en a pas.
    Perso je bosse très majoritairement en C#, que le C++ ait de la reflection ou non ne changera pas ma vie, je suis juste curieux.

    Citation Envoyé par Bousk Voir le message
    Bof, la sérialisation sera faite en json/xml que l'on manipulera de part et d'autre. Pas besoin de réflexion, sauf à vouloir écraser une mouche au marteau-piqueur.
    Et les cas où "je veux pouvoir tout gérer, je ne sais pas du tout à quoi vont ressembler les datas récupérées" j'en ai jamais rencontré perso. Soit les data sont les miennes, donc je les connais, soit y'a une doc qu indique dans quel état elles arrivent.
    Et tu la fais comment la sérialisation json/xml ? Tout ce que j'ai vu jusqu'ici revient a écrire sois-même la sérialisation. C'est à dire fournir des fonctions qui écrivent/lisent une instance et ce pour chaque type sérialisable. Et donc si jamais tu ajoute un membre dans une classe, il faut penser à mettre à jour la fonction de sérialisation correspondante. Le compilo ne t'aidera même pas ne serait-ce qu'a coup de warning, pour te protéger des oublis.
    Je ne vois pas en quoi c'est écraser une mouche au marteau-piqueur.

  4. #4
    Membre averti

    Profil pro
    Inscrit en
    décembre 2013
    Messages
    326
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : décembre 2013
    Messages : 326
    Points : 434
    Points
    434
    Par défaut
    Il y a des travaux pour ajouter de la réflexion au C++.
    Le problème est que cela n'est pas aussi évident qu'il n'y parait.

    Quand tu fais de la sérialisation, tu "convertie" une classe C++ en xml/json/ce-que-tu-veux, puis tu reconverties en C++. Or, ce mécanisme est totalement incompatible avec la sémantique d’entité, donc toutes les classes utilisant l’héritage (non copiable) et les pointeurs (adresse mémoire non réutilisable)

    (sauf erreur de ma part) Dans les autres langages, la sérialisation est activée par défaut et tu as un mécanisme qui permet d'interdire la sérialisation pour les classes qui ne sont pas compatibles.
    Au final, le C++ suit une démarche inverse : la sérialisation n'est pas activée par défaut, il faut écrire explicitement les opérateurs << et >> pour sérialiser les classes que l'on souhaite.
    Les libs de sérialisation proposent simplement des outils pour échanger les données (des byte array avec un format défini), des facilités pour créer les opérateurs de sérialisation, le support du endien, etc.

    Concernant le support du xml/json, c'est avant tout un problème de "philosophie" du C++. Le langage se doit d’être indépendant des "modes" qui peuvent changer. Le xml/json sont des normes externes et donc le C++ ne peut pas prendre en charge ce genre de chose, c'est le boulot les libs externe (il y en a plein déjà)

  5. #5
    Membre expérimenté Avatar de ctxnop
    Homme Profil pro
    Développeur informatique
    Inscrit en
    juillet 2007
    Messages
    858
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Morbihan (Bretagne)

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

    Informations forums :
    Inscription : juillet 2007
    Messages : 858
    Points : 1 719
    Points
    1 719
    Par défaut
    Citation Envoyé par mintho carmo Voir le message
    Il y a des travaux pour ajouter de la réflexion au C++.
    Le problème est que cela n'est pas aussi évident qu'il n'y parait.
    Ah tiens, j'avais pas vu celui là. Dans mes recherche ne n'ai vu que des gens qui se faisaient cracher dessus parce que la reflection c'est trop lourd et on peut avoir d'impacte de perf quand on l'utilise pas (évidemment en omettant qu'on demande justement une reflection on demand et non active partout tout le temps), on peut s'en passer (en faisant tout à la main ce qui pose de gros problèmes entre les risques d'erreur humaine et la maintenance que ca engendre), etc...

    Citation Envoyé par mintho carmo Voir le message
    Quand tu fais de la sérialisation, tu "convertie" une classe C++ en xml/json/ce-que-tu-veux, puis tu reconverties en C++. Or, ce mécanisme est totalement incompatible avec la sémantique d’entité, donc toutes les classes utilisant l’héritage (non copiable) et les pointeurs (adresse mémoire non réutilisable)
    D'où le fait que je parle de contraintes à respecter pour la reflection.
    On peut imaginer qu'une sérialisation fasse forcément du deep-copy par exemple, imposant d'avoir des instances copiables. Cependant il s'agit la de deux choses séparées pour moi. La reflection doit permettre d'inspecter au runtime les classes. Savoir qu'elle contient une méthode truc, qui retourne tel type de données, etc...
    La sérialisation est quelque chose qu'on peut implémenter par dessus la reflection. Et imposer des contraintes supplémentaires n'est pas un problème.

    Citation Envoyé par mintho carmo Voir le message
    (sauf erreur de ma part) Dans les autres langages, la sérialisation est activée par défaut et tu as un mécanisme qui permet d'interdire la sérialisation pour les classes qui ne sont pas compatibles.
    Au final, le C++ suit une démarche inverse : la sérialisation n'est pas activée par défaut, il faut écrire explicitement les opérateurs << et >> pour sérialiser les classes que l'on souhaite.
    Les libs de sérialisation proposent simplement des outils pour échanger les données (des byte array avec un format défini), des facilités pour créer les opérateurs de sérialisation, le support du endien, etc.
    En fait ca dépend.
    Par exemple en .Net la reflection est active tout le temps, pas moyen de la désactiver.
    La sérialisation est possible sur tout objet dès lors que l'objet racine du graph à sérialiser est une référence (pour schématiser a l'extrême, il faut que ce soit une instance qui a été crée via un "new" explicite)
    Ensuite, suivant le serialiseur, il peut être obligatoire, ou non, que les objets du graph implémente une interface de sérialisation (ISerializable, ou IXmlSerializable) auquel cas on est dans le même cas que les opérateurs << et >> du C++, soit on place des attributs sur les classes/membres pour piloter le sérialiseur.
    Certains serialiseurs, comme le serialiseur XML, sérialisent toute propriété publique sauf indication contraire, il n'y a donc aucune obligation d'utiliser les interfaces de serialisation ou les attributs. D'autres imposeront la présence des attributs et échoueront si ne serait-ce qu'un seul objet du graph n'a pas ces attributs.
    Bref, c'est très personnalisable et on a les deux modes de fonctionnement : celui où on fait tout à la main et celui qui se base sur la reflection.

    Citation Envoyé par mintho carmo Voir le message
    Concernant le support du xml/json, c'est avant tout un problème de "philosophie" du C++. Le langage se doit d’être indépendant des "modes" qui peuvent changer. Le xml/json sont des normes externes et donc le C++ ne peut pas prendre en charge ce genre de chose, c'est le boulot les libs externe (il y en a plein déjà)
    On remarquera aussi que ma question d'origine ne parle aucunement d'xml ou de json
    Comme je disais dans ma question d'origine, le manque de reflection est pour moi un frein au développement de système de sérialisation, qui lui même est un frein au développement de solutions réseaux.
    Autrement dit, avec la reflection une lib pourrait implémenter un sérialiseur XML. Et basé sur ce serialiseur XML on pourrait avoir une lib qui fait un peu la même chose que .Net Remoting par exemple, ou WCF, ou je ne sais quoi d'autre.

    Mais surtout, encore une fois, le but de la question n'est pas de faire, à l'image d'un gamin qui fait son caprice dans un supermarché pour que ses parent cèdent et lui achètent ce qu'il demande, un réquisitoire exigeant la mise en place de la reflection en C++.
    Ma question, je le rappel, est de connaitre les raisons qui font qu'il n'y en a pas.
    Je pensais jusqu'ici qu'il n'y en aurait probablement pas, en tout cas avant très longtemps, et donc je voulais savoir quelles sont les raisons qui font que c'est rejeté.

  6. #6
    Expert éminent sénior

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

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

    Informations forums :
    Inscription : juin 2007
    Messages : 5 158
    Points : 16 997
    Points
    16 997
    Par défaut
    La réponse souvent faite à "Pourquoi pas de reflection?" est "Pourquoi faire?".
    Il y a d'autres réponses à la plupart des problèmes traités par introspection.
    Notamment, les templates et la métaprogrammation.

    J'ai fais pas mal de Java, qui l'utilise assez souvent (surtout instanceof et Class<truc>). Et je n'ai jamais ressenti un manque en C++.
    Assez souvent parce que les génériques de Java sont compilées en utilsant Object (c'est à dire Object& en C++), quand en C++, on a des templates qui produisent du code complètement typés.
    Mes principes de bases du codeur qui veut pouvoir dormir:
    • Une variable de moins est une source d'erreur en moins.
    • Un pointeur de moins est une montagne d'erreurs en moins.
    • Un copier-coller, ça doit se justifier... Deux, c'est un de trop.
    • jamais signifie "sauf si j'ai passé trois jours à prouver que je peux".
    • La plus sotte des questions est celle qu'on ne pose pas.
    Pour faire des graphes, essayez yEd.
    le ter nel est le titre porté par un de mes personnages de jeu de rôle

  7. #7
    Membre averti

    Profil pro
    Inscrit en
    décembre 2013
    Messages
    326
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : décembre 2013
    Messages : 326
    Points : 434
    Points
    434
    Par défaut
    On part de toute façon vers une réflexion compile time, pas runtime.

    Au final, il y a pas mal de système de sérialisation en C++ (et de réflexion/introspection). C'est juste que l'on considère que ce n'est pas au langage de proposer cela, mais a des outils externes.

    Perso, j'utilise généralement des struct POD rien que pour la sérialisation. Pas trop de risque d'oublier un membre, ni d’écriture trop lourde. Du coup, je n'ai pas besoin/envie d'avoir un mécanisme automatique qui va me casser les pieds pour les 1000 classes qui n'ont pas besoin d’être sérialisées, juste pour me simplifier la vie sur les 10 classes sérialisables

  8. #8
    Membre expérimenté Avatar de ctxnop
    Homme Profil pro
    Développeur informatique
    Inscrit en
    juillet 2007
    Messages
    858
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Morbihan (Bretagne)

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

    Informations forums :
    Inscription : juillet 2007
    Messages : 858
    Points : 1 719
    Points
    1 719
    Par défaut
    Citation Envoyé par leternel Voir le message
    La réponse souvent faite à "Pourquoi pas de reflection?" est "Pourquoi faire?".
    Il y a d'autres réponses à la plupart des problèmes traités par introspection.
    Notamment, les templates et la métaprogrammation.

    J'ai fais pas mal de Java, qui l'utilise assez souvent (surtout instanceof et Class<truc>). Et je n'ai jamais ressenti un manque en C++.
    Assez souvent parce que les génériques de Java sont compilées en utilsant Object (c'est à dire Object& en C++), quand en C++, on a des templates qui produisent du code complètement typés.
    Bah je serai assez curieux de voir comment tu fais pour répondre aussi simplement à tout ce à quoi répond la reflection (et c'est une question sérieuse, j'aimerai vraiment voir comment tu réponds aux mêmes problématiques).
    On parlait même de sérialisation par exemple. Tout ce que j'ai vu jusqu'ici revenait à écrire soit même une méthode pour lire et écrire et ce pour chaque type à sérialiser, posant ainsi la problématique du risque de l'erreur humaine et de la maintenance (quand j'ajoute un membre sur le type, il faut penser a modifier la méthode de lecture et la méthode d'écriture, le compilo ne préviendra pas en cas d'oubli).
    Mais il y a aussi la construction automatique des contrôles graphiques en fonction de la source de données. Par exemple, si je place une liste de Person (cité en exemple plus bas) dans une grille, elle créera toute seule les 3 colonnes qui vont bien. Alors évidemment, c'est un exemple simple puisque je sais ici de quel type est l'objet, qu'il ne contient que 3 propriétés, etc...
    Des cas d'utilisations il y en a des quantités industrielles. Il existe très certainement d'autres façon de faire pour chaque cas d'utilisation, mais ca ne justifie pas de ne pas permettre l'utilisation de la reflection.

    Laissons les gens décider des outils qu'ils veulent utiliser, même si ces outils sont moins bon.
    Qu'on incite les gens à utiliser telle ou telle méthode parce qu'elle est meilleure pour le but souhaité ne me pose aucun problème. Et il n'est absolument pas question de supprimer les méthodes actuelles pour ne mettre que la reflection à la place. Mais le fait qu'il existe des méthodes qui marchent déjà pour un but donné ne justifient pas de refuser une nouvelle méthode. Surtout quand les méthodes actuelles sont complexes ou limitées. Je ne dis pas que la reflection n'a pas ses limites ou qu'elle n'est pas complexe. Mais certains s'en sortent mieux avec ces système.

    Mais bon, passons, je ne veux pas transformer ce post en un plaidoyer pour la reflection vs les-autres-méthodes. Encore une fois je cherche les vrais raisons valables d'un refus de la reflection.

    Citation Envoyé par mintho carmo Voir le message
    Du coup, je n'ai pas besoin/envie d'avoir un mécanisme automatique qui va me casser les pieds pour les 1000 classes qui n'ont pas besoin d’être sérialisées, juste pour me simplifier la vie sur les 10 classes sérialisables
    C'est typiquement le genre de réaction que je n'arrive pas à comprendre...
    Pourquoi penser qu'un tel système te cassera les pieds pour les classes qui n'ont pas besoin d'être sérialisées ? Il n'y a aucune raison que ces classes la subissent quoi que ce soit comme changement. Il n'y a donc aucune raison pour que ca te casses les pieds. En conséquence pourquoi refuser un système qui te simplifierai la vie sur les 10 classes restante ? Juste "par principe" ? Parce que "je suis un homme, un vrai" ? Parce que "j'aime pas quand c'est trop simple" ?

    Prenons un exemple en C# qui a de la reflexion et de la serialisation XML tout en restant relativement proche du C++ :
    Code c# : 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
     
    [XmlRoot("person")]
    public class Person
    {
        public string FirstName {get;set;}
        public string LastName {get;set;}
        public uint Age {get;set;}
    }
     
    class Program
    {
        static void Main()
        {
            Person p = new Person { FirstName = "Alphonse", LastName = "Smith", Age = 38 };
            XmlSerializer xs = new XmlSerializer(typeof(Person));
            using (FileStream fs = new FileStream("test.xml", FileMode.Create))
            {
                xs.Serialize(fs, p);
            }
        }
    }
    Dans cet exemple, la présence de l'attribut "XmlRoot" est optionnel, puisqu'en .Net le XmlSerializer sérialise via la reflection toute propriété publique de tout type (bon en vrai il n'y a pas que de la reflection derrière ce serialiseur puisqu'il génère une classe avec les méthodes de sérialisation/désérialisation, cette classe est construite et utilisée au runtime).
    Je ne vois pas pourquoi il ne pourrait pas y avoir un système relativement équivalent. Le principe serait qu'un simple attribut, ou mot clef, ou what-ever, indique au compilateur qu'il faille générer les metadatas de la classe ciblée. Ces metadatas seraient alors interrogeable au runtime via une API.

    L'idée c'est que tout code tel qu'il est actuellement, qui n'utilise pas la reflection, ne change pas d'un pouce. Le contraire est juste impensable. Partant de ça, en aucun cas le système ne pourrait embêter ceux qui ne veulent pas l'utiliser, qui ne l'utilisent pas, ou qui l'utilisent uniquement pour 2 ou 3 classes. Ça me semble être l'un des précepte du C++ : ne pas casser l'existant et ne pas imposer de choix.

  9. #9
    Membre averti

    Profil pro
    Inscrit en
    décembre 2013
    Messages
    326
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : décembre 2013
    Messages : 326
    Points : 434
    Points
    434
    Par défaut
    c'est pas une question d’être "un homme". Je n'aime pas non plus me taper 100 lignes de code lorsque 1 suffit.
    Regarde une lib comme boost.serialize. Ca prend pas 100 lignes pour faire cela, il y a juste une fonction supplémentaire a déclarer dans la classe de sérialisation.
    Quand au risque d'erreur, si tu as une classe qui ne fait que cela (respect du SRP, localité des informations), difficile de se planter.

  10. #10
    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 : 47
    Localisation : France, Yvelines (Île de France)

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

    Informations forums :
    Inscription : août 2004
    Messages : 5 463
    Points : 16 213
    Points
    16 213
    Par défaut
    Je pense qu'il est faux de dire qu'il n'y a pas d'efforts vers le réflexion. Il y en a. Probablement pas assez, mais globalement, tout le monde semble d’accord pour dire que ce serait un plus. Il y a même un groupe de travail autour de ce sujet.

    Il semble y avoir un consensus sur le point suivant : Il faut d'abord se concentrer sur une réflexion au compile-time. À partir de là, une reflexion runtime sera simple à mettre en place pour qui veut.

    C'est hélas à peu près le seul point où il semble y avoir accord... Doit-on avancer petit pas par petit pas, ou vaut-il mieux avoir une vision globale ? Est-il acceptable de baisser les performances de compilation pour permettre la reflexion ? Dans quelle mesure ? Est-il acceptable de baisser les performances au runtime ? Dans quelles mesure ?...

    Et surtout je pense que c'est un sujet pour lequel tout le monde est d'accord pour que ça avance, mais qu'il manque un poids lourd du comité qui soit vraiment motivé pour le faire avancer, et qui en fasse son activité principale.

    Quelques papiers sur le sujet :
    http://www.open-std.org/jtc1/sc22/wg...2014/n3984.pdf
    http://www.open-std.org/jtc1/sc22/wg...2014/n3996.pdf
    http://www.open-std.org/jtc1/sc22/wg...2014/n3951.pdf
    http://www.open-std.org/jtc1/sc22/wg...2014/n3972.pdf
    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.

  11. #11
    Membre expérimenté Avatar de ctxnop
    Homme Profil pro
    Développeur informatique
    Inscrit en
    juillet 2007
    Messages
    858
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Morbihan (Bretagne)

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

    Informations forums :
    Inscription : juillet 2007
    Messages : 858
    Points : 1 719
    Points
    1 719
    Par défaut
    Content de voir qu'il y a finalement des choses qui vont dans ce sens.
    Personnellement les coûts en compiletime et runtime ne me posent aucun souci dès lors qu'ils n'interviennent que si la reflection est activée/utilisée. Ça me semble impensable que ça puisse impacter un code qui ne l'utilise pas.

  12. #12
    Membre averti
    Profil pro
    Inscrit en
    janvier 2007
    Messages
    301
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : janvier 2007
    Messages : 301
    Points : 344
    Points
    344
    Par défaut
    Je plussoi sur le manque d'introspection en C++. Mon cas d'usage c'est pour faire du remote method invocation: c'est ultra galère; soit on passe par un précompilateur (par exemple windows RPC avec un idl compilé qui génère des .c et .h à inclure) soit on passe par des macros qui "machent" un peu le travail sur la génération des métadata (par exemple Boost.Reflect; c'est une lib non officielle et n'est pas actuellement dans boost) mais avec tous les problèmes évoqués par l'OP.
    Bref, pas de solution élégante au problème alors que c'est si simple dans d'autres languages.

    PS: pour un autre cas d'usage, j'étais tombé sur cet article

  13. #13
    Expert éminent sénior
    Avatar de Luc Hermitte
    Homme Profil pro
    Développeur informatique
    Inscrit en
    août 2003
    Messages
    5 273
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : août 2003
    Messages : 5 273
    Points : 10 959
    Points
    10 959
    Par défaut
    Pour XML, deux cas de figure:
    - je veux sérialiser avec moi-même, déjà pas besoin de cette saleté d'XML, et ensuite boost.serialize fera le boulot. Si vraiment tu veux tout générer automatiquement, je tendrai à passer par des fichiers texte que je parserai avec perl/ruby pour générer classes C++ et code de sérialization pour boost.serialize
    - je dois échanger avec d'autres, alors on commence par pondre le format d'échange avec un .xsd. Puis on passe des FSOSS (comme CodeSynthesis XSD/tree) sur les .xsd pour générer le code C++ des classes de données et le code de sérialisation. Le jour où schéma change, les classes générées changent aussi, et il faudra adapter le code.

    Pour les bases de données, il me semble aussi avoir vu des choses qui génèrent le code à partir des schémas.
    Pour JSON, j'ai vu passer des lib ces derniers mois, mais je n'ai pas creusé.
    Blog|FAQ C++|FAQ fclc++|FAQ Comeau|FAQ C++lite|FAQ BS|Bons livres sur le C++
    Les MP ne sont pas une hotline. Je ne réponds à aucune question technique par le biais de ce média. Et de toutes façons, ma BAL sur dvpz est pleine...

  14. #14
    Expert confirmé

    Profil pro
    Inscrit en
    avril 2010
    Messages
    481
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : avril 2010
    Messages : 481
    Points : 4 238
    Points
    4 238
    Par défaut
    Je plussoi sur le manque d'introspection en C++.
    +1

    C'est pour moi le plus gros manque du langage C++ par rapport au C# ou Java.
    Même s'il ne faut pas l'utiliser pour faire tout et n'importe quoi, ça peut être extrêmement utile dans certaines situations.

    C'est en partie ce qui m'a motivé pour le développement de la bibliothèque QxOrm !
    D'ailleurs, on retrouve dans cette discussion plusieurs sujets traités par la bibliothèque QxOrm : l'introspection, la sérialisation, la génération de code à partir de schémas existants (QxEntityEditor), remote method invocation (module QxService).
    Alors oui aujourd’hui, une étape de mapping est nécessaire en C++ pour enregistrer les éléments dans le moteur d'introspection : c'est pourquoi cet enregistrement est effectué qu'une seule fois avec QxOrm, et ensuite toutes les fonctionnalités de la bibliothèque sont disponibles (l'introspection, la sérialisation, la persistance, etc...).
    Le site de la bibliothèque QxOrm : bibliothèque C++ de gestion de données (Mapping Objet Relationnel ou ORM) basée sur les frameworks Qt et boost.
    QxEntityEditor : éditeur graphique pour la bibliothèque QxOrm (application multi-plateforme pour gérer graphiquement le modèle d'entités).

    Tutoriel : installer un environnement de développement avec QxOrm sous Windows.
    Tutoriel qxBlog : gestion de blogs en C++/Qt.
    Tutoriel qxClientServer : création d'un serveur d'applications en C++/Qt.

  15. #15
    Membre émérite
    Avatar de white_tentacle
    Profil pro
    Inscrit en
    novembre 2008
    Messages
    1 505
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : novembre 2008
    Messages : 1 505
    Points : 2 798
    Points
    2 798
    Par défaut
    Citation Envoyé par Luc Hermitte Voir le message
    Pour les bases de données, il me semble aussi avoir vu des choses qui génèrent le code à partir des schémas.
    J’ai toujours trouvé cette approche comme allant à l’envers. Je vois bien un cas d’utilisation, c’est si je dois faire un programme d’interrogation d’une BDD dont je ne maîtrise pas la structure.

    Mais pour tout le reste, je trouve beaucoup plus pertinente l’approche inverse : je génère le schéma de BDD à partir du code (ça rejoint ce que dit l’op, il faut un mécanisme d’introspection statique à minima). Je n’y vois que des avantages par rapport à l’approche inverse :
    * je gère tout dans le même langage
    * je suis capable de détecter très facilement les incohérences code / schéma à l’exécution, et d’y répondre éventuellement
    * la sérialisation vers un format X devient quasi triviale (car c’est le même mécanisme, ou presque, qui permet de sérialiser en base qui va être utilisé)
    * je ne dépend pas d’une moulinette externe à rajouter dans ma chaîne de compilation

  16. #16
    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 : 47
    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 white_tentacle Voir le message
    J’ai toujours trouvé cette approche comme allant à l’envers. Je vois bien un cas d’utilisation, c’est si je dois faire un programme d’interrogation d’une BDD dont je ne maîtrise pas la structure.
    J'ai l'impression que ce cas d'utilisation est très courant. Car un des principaux intérêts d'une BDD par rapport à une solution plus simple, c'est si elle sert de moyen de communication entre plusieurs applications.
    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.

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. problème d'introspection sous eclipse
    Par rainz dans le forum Eclipse Java
    Réponses: 4
    Dernier message: 13/05/2005, 16h33
  2. [Java 5] Réflexion sur les énumérations type-safe
    Par rozwel dans le forum Langage
    Réponses: 5
    Dernier message: 04/12/2004, 20h34
  3. fonction de tri par introspection
    Par ned-flanders dans le forum C++
    Réponses: 7
    Dernier message: 21/10/2004, 11h49
  4. [JNDI] [LDAP] [DirContext] [LdapContext] DN / introspection
    Par wazup dans le forum API standards et tierces
    Réponses: 2
    Dernier message: 09/04/2004, 15h16

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