Nouvelle bibliothèque libre de réflexion pour C++ [Nouveauté]

**Laurent Gomila** · 03/09/2009, 11h08

Oui, toujours dans l'optique de ne pas être intrusif, l'objet lui-même ne véhicule pas d'information relative à l'introspection, tout lui est associé de manière externe.

**Klaim** · 03/09/2009, 14h25

A part pour le binding de language de scripts, je vois aussi que ça pourrait grandement aider pour des outils d'edition de jeu (ou autre) par exemple. Ca semble du coup très facile d'exposer directement les classes représentant les entitées d'un jeu au code de l'outil d'edition et permettre au développeur de se concentrer sur cet outil.

**Laurent Gomila** · 03/09/2009, 14h34

Complètement, d'ailleurs dans le studio de jeux dans lequel je bossais avant, on avait un système similaire et il était impressionnant de voir à quel point ça décuplait les possibilités des game designers, et cela nous allégeait le travail.
Et cela concernait aussi le binding script, qui était très largement utilisé pour tout le code de gameplay.

**poukill** · 09/04/2010, 10h59

Hello, CAMP m'intéresse beaucoup pour mon projet, mais je ne trouve plus de lien valide.

Le projet n'est plus libre ?

**Laurent Gomila** · 09/04/2010, 12h09

Salut

CAMP est toujours libre et disponible, mais il y a eu quelques changements, je t'explique tout ça par MP

**Davidbrcz** · 09/04/2010, 17h33

Envoyé par Laurent Gomila

Salut

CAMP est toujours libre et disponible, mais il y a eu quelques changements, je t'explique tout ça par MP

Pourquoi par MP ? Je suis tout aussi avide d'explications.

Merci.

**Laurent Gomila** · 09/04/2010, 18h34

En fait ce qui concerne CAMP est en remaniement en ce moment, je posterai des explications quand tout aura été tiré au clair.

Pour le moment le site web n'a plus de page pour CAMP, mais je peux fournir les packages par e-mail, d'où le MP. Mais effectivement j'aurais peut-être dû dire tout ça tout à l'heure

**guillaume07** · 09/04/2010, 20h35

Envoyé par ram-0000

J'avoue que je me le demande aussi.

Si quelqu'un avait une explication simple avec un exemple concret à proposer, je lui en serait éternellement reconnaissant.

exemple le designer d'un framework graphique type qt, utilise l'introspection pour afficher le volet des propriétés pour chaque widget

**camboui** · 11/04/2010, 22h06

Envoyé par Laurent Gomila

En fait ce qui concerne CAMP est en remaniement en ce moment, je posterai des explications quand tout aura été tiré au clair.

Pour le moment le site web n'a plus de page pour CAMP, mais je peux fournir les packages par e-mail, d'où le MP. Mais effectivement j'aurais peut-être dû dire tout ça tout à l'heure

CAMP me semble très intéresssant pour le SBD que j'envisage. Pas d'urgence, pas besoin de m'envoyer les packages, mais tiens-nous au courant quand se sera de nouveau dispo

**Laurent Gomila** · 11/04/2010, 22h16

Oui oui bien sûr, vous aurez des news dès demain, et un nouveau site web / espace développeur devrait être disponible d'ici quelques jours.

C'est quoi un SBD ? Tu voulais peut-être dire SGBD ?

**camboui** · 11/04/2010, 22h37

Oui, SGDB, sauf que le qualifier de "Général" est peut-être excessif.
Je pense d'ailleurs qu'aucun SGBD ne mérite ce qualificatif.

EDIT: bon, après vérification SGBD veut dire "système de gestion de base de données". Je pensais que c'était "système général de base de données".
Je vais dormir, c'est l'heure...

**Laurent Gomila** · 12/04/2010, 12h28

Comme promis voilà les news :
- Le code source de CAMP va très prochainement être hébergé publiquement sur www.github.com
- Un nouveau site dédié au projet fournira wiki, forum, task tracker, etc.
- La licence passera en LGPL
- Une version 0.7 sortira peu de temps après pour remettre tout au clair
- A partir de là je travaillerai activement sur la version 1.0 et sur le support / développement de la communauté

