truc.h [Error C2086] 'wxTextCtrl *truc::Force_val' : redefinition

Bonjour,

je suis sur une reprise de code C++, pour créer une DLL.
L'EDI est wxdevC++ et la compilateur VC 2005.

je ne comprends pas d'ou vient cett erreur qui me parait insensée, et mes recherches ont été vaines jusqu'ici.

en clair : mon fichier wxform me génère du code, qui refuse de compiler pour les motifs suivants :

pour plusieurs éléments du form, j'ai une erreur liée à leur redéfinition, telle que celle-ci :

Citation:

---

[...]\truc.h [Error C2086] 'wxTextCtrl *truc::Force_val' : redefinition

---

En effet, quand je regarde truc.h, les attributs en question sont définis à la fois dans la partie private et dans la partie public.

Comme c'est du code généré automatiquement, je ne peux pas le modifier à la main, je me dis qu'il doit y avoir une raison à cette redéfiniton, et je voudrais savoir que faire pour que le compilateur accepte ces redéfinitions, qui amha ne le regardent pas ! 8O

Bref, auriez vous une idée, car je déséspère de trouver une solution seule !
merci!

Citation:

---

ces redéfinitions, qui amha ne le regardent pas !

---

Elle est pas male celle-là. Le compilateur doit vérifier si un code peux accéder un attribut en fonction du contexte et il ne devrait pas s'inquiété d'avoir un attribut à la fois private et public ? :aie::aie::aie:

Le problème est en amont, soit c'est un bug dans l'outil de génération, soit c'est une mauvaise utilisation de l'outil de génération, soit on lui à fait un petit bébé dans le dos en modifiant son code après lui.

En clair, votre .h est à corrigé, peu importe la méthode.

A moins, que vous n'ayez pas fait attention aux defines et, dans se cas, c'est vous qui avez peut-être loupé une constante de compilation.

Salut,
Effectivement, plusieurs variables membres avec le même nom dans une classe ne sont pas autorisées par le langage même si leur visibilité est différente. Comment désignerais-tu l'une plutôt que l'autre ?
Comme dit par bacelar, soit tu as une directive de compilation à positionner (les déclarations sont-elles encadrées de #ifdef) ou revoir ton outil de génération.

Hi, merci pour les réponses.

Vous avez raison, deux variables du mm nom, heureusement que ça alerte le compilo.

Bon, cela-dit ça m'étonne que wxdevcpp fasse une telle chose...

Dans l'état, je ne peux pas modifier le .h comme ça, car dès que je reconstruit le projet, il est regénéré dans sa forme initiale.

Je vais faire un tour sur le site de l'outil, et vous tiens au courant.
Si vous avez d'autres pistes, je les prend car je suis toujours bloqué avec cette bêtise :cry:

++

Bon ok, une partie du code du .h est modifiable.

Les variables ont été redéfinies à la main dans la zone public, afin d'y avoir accès depuis l'extérieur, ce qui est 'illégal' (je me demande comment cette chose a pu être compilée auparavant ducoup, mais peu importe).

Si mes souvenirs sont exacts, pour accéder à des membres private, il faut que je créée des fonctions d'accès ... Ces fonctions, seront private ou public ?

Piouff, il faut que je me replonge dans mes cours !

merci encore pour votre aide !

Citation:

---

Envoyé par stilgar_karas

Les variables ont été redéfinies à la main dans la zone public, afin d'y avoir accès depuis l'extérieur, ce qui est 'illégal' (je me demande comment cette chose a pu être compilée auparavant ducoup, mais peu importe).

---

En plus d'être illégal, ça relève du travail de sappe !

Citation:

---

Envoyé par stilgar_karas

Si mes souvenirs sont exacts, pour accéder à des membres private, il faut que je créée des fonctions d'accès ... Ces fonctions, seront private ou public ?

---

Là, il faut choisir : soit les variables sont privées et alors il n'est pas intéressant d'avoir des getters et des setters ; soit elles ont des getter et des setter ... alors autant les rendre complètement publique !
En général, quand on ajoute des getter et des setters sur les membres d'une classe, c'est que celle-ci a un problème de conception.

Citation:

---

Là, il faut choisir : soit les variables sont privées et alors il n'est pas intéressant d'avoir des getters et des setters ; soit elles ont des getter et des setter ... alors autant les rendre complètement publique !
En général, quand on ajoute des getter et des setters sur les membres d'une classe, c'est que celle-ci a un problème de conception.

---

Getter et setter, oui. C'est ce que j'ai fait en définitive : Puisque le générateur me colle les attributs en private, je n'ai pas vraiment d'autre choix.

Bon, le problème est résolu ainsi, mais je garde ta remarque à l'esprit pour la suite. Cela-dit, n'est ce pas le principe de l'encapsulation que de mettre un max d'attributs de classe en private, et d'y associer ces fonctions d'accès justement ?

J'ai retapé un peu mes cours de C++, et de mémoire, il me semblait que c'était justement une stratégie 'saine'.

Encore merci pour votre aide, j'en suis à un problème de linkage maintenant (donc c'est que ça avance ah !)

Citation:

---

Envoyé par stilgar_karas

Cela-dit, n'est ce pas le principe de l'encapsulation que de mettre un max d'attributs de classe en private, et d'y associer ces fonctions d'accès justement ?

---

Sauf que mettre des attributs en privée et rajouter des getters et setters, c'est tout simplement casser cette encapsulation. Parfois une seule amitié suffit pour supprimer ces accesseurs.