À la toute fin du discours de Scott Schurr "Présentation constexpr" à la CppCon , il demande "Y a-t-il un moyen d'empoisonner une fonction"? Il explique ensuite que cela peut être fait (bien que de manière non standard) en:
- Mettre un
throwdans uneconstexprfonction - Déclarer un non résolu
extern const char* - Référencer les non résolus
externdans lethrow
Je sens que je suis un peu hors de ma profondeur ici, mais je suis curieux:
- Que signifie «empoisonner une fonction»?
- Quelle est la signification / l'utilité de la technique qu'il décrit?
constexprfonction est évalué au moment de la compilation.constexprfonction pouvait être utilisée soit au moment de la compilation, soit au moment de l'exécution. C'est donc un moyen de le forcer afin que vous ne puissiez pas l'utiliser au moment de l'exécution? Quand est-ce utile?constexprfonction n'est souvent pas l'implémentation la plus efficace à cause des contraintes, donc on peut ne pas vouloir qu'elle soit évaluée au moment de l'exécution; ou, c'est peut-être le cas d'erreur (comme dans son exemple).Réponses:
En général, il s'agit de rendre une fonction inutilisable, par exemple si vous voulez interdire l'utilisation de l'allocation dynamique dans un programme, vous pouvez "empoisonner" la
mallocfonction pour qu'elle ne puisse pas être utilisée.Dans la vidéo, il l'utilise d'une manière plus spécifique, ce qui est clair si vous lisez la diapositive qui s'affiche quand il parle d'empoisonner la fonction, qui dit "Un moyen de forcer la compilation uniquement?"
Il parle donc d '"empoisonner" la fonction pour la rendre impossible à exécuter au moment de l'exécution, donc elle ne peut être appelée que dans des expressions constantes. La technique consiste à avoir une branche dans la fonction qui n'est jamais prise lorsqu'elle est appelée dans un contexte de compilation, et à faire en sorte que cette branche contienne quelque chose qui provoquera une erreur.
Une
throwexpression est autorisée dans une fonction constexpr, tant qu'elle n'est jamais atteinte lors des appels de la fonction au moment de la compilation (car vous ne pouvez pas lever d'exception au moment de la compilation, c'est une opération intrinsèquement dynamique, comme l'allocation de mémoire). Ainsi, une expression throw qui fait référence à un symbole non défini ne sera pas utilisée lors des appels au moment de la compilation (car la compilation échouerait) et ne peut pas être utilisée au moment de l'exécution, car le symbole non défini provoque une erreur de l'éditeur de liens.Étant donné que le symbole non défini n'est pas "utilisé par odr" dans les appels de la fonction au moment de la compilation, en pratique, le compilateur ne créera pas de référence au symbole, il est donc normal qu'il ne soit pas défini.
Est-ce utile? Il montre comment le faire, sans nécessairement dire que c'est une bonne idée ou très utile. Si vous avez besoin de le faire pour une raison quelconque, sa technique pourrait résoudre votre problème. Si vous n'en avez pas besoin, vous n'avez pas à vous en soucier.
Une des raisons pour lesquelles cela peut être utile est lorsque la version à la compilation d'une opération n'est pas aussi efficace qu'elle pourrait l'être. Il existe des restrictions sur le type d'expressions autorisées dans une fonction constexpr (en particulier en C ++ 11, certaines restrictions ont été supprimées en C ++ 14). Ainsi, vous pouvez avoir deux versions d'une fonction pour effectuer un calcul, une qui est optimale, mais utilise des expressions qui ne sont pas autorisées dans une fonction constexpr, et une qui est une fonction constexpr valide, mais qui fonctionnerait mal si elle est appelée à l'exécution- temps. Vous pouvez empoisonner la version sous-optimale pour vous assurer qu'elle n'est jamais utilisée pour les appels d'exécution, en vous assurant que la version la plus efficace (non-constexpr) est utilisée pour les appels d'exécution.
NB Les performances d'une fonction constexpr utilisée au moment de la compilation ne sont pas vraiment importantes, car elle n'a de toute façon pas de surcharge d'exécution. Cela peut ralentir votre compilation en obligeant le compilateur à faire un travail supplémentaire, mais cela n'aura aucun coût en termes de performances d'exécution.
la source
«Empoisonner» un identificateur signifie que toute référence à l'identificateur après «l'empoisonnement» est une erreur de compilation matérielle. Cette technique peut être utilisée, par exemple, pour la dépréciation définitive (la fonction est obsolète, ne l'utilisez jamais!).
Dans GCC traditionnellement il y avait un pragma pour cela:
#pragma GCC poison.la source