Quelles approches pouvez-vous utiliser lorsque:
7 Réponses :
Vous pouvez utiliser des fonctions virtuelles pures (= 0;) pour les classes héritées, ou plus communément, les déclarer mais ne les définissez pas. Vous ne pouvez pas appeler une fonction sans définition.
Les fonctions virtuelles pures auront besoin d'une implémentation dans l'une des classes dérivées.
Le but n'est pas de le faire. De cette façon, s'ils ont essayé d'appeler, ça échouera.
Le code ne compilera pas, rendant le reste de la classe (déjà mise en œuvre) inutile.
L'objectif est de s'assurer que les méthodes spécifiques ne peuvent pas être invoquées, et non de casser complètement les classes dérivées existantes (ou les consommateurs de la classe de base elle-même, qui deviendraient soudainement non instanciable). Et si une classe dérivée devait alors fournir une implémentation de stub uniquement pour incrévenir la construction, alors lorsque la classe de base fournit la mise en œuvre de la méthode réelle, la classe dérivée utiliserait toujours la mauvaise version. Super. L'utilisation de méthodes virtuelles pure est inutile. (Votre deuxième recommandation sur simplement ne pas mettre en œuvre les méthodes convient cependant.)
Je ne le vérifierais pas dans le référentiel.
Meilleure option, méthodes. Si le code n'est pas un code utilisable, ne le vérifiez pas jusqu'à ce qu'il soit dans un état utilisable. Aucun mal s'ils ne peuvent pas l'utiliser de toute façon. Ou branche-then-fusionne.
La réponse la plus simple est de leur dire. La communication est essentielle chaque fois que vous travaillez avec un groupe de personnes.
Une option plus robuste (et probablement la meilleure) consiste à créer votre propre branche pour développer la nouvelle fonctionnalité et ne le fusionner que lorsqu'il est complet.
Toutefois, si vous voulez vraiment que vos méthodes soient implémentées dans l'arborescence source principale, mais ne voulez pas les utiliser, schez-les avec une exception ou une affirmation.
+1. pour affirmer. C'est la réponse la plus directe pour faire exactement ce que la question demandait.
ASSTERT / EXCEPTION La manière est ladite communication mais avec des moyens du code au lieu de la communication verbale / chat. Et dans ce cas, il devrait être préféré sur verbal. Ou quoi d'autre? Chaque fois que l'on a fait un talon de fonction, il faut gêner ses collègues avec des réunions ou des appels téléphoniques, lorsque la plupart d'entre eux n'appelleraient jamais le talon?
quelque chose comme ça devrait bien fonctionner bien: affirmation (faux && "pas encore implémenté, ne pas aller à la recherche de bugs!")
@Assk, en effet, j'avais l'intention de "leur dire" d'être largement applicable à de nombreuses formes de communication (e-mail, commentaires, etc.). Personnellement, je préférerais savoir de ne pas utiliser une fonction parce que ce fait a été communiqué avec moi que d'essayer de l'utiliser uniquement pour le savoir à la compilation / à l'exécution dont je n'aurais pas dû être en premier lieu.
Vous devriez soit, tout simplement pas commettre le code, ni mieux encore, commettez-le à une succursale de développement, de sorte qu'elle soit au moins hors de votre machine en cas de défaillance catastrophique de votre boîte.
C'est ce que je fais au travail avec mon repo git. Je pousse mon travail à la fin de la journée à un repo à distance (pas la branche principale). Mon collègue est conscient que ces branches sont super duper instables et ne pas être touchées avec un pôle de dix pieds à moins qu'il aime vraiment avoir des branches cassées.
Git est super pratique pour cette situation, j'imagine, d'autres DVC avec une ramification bon marché. Faire cela dans SVN ou pire pourtant, CVS signifierait la douleur et la souffrance.
Faites-moi confiance, pas autant de souffrance que vous obtenez si vous n'avez pas de contrôle de version. Même les RCS sur NFS sont meilleurs que cela. (Juste. Vous pourriez aussi bien utiliser VSS dans cette affaire pour toute la convivialité de cela.)
J'aimais le concept de .NET d'un Il présente les avantages de:
notimplementaedException . Vous pouvez facilement définir votre propre, dérivé de std :: exception , remplacer ce que comme "non implémenté".
Assert est le meilleur moyen. Affirmer que cela ne résilier pas que le programme est encore meilleur, de sorte qu'un collègue puisse continuer à tester son code sans être bloqué par vos talons de fonction, et il reste parfaitement informé de ce qui n'est pas encore mis en œuvre.
Si votre IDE ne veut pas "T Prise en charge des asserts intelligents ou des points d'arrêt persistants ici est une implémentation simple (C ++): Avantages: Inconvénients: P.s. Crédits pour la mise en œuvre initiale debug_assert Allez à mon collègue E. g.
Ne serait-il pas préférable de remplacer __ émet __ (0x90cc) avec __ asm __ ("int $ 0x3;") ?
@TAURAN: ASM n'a pas été autorisé dans les modèles de classe (au moins dans mon IDE), il ne serait donc pas possible de l'utiliser partout.
Comment est compilateur?
déclarez-le. Ne l'a pas mis en œuvre fort>.
Lorsque le programmeur utilise pour appeler la partie non programmée de Code Linker se plaint, qui est le coup clair au programmeur. class myClass
{
int i;
public:
void print(); //NOt yet implemented
void display()
{
cout<<"I am implemented"<<endl;
}
};
int main()
{
myClass var;
var.display();
var.print(); // **This line gives the linking error and hints user at early stage.**
return 0;
}
Vous pouvez utiliser des avertissements de préprocesseur à l'intérieur des talons de méthode.
Vous devez créer une succursale pour votre code temporaire et la fusionner lorsque vous avez terminé de la mettre en œuvre.
@Markos: il ne convient pas au développement descendant