Qu’est-ce que le type-safe dans .net?

Qu’est-ce que le type-safe?

Qu’est-ce que cela signifie et pourquoi est-ce important?

Si vous vous demandez quelle est l’idée de “type-safe” en général , c’est la caractéristique du code qui permet au développeur d’être certain qu’une valeur ou un object présente certaines propriétés (c’est-à-dire être d’un certain type) pour que il / elle peut l’utiliser d’une manière spécifique sans crainte d’un comportement inattendu ou indéfini.

Par exemple, en C #, vous pourriez dire que la classe ArrayList n’est pas sécurisée car elle peut stocker n’importe quel object , ce qui signifie que vous pouvez faire quelque chose comme ceci:

 var integers = new ArrayList(); integers.Add(1); integers.Add(2); integers.Add("3"); for (int i = 0; i < integers.Count; ++i) { int integer = (int)integers[i]; // do something } 

Ce qui précède comstackra parce que la valeur "3", même s'il s'agit d'une chaîne et non d'un entier, peut légalement être ajoutée à une ArrayList puisque Ssortingng dérive (comme Int32 ) de Object . Cependant, une InvalidCastException sera InvalidCastException lorsque vous essayez de définir integer sur (int)integers[2] car une Ssortingng ne peut pas être Int32 en Int32 .

D'un autre côté, la classe List est type-safe pour exactement la raison opposée - c'est-à-dire que le code ci-dessus ne comstackrait pas si les integers étaient un List . Toute valeur à laquelle vous pouvez accéder par le développeur depuis une liste de type List vous pouvez être certain est un int (ou quel que soit le T correspondant à une List générique List ); et vous pouvez donc être sûr que vous serez capable d'effectuer des opérations telles que la diffusion dans int (évidemment) ou, disons, long .

C – Vous déclarez un int, le convertissez en char et accédez à la mémoire au-delà des limites de l’int

 int i = 10; char *s = (char*)i; print(*(s+10)); 

C # – Les types sont sécurisés

 int i = 10; char *s //This is invalid unless you are using unsafe context. 

Les pointeurs ne sont pas directement pris en charge par .NET

Le code de type sécurisé accède uniquement aux emplacements de mémoire auxquels il est autorisé à accéder. Par exemple, le code de type sécurisé ne peut pas lire les valeurs des champs privés d’un autre object. Il n’accède aux types que de manière bien définie et autorisée.

Lors de la compilation juste-à-temps (JIT), un processus de vérification facultatif examine les métadonnées et le langage intermédiaire Microsoft (MSIL) d’une méthode à comstackr JIT en code machine natif pour vérifier qu’elles sont de type sécurisé. Ce processus est ignoré si le code a la permission de contourner la vérification

Bien que la vérification de la sécurité de type ne soit pas obligatoire pour exécuter du code géré, la sécurité de type joue un rôle crucial dans l’isolement de l’assemblage et l’application de la sécurité. Lorsque le code est de type sécurisé, le Common Language Runtime peut isoler complètement les assemblys. Cet isolement permet de s’assurer que les assemblages ne s’affectent pas mutuellement et augmente la fiabilité de l’application.

Pour plus de liens de référence msdn

Un bon article expliquant que c’est ici

La sécurité de type dans .NET a été introduite pour empêcher les objects d’un type d’entrer dans la mémoire affectée à l’autre object.

Par exemple et une discussion détaillée, veuillez visiter ce lien

Vouliez-vous parler de type-safe en particulier ou de type-safety en général?

Je ne suis pas d’accord avec la réponse acceptée: ArrayList est un ignorant de type sécurisé (ni type sûr ni type sûr): https://stackoverflow.com/a/17984521/1145224

Richter – CLR via C #, 4ème édition (page 93):

La sécurité de type est la caractéristique principale du CLR. Vous pouvez toujours découvrir le type exact de l’object en appelant la méthode GetType non-virtuelle du System.Object.

Par exemple, la classe Hero ne peut pas remplacer la méthode GetType pour devenir un type de SuperHero.

Cette fonctionnalité System.Object permet à CLR de vérifier la possibilité de lancer des objects à l’exécution. Par exemple:

 internal class Employee { ... } public sealed class Program { public static Main() { DateTime dt = new DateTime(2016, 1, 1); PromoteEmployee(newYears); } public static PromoteEmployee(Object o) { Employee e = (Employee)o; //InvalidCastException, runtime error } } 

Le type CastTimeTime sur Type d’employé est un exemple de tentative de conversion non sécurisée.

Je ne suis pas d’accord avec certaines réponses ici. C # a peu de niveaux de sécurité .

EDIT: La sécurité de type a 2 niveaux de signification (si on discute généralement des langages de programmation, comme dans ce sujet)

L’une est la sécurité de type compilation , proche de la refactorisation, etc., les fautes de frappe du compilateur, l’atsortingbution mal orthographiée de valeurs aux mauvaises variables (propriétés), c’est-à-dire la chaîne à la variable int. Le code C # typique est sûr pour le type, un moyen connu pour désactiver cette fonctionnalité est dynamic mot clé dynamic , ou des conteneurs non génériques, les erreurs comme ci-dessus sont retardées à l’exécution. Exemple: le code C / C ++ sans piratage est (généralement) de type sécurisé au moment de la compilation. Je pense qu’il est possible d’écrire (pirater) le casting en C # qui cache les conflits de type.

Le niveau suivant est la sécurité de type runtime , C # est sûr en général (sans sections dangereuses). Même la valeur dynamic est vérifiée à l’exécution. En revanche: C / C ++ n’est pas de type sécurisé à l’exécution. Si le compilateur accepte le code, l’atsortingbution non logique n’est pas vérifiée à l’exécution, fournissant des erreurs bizarres / étranges / au niveau du système ou tardives, typiques pour le langage C.

Peu de répondeurs dans ce fil de discussion mélangent d’autres zones où C # est sûr (sécurité de la mémoire, sécurité de la scope, pointeur nul, etc.). Pour être ssortingct, ce sont des types de sécurité différents.

Théorie: https://en.wikipedia.org/wiki/Type_safety