Boxe (programmation informatique)

En informatique , le boxing (ou encapsulation) est la transformation consistant à placer un type primitif dans un objet afin que la valeur puisse être utilisée comme référence . Le unboxing est la transformation inverse consistant à extraire la valeur primitive de son objet wrapper. L'autoboxing est le terme utilisé pour appliquer automatiquement les transformations de boxing et/ou de unboxing selon les besoins.

L'utilisation la plus courante de la boxe est en Java où il existe une distinction entre les types de référence et de valeur pour des raisons telles que l'efficacité d'exécution et les problèmes de syntaxe et de sémantique. En Java, a LinkedListne peut stocker que des valeurs de type Object. On pourrait souhaiter avoir un LinkedListde int, mais ce n'est pas directement possible. Au lieu de cela, Java définit des classes wrapper primitives correspondant à chaque type primitif : Integeret int, Characteret char, Floatet float, etc. On peut alors définir a LinkedListen utilisant le type boxed Integeret insérer intdes valeurs dans la liste en les encadrant comme Integerdes objets. (En utilisant les types paramétrés génériques introduits dans J2SE 5.0, ce type est représenté par .) LinkedList<Integer>

D'autre part, C# n'a pas de classes wrapper primitives, mais permet de boxer n'importe quel type de valeur, en renvoyant une Objectréférence générique. En Objective-C , toute valeur primitive peut être préfixée par un @pour en faire un NSNumberun (par exemple @123ou un ). Cela permet de les ajouter dans n'importe laquelle des collections standard, comme un . @(123)NSArray

Haskell n'a que peu ou pas de notion de type de référence , mais utilise toujours le terme « en boîte » pour la représentation uniforme du pointeur vers l'union étiquetée du système d'exécution .

L'objet encadré est toujours une copie de l'objet de valeur et est généralement immuable . Le déballage de l'objet renvoie également une copie de la valeur stockée. Le déballage et le déballage répétés des objets peuvent avoir un impact sérieux sur les performances, car le boxing alloue dynamiquement de nouveaux objets et le déballage (si la valeur encadrée n'est plus utilisée) les rend alors éligibles au garbage collection . Cependant, les garbage collector modernes tels que le garbage collector Java HotSpot par défaut peuvent collecter plus efficacement les objets à courte durée de vie, donc si les objets encadrés ont une courte durée de vie, l'impact sur les performances peut ne pas être grave.

