Discussion :

[Klaim]

L'injection de dépendance... ça serait pas utile pour des framework web façon CPPCMS?

[JulienDuSud]

Ou comment faire du java en C++.. autant lancé netbeans / eclipse et faire du java ..

Le GC n'est pas la seule différence entre le Java et le C++. shared_ptr peut être assimilé à un garbage collector, quelque part. Pourtant c'est pas pour autant que le C++ se transforme d'un coup en java parce qu'on a plus de delete .

Les templates, le contrôle complet de l'allocation, la surcharge d'opérateurs, l'héritage multiple, avoir des classes sans méthodes virtuelles, etc...

[Goten]

Je réagissais à un tout, pas qu'au gc. Et le Père peut vouloir un gc c'est pas pour autant que je suis d'accord. Je préfère une approche déterministe personnellement. (d'autant plus qu'un gc __celui de java en tout cas__ ça se met en défaut aisément).

[JulienDuSud]

Je réagissais à un tout, pas qu'au gc. Et le Père peut vouloir un gc c'est pas pour autant que je suis d'accord. Je préfère une approche déterministe personnellement. (d'autant plus qu'un gc __celui de java en tout cas__ ça se met en défaut aisément).

Le jour où tu feras quelque chose de non-déterministe sur un PC tu m'appelles ^^.

Le but de tout programmeur, c'est de simplifier sa tâche compliquée à chaque étape du développement. CAMP permet une solution simple à certains problèmes très compliqués. shared_ptr permet de simplifier d'autres problèmes, l'injection de dépendances permet de simplifier encore des problèmes différents, etc etc. De plus, tout cela fait partie de la séparation de rôles, qui est un pillier très important de la programmation orienté objet. Le nier c'est de descendre le C++ au niveau de l'assembleur. Autant faire de l'assembleur dans ce cas !

De toutes manières, tant que cela reste du C++ pur et n'impose pas de devoir faire tourner son logiciel dans un environnement précis, alors pour moi tout est bon à prendre

Bref, je pense qu'il est inutile de polluer ce topic, si tu veux en discuter d'avantage, je te propose de créer un topic .

[Lavock]

Non mais ça me rassure, y a pas qu'à moi que CAMP fait pensais sévèrement à du JEE/spring >< !

M'enfin, si c'est pour faire ça, je préfère les @remote à toute ces lignes compliqué -_-' !

Mais quand même, chapeau bas !

Pour les inje de dépendance, je crois que y a un tuto spring sur la partie java du site.

[3DArchi]

Salut,

Le jour où tu feras quelque chose de non-déterministe sur un PC tu m'appelles ^^.

C'est quoi ton PC ? Parce que le mien, j'ai parfois des doutes entre ce qu'il fait et ce que je veux qu'il fasse.
En fait, je me demande si je ne pense pas le contraire (mais c'est un autre débat).

Le but de tout programmeur, c'est de simplifier sa tâche compliquée à chaque étape du développement. CAMP permet une solution simple à certains problèmes très compliqués. shared_ptr permet de simplifier d'autres problèmes, l'injection de dépendances permet de simplifier encore des problèmes différents, etc etc. De plus, tout cela fait partie de la séparation de rôles, qui est un pillier très important de la programmation orienté objet. Le nier c'est de descendre le C++ au niveau de l'assembleur. Autant faire de l'assembleur dans ce cas !

De toutes manières, tant que cela reste du C++ pur et n'impose pas de devoir faire tourner son logiciel dans un environnement précis, alors pour moi tout est bon à prendre

On voit avec cette discussion à quel point CAMP peut être intéressant vu la variété de chose qu'il permet de faire. On sent que c'est là sa puissance. Probablement qu'il y a encore d'autres pistes à explorer.
En tout cas, moi je dit chapeau bas à Laurent et son équipe

[poukill]

C'est encourageant...
c'est quoi ton projet ? et que lui apporte CAMP ?
perso j'ai besoin d'exemples concrets pour bien comprendre à quoi ça peut servir.
tu pourrais peut-être parler un peu plus de ton utilisation de CAMP pour aider les gens comme moi ?

C'est chose faite.
Sur le wiki de CAMP, j'explique comment CAMP a résolu la modification d'objets depuis une interface graphique via l'introspection.
C'est ICI !

J'espère que ça éclairera du monde, car cette lib, elle vaut de l'or !

[Laurent Gomila]

Nous venons d'écrire un module XML :
http://dev.tegesoft.com/projects/camp/wiki/Camp_xml

N'hésitez pas à l'essayer et à nous donner votre avis

[Klaim]

Je prends note pour l'utililser dés que je reviens sur mon projet perso. Justement je dois faire de la serialization xml du modele que j'ai quasimment fini de mettre en place coté c++. Je vais tester avec QtXML

J'imagine qu'il faudra quand même passer par Qt pour la vérification via xsd?

[Laurent Gomila]

J'imagine qu'il faudra quand même passer par Qt pour la vérification via xsd?

Oui. camp-xml est un module très simple de sérialisation, XSD c'est complètement hors contexte ici.

Ceci-dit si tu veux t'amuser je pense que tu peux créer un module qui crée un fichier XSD à partir d'une meta-classe

[Klaim]

Peut être si je trouve le temps mais j'en doute ^^;

[epsilon68]

je suis bien tenté par un serializer en Json... :-)

