2009-11-25 5 views
5

Lors de l'examen de l'une de nos classes C++ par le biais de la couverture, il a affiché un message d'erreur sur une classe particulière. La classe est la suivante:Identificateur de classe utilisé dans la déclaration de classe. Est-ce une bonne pratique?

class InputRecord 
{ 
    /* Construtor */ 
    ... 
    InputRecord::RejectRecord(); 
    ... 
    /* Destructor */ 
} 

Quelle est la signification de l'utilisation d'un identifiant à l'intérieur de la classe? Est-ce une bonne pratique de suivre cela?

Merci, Mathew Liju

Répondre

5

Sur les compilateurs gcc (v4.1 et versions supérieures), la compilation avec "erreur: qualification supplémentaire" échouerait. C'est donc une bonne pratique de ne pas le mettre là! Voir qui décrit la qualification supplémentaire comme C++ non légale.

+0

pas seulement gcc, tout compilateur sauf visual studio. –

0

G'day,

J'ai toujours pensé ce genre d'identifiant a été utilisé dans la mise en œuvre et n'a pas été nécessaire dans la définition de classe.

Une déclaration de classe est

class InputRecord; 

Qu'est-ce que vous avez il y a une définition de classe.

class InputRecord 
{ 
    /* Construtor */ 
    ... 
    RejectRecord(); 
    ... 
    /* Destructor */ 
} 

puis dans votre fichier .cpp vous avez la mise en œuvre

InputRecord::RejectRecord() 
{ 
    ... 
} 
+0

Même si c'est ma compréhension. Avant de prendre une décision sur le changement de programme, je veux juste confirmer ma compréhension. En tout cas merci pour la réponse :-) –

0

En général, il n'y a pas de cas où l'homonymie fourni par le InputRecord:: explicite dans votre exemple de code sont susceptibles d'être quoi que ce soit autre que redondant. Si le code effectue des manipulations complexes pour lesquelles la classe spécifique est pertinente (disons que vous la transmettez à une classe de base qui possède une version masquée), cela peut aider à clarifier le code pour le rendre explicite. C'est un peu comme this-> (ou this. en C#/Java).

Personnellement, je supprimerais ces spécificateurs redondants et trouver une autre façon de faire passer le point.

+0

En fait, je pense que C++ et Java devraient forcer les gens à l'utiliser pour les variables membres, donc nous n'avons plus besoin de les nommer mValue, m_value, m_Value, value_ etc. –

+0

Nous devons les nommer 'm ...'? : P Du point de vue de la programmation fonctionnelle, vous aimeriez être amené à réfléchir avant d'utiliser l'état/D'un point de vue OO, il serait «normal». Pour certains types de choses, cela aurait l'air * vraiment * moche. Certaines «normes» de programmation ne disent pas de préfixe car il devrait être clair à partir du code si c'est un membre ou un param - ce qui est bien si vous écrivez un code approprié. (Personnellement, je n'utilise pas la notation hongroise, mais je m'y accroche au préfixe [avec '_'] sachant que c'est faux, je détesterais avoir à préfixer 'this.' partout). Je pense que c'est un cas clair d'absence de solution OSFA. –

0

Dans la définition de classe, j'utilise uniquement des identifiants de classe si j'ai des paramètres nommés de la même façon (ou identiques) pour les membres privés de la classe. Il évite l'ambiguïté et rend le code plus facile à lire en même temps. Je ne peux pas penser à un autre cas dans lequel vous auriez besoin de l'utiliser.

Questions connexes