Discussion :

[camboui]

[vikki]

Hello,
Je commence à utiliser CAMP régulièrement pour la génération automatique d'éléments graphiques et je dis un grand bravo, la lib est bien complète et vraiment facile à utiliser .

J'utilise également boost.python et je me demandais quelle forme prendrait le module d'interfaçage avec python? S'agit-il d'encapsuler des appels à boost.python depuis CAMP? Ou comptes tu refaire l'encapsulation de l'API CPython (en gros quel niveau de compatibilité entre les deux libs)?

[Laurent Gomila]

Je commence à utiliser CAMP régulièrement pour la génération automatique d'éléments graphiques et je dis un grand bravo, la lib est bien complète et vraiment facile à utiliser

Merci

J'utilise également boost.python et je me demandais quelle forme prendrait le module d'interfaçage avec python? S'agit-il d'encapsuler des appels à boost.python depuis CAMP? Ou comptes tu refaire l'encapsulation de l'API CPython (en gros quel niveau de compatibilité entre les deux libs)?

boost.python, en gros c'est CAMP + son module Python réunis en un seul bloc. Il n'y a donc aucun intérêt à utiliser boost.python pour le module Python de CAMP, puisque toute la partie binding de classe et introspection existe déjà. On n'a réellement besoin que de l'API C de Python.

[vikki]

boost.python, en gros c'est CAMP + son module Python réunis en un seul bloc. Il n'y a donc aucun intérêt à utiliser boost.python pour le module Python de CAMP, puisque toute la partie binding de classe et introspection existe déjà. On n'a réellement besoin que de l'API C de Python.

Ok, donc a priori on pourra exposer nos classes avec une lib ou l'autre (dans CAMP une unique exposition pour python et les metaclass) et continuer à utiliser la partie manipulation d'objets python avec boost.python (ou autre). Ca à l'air nickel

[Laurent Gomila]

Ca a pris un peu plus de temps que prévu, mais nous avons enfin un site fonctionnel et complet pour le projet :

http://dev.tegesoft.com/projects/camp

Le site (basé sur redmine) est assez complet : il y a un wiki avec des tutoriels, une roadmap, un système de tickets pour rapporter des bugs/fonctionnalités, un dépôt contenant les fichiers de toutes les versions.

Nous en avons également profité pour publier officiellement la version 0.7.0 sous licence LGPL. Nous travaillons d'ores et déjà activement sur la prochaine release.

N'hésitez pas à venir vous enregistrer pour donner votre avis

Maintenant que tout est prêt pour la communauté, j'espère vraiment que cette bibliothèque pourra servir à pas mal de monde et évoluer.

[jblecanard]

Merci pour ton travail j'espère aussi que la librairie rencontrera un certain succès auprès de la communauté

[Goten]

Faut définitivement que je me penche dessus. (et sous le capot surtout).

[JulienDuSud]

Ca a l'air vraiment sympa et propre point de vue client, super travail déjà rien que de ce point de vue !

Je ne compte pas l'utiliser dans l'immédiat, mais je sais que j'en aurais très certainement l'utilité très très bientôt .

[poukill]

Perso dans notre projet, CAMP c'est que du bonheur ! Ca marche au poil !

[fridjaou]

Perso dans notre projet, CAMP c'est que du bonheur ! Ca marche au poil !

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 ?

