Discussion :

[poukill]

Ok d'accord j'ai très bien compris...
D'un choc à l'autre, je ne peux pas conserver mes caméras (les paramètres dépendent aussi du choc... )
Donc pas de migration!

Je me pose deux questions:

1) En ce qui concerne Camera et CFP, vaut-il mieux que je stocke la référence à choc, ou alors le pointeur sur un choc?
Sachant qu'un choc peut avoir plusieurs caméras: est-il possible d'avoir plusieurs références sur le même objet?
Si oui -> je vais utiliser une référence
Sinon -> pointeur

2) Si pointeur il y a, l'utisation d'un pointeur intelligent est-elle possible ici?

Je crois que c'est une des dernières questions!

Merci encore à Luc et à Miles

[Matthieu Brucher]

1) oui, c'est possible, mais il faut que la référence soit connue au moment de l'appel, donc par exemple s'ils sont construits à l'initialisation de la classe, ça ne va pas aller -> pointeur.
2) pointeur intelligent oui, sachant que lorsque le dernier pointeur intelligent est détruit, la ressource partagée aussi. Ca veut dire aussi qu'il peut y avoir des cycles - genre choc qui référence des caméras qui référencent le choc -> weak_ptr pour casser la dépendance, mais attention, il faut qu'il y ait un shared_ptr quand même quelque part -

[poukill]

Miles, j'ai parcouru tes tutos boost, ainsi que les std::auto_ptr de la FAQ. Et je me suis posé brutalement une question:

Est-il possible de stocker dans choc un vector<CFP> ? Vu que j'ai besoin de plusieurs CFP? (CFP possèdent des méthodes virtuelles pures)
En effet, un simple pointeur ne suffit plus.

[Matthieu Brucher]

pas un vecteur<CFP>, un vecteur<CFP*> peut-être, d'om l'intérêt des pointeurs intelligents. Mais il paraît que dans Boost, il y a des bestiaux pour ça aussi, mais je n'ai eu le temps de faire un tuto sur tout pour l'instant

[poukill]

Question bête: Pourquoi un vector<CFP*> et pas un vector<CFP>?
Je ne peux pas tout stocker directement dans Choc? C'est pas une bonne idée?

[Matthieu Brucher]

un vecteur de CFP, c'est un vecteur d'objets CFP, et comme ce sont des objets qu'on ne peut pas instancier, ça plantera.

[poukill]

un vecteur de CFP, c'est un vecteur d'objets CFP, et comme ce sont des objets qu'on ne peut pas instancier, ça plantera.

+1
Bon. Il me reste encore des progrès à faire...
En tous cas, ta réponse est très claire. Merci!

[poukill]

Hum, une question dans le même genre:

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
Class Choc
{
private:
    vector<CFP*> cfp;
    int numero_camera;
    string nom_composant 
....
}

class CFP
{
private:
    Camera camera; // OU Camera & camera ?
....
}

Sachant que pour un CFP, je n'ai qu'une camera? Je penche pour la première solution.

Tu confirmes?

[Matthieu Brucher]

C'est une caméra par composant ou par expérience ?

[poukill]

Par composant

[Matthieu Brucher]

Et un composant a toujours une seule caméra associée ? A ce moment, une instance de Camera comme tu l'as fait convient.

[poukill]

Oui, en fait le double avantage que j'y voyais, c'est que :
1) C'est réellement ce qui se passe : une caméra par composant:
2) Lorqu'on détruit un CFP, il faut aussi détruire sa caméra associée.

Je pense que tout ça doit se dérouler correctement, non?

[Matthieu Brucher]

Oui, ça doit pouvoir marcher

[poukill]

Et pourquoi ne pas centraliser ces infos dans ton monde (le choc) ?

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
--------------------------------------------
// Camera .h
struct Choc; // déclaration en avant, nécessaire pour les dependances circulaires (FAQ)

struct Camera {
    Camera(Choc & c);
...
private:
    Choc      & getChoc()       {return m_choc; }
    Choc const& getChoc() const {return m_choc; }
    int getChocNum() const;

