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

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.

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.

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.

Hello, CAMP m'intéresse beaucoup pour mon projet, mais je ne trouve plus de lien valide. :(
Le projet n'est plus libre ? :koi:

Salut

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

Citation:

---

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.

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

Citation:

---

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

Citation:

---

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

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 ?

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

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é

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

A propos du fameux code déclaratif :

Code:

---

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:

---

1 2 3 4

CAMP_TYPE(Person); CAMP_DECLARE_PUBLIC_METHODS(Person); CAMP_DECLARE_PRIVATE_FIELDS(Person);

---

Ou quelque chose dans l'idée.

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

+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:

---

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 ! ;)

Citation:

---

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 :mrgreen: je dis pas que c'est facile.

Citation:

---

Envoyé par jblecanard

- Si c'est comment techniquement ? C'est le boulot de la lib :mrgreen: je dis pas que c'est facile.

---

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

Citation:

---

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.

Citation:

---

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++ :mouarf:. 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.

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.