Dans certains langages, il existe une équivalence directe entre un type primitif non encadré et une référence à un type d'objet encadré immuable. En fait, il est possible de remplacer tous les types primitifs d'un programme par des types d'objet encadrés. Alors que l'affectation d'un type primitif à un autre copiera sa valeur, l'affectation d'une référence à un objet encadré à un autre copiera la valeur de référence pour faire référence au même objet que la première référence. Cependant, cela ne posera aucun problème, car les objets sont immuables, il n'y a donc sémantiquement aucune différence réelle entre deux références au même objet ou à des objets différents (à moins que vous ne regardiez l'égalité physique). Pour toutes les opérations autres que l'affectation, telles que les opérateurs arithmétiques, de comparaison et logiques, on peut désencadrer le type encadré, effectuer l'opération et réencadrer le résultat si nécessaire. Ainsi, il est possible de ne pas stocker du tout de types primitifs.

L'autoboxing est le terme utilisé pour obtenir un type de référence à partir d'un type de valeur simplement par conversion de type (implicite ou explicite). Le compilateur fournit automatiquement le code source supplémentaire qui crée l'objet.

Par exemple, dans les versions de Java antérieures à J2SE 5.0, le code suivant n'était pas compilé :

Integer i = new Integer ( 9 ); Integer i = 9 ; // erreur dans les versions antérieures à 5.0 !

Les compilateurs antérieurs à la version 5.0 n'acceptaient pas la dernière ligne. Integersont des objets de référence, en apparence pas différents de List, Object, etc. Pour convertir de an inten an Integer, il fallait instancier « manuellement » l'objet Integer. À partir de J2SE 5.0, le compilateur acceptera la dernière ligne et la transformera automatiquement de sorte qu'un objet Integer soit créé pour stocker la valeur 9. Cela signifie qu'à partir de J2SE 5.0, quelque chose comme , où et sont eux-mêmes, sera compilé maintenant - a et b sont déballés, les valeurs entières additionnées et le résultat est automatiquement mis en boîte dans un nouveau , qui est finalement stocké dans la variable . Les opérateurs d'égalité ne peuvent pas être utilisés de cette façon, car les opérateurs d'égalité sont déjà définis pour les types de référence, pour l'égalité des références ; pour tester l'égalité de la valeur dans un type en boîte, il faut toujours les déballer manuellement et comparer les primitives, ou utiliser la méthode . Integerc=a+babIntegerIntegercObjects.equals

Autre exemple : J2SE 5.0 permet au programmeur de traiter une collection (comme un LinkedList) comme si elle contenait intdes valeurs au lieu Integerd'objets. Cela ne contredit pas ce qui a été dit plus haut : la collection ne contient toujours que des références à des objets dynamiques, et elle ne peut pas lister des types primitifs. Elle ne peut pas être un , mais elle doit être un à la place. Cependant, le compilateur transforme automatiquement le code de sorte que la liste recevra « silencieusement » des objets, tandis que le code source ne mentionne que des valeurs primitives. Par exemple, le programmeur peut maintenant écrire et penser comme si les étaient ajoutés à la liste ; mais, le compilateur aura en fait transformé la ligne en . LinkedList<int>LinkedList<Integer>list.add(3)int 3list.add(newInteger(3))

Avec le déballage automatique, le compilateur fournit automatiquement le code source supplémentaire qui récupère la valeur de cet objet, soit en invoquant une méthode sur cet objet, soit par d'autres moyens.

Par exemple, dans les versions de Java antérieures à J2SE 5.0, le code suivant n'était pas compilé :

Integer k = new Integer ( 4 ); int l = k . intValue (); // toujours correct int m = k ; // aurait été une erreur, mais c'est bon maintenant

C# ne prend pas en charge le déballage automatique au même sens que Java, car il ne dispose pas d'un ensemble distinct de types primitifs et de types d'objets. Tous les types qui ont à la fois une version primitive et une version objet en Java sont automatiquement implémentés par le compilateur C# en tant que types primitifs (valeur) ou types objet (référence).

Dans les deux langages, la boxe automatique n'effectue pas de downcasting automatiquement, c'est-à-dire que le code suivant ne sera pas compilé :

C#:

int i = 42 ; object o = i ; // box int j = o ; // unbox (erreur) Console . WriteLine ( j ); // ligne inaccessible, l'auteur aurait pu s'attendre à une sortie "42"

Java:

int i = 42 ; Object o = i ; // box int j = o ; // unbox (erreur) System . out . println ( j ); // ligne inaccessible, l'auteur aurait pu s'attendre à une sortie "42"

Le Pascal Objet moderne dispose d'une autre façon d'effectuer des opérations sur des types simples, proche du boxing, appelées aides de type dans FreePascal ou aides d'enregistrement dans Delphi et FreePascal en mode Delphi. Les dialectes mentionnés sont des langages de compilation en natif d'Object Pascal, et manquent donc de certaines des fonctionnalités que C# et Java peuvent implémenter. Notamment l'inférence de type
à l'exécution sur des variables fortement typées. Mais la fonctionnalité est liée au boxing. Elle permet au programmeur d'utiliser des constructions comme

{$ifdef fpc}{$mode delphi}{$endif} 
utilise sysutils ; // cette unité contient des wrappers pour les types simples var x : integer = 100 ; s : string ; begin s := x . ToString ; writeln ( s ) ; end .