Problème héritage et construction de classe

Bonjour,

je suis en train de développer une classe c++ qui hérite d'une autre classe à laquelle je n'ai pas accès et à l'appel d'une méthode de la classe mère pour initialiser un attribut, ça plante: std::bad_alloc.

Code:

---

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

#ifndef VEHICLE_CPP #define VEHICLE_CPP   #include "Vehicle.h"   Vehicle::Vehicle() : PEADOS::Vehicle() { }   Vehicle::~Vehicle(void) { }   string Vehicle::getIdent(void) { return ident; }   void Vehicle::setVehicle(Interface::Vehicle* vehicle) { ident = vehicle->ident(); groupIdent = vehicle->groupIdent(); string m_type = vehicle->type(); setType(m_type); setFuel(vehicle->fuel()); setPosition(vehicle->positionV()->x(), vehicle->positionV()->y(), (double)0); return; }   #endif

---

J'appelle la méthode comme suit:

Code:

---

1 2	Vehicle* newVehicle = new Vehicle(); newVehicle->setVehicle(vehic);

---

et ça plante au niveau du setType uniquement, les autres set de la classe mère fonctionnent bien.

Quelqu'un voit une erreur?

Merci d'avance pour vos réponses.

Evites de définir des méthodes qui seront définit automatiquement par le compilateur si elles ne font rien de spéacial (tu feras pas mieux que lui).

Quel est le type de m_type, la signature de setType et ce quel doit faire ?

PS: Tu es certain de pouvoir hériter de cette classe ? Le destructeur est bien virtuel ?

Bonsoir,

je ne comprends pas l'appel fait dans ton constructeur :

Code:

---

1 2 3 4

Vehicle::Vehicle() : PEADOS::Vehicle() { }

---

Ta classe Vehicle hérite d'une autre classe également nommée Vehicle?
Si c'est cela, je pense qu'il serait préférable de nommer autrement ta classe pour éviter toute ambiguïté.
Peut-être que ton problème vient de là?

Ca peut devenir problématique si des "using namespace" sont utilisés...
Si j'ai bien compris, tu as ta propre classe Vehicle, celle dans PEADOS et celle dans Interface?
Est-ce que par hasard, il n'y aurait pas un using namespace PEADOS ou using namespace Interface dans le fichier où se produit l'erreur?

@Flob90
m_type est un string et la signature de la fonction est void setType(string & name)
je ne vois rien qui fait que je ne pourrais pas hériter de cette classe et le destructeur est bien virtuel.

@Aleph69
On m'a conseillé d'écrire le constructeur de cette façon pour forcer à appeler celui de la classe mère en premier.
Oui c'est bien ça ma classe Vehicle hérite d'une autre classe appelée aussi Vehicle, mais j'ai essayé de la renommer pour tester, ça n'a rien changé!
En effet, j'ai également une classe Vehicle dans Interface, mais je n'ai pas mis de using namespace dans le fichier où se produit l'erreur.

j'ai une autre question?

pourquoi as tu cela?

Code:

---

1 2 3 4 5

#ifndef VEHICLE_CPP #define VEHICLE_CPP ... #endif

---

normalement cela n'est à faire que sur des .h pour éviter les doubles inclusions.

Citation:

---

Envoyé par jabbounet

j'ai une autre question?

pourquoi as tu cela?

Code:

---

1 2 3 4 5

#ifndef VEHICLE_CPP #define VEHICLE_CPP ... #endif

---

normalement cela n'est à faire que sur des .h pour éviter les doubles inclusions.

---

ah ok, je savais pas! merci

Bonjour,

que se passe-t-il si tu passes par le constructeur par copie de PEADOS::Vehicle?
En d'autres termes, essaye de remplacer

Code:

---

1 2 3

Vehicle* newVehicle = new Vehicle(); newVehicle->setVehicle(vehic);

---

par

Code:

---

1 2	Vehicle* newVehicle = new Vehicle(vehic);

---

Donne-nous également Vehicle.h et la manière dont est construit vehic dans ton prochain message s'il-te-plaît.
Il y a peut-être une donnée membre mal allouée.
Si la méthode setType est implémentée autrement que comme cela, ca serait bien de la donner également :

Code:

---

1 2 3 4 5

void Vehicle::setType(string const & name) { this->type = name; }

