Avantages et inconvénients de cordes immuables

au moins dans le cas de Java, une partie de la raison de la création de chaînes immuables était la sécurité et la sécurité thread-sécurité. Java place une prime sur la sécurité de l'exécution (il a été conçu à l'origine pour autoriser les boîtes de pointe et les navigateurs Web pour télécharger et exécuter du contenu à distance sans compromettre le système hôte). Pour aider à augmenter la sécurité, les chaînes sont immuables et ne peuvent être sous-classées. Cela signifie que le temps d'exécution Java peut transmettre et recevoir des chaînes de l'utilisateur tout en garantissant que la valeur de la chaîne restera constante (c'est-à-dire qu'un attaquant ne peut pas sous-classer la chaîne, transmettre ce qui ressemble à une chaîne valide dans une fonction, mais Changez ensuite la valeur ultérieurement pour accéder aux mauvaises données ou utiliser plusieurs threads multiples de sorte qu'une chaîne a l'air correcte à un moment donné, mais est ensuite mutée ultérieurement).

En outre, l'immuabilité comporte des avantages d'efficacité dans les systèmes multithreads, car aucun verrouillage ne doit être effectué sur la chaîne. Il permet également d'implémenter facilement des opérations de sous-chaîne, car de nombreuses chaînes peuvent partager le même réseau sous-jacent de caractères, bien que différents points de début et de fin.

Si vous y réfléchissez, tous les types de données fondamentaux sont immuables. Vous ne changez pas d'entier 10 en 11, vous remplacez 10 avec 11. Faire des cordes fondamentales, et immuables, permet une mise en commun et d'autres optimisations qui ne seraient pas possibles autrement.

Quant aux inconvénients, les chaînes immuables nécessitent des structures de données complémentaires mutables (c'est-à-dire des tampons à cordes) pour permettre des opérations économiques ajoutées, de réorganisation et d'autres opérations similaires.

Ces opérations effectuées sur des structures immuables nécessiteraient des quantités déraisonnables de ressources.

programmation à Lua a un explication brillante sur la question.

Pour réfléchir davantage, certaines langues (telles que les LISP communes) ont des fonctions non destructives et destructrices, d'autres - des listes immuables et mutables (Python).

Pour quote Un livre sur le LISP commun :

Si l'affectation est si lourde avec péril, pourquoi ne pas l'omettre de la Langue? Il y a deux raisons: expressivité et efficacité. L'affectation est le moyen le plus clair de modifier les données partagées. Et l'affectation est plus efficace que la liaison. La liaison crée un nouvel emplacement de stockage, qui alloue stockage, qui consomme de la mémoire supplémentaire (si le la liaison ne dépasse jamais de portée) ou taxes le collecteur des ordures (si La liaison finit par sortir de la portée).

---

Cependant, comme un contre-exemple, de nombreux interprètes JavaScript (qui ont des chaînes immuables), traitent des chaînes comme des tableaux mutables sur le niveau de mise en œuvre.

Dans la même veine, Clojure a des transitoires , qui ressemblent à des fonctions pures élégantes sur des structures de données immuables, mais à l'intérieur Utiliser l'état mutable pour une efficacité.

Une des raisons pour lesquelles des chaînes immuables sont bonnes est de faciliter la prise en charge d'unicode. Unicode moderne ne peut plus s'adapter efficacement à une cellule de données de taille fixe, qui tue la correspondance individuelle entre l'indice de chaîne et l'adresse de mémoire qui donne des cordes mutables leur avantage.

Dans le passé, la plupart des applications occidentales utilisaient des caractères monopy-octet (divers codages à base d'ASCII, ou EBCDIC ...), de sorte que vous pourriez généralement les gérer efficacement en traitant des cordes en tant que tampons d'octets (que dans les applications C traditionnelles).

Quand Unicode était assez nouveau, il n'y avait plus d'exigence pour quoi que ce soit en dehors des 16 premiers bits, Java a donc utilisé des caractères à double octet pour son chaîne S (et Stringbuffer s). Cela a utilisé deux fois la mémoire et ignoré tous les problèmes pouvant survenir des extensions Unicode au-delà de 16 bits, mais c'était pratique à l'époque.

Maintenant, Unicode n'est pas aussi nouveau, et tandis que les personnages les plus utilisés correspondent toujours à 16 bits, vous ne pouvez pas vraiment vous échapper avec prétendre que le plan de base multilingue est tout ce qui existe. Si vous souhaitez affirmer honnêtement une assistance Unicode, vous avez besoin de caractères de longueur variable ou même de cellules de caractère (32 bits?).

Avec des caractères de longueur variable, vous ne pouvez plus indexer une chaîne de longueur arbitraire dans O (1) - à l'échec de l'heure, vous devez compter depuis le début pour déterminer ce que le caractère de N'th. Cela tue également l'avantage principal des tampons de cordes mutables: la possibilité de modifier de manière transparente des substrings en place.

Heureusement, la plupart des manipulations de chaîne n'ont pas besoin de cette capacité de modification en place. Lexing, analyse et recherche Tout procéder sur une base séquentielle, itérative, du début à la fin. La recherche générale-and-remplacer n'a jamais été mise en place pour commencer, car la chaîne de remplacement ne doit pas nécessairement avoir la même longueur que l'original.