dans le C # Documentation pour les délégués, il est indiqué "Un délégué est un type de référence qui peut être utilisé pour encapsuler une méthode nommée ou anonyme. Les délégués sont similaires aux pointeurs de la fonction en C ++; Cependant, les délégués sont sécurisés et Ma question est, que veulent-ils dire par un délégué qu'il "
5 Réponses :
Dans ce contexte, je pense que Sécurité signifie qu'un délégué ne peut pas tenir une valeur non valide. Cela chevauche probablement un peu un peu avec la partie de sécurité. P>
Cela signifie que vous ne pouvez pas "gâcher" comme vous le pouviez en C / C ++, rendant le pointeur de fonction pointer sur des zones de mémoire invalides ou pire, au code malveillant. P>
Il les compare aux pointeurs de fonction en C ++, qui peuvent être utilisés pour "souffler ta jambe" comme l'a dit l'homme. P>
Les pointeurs de fonction C ++ sont en réalité très sûrs. Vous devez faire quelque chose de spectaculaire stupide pour obtenir un pointeur de fonction sauvage (d'autre part, les pointeurs de données sont souvent utilisés après la suppression, les fuites, etc.)
Ma question est, que veulent-ils dire par un Delagate est "sécurisé"? P>
Les fonctions appelées avec un délégué reçoivent le contexte de sécurité de l'appelant, qui empêche un délégué de réaliser une tâche non disponible pour un appelant de privilège inférieur. strong> Les délégués peuvent être initialisés avec des pointeurs sur des fonctions qui sont implémentés n'importe où. Le seul La limitation est la signature. Les appelants doivent faire attention lorsque vous invoquez délégués contenant des pointeurs de fonction à des sources inconnues, où il y a pourrait être une mise en œuvre inattendue. Utilisez le code Accéder à la sécurité à protéger les délégués. P> blockQuote>
Cela explique comment les délégués, sinon utilisés correctement, introduisent des insécurités. Tout à fait le contraire de la réclamation dans la question.
@Benvoigt - En réalité, il est juste sur le point de voir sécurisé b>. "Un délégué reçoit le contexte de sécurité de l'appelant, qui empêche une déléguée d'effectuer une tâche non disponible pour un appelant de privilège inférieur." ce qui signifie qu'ils sont sécurisés
Ce n'est pas une différence de C ++, que la citation dans la question des revendications.
Je ne dis pas que c'est, apparemment, l'auteur ne savait pas tout à fait comment parler de cette partie. Mais cela répond à la question "Ma question est que cela signifie-t-il par un delagate" Secure "?"
Les délégués appliquent des appels de type sécurisés aux méthodes. Cela fonctionne généralement par une vérification de type statique effectuée par le compilateur. Mais n'est pas le seul moyen, vous pouvez utiliser Toutes ces tentatives compileront sans plainte. Aucun d'entre eux n'exécutera, vous obtiendrez des exceptions d'exécution. C'est ce qui rend les délégués sécurisés, vous ne pouvez pas les utiliser pour appeler une méthode qui laissera la pile déséquilibrée ou induire la méthode cible pour accéder à des emplacements de pile qui ne sont pas initialisés ou ne font pas partie du cadre d'activation. Le code malware traditionnel des programmes malveillants. Aucune vérification de ce type d'exécution n'existe en C ou C ++, leurs compilers effectuent uniquement une vérification statique et qui peut être contournée avec une simple distribution. P> P> délégué.dynamicinvoke () code> pour contourner le type de compilateur. Un exemple:
using System;
class Program {
delegate void foo(long arg);
static void Main(string[] args) {
var obj = new Example();
var dlg = Delegate.CreateDelegate(typeof(foo), obj, "Target");
dlg.DynamicInvoke(42);
}
}
class Example {
private long field;
public void Target(long arg) {
field = arg;
}
}
dynamicinvoke code> appel li>
dynamicinvoke code> appel li>
ul>
On dirait que cette partie a été écrite par marketing ... cela ne signifie pas rien i> du tout. La sécurité est dans une conception, pas une fonctionnalité de langue.
Pas une caractéristique linguistique? Bien sûr, il est également dépendant de la langue, regardez ADA
@Benvoigt en fait, cela signifie quelque chose. Il est impossible pour un délégué de pointer vers une adresse non valide, ce qui peut se produire dans C. En tant que tel, ils sont sûrs à utiliser - vous ne saurez pas dans une mémoire aléatoire.
@Tomtom: les délégués sauvages sont au moins aussi probables que des pointeurs de fonction sauvages. (Peut probablement plus probablement, puisque lors de l'utilisation de délégués avec p / invoKe, il n'y a pas de type de vérification croisée possible entre l'appelant et la callee) C ++ Les points de fonction sont parfaitement en sécurité, à moins que vous ne commenciez pas les casser (toujours une mauvaise idée) et des délégués rencontrent également des ennuis. lorsque vous désactivez le système de type.
@Benvoigt non, ils ne le sont pas. Le Pinvoke est un boîtier de frange. La coulée peut être une mauvaise idée, elle est totalement sauvegarde dans C #. De plus, il existe de la sécurité, telle que CAS (sécurité d'accès au code) qui joue également dans des délégués.
Ouf, je pense qu'ils introduisaient un autre mot clé i> ...
@Tomtom: C # n'est pas en sécurité non plus. Vous pouvez lancer des pointeurs dans un bloc dangereux, vous pouvez utiliser
marshal.copy code>. De nombreuses façons d'écraser la sécurité de la mémoire de contournement de la mémoire. Je retourne à ce que j'ai dit quand j'ai commenté l'une des réponses ... Vous devez faire quelque chose de spectaculairement stupide pour rencontrer des ennuis en C ++ ou C #.
Eh bien, des tonnes de personnes en C pas d'accord avec vous, la corruption du pointeur est une question là-bas, et des blocs dangereux dans C # ne valent sérieusement pas la peine de parler de Becauset, il invalide la sécurité à l'inverse.
@TomTom: Aucune des erreurs de pointeur habituelles (utilisation après la suppression, indexation d'une matrice, etc.) s'applique aux pointeurs de la fonction. Je souhaite que les gens ne répètent pas simplement quelles sont les "tonnes de personnes" et essayer de comprendre eux-mêmes les problèmes techniques eux-mêmes.
@Tomtom: Mais pourquoi discutons-nous de Sécurité de type i> lorsque cette question est spécifiquement sur l'autre partie de la citation?