65 votes

chaînes immuables vs std::string

Je me suis récemment renseigné sur les chaînes de caractères immuables. Pourquoi les chaînes de caractères ne peuvent-elles pas être mutables en Java et .NET ? y Pourquoi .NET String est immuable ? ainsi que des informations sur les raisons pour lesquelles D choisit des chaînes immuables. Il semble y avoir de nombreux avantages.

  • trivialement thread safe
  • plus sûr
  • plus efficace en termes de mémoire dans la plupart des cas d'utilisation.
  • des sous-chaînes bon marché (tokenizing et slicing)

Sans compter que la plupart des nouveaux langages ont des chaînes immuables, D2.0, Java, C#, Python, etc.

Le C++ bénéficierait-il de chaînes de caractères immuables ?

Est-il possible d'implémenter une classe de chaîne immuable en c++ (ou c++0x) qui aurait tous ces avantages ?


mettre à jour :

Il existe deux tentatives de chaînes de caractères immuables const_string y fix_str . Aucun des deux n'a été mis à jour depuis une demi-décennie. Sont-ils au moins utilisés ? Pourquoi const_string ne s'est jamais retrouvé dans boost ?

42 votes

Un argument très élaboré et convaincant que vous avez fait là, BlueRaja.

6 votes

Eh bien, BlueRaja n'a pas vraiment fait un argument, comme vous l'avez tous si clairement souligné. Mais il pourrait avoir raison, en ce sens que le C++ est peut-être trop un langage hybride pour que les tentatives puristes d'une chaîne de caractères immuable trouvent leur place. Cela en dit plus sur la culture C++ que sur le langage lui-même, bien sûr.

5 votes

Objection ! La chaîne de caractères de Ruby n'est pas immuable !

-1voto

Pierre Carrier Points 145

Les chaînes de caractères sont mutables en Ruby.

$ irb
>> foo="hello"
=> "hello"
>> bar=foo
=> "hello"
>> foo << "world"
=> "helloworld"
>> print bar
helloworld=> nil
  • trivialement thread safe

J'aurais tendance à oublier les arguments de sécurité. Si vous voulez être thread-safe, verrouillez-le, ou n'y touchez pas. Le C++ n'est pas un langage pratique, ayez vos propres conventions.

  • plus sûr

Non. Dès que vous avez de l'arithmétique de pointeur et un accès non protégé à l'espace d'adressage, oubliez la sécurité. Plus sûr contre un codage innocemment mauvais, oui.

  • plus efficace en termes de mémoire dans la plupart des cas d'utilisation.

À moins de mettre en œuvre des mécanismes gourmands en ressources CPU, je ne vois pas comment.

  • des sous-chaînes bon marché (tokenizing et slicing)

Ce serait un très bon point. Cela pourrait se faire en faisant référence à une chaîne de caractères avec des renvois, où les modifications apportées à une chaîne de caractères entraîneraient une copie. La tokenisation et le découpage deviennent gratuits, les mutations deviennent coûteuses.

-5voto

yomi Points 1

Les chaînes C++ sont thread safe, tous les objets immuables sont garantis thread safe mais le StringBuffer de Java est mutable comme les chaînes C++ et les deux sont thread safe. Pourquoi s'inquiéter de la vitesse, définissez vos paramètres de méthode ou de fonction avec le mot-clé const pour indiquer au compilateur que la chaîne sera immuable dans cette portée. En d'autres termes, lorsque vous ajoutez d'autres chaînes de caractères à la chaîne principale, vous disposez d'une liste de chaînes de caractères jusqu'à ce que vous ayez réellement besoin de la chaîne entière.

les objets immuables et mutables fonctionnent à la même vitesse à ma connaissance, à l'exception de leurs méthodes qui sont une question de pour et de contre. les primitives constantes et les primitives variables se déplacent à des vitesses différentes parce qu'au niveau de la machine, les variables sont assignées à un registre ou à un espace mémoire qui nécessitent quelques opérations binaires, tandis que les constantes sont des étiquettes qui ne nécessitent aucune de ces opérations et sont donc plus rapides (ou moins de travail est fait). cela ne fonctionne que pour les primitives et pas pour les objets.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X