8
votes

Pourquoi ne peut-il pas être surchargé par type de retour?

DUPLICATES possibles:

surcharge de fonction par type de retour?

Puzzle: surcharge une fonction C ++ en fonction de la valeur de retour
Parce que j'ai une bibliothèque qui expose un tas de fonctions sous la forme de: xxx
et maintenant je dois envelopper ces. Je préférerais ne pas réécrire le même ensemble de fonctions. Je voudrais faire quelque chose comme xxx
mais je ne peux pas sembler obtenir ce travail. Des idées?

c++ types return overloading

4 commentaires

Outre le lien ci-dessus, il y a aussi Stackoverflow.com/questions/226144/... et quelques autres

Vous dites que vous avez une bibliothèque qui surcharge déjà par type de retour? Cela semble improbable

@JAlf: Je suppose que les fonctions sont dans différents espaces de noms.

@Als: Peut-être. Ou peut-être qu'ils ont réellement des noms différents. Nous ne savons pas, mais la question, telle qu'elle se trouve, implique qu'il a une bibliothèque qui fait déjà ce qu'il dit qu'il ne peut pas faire (et qui est impossible), puis compte tenu de cette prémisse, il essaie de faire quelque chose de tout à fait Différent qui pourrait être atteint avec une spécialisation de modèle (mappage d'un getval () à différentes implémentations en fonction du type de t

5 Réponses : 0 votes Vous pouvez essayer modèle t getval (t) {...} à la place (à l'aide d'une variable factice pour effectuer une résolution) Utilisez les conversions de type ou simplement utiliser le getvalbool etc. 2 commentaires Il n'y a pas de différence entre modèle T getval () et template t getval () et la question indique que le premier ne fonctionne pas. Bien sûr, il serait bien de savoir pourquoi Nakiya croit que, mais sans demander que 1. n'est pas trop utile. @Ephement: Regardez à nouveau - il a passé un paramètre factice pour effectuer des travaux de surcharge. 0 votes Il n'y a qu'une seule fonction en C ++ pouvant être surchargée par type de retour, la fonction spéciale de l'opérateur de conversion implicite, nommée opérateur t () (avec t variable). < / p> 0 commentaires 20 votes Vous ne pouvez pas surcharger les types de retour, car il n'est pas obligatoire d'utiliser la valeur de retour des fonctions dans une expression d'appel de fonction. Par exemple, je peux simplement dire P> GetVal(); 7 commentaires Le compilateur pourrait simplement émettre un message "Type de retour ambigu" et refuser de compiler. Ce n'est pas assez de justification par lui-même. @Mark Ransom: prie de différer ici. Reportez-vous à 7,4,1 $ de "Le langage de programmation C ++ 3ème édition" de STROSTRUP Sinon: Supposons que nous définissions float getval () et double getval () et écrire int x = getval (); . Maintenant quoi? Soit un float ou un double peut être implicitement converti en int . @Karl Knechtel: Non. Le compilateur ne permettrait pas de définir de telles surcharges en premier lieu en donnant une erreur. Je pense qu'une chose est que la langue ne le permet tout simplement pas, l'autre chose est pourquoi pas. "Qu'est-ce que le compilateur fait maintenant?" - Cela pourrait émettre une erreur, ce qui serait une bonne chose, car il s'agit probablement d'une erreur logique de ne pas utiliser (ou d'ignorer explicitement) le résultat. Quant à Karl's "maintenant quoi?" - le même raisonnement pourrait également être appliqué à la surcharge sur les paramètres: vidien f (double); vide f (flotteur); f (10); "maintenant quoi?". Ce n'est pas un principe de surcharge qu'il doit être exempt d'ambiguïté. - En outre, si vous regardez la question liée, surcharge sur le type de retour peut être émulée en C ++. Je suppose qu'une forme plus générale de cet argument serait "si le résultat de l'appelant une fonction dépend de l'endroit où il est appelé?" Cela semble être un principe dangereux. Si j'appelle une fonction f (x) , le résultat doit être identique, peu importe qui je suis et où je l'ai appelé et ce que je prévois de faire avec le résultat. @jalf mais dans ce cas, INT F (X) et Double F (X) sont deux fonctions différentes. Dans tous les cas, même appeler INT F (x) deux fois n'est jamais garanti de renvoyer le même résultat en raison de la conservation de données en interne (via des variables statiques) ou de renvoyer différents résultats basés sur d'autres variables de classe ou des sources de données externes, il est accessible. Une garantie selon laquelle une fonction F (x) renvoie toujours le même résultat n'est possible que dans quelques langues spécialisées qui imposent beaucoup d'autres restrictions afin de rendre cette garantie, et C ++ n'est pas l'une d'entre elles. 2 votes Le type de retour des fonctions ne fait pas partie du nom mangelé généré par le compilateur pour identifier de manière unique chaque fonction. Chacun des éléments suivants: Nombre d'arguments Type d'arguments Séquence d'arguments sont les paramètres utilisés pour générer le nom de la mutilé unique pour chaque fonction. Il est sur la base de ces noms non mangés uniques que le compilateur peut comprendre quelle fonction appeler même si les noms sont les mêmes (surcharge). 3 commentaires Même si le type de retour a été utilisé pour Name Mangling, il ne serait pas possible de déterminer la fonction exacte à appeler si la valeur de retour de l'appel de fonction a été supprimée. Pour être précis: le fait que Name Mangling ne compte pas que le type de retour soit un résultat, pas une cause. Si la norme avait dit que c'était possible, Name Mangling Qwoud aurait inclus le type de retour. @ Chubsdad, Msalters: convenu, point bien fait! 0 votes Non, vous ne pouvez pas surcharger en fonction du type de retour. des documents standard., Sec 13.1.2 , - Les déclarations de fonction qui diffèrent uniquement dans le type de retour ne peuvent pas être surchargées. et en ce qui concerne votre bibliothèque, chaque fonction peut appartenir à un espace de noms différent, sinon ce n'est pas possible non plus. 0 commentaires

Articles qui pourrait vous intéresser : Catalina C ++: L'utilisation d'en-têtes <cmath> génère une erreur: aucun membre nommé 'signbit' dans l'espace de noms global installation du compilateur c ++ 11 (+) sans autorisation d'administrateur Application de console C ++ VS2019 - Le débogueur n'acceptera pas les arguments de commande Meilleur moyen en C ++ de garder une grosse structure atomique?