**jblecanard** · 13/04/2010, 16h51

Cool, CAMP risque de m'intéresser aussi à terme

A propos du fameux code déclaratif :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
     // Bind our Person class to CAMP
     camp::Class::declare<Person>("Person")
         .constructor1<std::string>()
         .property("name", &Person::name)
         .property("age", &Person::age, &Person::setAge)
         .function("speak", &Person::speak);

Je trouve que c'est bien car cela permet de choisir finement le niveau d'exposition de la classe aux méta-données.

Par contre, ça serait bien si on avait aussi une macro pour le faire tout seul dans certain cas.

Du genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
CAMP_TYPE(Person);
CAMP_DECLARE_PUBLIC_METHODS(Person);
CAMP_DECLARE_PRIVATE_FIELDS(Person);

Ou quelque chose dans l'idée.

**Laurent Gomila** · 13/04/2010, 17h01

Et comment cette macro connaîtrait-elle les fonctions et membres à déclarer ?

**poukill** · 13/04/2010, 17h31

+1
Surtout qu'il y a des membres public ou privés sans getter que l'on se souhaite pas exposer...

Qui plus est, tu peux aussi documenter à la manière des docs_string de Boost.Python grâce au tag, genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
camp::Class::declare<CBlobMerging>("CBlobMerging")
		.tag("help", "test")
		.base<IVisionModule>()
		.constructor0()
		.property("orientation",	&CBlobMerging::m_orientation).tag("property", "Orientation of the box")
		.property("distance",		&CBlobMerging::m_distance).tag("property", "Distance between two boxes")
		.property("input",			&CBlobMerging::m_input_name).tag("input", "List of Bounding Boxes")
		.property("output",			&CBlobMerging::m_output_name).tag("output", "List of Bounding Boxes");

Du coup, pas de miracle, il faut tout faire à la main !

**jblecanard** · 13/04/2010, 17h41

Envoyé par poukill

+1
Surtout qu'il y a des membres public ou privés sans getter que l'on se souhaite pas exposer...

Je suis d'accord, mais dans ce cas il suffit de ne pas utiliser la macro et de déclarer à la mano (je rejoins mon post précédent ou je dis que c'est bien pour gérer l'exposition finement).

Quant à comment une telle macro trouve les membres à déclarer, ça dépend de ta question :
- Si c'est quels membres choisir ? Ben par exemple, toutes les méthodes publiques (CAMP_DECLARE_PUBLIC_METHODS).
- Si c'est comment techniquement ? C'est le boulot de la lib

je dis pas que c'est facile.

**camboui** · 13/04/2010, 17h48

Envoyé par jblecanard

- Si c'est comment techniquement ? C'est le boulot de la lib

je dis pas que c'est facile.

Je pense bien que c'est impossible, sauf si C++ peut énumérer. J'en doute.

**Jean-Marc.Bourguet** · 13/04/2010, 17h57

Envoyé par camboui

Je pense bien que c'est impossible, sauf si C++ peut énumérer. J'en doute.

Je confirme que ce n'est pas possible.

**jblecanard** · 13/04/2010, 18h02

Envoyé par camboui

Je pense bien que c'est impossible, sauf si C++ peut énumérer. J'en doute.

Pour faire preuve de mauvaise foi, je dirais qu'on parle bien d'une macro, et donc qu'on est encore dans le précompilo, et pas dans C++

. Mais vous avez raison, c'est sans doute en effet impossible sans génération de code.

On peut le faire avec de la génération, mais ça touche à la chaîne de compilation et on sort du cadre de camp.

**Laurent Gomila** · 16/04/2010, 17h53

Voilà l'adresse du nouveau dépôt sur github :
http://github.com/tegesoft/camp

Le code qui s'y trouve est déjà passé en LGPL, nous ferons aussi bientôt une nouvelle release toute propre.

Le site web avec wiki/forum/tracker sera mis en place un peu plus tard.

Nouvelle bibliothèque libre de réflexion pour C++ [Nouveauté]

C++

Discussions similaires

Partager

Partager