Discussion :

[buzzkaido]

Bonjour,

Je cherche, dans une fonction, à modifier la valeur d'un pointeur qui est passé en paramètre.

Je veux bien modifier la valeur du pointeur (l'adresse sur laquelle il pointe) et non pas les données pointées (sinon, c'est facile...)

J'ai donc essayé :

Code :

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

bool createObject(CoreObject*& pObject)

Mais le compilo n'a pas l'air d'aimer ça... (je n'ai plus les messages d'erreur sous la main)

Existe-t-il une solution autre que :

Code :

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

bool createObject(CoreObject** pObject)

Merci !

[Dreambeliever]

Salut,

il n'y a pas de problèmes.

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
#include <iostream>
#include <vector>
#include <cmath>
 
using namespace std;
 
int a (int *&b)
{
    b=NULL;
}
 
int main(){
    int d;
    int *c = &d;
    a(c);
    cout << c << endl;
    return 0;
}

[buzzkaido]

Ah ! Oui !

Je m'a trompé dans la description...

J'ai cette fonction :

Code :

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

bool createObject(CoreObject*& pObject)

Et par exemple, la classe CoreNode derive de CoreObject. Le code suivant ne passe pas (probleme de conversion)

Code :

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

1
2
CoreNode* pNode = NULL;
createObject(pNode)

Pour cause de problemes de types.... pourtant la conversion est valide, non ?

Pour info, derriere cette fonction, il y a un mecanisme qui me garantit que l'on ne fera pas pointer un CoreNode* vers un CoreObject, mais seulement vers un CoreNode.

[Dreambeliever]

Il vaudrait mieux utiliser des templates si tu veux qu'une fonction ait un comportement différent selon le type de l'argument utilisé.

Ou alors faire deux fonctions, une qui prend un CoreObject*, une autre qui prend un CoreNode*.

Sans plus de détails sur les fonctions, il est difficile de voir ce qui cloche ou si on peut faire un cast assez barbare.

[JulienDuSud]

Comme le décrit Dreambeliever, on n'initialise pas un objet par son ancêtre. On l'initialiser au bon type, et ensuite on l'upcast.

[buzzkaido]

Effectivement, je viens de comprendre mon erreur...

Du coup, en faisant ça :

Code :

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

template <class T> bool createObject(T*& pObject)

Effectivement, ça marche...

Comme le décrit Dreambeliever, on n'initialise pas un objet par son ancêtre. On l'initialiser au bon type, et ensuite on l'upcast.

Tout à fait d'accord... mais c'est un cas un peu particulier : des objets (dont on ne connait pas le type à l'avance) sont chargés depuis du XML à l'aide de plugins...

En gros, dans le code, on ne connait pas le type de ce qu'on manipule... et cette fonction permet d'essayer de creer un objet d'un type donné depuis un fichier XML :

=> si tout se passe bien (XML valide, plugin trouvé, chargé...) on recupere un pointeur valide
=> en cas de soucis, on recupere un pointeur NULL

En gros cette fonction s'occupe de tout : chargement, decodage, lancement du plugin et "cast" de l'objet en l'interface voulue (si possible)

Et tout ça bien sûr, "extensible" : sans modifier le soft "central" on peut ajouter de nouveaux plugins capables de gerer de nouveau types d'objets : les charger, les créer, les ajouter dans le graphe de noeuds, faire des traitements dessus... sans qu'on ne connaisse quoique ce soit sur l'objet à l'avance (à par son type de base : CoreObject)

[cynique]

Code :

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

bool createObject(CoreObject*& pObject)

Code :

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

1
2
CoreNode* pNode = NULL;
createObject(pNode)

Pour cause de problemes de types.... pourtant la conversion est valide, non ?

Non. Regarde ces declarations:

Code :

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

1
2
3
4
 
  void createObject1( CoreObject *pObject );
 
  void createObject2( CoreObject *&rpObject );

Dans le premier cas, pObject est un pointeur. Il cible un CoreObject ou un objet d'une classe dérivée de CoreObject.

Dans le deuxième cas, rpObject est une réference. Elle ne cible que "un pointeur sur un CoreObject".

Un pointeur sur un CoreNode n'est pas un pointer sur un CoreObject, et la réference rpObject ne peut pas cibler un CoreNode *.

[buzzkaido]

Exact, mais je pensais que le compilo était capable de déduire la conversion, vu que les types concernés héritent l'un de l'autre.

Merci !

[Médinoc]

Le problème, c'est que ça permettrait de faire ceci sans warning:

Code C++ :

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

1
2
3
4
5
6
7
8
9
10
11
bool createObject(Base *&rpObj)
{
	rpObj = new DerivA;
	return true;
}
 
int main(void)
{
	DerivB *pObj;
	createObject(pObj);
}

C'est pourquoi, même si X* est implicitement convertible en Y*, X*& n'est pas implicitement convertible en Y*&.
Il en est de même pour X** et Y**, d'ailleurs.

[3DArchi]

Bonjour,
Peut-être peux-tu mettre en oeuvre le pattern factory et utiliser le retour-co-variant.

[buzzkaido]

En fait, ma solution est inspirée de ce pattern. Mais :

pas de retours co-variants car :
- utile que si le compilo connait le type exact que l'on manipule à la compilation (sinon il ne peut contrôler les contraintes de co-variance)
- justement, je ne connais presque rien à la compilation

type de retour template (pour les opérations de création) permettant de "demander" de créer un objet de tel type depuis un jeu de données (XML ou autre) :
- l'objet construit est du type "concret" de l'objet stocké dans le XML (le "vrai" type écrit dans le XML)
- si l'objet peut être retourné (casté en T*) il est retourné
- sinon il est détruit, et NULL est retourné

Ainsi :

- on peut demander la création d'un objet "Base*" a partir de données dans XML du type "Fils*" : un nouveau objet Fils sera créé puis retourné sous la forme d'un "Base*"

- dans le code de l'appli, je ne manipule que des types que je connais (en général, la classe mère), si des plugins sont chargés avec des objets de type nouveaux (non connus de moi) le code fonctionne quand même

- dans le code des factory qui sont incluses dans les plugins, le système de template permet de n'avoir a implémenter que des fonctions du style :

(exemple pour la factory associée à un CoreNodeGroup, qui derive de CoerNode, qui derive de CoreObject)

Code :

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

Menu* createMenu(CoreNodeGroup* pGroup)

Avec bien comme parametre "CoreNodeGroup* pGroup" et non pas "CoreObject* pObject".

Ce qui simplifie grandement le travail des développeurs qui implémentent les plugins : plus besoins de se soucier du type, de down-caster ou quoique ce soit, toutes les signatures de méthodes sont adaptées.