Est-il possible d'empêcher la surcharge des fonctions définies par l'utilisateur en C++? Supposons que j'ai une fonction:Comment prévenir les surcharges?
void foo(int , int);
Puis-je empêcher foo d'être surchargé, et si oui, comment? Si je peux, cela peut-il être étendu pour empêcher l'annulation des méthodes par héritage?
Vous ne pouvez pas.
En un mot: non. Vous ne pouvez pas empêcher qu'une surcharge de foo soit définie avec une signature différente ailleurs et vous ne pouvez pas non plus empêcher les fonctions virtuelles d'être remplacées.
Dans le monde C++, vous devez accorder une certaine confiance aux personnes qui écrivent du code dans votre programme.
Cela peut être une question très bête ...... je suis encore en train d'apprendre le C++. Comment le concepteur de C++ a-t-il empêché certains opérateurs d'être surchargés? –
Eh bien, si vous inventez la langue, vous arrivez à faire les règles. C'est ce que vous vouliez dire? –
Je me demandais, comment ont-ils réalisé cela. –
Section 13.1.1 par 13.1.3 de la norme décrit les types de fonctions qui peuvent ne être surchargée:
déclarations de fonctions Certains ne peuvent pas être surchargées:
- déclarations de fonctions qui ne diffèrent que dans le type de retour ne peut pas être surchargé.
- Les déclarations de fonction de membre avec le même nom et les mêmes types de paramètres ne peuvent pas être surchargées si l'une d'entre elles est une déclaration de fonction de membre statique (9.4).
Note: comme indiqué dans 8.3.5, les déclarations de fonctions qui ont des déclarations de paramètres équivalents déclarent la même fonction et ne peuvent donc pas être surchargées:
- déclarations de paramètres qui ne diffèrent que par l'utilisation de typedef équivalent « types "sont équivalents. Un typedef n'est pas un type distinct, mais seulement un synonyme d'un autre type (7.1.3).
- Les déclarations de paramètres qui diffèrent uniquement par un pointeur * par rapport à un tableau [] sont équivalentes. C'est-à-dire que la déclaration de tableau est ajustée pour devenir une déclaration de pointeur (8.3.5). Seules les dimensions du second tableau et des suivantes sont significatives dans les types de paramètres (8.3.4).
- Les déclarations de paramètres qui diffèrent uniquement par celle-ci est un type de fonction et l'autre est un pointeur sur le même type de fonction sont équivalentes. C'est-à-dire que le type de fonction est ajusté pour devenir un pointeur sur le type de fonction (8.3.5).
- Les déclarations de paramètres qui ne diffèrent que par la présence ou l'absence de const et/ou de volatile sont équivalentes. Autrement dit, les spécificateurs de type const et volatile pour chaque type de paramètre sont ignorés lors de la détermination de la fonction déclarée, définie ou appelée.
- Deux déclarations de paramètres qui diffèrent uniquement par leurs arguments par défaut sont équivalentes.
Dans le cas contraire, la fonction peut être surchargé, et il n'y a aucun moyen d'empêcher cela.
La seule façon raisonnable serait de donner le lien fonction C:
extern "C" void foo(int , int);
Cela fonctionne car avec liaison C, les noms ne sont pas mutilée, de sorte que vous ne pouvez pas faire une surcharge (qui repose sur encoder les types d'arguments dans le nom du symbole).
Évidemment, cela ne s'étendra pas aux fonctions membres.
Cela n'empêche pas vraiment les autres d'écrire 'void foo (int) {}' juste à côté. –
Vous ne pouvez avoir qu'une fonction avec un nom donné qui a une liaison C, mais cela ne vous empêche pas d'avoir un 'foo' avec une signature différente qui a elle-même une liaison C++. –
Cela n'empêche pas la surcharge. Cela compile: 'extern 'C" void foo (int, int); void foo (double, int); int main() {} ' – greyfade
Faire une fonction statique dans une classe et dire aux gens de ne pas modifier cette classe?
Faire ce que UncleBens a dit, et inclure dans la classe une constante qui est une somme de contrôle cryptée du texte dans la classe, et une fonction pour le tester pour la validité. De cette façon, personne ne peut changer de classe. Juste une pensée (peut-être pas très bonne).
Comme je pense à ce sujet, c'est assez bête parce que la classe aurait besoin de son propre texte. Cependant, comme alternative, il pourrait lire son code binaire compilé, et avoir une somme de contrôle pour cela. Je sors d'ici.
Le code binaire de la classe (quel qu'il soit, comment démêler le désordre binaire laissé par un compilateur d'optimisation?) Devrait inclure cette constante. Parler de la récursivité. – sbi
@sbi: oui, mais c'est un truc standard dans le monde embarqué pour la somme de contrôle du binaire, ne serait-ce que pour détecter la corruption de la mémoire. –
Dites-nous, pourquoi voulez-vous empêcher les autres de le surcharger? –
Je sens une certaine confusion ici: la surcharge n'a rien à voir avec l'héritage et le dépassement, ce sont des bêtes totalement différentes. – sbk
Je ne vois pas d'idées confuses ici, donc je vais modifier pour plus de clarté. –