Probleme de cast en constructeur copy.

**hickscorp** · 22/08/2006, 13h29

Bonjour à toutes et à tous!

Voilà, j'ai un souci avec un de mes dev.
Je résume rapidement en simplifiant un max.
J'ai une classe de base nomée IOBject. Cette classe ne fais pas grand chose, joue juste le rôle d'interface:
( Edité après que j'ai vu que les tabs ont complètement ravagé le code ^^, et ajout de GetContent pour que vous voyez la méthode.)

Code :

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

1
2
3
4
5
6
 
class IObject {
public:
	virtual char* ToString (void) const { return "IObject"; };
	virtual		~IObject () {};
};

Ensuite, j'ai une classe dérivée CHString qui hérite de IObject. voici les infos importantes pour la compréhension de mon problème:

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
 
// __ctors
CHString::CHString() : szContent(NULL) {
	SetContent("");
}
CHString::CHString(const char* szInit) : szContent(NULL) {
	if (szInit!=szContent)
		SetContent(szInit);
}
CHString::CHString(const IObject& cInit) : szContent(NULL) {
	if (&cInit!=this)
		SetContent(cInit.ToString());
}
 
// IObject virtual implementation
char* CHString::ToString(void) const {
	return GetContent();
}
 
// Getter on the String's content...
char* CHString::GetContent() const {
	return szContent;
}
// Set the String content...
void CHString::SetContent(const char* szNewContent) {
	ReallocContent(strlen(szNewContent));
	strcpy(szContent, szNewContent);
}
// Frees the memory used by the content.
void CHString::FreeContent() {
	if (szContent!=NULL)
		delete [] szContent;
}
// Changes the size of the allocated content.
void CHString::ReallocContent(size_t iNewLength) {
	try {
		FreeContent();
		szContent	= new char[iNewLength+1];
	} catch (...) {
		throw CMemoryErrorEx("Unable to allocate data for a CHString object.", __FILE__, __LINE__);
	}
}

NOTEZ BIEN que le type d'objet requis en 2e constructeur est "IObject"...

Ensuite, dans mon prog, disons que je fasse ceci:

Code :

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

1
2
3
4
 
CHString	sTestStr1("Test");		// Ca passe...
CHString	sTestStr2(sTestStr1);		// Crash!
CHString	sTestStr3	= sTestStr2;	// Crash!

Les crash sonts soit disant provoqués par "Exception: User breakpoint.", même quand il n'y a pas de breakpoints.
Notez, qu'après debug du truc, la première instanciation appelle le 2e constructeur. Les deux autres n'appellent AUCUN constructeur

J'ai tenté un changement qui résoud le problème, mais du coup mon programme ne pourra pas fonctionner pour ce que je veux en faire: j'ai changé le type d'objet requis en constructeur 2 pour un "CHString". Et là ça passe, les deux appels se fonts par ce constructeur...

Si quelqu'un a une idée, je suis prenneur ^^

Merci!
Pierrot.

**Médinoc** · 22/08/2006, 13h36

Regarde ton premier post et tu verras les ravages de l'indentation intermédiaire par des tabs. Les tabs, c'est uniquement en début de ligne.
Fais retourner un char const * à ToString() : Je suis surpris que ça compile pour l'instant...
Tu ne nous montre pas le code de GetContent()...
CHString hérite bien de IObject ?

**hickscorp** · 22/08/2006, 13h53

Merci pour ta réponse,

J'ai changé le premier post, désolé pour le formatage.
CHString hérite bien de IObject, peut être pas de la bonne façon?:

Code :

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

1
2
3
4
 
class CHString	: public IObject {
[...]
};

Concernant le char* const ToString() à la place du char* ToString() const, ça ne fonctionne pas... cv-qualifiers bien sûr:

Code :

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

1
2
 
Error: the object has cv-qualifiers that are not compatible with the member function

C'est voulu pour le char* ToString const ^^.

Note: J'ai essayé en mettant la variable szContent en public et en private, cela ne change rien...

Merci de votre aide!
Pierrot.

**Médinoc** · 22/08/2006, 13h58

Si tu exécutes entièrement en Debug ("Start debugging") et que tu remontes un petit peu la pile d'appel ("Call Stack"), tu pourras sans doute voir où ça plante précisément dans le constructeur...

Et si, tu peux mettre const partout, sauf si tu utilises le retour de ToString() avec une fonction qui exige une chaîne modifiable, sans qu'on sache pourquoi (mais ce serait une mauvaise raison car les chaînes que tu retournes sont non-modifiables de toute façon).
Edit: On s'est mal compris. En fait, je conseillais char const * ToString() const...

**hickscorp** · 22/08/2006, 14h06

Bon j'ai dû mal m'exprimer.

Ca ne plante pas au moment du constructeur, car (ne me dites pas c'est pas vrai, moi non plus j'y crois pas) AUCUN constructeur n'est appellé quand l'objet requis est de type IObject. Le bug apparrait à la fin de ma fonction principale, au moment où les destructeurs sont appellés. Le cas 1 fonctionne, et est détruit. Les deux autres non, le destructeur plante, et je n'arrive pas à localiser quoi que ce soit de pertinent en pile.

Concernant les consts, je vais tester en char const * ToString() const. Tu m'expliques la différence profonde?

Edit: Je viens de passer en "char* const CHString::ToString(void) const". Ca compile, le bug est toujours là. Selon toi il faudrait que je change partout? oO

Merci beaucoup!
Pierrot.

**Médinoc** · 22/08/2006, 14h12

La différence profonde, c'est que là, on ne pourra VRAIMENT pas tenter de modifier la chaîne retournée (parce que si on tente d'écrire à l'adresse retournée par IObject::ToString(), on aura une belle Access Violation sous Windows, un belle segfault sous Linux.
(Un de mes plus grands reproches à Visual C++ est qu'il ne semble pas avoir d'option équivalente au paramètre -Wwrite-strings de GCC).

En fait, pour le coup du constructeur de copie, je crois que j'ai trouvé l'origine du bug: Ce constructeur n'est PAS un constructeur de copie! C'est un constructeur de conversion pour tout ce qui hérite de IObject.

Ainsi, lorsque le compilo tombe sur tes deux instanciations, il appelle le constructeur de copie par défaut au lieu d'appeler ton constructeur: La bête copie membre à membre.
Résultat, les destructeurs tentent de désallouer deux fois la même zone.

-->Donc, pour corriger, il faut que tu fasses ton constructeur de copie spécifique à CHString, qui fera la même chose que ton constructeur à partir de IObject.

**hickscorp** · 22/08/2006, 14h22

Tu veux dire qu'il faut dans CHString un constructeur qui requiert un IObject, un autre qui requiert un CHString?!

Mais là ça fout en l'air tout mon truc. Je m'ezplique ^^
Le but de la manoeuvre c'est d'avoir, grace à IObject, l'assurance que tous les objets en étant dérivés comportent la méthode ToString. De cette façon, peut importe l'objet qu'on passe à la classe CHString (ou CHInt ou CHWhateverUWant), le constructeur de CHString initialiserait son contenu grace à la méthode générique... Le but étant bien sûr que si je développe une classe CHFloat, je puisse la passer en param au constructeur de CHString SANS avoir à ajouter un constructeur dans CHString. Ca s'appelle pas le polymorphisme? Je sais plus ^^ Peut être le transtypage?

Le meilleur exemple pour ça est le tuto qu'avait fait Laurent Gomila, on a une classe ILogger avec deux trois méthodes virtual, ensuite on en dérive par exemple une classe CLoggerFile et on peut ensuite s'ammuser à faire ILogger::SetInstance(new CLoggerFile("Debug.txt"));. Et du coup pour loguer on a plus qu'à faire: ILogger::Log("Ce qu'on veut"). La classe ILogger prend en paramètre une instance de ILogger! Et vu que ses méthodes sont virtual pour la plupart, elles appellent bien dans CLoggerFile qui les implémente.

Vouala ce que je cherche à faire ^^ C'est juste que je ne comprend pas pourquoi ça ne fonctionne pas, ça devrait pourtant

Merci!
Pierrot.

**Médinoc** · 22/08/2006, 14h38

Le constructeur de copie est un cas particulier. Il te faut donc un constructeur pour n'importe quel IObject, et un constructeur de copie (que tu peux rendre private si tu veux interdire la copie de CHString).

**hickscorp** · 22/08/2006, 14h55

Donc, à quoi ressemblerait le constructeur pour "n'importe quel IObject"? Je pensais que c'est ce que j'avais fait...

**Médinoc** · 22/08/2006, 15h02

Oui, c'est bien celui-ci.

Mais tu dois ajouter un vrai constructeur de copie qui fera la même chose.

**Luc Hermitte** · 22/08/2006, 23h45

Envoyé par hickscorp

CHString hérite bien de IObject, peut être pas de la bonne façon?:

Si c'est ça la question, c'est un très mauvais choix de design. On le rencontre généralement dans les langages où l'abscence de généricité afaiblit le typage. Perso, entre un type Object duquel tout le monde dérive et un void*, je ne vois aucune différence.

Dans les effets de bords, autre que la perte d'un typage fort, bonne chance pour implémenter une sémantique de valeur (et en particulier de copie! (ou comment revenir au thème initial)) sur ta classe de chaînes. C'est pas que cela soit impossible ... c'est juste que tu auras de la gymnastique inutilement compliquée qui ne te rendra même pas un typage fort.

Au fait. Pourquoi réinventer la roue ?

**Médinoc** · 23/08/2006, 08h59

C'est vrai que le coup du IObject, là, il faudrait plutôt lui donner un nom du genre IConvertibleToString...

**hickscorp** · 23/08/2006, 13h44

Bon merci pour ces réponses, effectivement le ICharArrayExportable est une bien meilleure idée que le IObject... Seulement voilà, le IObject ne contient pas que ça ^^

Ya pas mal d'autres méthodes que je ne m'amuserais pas à poster ici, mais histoire de se faire une idée et entre autres, une persistence BDD... Un objet peut avoir plusieurs états: Abstract, Up-To-Date, Deleted, Modified. Ensuite des méthodes statiques s'occupent de le maintenir en base...

Bref, je vais revoir mon design, je pense avoir trop essayé de m'approcher de java sur ce coup ^^

En tout cas, merci pour vos réponses, problème résolu.
Pierrot.

**Médinoc** · 23/08/2006, 14h06

Mon conseil: Tu multiplies les interfaces, et tu peux même faire de l'héritage d'interfaces, jusqu'à trouver l'ensemble qui te convient.
Et ensuite, tu pourras te préoccuper des objets eux-mêmes.

De plus, je te conseille de ne proposer en plus des classes abstraites mères, des classes d'objets à inclure directement pour implémenter certaines interfaces (cela t'évitera d'avoir à faire de l'héritage multiple de classes contenant des données, ce qui sera plus proche de Java et de .Net.)

Probleme de cast en constructeur copy.

C++

Discussions similaires

Partager

Partager