Discussion :

[Vonziz]

Bonjour,

Dans une méthode d'une classe A, j'ai le code suivant :

Code :

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

1
2
3
4
 
EXInstance AskInstanceValue(int i) {
return gcnew EXInstance(pFile->AskInstances()[i].Value());
}

Voici le constructeur de ma classe EXInstance :

Code :

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

1
2
3
4
5
 
EXInstance(EX_Instance* pI) 
{
pInstance=pI;
 }

La méthode

Code :

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

pFile->AskInstances()[i].Value()

retourne un const EX_Component *, je n'ai pas la main sur le code de cette DLL (code compilé en DLL).

Voici l'erreur retournée :

Erreur 3 error C2664: (..) : impossible de convertir le paramètre 1 de 'const EX_Component *' en 'EX_Component *'

Pouvez-vous m'éclairer s'il vous plaît, je ne suis pas un spécialiste en pointeur... ^^

Merci!

[Spout]

Le constructeur de EXInstance prend en paramètre un const EX_Instance*, autrement dit un pointeur constant sur un EX_Instance.
Constant signifie que l'objet ne pourra pas être modifié par la méthode appelante (ici, le constructeur de EXInstance). Hors, il semblerait que tu veuilles modifier cet objet. Ce dont tu n'as pas le droit; il faut que le constructeur de EXInstance prenne un pointeur constant en paramètre.

[SoniX]

Plus exactement, const EXInstance * est un pointeur sur des données constante (autrement dit, le pointeur est modifiable, il peut être incrémenté ou modifié pour pointer un autre objet), mais les données pointées ne sont pas modifiable.

Pour ton code, il faudrait :

Code :

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

1
2
3
4
5
6
7
8
9
10
 
class EXInstance
{
	const EX_Instance	*pInstance;
 
	EXInstance(const EX_Instance* pI) 
	{
		pInstance=pI;
 	}
};

:

Il faut aussi que EX_Instance et EX_Component soit liées par un héritage.

[Vonziz]

Ok donc si à un moment donné, on se retrouve avec un const dans une variable, on doit faire avec ce const dans toutes les manipulations ultérieure de la variable, c'est ca?

Pas moyen de remettre le const en variable?

Car cette variable const, je la récupère d'une DLL sur laquelle je n'ai pas la main d'où le problème pour la rendre variable!

[Vonziz]

Ok, ok, merci pour vos réponses très précieuses. J'essai tout ca demain.

A titre informatif, je fais ces développements dans le cadre d'un wrapper C++/CLI pour un dev C#. J'espère que ces contraintes de const ne poseront pas de problèmes.

[Spout]

Pas moyen de remettre le const en variable?

Si, je crois que c'est possible avec un const_cast. Mais je te déconseille TRÈS FORTEMENT de le faire. Car si la librairie renvoie un const, c'est qu'il y a une bonne raison (conceptuelle ou pratique)... A toi alors de revoir ta propre conception.

[Vonziz]

Oké c'est bon à savoir. Je verrais ca demain et je vous recontacte si j'ai des difficultés. Merci encore. +++

[SoniX]

Ok donc si à un moment donné, on se retrouve avec un const dans une variable, on doit faire avec ce const dans toutes les manipulations ultérieure de la variable, c'est ca?

Pas moyen de remettre le const en variable?

La 'constitude' se propage dans tous les appels, c'est une contrainte, mais qui existe pour une bonnes raisons, généralement pour garantir qu'un utilisateur ne fasse pas de bêtise avec les ressources qu'on lui confient.

Pour se débarrasser du 'const', deux solutions :

- La moche, en utilisant le const_cast<>, mais dans ce cas tu violes les contraintes imposés (généralement pour de bonne raison)

- L'autre, consistant à copier l'objet constant dans une nouvelle instance non constante (qui t'appartient et dont tu assures la gestion)

[Vonziz]

Dernière question de ce débat très intéressant : Ok pour respecter cette contrainte de const. Autant programmer proprement, je suis le premier à le dire...

Seulement, comment fait-on si on utilise des appels système qui réclament des données "non constées", il n'y a pas un problème de typage dans ce genre de cas?! Le compilateur nous jette ou pas?

[Spout]

Seulement, comment fait-on si on utilise des appels système qui réclament des données "non constées",

De quels appels tu parles?

il n'y a pas un problème de typage dans ce genre de cas?! Le compilateur nous jette ou pas?

Je pars toujours du principe que les gens qui font les APIs sont plus intelligents que moi, et que telle fonction a tel prototype et pas un autre pour une bonne raison .
Mais ça dépends de ces appels système dont tu parles...

[Vonziz]

Je prends un exemple infondé mais qui te situeras le fond de ma pensée.

Imagine que tu récupères un const char* de ton API faite par ton développeur super intelligent super puissant.

Imagine maintenant que tu appelles une routine de system32 du style fprintf(char*) (=> Appel inexistant en réel).

Si tu fais fprtinf de ton const char*, le compilateur va te jeter car il attend un char*?

J'espère avoir été clair... ^^

[Spout]

Oui il va te jeter, car tu n'as pas à modifier le texte renvoyé. Mais rien ne t'empêche de créer une copie à partir de celui-ci et d'en faire ce que tu veux après... (rajouter des caractères, en enlever, ..)
Pour les chaînes de caractères ce n'est pas tellement important. Ça devient beaucoup plus délicat quand il commence à s'agir d'objets plus complexes, comme des classes. Car dans ton cas par exemple, copier l'objet pour le modifier est clairement une entorse à la conception de la librairie. Il est possible que la librairie n'aie pas envisagé l'utilisation que tu en fais, mais je te conseille plutôt de t'adapter à elle que l'inverse. Car ça pourrait être la source de bugs plus vicieux dans ton code (utilisation non prévue de pointeurs, variables ou autres,...).

[3DArchi]

Normalement, l'API faite par ton développeur super intelligent super puissant te fourni des méthodes permettant de modifier l'objet à partir de l'instance const qu'il t'a retourné et/ou d'obtenir un objet non const.

[Vonziz]

Merci à tous, explications très claires et complètes.

[Médinoc]

Attends, tu programmes en C++ ou en C++/CLI ?
J'ai vu un gcnew dans le code de ton premier post...

[Vonziz]

C'est du C++/CLI.