Discussion :

[epsilon68]

en tous les cas j'aime vraiment bien ta lib,
si je compare le code (utilisateur) avec mirror,
c'est beaucoup plus clean avec la tienne.

en plus on peut controler quel attribut (ou autre) exactement nous voulons inclure ou non.

je pense que je vais (dois) m'y mettre tres prochainement.

cependant, peux-tu juste me dire si on peut faire 2 meta classes pour une meme classe? mon utilisation serait que parfois je dois faire une metaclasse pour un certain type de serialisation, puis j'en ai besoin d'une autre pour un autre contexte.

encore felicitations, le code est vraiment clean.

[Laurent Gomila]

en tous les cas j'aime vraiment bien ta lib,
si je compare le code (utilisateur) avec mirror,
c'est beaucoup plus clean avec la tienne.

Disons que ce n'est pas la même approche, voire le même but. boost.mirror fournit un vrai mapping 1:1 entre code C++ et informations réflechies. Les macros sont plus verbeuses, mais du coup tout est "pré-câblé" directement, les infos sont même exploitables par le compilo pour écrire des meta-programmes.

cependant, peux-tu juste me dire si on peut faire 2 meta classes pour une meme classe? mon utilisation serait que parfois je dois faire une metaclasse pour un certain type de serialisation, puis j'en ai besoin d'une autre pour un autre contexte.

Nop (du moins pas en même temps). Ca créerait trop d'inconsistences en interne, car CAMP doit pouvoir déterminer de manière unique et automatique quelle meta-classe est associée à quel type C++.

[epsilon68]

J'ai vu qu'un module json existait...
mais je pense que le json devrait etre écrit sans utiliser de structure intermediaire... je pense que je vais l'implementer tres prochainement!

CAMP est vraiment cool :-)

[epsilon68]

Hello,

j'ai compilé camp pour macosx, et je tourne autour avant de m'attaquer à mon probleme. J'utilise aussi Qt et la je regarde pour QString.
J'aurais bien une question, dans le source code suivant:

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
class MyClass
{
public:
 
    int func(QString s, int i) { return i*2; }
    QString prop;
};
 
CAMP_TYPE(MyClass)
 
int main()
{
    camp::Class::declare<MyClass>("MyClass")
        .function("func", &MyClass::func)
        .property("prop", &MyClass::prop)
        ;
 
    MyClass o;
    o.prop = "coucou";
 
    std::cout << "prop: " << o.prop.toLatin1().constData() << std::endl;
 
    camp::UserObject object = o;
    object.set("prop", "hello");
    std::string s = object.get("prop");
 
    std::cout << "prop (camp): " << o.prop.toLatin1().constData() << std::endl;
 
    int i = object.call("func", camp::Args("hello", 20));
 
    std::cout << "func (camp): " << i << std::endl;
 
    return 0;
}

quand on fait:

Code :

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

std::string s = object.get("prop");

pareil pour:

Code :

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

object.set("prop", "hello");

comment se fait la conversion entre unicode et std::string?

EDIT: trouvé: par fromStdString et toStdString
mais alors me suis-je dis... que faire avec unicode?
bein en fait assigner et recuperer des QString marche aussi
c'est génial!

[epsilon68]

Nop (du moins pas en même temps). Ca créerait trop d'inconsistences en interne, car CAMP doit pouvoir déterminer de manière unique et automatique quelle meta-classe est associée à quel type C++.

en fait, on peut se servir des tags sur les propriétés donc c'est bon :-)

[vikki]

Bonjour à tous,
Puisque ce post est dédié à CAMP, je permet d'écrire ici plutôt que de créer une nouvelle discussion.
Je me demandais s'il était possible d'enregistrer une classe auprès de CAMP de manière dynamique, donc sans passer par la macro CAMP_TYPE et la spécialisation de classe sous-jacente. J'ai réussi à la faire en définissant une méthode statique CAMP_TYPE_NOT_REGISTERED() dans ma classe à enregistrer de cette manière (l'exemple est un peu bidon mais fonctionne):

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
 
struct cstring : public std::string
{
	std::string str;
	static const char* CAMP_TYPE_NOT_REGISTERED(){return "cstring";}
};
 
void register_cstring()
{
        camp::Class::declare<cstring>("CTestString")
       .constructor0();
}
 
//dans main():
const camp::Class& metaclass = camp::classByName("CTestString");
std::string* str= metaclass.construct<std::string>();

