Discussion :

[ctxnop]

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.

[Bousk]

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.

[ctxnop]

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.

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.

[mintho carmo]

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à)

[ctxnop]

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...

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.

(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.

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é.

[ternel]

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.

[mintho carmo]

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

[ctxnop]

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.

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.

[mintho carmo]

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.

[JolyLoic]

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

[ctxnop]

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.

[CedricMocquillon]

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

[Luc Hermitte]

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é.

[QxOrm]

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...).

[white_tentacle]

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

[JolyLoic]

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.