[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 en cours de discussion avec Laurent. Je vais écrire quelque chose d'ici peu pour expliquer quels services CAMP nous a rendu dans notre projet et comment tout cela a t-il été mis en place. Je viendrai poster ici une fois que tout sera terminé !

[zeppelinux]

Bonjour,

CAMP me semble tres interessant.
Je pense qu'il permettrait notemment d'implementer un framework d'injection
de dependences.
Je verrais bien quelque chose dans ce gout la, en s'inspirant de Google Guice :

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
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
 
 
using namespace camp;
 
class Module {
  public:
    virtual ~Module ();
 
  protected:
    virtual void configure () = 0;
 
    virtual Module& bind (Class& c);
 
    virtual Module& to (Class& c);
 
    template <typename Scope> Module& as ();
};
 
 
class Injector {
  public:
    virtual ~Injector ();
 
    static Injector& create (const std::list<Module*>& modules);
 
    template <typename T> void destroy (T& c);
 
    template <typename T> T& instance (Class& c);
 
 
  protected:
    Injector ();
};
 
 
class A {
	public:
    A () {
      Class::declare<A>("A")
        .constructor();
    }
 
    virtual ~A () {}
};
 
class B : public A {
	public:
    B () {
      Class::declare<B>("B")
        .constructor();
    }
 
    virtual ~B () {}
};
 
class D {
	public:
    D () {
      Class::declare<D>("D")
        .constructor();
    }
 
    virtual ~D () {}
};
 
 
class E {
  public:
    E (A& a, D& d) :
      a (a),
      d (d) {
 
      Class::declare<E>("E")
        .constructor<A, D>();
    }
 
    virtual ~E ();
 
 
    A& a;
    D& d;
};
 
 
class MyModule1 : public Module {
  public:
    virtual ~MyModule1 () {}
 
  protected:
    virtual void configure () {
      // Simple binding
      bind(Class::classByType<A>()).to(Class::classByType<B>());
 
      // Singleton binding
      bind(Class::classByType<D>()).as<Singleton>();
    }
};
 
class MyModule2 : public Module {
  public:
    virtual ~MyModule2 () {}
 
  protected:
    virtual void configure () {
      // Direct implementation binding
      bind(Class::classByType<D>());
 
      bind(Class::classByType<E>());
    }
};
 
 
int main (int argc, char** argv) {
 
  using boost::assign::list_of;
 
  Injector& injector = Injector.create(list_of (new MyModule()) (new MyModule2()));
 
  // From MyModule1
  A& a1 = injector.instance(Class::classByType<A>());
  A& a2 = injector.instance(Class::classByType<A>());
 
  assert (&a1 != &a2);
 
  // From MyModule2
  D& d1 = injector.instance(Class::classByType<D>());
  D& d2 = injector.instance(Class::classByType<D>());
 
  assert (&d1 == &d2);
 
  E& e = injector.instance(Class::classByType<E>());
  assert (&e.a != &a1 && &e.a != &a2);
  assert (&e.d == &d1 && &e.d == &d2);
 
  injector.destroy(e); // delete on &e.a and &e
 
  // delete everything which is not destroyed yet
  delete &injector;
 
  return 0;
}

[Laurent Gomila]

Je pense qu'il permettrait notemment d'implementer un framework d'injection
de dependences.

Je pense qu'il y a pas mal de développeurs C++ qui ne sont pas encore familiers avec le concept d'injection de dépendances, à commencer par moi. J'ai un peu de mal à saisir ce que tu proposes, même avec l'exemple. Est-ce que tu pourrais expliquer ce que sont censées faire les fonctions dont tu n'as pas donné le code (bind, to, as, ...), et ce qu'accomplit concrètement leurs appels ?

[zeppelinux]

J'avais en tete ce que propose le framework de Google, Guice.

L'idee est de piloter toute l'instanciation des classes de ton projet et
leur cycle de vie par un framework.
Ca peut sembler un peu delirant au premier abord, mais a terme ca apporte
un grand confort dans le developpement.

Rapidement, l'idee est de pouvoir mapper des classes abstraites (ou interfaces en Java) a une implementation ou alors directement une implementation.
Ensuite lorsque tu ecris une classe qui va dependre (parametres dans le constructeur) de classes abstraites, le framework va etre capable bien evidement d'instancier ta classe mais aussi ses dependences (implementations des interfaces) en construisant un graphe de dependences et en faisant un tri topologique afin de recuperer l'ordre d'instanciation des classes.

Cela permet entre autre de s'affranchir de l'ecriture de Factories.

Ensuite, connaissant le graphe de dependences de tes classes, tu vas pouvoir aussi gerer leur cycle de vie et ainsi leur destruction.

Guice ajoute la notion de Scope permettant de definir la duree de vie des instances (exemple avec le Singleton) et la possibilite de definir ses propres Scopes.

Guice permet donc l'injection de dependences mais aussi des fonctionnalites plus avancees comme l'injection d'intercepteurs permettant de faire de la programmation orientee aspect.

Je t'invite a aller jetter un oeil au lien vers Guice au debut de mon message.
Alors evidemment le Java apporte un grand confort via les annotations pour ce genre de chose, mais je pense que moyennant les quelques lignes de description via CAMP, on peut tendre vers certaines des fonctionnalites interessantes de Guice.


Les methodes bind(), to(), as() viennent de Guice, tu pourras voir un exemple dans le Getting Started.
bind/to permet de faire un mapping entre une classe abstraite et son implementation afin que le framework soit informe de l'implementation a injecter lorsqu'il doit resoudre une dependence abstraite.

Un autre interet de l'injection de dependence est la facilite de faire evoluer du code.
Si tu rajoutes une dependence a ta classe (nouveau parametre dans le constructeur) et que celle-ci est geree par le framework d'injection de dependences (en ayant realise le binding), tu n'auras pas besoin de modifier tout le code d'instantiation (potentiellement en cascade si les dependences sont transmises de classes en classes) puisque c'est le framework lui meme qui prend en charge les instantiations.

[poukill]

Hum... Etant donné qu'en C++ il n'a y pas de garbage collector comme en java, ça veut dire que ton framework gère l'intégralité des objets créés, y compris la construction et destruction. Je suis pas sûr que ce soit hyper compatible avec la destruction déterministe des objets en C++, notamment avec l'approche RAII.

Celà dit, j'ai lu rapidement, il est tard là ! Je vais regarder un peu plus en détail dès que j'aurai plus de temps !

[zeppelinux]

Oui il faudrait faire un appel explicite a une methode pour la destruction d'une instance mais connaissant les dependences de cette instance, tu peux aussi les detruire si ton instance est la seule a dependre d'elles et qu'elles ne sont pas declarees comme etant des singletons.

[jblecanard]

L'idée d'utilisation de CAMP de zeppelinux me plaît beaucoup !

Et doter le framework d'un garbage collector maison est tout à fait faisable, éventullement via un mécanisme intrusif d'AddRef/Release.

[Goten]

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

[zeppelinux]

Goten, l'idee n'est evidement pas de faire de l'injection de dependence dans un contexte ou l'on a de fortes contraintes en matiere de determinisme temporel (par exemple).

Mais c'est tout a fait envisageable pour du code classique sachant que l'overhead dans l'utilisation d'un tel framework n'est pas enorme en matiere de temps du fait que le plus gros du boulot (construction du graphe) se passe a l'initialisation.

Apres l'idee de CAMP c'est aussi de combler les lacunes du C++ en matiere d'introspection, concept present dans beaucoup de langages et notemment le Java qui s'appuie tres fortement sur celui-ci.
Donc s'inspirer de technologies venant de d'autres mondes comme Java ne me semble pas forcemment deconnant a partir du moment ou c'est realisable.

[jblecanard]

Je pense que Goten réagissait surtout au propos par rapport au garbage collector ? C'est le truc qui fait tilter souvent et qui fait dire "bah va faire du java à la place".

Là on parle d'un garbage collector calibré spécifiquement pour ce framework. D'ailleurs, il n'y a qu'à lire ce qu'en dit ce cher Bjarne. Il n'y a pas de raison de se priver d'un garbage collector en C++ sous prétexte que java en a déjà un. Le fait est qu'on a le choix et qu'on peut le gérer soi même finement, PAS comme java.