L'injection de dépendance... ça serait pas utile pour des framework web façon CPPCMS?
Version imprimable
L'injection de dépendance... ça serait pas utile pour des framework web façon CPPCMS?
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 :calim2:.
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...
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 :).
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.
Salut,
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. :mouarf:
En fait, je me demande si je ne pense pas le contraire (mais c'est un autre débat).
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 :hola:
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 ! :ccool:
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 :ccool:
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?
Oui. camp-xml est un module très simple de sérialisation, XSD c'est complètement hors contexte ici.Citation:
J'imagine qu'il faudra quand même passer par Qt pour la vérification via xsd?
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 ;)
Peut être si je trouve le temps mais j'en doute ^^;
je suis bien tenté par un serializer en Json... :-)
par contre je n'ai pas vu, est-elle multi-plateforme?
Bien entendu, ça n'utilise que du code C++ classique.
Sympa ce nouveau module xml !
Par contre, une question:
Je ne comprends pas trop ce que ça veut dire :oops:.Citation:
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.
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:
Ce genre de chose pourrait vraiment être superbe :DCode:
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, ®isterPersonInterface ); CAMP_AUTO_TYPE( Women, ®isterWomen ); CAMP_AUTO_TYPE( Man, ®isterMan ); 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 ); }
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...
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.Citation:
Je ne comprends pas trop ce que ça veut dire
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.Citation:
Ne serait-il pas possible de définir une interface sur laquelle viendra se coller plusieurs types d'objets qu'instancierait Camp ?
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 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 :D.Citation:
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.
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.Citation:
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 ?
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.
Ce n'est pas une fonctionnalité qui doit voir le jour, tu peux déjà le faire.Citation:
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
Je pense tout simplement qu'elle n'est pas prête pour ça, mais j'y penserai dans quelques mois/années :P
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