Ça fonctionne avec la version 0.6.0 (pas testé avec la 0.7.1), mais ca ressemble plus à un hack qu'autre chose...

[Laurent Gomila]

Ca compile, mais ça ne fonctionnera pas. Là tout ce que tu fais c'est éviter le système mis en place pour avoir un message d'erreur compréhensible lorsque la classe n'est pas déclarée avec CAMP_TYPE. Mais ce n'est pas juste pour faire beau qu'on a mis en place ce système

Je ne comprends pas pourquoi tu veux éviter cette macro, elle ne déclare rien, elle associe juste un identificateur à la classe pendant la compilation. La déclaration de la meta-classe intervient avec camp::Class::declare, et ça c'est bien dynamique.

[vikki]

Hello,

J'ai fait un petit programme test qui me semble fonctionner correctement.

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
 
//// main.cpp ////
 
#include <camp/camptype.hpp>
#include <camp/class.hpp>
#include <iostream>
 
struct A
{
	virtual void print() {std::cout<<"A"<<std::endl;}
};
 
struct B : public A
{
	virtual void print() {std::cout<<"B"<<std::endl;}
	static const char* CAMP_TYPE_NOT_REGISTERED(){return "B";}
};
 
CAMP_TYPE(A);
 
int main()
{
	camp::Class::declare<A>("A")
		.constructor0();
 
	camp::Class::declare<B>("B")
		.base<A>()
		.constructor0();
 
 
     const camp::Class& metaclass = camp::classByName("B");
     A* a = metaclass.construct<A>();
	 a->print();
 
	 std::system("pause");
}

Bon, après je ne suis pas sûr à 100% de l'utilité. Mon but est de créer un système de plugins (probablement basé sur l'API de Qt), chaque plugin contenant une classe fille de A et une fonction permettant le bind de cette classe vers camp (je m'en sers pour la génération automatique d'éléments d'IHM). Du coup je ne sais pas trop ce qui ce passe en utilisant CAMP_TYPE à l'intérieur de mon plugin, l'appli principale va-t-elle vraiment reconnaitre le nouveau type enregistré (vu que tout semble se faire à la compilation), ou alors faudra-t-il que j'exporte également la spécialisation de classe implémentée par CAMP_TYPE? ou alors j'ai rien compris ?

[Laurent Gomila]

En fait, étant donné la façon dont CAMP_TYPE_NOT_REGISTERED est utilisé pour générer une erreur, la fonction que tu définis joue effectivement le même rôle qu'un CAMP_TYPE. Mais du coup autant utiliser CAMP_TYPE...

Ensuite effectivement CAMP_TYPE n'est pas toujours nécessaire, en particulier dans ton cas. Tout comme en C++ tu n'aurais pas besoin d'inclure l'en-tête de la classe B pour l'utiliser via un A*, avec CAMP tu n'as pas besoin de CAMP_TYPE(B). En fait, CAMP_TYPE n'est requis que pour les opérations statiques (à la compilation) impliquant le type en question. C'est pour cela qu'on le met en général juste après la définition de la classe : si tu peux te passer de celle-ci, tu peux aussi te passer du CAMP_TYPE correspondant (et inversement).
Tu aurais eu une erreur de compilation si par exemple tu avais écrit camp::classByType<B>().

Donc pour résumer, CAMP_TYPE est bien nécessaire mais uniquement pour déclarer la metaclasse, donc dans le plugin. Dans ton programme principal tu n'en auras pas besoin.

[vikki]

Ensuite effectivement CAMP_TYPE n'est pas toujours nécessaire, en particulier dans ton cas. Tout comme en C++ tu n'aurais pas besoin d'inclure l'en-tête de la classe B pour l'utiliser via un A*, avec CAMP tu n'as pas besoin de CAMP_TYPE(B). En fait, CAMP_TYPE n'est requis que pour les opérations statiques (à la compilation) impliquant le type en question. C'est pour cela qu'on le met en général juste après la définition de la classe : si tu peux te passer de celle-ci, tu peux aussi te passer du CAMP_TYPE correspondant (et inversement).
Tu aurais eu une erreur de compilation si par exemple tu avais écrit camp::classByType<B>().

Ah oui, je vois mieux comment ca fonctionne et j'étais bien à coté de mes pompes J'ai fait un petit test de plugin avec boost.python et camp et ca marche nickel, merci beaucoup !