reference sur pointeur

Version imprimable

12/06/2009, 16h12
buzzkaido

reference sur pointeur

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:

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:

bool createObject(CoreObject** pObject)

Merci !

Salut,

il n'y a pas de problèmes.

Code:

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;
}

12/06/2009, 17h20
buzzkaido
Ah ! Oui !

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

J'ai cette fonction :

Code:

bool createObject(CoreObject*& pObject)

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

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.
12/06/2009, 18h25
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.
12/06/2009, 21h30
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.
13/06/2009, 10h55
buzzkaido

Effectivement, je viens de comprendre mon erreur...

Du coup, en faisant ça :

Code:

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

Effectivement, ça marche...

Citation:

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)
14/06/2009, 11h16
cynique
Citation:
Envoyé par buzzkaido

Code:

bool createObject(CoreObject*& pObject)

Code:

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

Pour cause de problemes de types.... pourtant la conversion est valide, non ?
Non. :P Regarde ces declarations:
Code:

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 *.
14/06/2009, 14h08
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 !
15/06/2009, 12h21
Médinoc
Le problème, c'est que ça permettrait de faire ceci sans warning:
Code:

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.
15/06/2009, 15h14
3DArchi

Bonjour,
Peut-être peux-tu mettre en oeuvre le pattern factory et utiliser le retour-co-variant.
15/06/2009, 15h51
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:

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.