par contre je n'ai pas vu, est-elle multi-plateforme?

[Laurent Gomila]

Bien entendu, ça n'utilise que du code C++ classique.

[JulienDuSud]

Sympa ce nouveau module xml !

Par contre, une question:

The most important limitation is about object properties. When such a property is processed, camp-xml assumes that the underlying object already exists and simply fills it. It won't be able to create it dynamically.

Je ne comprends pas trop ce que ça veut dire .

Est-ce l'objet qui doit être instancié avant la déserialisation ou bien est-ce la propriété ?
Et les pointeurs dans tout ça ?
Est-il possible de spécifier la manière dont certaines propriétés sont sérialisées ? (à l'instar de boost.serialization)

Ne serait-il pas possible de définir une interface sur laquelle viendra se coller plusieurs types d'objets qu'instancierait Camp ?

Exemple:

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
37
38
39
40
41
42
43
44
45
46
 
struct PersonInterface {
	virtual void doStuff() = 0;
	virtual void doOtherStuff() = 0;
};
 
struct Women : PersonInterface {
	/* propriétés propres à la femme */
 
	void doStuff() {}
	void doOtherStuff() {}
};
 
struct Man : PersonInterface {
	/* propriétés propres à l'homme */
 
	void doStuff() {}
	void doOtherStuff() {}
};
 
void registerPersonInterface {
	camp::Interface::declare< PersonInterface >()
	  .function(doStuff)
	  .function(doOtherStuff);
}
 
void registerWomen() {
	camp::Class::declare< Women >("Women")
	  .implements( PersonInterface )
	  .property("na", &Women::na);
}
 
void registerMan() {
	// ...
}
 
CAMP_AUTO_TYPE( PersonInterface, &registerPersonInterface );
CAMP_AUTO_TYPE( Women, &registerWomen );
CAMP_AUTO_TYPE( Man, &registerMan );
 
int main()
{
	//ici, on peut déserialiser des femmes ou des hommes, par exemple.
	//l'instanciation du coup est déléguée à Camp :«
	PersonInterface& p = camp::xml::deserialize( root );
}

Ce genre de chose pourrait vraiment être superbe

Je ne connais pas du tout les limites du projet, je ne donne donc que des idées à peut-être (ou pas) développer. Mais j'imagine déjà la possibilité de pouvoir déserialiser des types à partir d'une interface abstraite directement sur un socket (par exemple): ça serait vraiment la panacée !

Mais je me demande si c'est pas un peu hors des objectifs de Camp au final...

[Laurent Gomila]

Je ne comprends pas trop ce que ça veut dire

Ca veut dire que si tu as une propriété qui est un pointeur sur un objet, CAMP ne va pas pouvoir l'instancier avant d'affecter ses propriétés. Il ne peut que faire l'hypothèse qu'il est déjà construit. Si ce n'est pas le cas, boum.

Ne serait-il pas possible de définir une interface sur laquelle viendra se coller plusieurs types d'objets qu'instancierait Camp ?

C'est faisable très facilement. Ca dévie un peu de ce que fait le module XML, mais il est tout à fait possible de proposer une variante qui sauvegarderait le nom de la classe pour pouvoir instancier et désérialiser l'objet convenablement. Dans ce cas, CAMP fait office de factory sans rien avoir à ajouter.

[JulienDuSud]

Ca veut dire que si tu as une propriété qui est un pointeur sur un objet, CAMP ne va pas pouvoir l'instancier avant d'affecter ses propriétés. Il ne peut que faire l'hypothèse qu'il est déjà construit. Si ce n'est pas le cas, boum.

Même si je ne suis pas un fervant accro aux pointeurs, je pense que c'est tout de même une sacré limitation.

Ne serait-il pas possible de déclarer qu'une propriété est un pointeur et de lier la propriété à une fonction pour que Camp appelle celui-ci pré-déserialisation ? Avec quelques automatismes du style utiliser l'allocateur standard, afin de ne pas avoir à écrire une fonction d'instanciation spécifique à chaque fois ? En somme, prévenir Camp que la propriété est un objet alloué dynamiquement ? (pour ce qui est des objets partagés, je comprend très bien que c'est au programmeur de le gérer, et le noxml conviendrait parfaitement)