---

Si le destructeur n'était pas virtuel tu n'aurais pas dû hériter par exemple, mais comme ce n'est pas le cas ton héritage peut être bon. (si tu l'as jugé pertinant, on va dire qu'il l'est :) )

Enlèves ton constructeur et ton destructeur, il ne font rien, le compilateur les fera aussi bien que toi. Et la personne qui t'as conseillé cette écriture ne doit pas être au courant que le constructeur de la classe mère sera quand même appelé même si tu ne lui dis pas.

Pour setType je demandais ca que je ne vois pas d'initialisation de m_type, mais si il s'agit d'un string il est forcément initialisé par le constructeur et n'a pas de raison de produire une erreur.

Re,

j'ai une dernière question.
Pourquoi fais-tu

Code:

---

1 2 3 4

string m_type = vehicle->type(); setType(m_type); setFuel(vehicle->fuel());

---

et pas

Code:

---

1 2 3

setType(vehicle->type()); setFuel(vehicle->fuel());

---

Le constructeur de la classe mère (PEADOS::Vehicle) ne prend pas le type de Interface::Vehicle en paramètre

Voici mon .h

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

#ifndef VEHICLE_H #define VEHICLE_H   #include "InterfaceC.h"   #include "peados.h" #include "exports.h"   class Vehicle : public PEADOS::Vehicle { private: string ident; string groupIdent;   public: Vehicle(); ~Vehicle(void); string getIdent(void); void setVehicle(Interface::Vehicle* vehicle); };   #endif

---

Je récupère l'objet vehic d'une liste présente sur le serveur (c'est une application client/serveur CORBA). La valeur de chaque attribut est passée par une boite à bouton côté serveur.

Pour le setType je n'y ai pas accès, mais a priori il ne fait rien d'autre.

J'ai remplacé par setType((string)vehicle->type()); c'était un oubli de modification!

Re,

Citation:

---

J'ai remplacé par setType((string)vehicle->type()); c'était un oubli de modification!

---

Il est possible que le problème vienne de là.
Pourquoi dois-tu transtyper?
Quel type d'objet retourne la méthode type()?

La méthode type() renvoie un char*, ce qui provoque une erreur à la compilation

Re,

je suis à court d'idée! :f1:

Je me demande si ton erreur est vraiment située au niveau du setType ou si tu as un problème mémoire en amont...

Essaye de commenter la modif du type pour voir si le bad_alloc est toujours lancé.

Quand je commente le setType tout se passe bien, le bad_alloc n'est pas lancé.
D'autre part, je viens de tester la classe mère sans passer par l'héritage et dans ce cas le setType fonctionne comme il faut...

Bonsoir,

si c'est la méthode setType qui lance bad_alloc, elle doit faire autre chose que ce que l'on pense... puisqu'elle tente d'allouer quelque chose!

Étant donné que je n'ai pas accès au contenu de la classe dont je veux hériter, je vais devoir faire autrement!
Merci de votre aide en tout cas!

Bonjour,

j'étais un peu fatigué hier soir! ;)

En fait, je pense que ton problème est facilement contournable en faisant un constructeur du genre :

Code:

---

1 2 3 4

Vehicle::Vehicle(PEADOS::Vehicle const& vehic) :PEADOS::Vehicle(vehic) {}

---

Ca va te permettre de construire tes véhicules sans même savoir ce qui se passe dans le namespace PEADOS puisque tu passes explicitement par le constructeur par copie de la classe PEADOS::Vehicle.
Ensuite, ton exemple devient

Code:

---

1 2	Vehicle* newVehicle = new Vehicle(vehic);

---

Tu peux bien sûr ajouter des paramètres au constructeur pour initialiser des attributs privés.

Aleph, n'as tu pas confondu la classe

Code:

---

PEADOS::Vehicle

---

et la classe

Code:

---

Interface::Vehicle

---

?

Parce que je ne comprends pas bien comment tu veux faire pour utiliser le constructeur par copie de la classe

Code:

---

PEADOS::Vehicle

---

alors que c'est à partir d'un objet de type

Code:

---

Interface::Vehicle

---

que BadThing veut remplir les attributs.

Effectivement, alors il faut que Vehicle hérite de Interface::Vehicle de manière privée et faire appel au constructeur par copie de Interface::Vehicle.