2010-10-03 4 views
0

Mon code compile et s'exécute, mais on m'a dit que c'est assez problématique. Je ne comprends pas où je vais mal.Code problématique ??? Y a-t-il un problème avec mon destructeur?

Aussi, n'est-ce pas supposé avoir tort de déclarer "char _arrName [2];" et pour faire l'assignation "_arrName [2] = '\ 0';" ? N'est-ce pas un bug "hors limites"?

#include <iostream> 
using namespace std; 
class Base { 
protected: 
char* _name; 
public: 
virtual ~Base() { cout << "Base dtor of " << _name << endl; }; 
}; 
class D1: public Base { 
char _arrName[2]; 
public: 
D1() { 
_name= _arrName; 
_arrName[0]= 'D'; 
_arrName[1]= '1'; 
_arrName[2]= '\0'; 
} 
virtual ~D1() { cout << "D1 dtor" << endl; } 
}; 
int main() { 
Base* arr[2]; 
arr[0]= new D1(); 
delete arr[0]; 
} 
+3

Votre mise en forme est assez problématique. Est-ce vraiment la façon dont vous codez ou avez-vous juste une erreur copier + coller? –

+2

Pourquoi 'char * _name;' et 'char _arrName [2]'? Qu'est-ce qui ne va pas avec 'std :: string'? –

Répondre

-3

Il n'y a rien de mal avec votre code. C'est peut-être parce que vous n'avez pas indenté votre code, ce qui le rend 100 fois plus difficile à lire. Cependant, quelques suggestions je suggérerais que vous utilisiez std :: string au lieu de chaînes de style C simples. Cela rend votre travail beaucoup plus facile.

+5

Vraiment, rien? –

6

Oui, il y a une erreur définie sur cette ligne.

_arrName[2]= '\0'; 

_arrName est un tableau de deux char de sorte que vous ne pouvez utiliser les deux valeurs _arrName[0] et _arrName[1]. _arrName[2] est hors limites.

Il existe également un problème avec cette ligne.

virtual ~Base() { cout << "Base dtor of " << _name << endl; }; 

Parce que la classe dérivée a souligné _name pour pointer sur un membre du groupe de la classe dérivée, par le temps ~Base() est appelé ce tableau aura été détruit et _name ne sera plus en montrant un tableau valide.

Il existe un potentiel d'erreur dans la classe de base. _name n'est jamais initialisé donc il dépend des classes dérivées l'initialisant. Ceci est moins que la conception idéale, bien que dans la pratique il peut ou ne peut pas causer un vrai problème.

+0

merci beaucoup. Je ne comprends toujours pas pourquoi cette ligne: _arrName [2] = '\ 0'; compile et exécute sans messages d'erreur ou quelque chose comme ça .. – darven

+5

@Mattityahu Shmuel: Juste parce que quelque chose compile et s'exécute ne signifie pas nécessairement que le code est correct. De nombreuses formes de code incorrect (y compris les deux) provoquent _undefined behavior_. Cela signifie que le compilateur n'a pas à diagnostiquer l'erreur, mais il n'y a pas de contraintes sur ce que le programme pourrait faire. Littéralement, tout peut arriver. Si vous avez de la chance, le code peut tomber en panne et vous avertir de l'existence d'une erreur. –

Questions connexes