C'est faisable très facilement. Ca dévie un peu de ce que fait le module XML, mais il est tout à fait possible de proposer une variante qui sauvegarderait le nom de la classe pour pouvoir instancier et désérialiser l'objet convenablement. Dans ce cas, CAMP fait office de factory sans rien avoir à ajouter.

C'est une excellente nouvelle ! J'espère que ça cette fonctionnalité verra un jour le jour, rien que pour moi, ça m'ouvrirai énormément de portes quand à l'utilisation de la lib .

[Laurent Gomila]

Ne serait-il pas possible de déclarer qu'une propriété est un pointeur et de lier la propriété à une fonction pour que Camp appelle celui-ci pré-déserialisation ? Avec quelques automatismes du style utiliser l'allocateur standard, afin de ne pas avoir à écrire une fonction d'instanciation spécifique à chaque fois ? En somme, prévenir Camp que la propriété est un objet alloué dynamiquement ?

J'en doute. Il faut garder à l'esprit que CAMP offre des fonctionnalités très très génériques, et qu'allouer automatiquement un pointeur pour désérialiser l'objet correspondant est une chose très très spécifique. J'ai du mal à voir comment cette fonctionnalité s'inscrirait dans CAMP en dehors de ce contexte très spécifique.
En plus ce n'est pas une limitation, il est toujours possible de gérer ça avec du code un peu personnalisé par rapport au module camp-xml.

J'espère que ça cette fonctionnalité verra un jour le jour, rien que pour moi, ça m'ouvrirai énormément de portes quand à l'utilisation de la lib

Ce n'est pas une fonctionnalité qui doit voir le jour, tu peux déjà le faire.

[JulienDuSud]

Ce n'est pas une fonctionnalité qui doit voir le jour, tu peux déjà le faire.

oh !

Bon ben me reste plus qu'à me plonger dans la doc.

[epsilon68]

sur la mailing list de boost, 2 lib d'introspection sont dans la sandbox

intro
et mirror

pourquoi tu ne presenterais pas aussi ta lib?

[Laurent Gomila]

Je pense tout simplement qu'elle n'est pas prête pour ça, mais j'y penserai dans quelques mois/années

Je connaissais mirror, qui a une approche assez différente de CAMP, mais pas intro. Je vais jeter un coup d'oeil à ça

J'avais aussi entendu parler d'un projet boost pour abstraire boost.python et en faire un moteur de binding script générique, mais apparemment le projet a été abandonné faute de temps. Me rappelle plus le nom.

EDIT : j'ai retrouvé, c'est boost.langbinding