    Choc & m_choc; // référence => on ne change pas de contexte!
}

--------------------------------------------
// Choc.h
#include "Camera.h"
struct Choc {
    int         getNum() const;
    std::string getComposant() const;
....
private:
    int         m_numero;
    std::string m_composant;
    Camera      m_c1;
};

--------------------------------------------
// Camera.cpp
#include "Camera.h"
#include "Choc.h"

Camera::Camera(Choc & c) : m_choc(c) { ... }

int Camera::getChocNum() const {
    return getChoc().getNum();
}

--------------------------------------------
// Choc.cpp
#include "Camera.h"
#include "Choc.h"

Choc::Choc(....) : m_c1(*this) { ... }

Je me penche sur ce code de Luc Hermitte pour l'implémentation, bien que mon diagramme UML aie été modifié depuis.
Je ne comprend pas tout parfaitement , en particulier la ligne en rouge?

Le but est effectivement de récupérer l'instance de choc par référence, mais...

Merci d'avance...

[Matthieu Brucher]

On initialise la référence dans la liste d'initialisation - sinon ça ne marche plus -

[Eusebe]

C'est le constructeur de Camera qui initialise la référence sur le choc (m_choc).

Comme il s'agit d'une référence et non d'un pointeur, on ne peut pas la modifier après son initialisation.

Et cette initialisation se fait dès l'instanciation de l'objet, avant même d'entrer dans le bloc du constructeur. Pour initialiser une référence, il faut donc nécessairement utiliser les listes d'initialisation des constructeurs.

Voir la :
http://c.developpez.com/faq/cpp/?pag...EUR_liste_init

Est-ce que c'est bien ça qui te posait problème ?

[poukill]

Yes! Merci beaucoup... D'autant plus que j'avais déjà lu cette FAQ, mais avec le temps j'ai oublié...
Ca c'est fait!

J'ai une autre question, plus "subtile":
Admettons que j'ai plusieurs objets de type Camera.
Dans ma classe Camera, j'ai une autre classe Donnees:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
class Camera  {
public:
	Camera(std::string);
	~Camera();
	convertionDLTemperature();
	int getNumeroCamera();
	void setNumeroCamera(int numero_cam);
	void setCorrespondanceCameraNumero(std::string nom_cfp);
 
private:
	int numero_camera;
	Donnees donnees;
}

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
class Donnees
{
public:
	Donnees();
	~Donnees();
	CImg <unsigned short> getImageIR();
	CImgl <unsigned short> getFilmIR();
	CImg <unsigned short> getImageVisible();
	void setImageVisible(CImg <unsigned short>);
	void importImageIR(int);
	void importFilmIR();
 
private:
	CImgl <unsigned short> film_IR;
	CImg <unsigned short> image_IR;
	CImg <unsigned short> image_visible;
 
}

Donnees étant private dans Camera...

Etant donné que c'est le constructeur de Camera qui appelle le constructeur de Donnees (en lui donnant le nom donnees), comment faire?
1) Toutes les classes portent le même nom
2) Si je leur donne des noms différents, comment un autre programmeur qui ne connait pas ces noms va faire pour travailler avec ces données?

Faut-il encore que je concoive mon pb autrement?

[Matthieu Brucher]

Comprend pas ta question, désolé.

[poukill]

Ok je vais reformuler:

Si je crée plusieurs objets Camera (c'est le programme qui le fait), comment vais-je récupérer imageIR dans donnees?

Ca doit maintenant te paraitre bete, mais c'est pas clair dans ma tête!

[Matthieu Brucher]

Ah, je crois que je vois. Ton objet Camera lit en fait les Donnees utiles à l'expérience. En fait, je pense plutôt que ce qu'il faudrait faire, c'est une espèce de singleton Camera qui contient en fait une instance par Camera et qui est capable de lire des Donnees et de les renvoyer, et c'est ce qui est renvoyé que tu utilises pour contruire ton objet dans la liste d'initialisation, et tu as dans ton CFP une instance de Donnees et non plus de Camera. Tu vois ce que je veux dire ?