réflexion sur la mutabilité

Salut à tous.
Je me pose une question de conception qui est en rapport avec une discussion sur la mutabilité des strings en C++ que j'ai croisée il y un petit temps.
Si on respecte strictement ce principe, il est évident qu'on ne peut inclure d'opérateur d'affectation dans une classe. L'ennui, c'est qu'une classe sans opérateur d'affectation ce n'est pas pratique à manipuler :).
Même si un compilateur C++ considère un opérateur d'affectation comme n'importe quel autre opérateur, conceptuellement ce n'est pas pareil. Son fonctionnement consiste presque toujours à détruire l'objet puis à lui assigner une autre valeur (et il est bien rare qu'on impose un comportement différent), on peut donc considérer le plus souvent que ce n'est qu'un raccourci de la syntaxe qui nous dispense d'appeler le destructeur puis le constructeur de copie, comme les conteneurs de la stl le font par l'intermédiaire des allocateurs par exemple.
Vous pourriez me dire qu'une fois que la valeur de la mémoire est fixée, elle est fixée, on a qu'à instancier ailleurs. Mouais, c'est bon pour le lisp ça, vous imaginez un algo de tri?
Donc le sujet: pour ou contre des classes non-mutables mais quand même avec opérateur d'affectation?

Les opérateurs d'affectation ne me gène pas du tout. Travailler sans, c'est possible -- il y a des langages qui l'imposent -- et a même des utilités: certains compilateurs utilisent des formes intermédiaires fort proche (SSA). C'est un style un peu différent.

Les types immuables n'ont pas du tout le même contexte en C++ qu'en java: En java, la classe String est un type référence (comme toutes les autres classes en java), donc forcément allouée sur le tas, et utilisée via une référence intelligente (gestion mémoire automatique).

En C++, la classe std::string est un type valeur. Il serait possible d'utiliser une classe de chaîne immuable, mais il faudrait l'utiliser uniquement par le tas. Le nouveau type String ressemblerait donc à ceci:

Code:

---

1 2 3 4 5 6 7 8 9 10 11

class unmutable_string { // ... };   class String { //... private: boost::shared_ptr<unmutable_string> str; };

---

Je ne connais aucune classe de chaîne ainsi gérée en C++, en raison des coûts en performance. Mais je connais quelque chose de proche: Les classes de chaînes en Copy-On-Write, comme celles de Qt ou de MFC. La différence principale entre COW et immuabilité complète, c'est que la chaîne devient mutable si elle n'a qu'une seule référence.

Il me semble qu'ASL d'Adobe a pas mal de trucs comme ça :
- pour les chaines statiques,
- les immuables
- les COWs

Citation:

---

Envoyé par Médinoc

Je ne connais aucune classe de chaîne ainsi gérée en C++, en raison des coûts en performance.

---

Et pourtant il y en a...

Un probleme avec les chaines, c'est qu'il y a deux concepts derriere. Un concept de valeur (et pour celui-la, la non mutabilite est interessante), et un concept de conteneur (et la, la mutabilite fait partie intrinseque de la chose). std::string resulte d'un compromis entre les deux, qui comme tout les compromis ne satisfait personne. D'experience, separer les deux concepts en deux classes a des avantages. Donc utiliser les chaines comme point de depart pour une reflexion sur comment doivent se comporter les classes de valeur ne me semble pas sain; je crois au contraire qu'il est profitable de partir d'une conception claire de la notion de valeur et d'entite pour voir comment eclairer ce qu'il faudrait faire pour les chaines. Surtout que les conteneurs sont aussi une source de confusion dans cette reflexion. Ils sont conceptuellement des entites (c'est l'objet qui compte plus que la valeur) mais qu'il est tres agreable d'avoir les operateurs des valeurs (assignation, comparaison, ...) agissant sur le contenu. Je me demande parfois si les conteneurs ne merite pas une designation au meme niveau qu'entite/valeur.

Oula, je vais replacer le contexte. Je ne citais cette discussion sur les strings qu'à titre d'exemple, ce qui m'interresse c'est la mutabilité en général.
Dans mon cas, je conçois une classe template contenant une valeur et il est possible, via une classe de trait, d'indiquer si la classe est mutable ou pas, ainsi que d'indiquer si la classe est copiable ou pas (oui je sais, ça a l'air bizarre présenté comme ça).
Donc mon dilemme est de savoir si pour le cas d'une classe copiable ET non mutable je devrais interdire l'opérateur d'affectation.

Citation:

---

Envoyé par zais_ethael

Donc mon dilemme est de savoir si pour le cas d'une classe copiable ET non mutable je devrais interdire l'opérateur d'affectation.

---

Non. Je n'arrive pas a voir le modele que tu utilises pour penser que c'est une bonne idee. En general, s'il y a un constructeur de copie, il y a une affectation.

Voila, c'est à ça que je voulais en venir.
L'ennui c'est que certains pourraient considérer que l'opérateur d'affectation rompt la non-mutabilité, alors que de mon point de vue il sert plutot à "détruire pour remplacer par une autre valeur". Je voulais juste vérifier que d'autres pouvaient penser dans le même sens.

Les types valeurs immuables de .Net (comme DateTime) possèdent un opérateur d'affectation valide et accessible.
D'ailleurs, en .Net, les types valeurs de base (int, etc.) peuvent être considérés comme des types valeur immuables: On ne peut faire aucune modification dessus sans utiliser un opérateur d'affectation (a += b est forcément traduit en a = a + b, il est impossible de définir un operator+= en .Net).

Citation:

---

Envoyé par Médinoc

Les types valeurs immuables de .Net (comme DateTime) possèdent un opérateur d'affectation valide et accessible.

---

Et? Le modele objet de .Net est suffisemment different de celui du C++ que Microsoft a du introduire un tas d'extension pour arriver a interfacer souplement le C++ avec .Net. Et le resultat n'est pas beau a voir.

Citation:

---

D'ailleurs, en .Net, les types valeurs de base (int, etc.) peuvent être considérés comme des types valeur immuables

---

Je ne connais pas un langage ou ce n'est pas le cas.

Citation:

---

On ne peut faire aucune modification dessus sans utiliser un opérateur d'affectation (a += b est forcément traduit en a = a + b, il est impossible de définir un operator+= en .Net).

---

Peux-tu m'eclairer sur ce que tu consideres exactement par .Net? Tu en parles comme d'un langage alors que c'en est pas un. Si C++/CLI n'a pas change depuis que j'ai analyse la proposition transmise pour la normalisation ISO en fast track, c'est un sur-ensemble strict de C++ (avec quelques effets bizarres des qu'on utilise la moindre chose qui n'est pas du C++ ISO). Donc on peut y definir un operateur += faisant autre chose que a = a + b. Et je ne me souviens pas que c'etait different pour les extensions introduites par C++/CLI.

Je crois qu'il ne parle pas du C++/CLI mais du C#/VB.Net, et plus particulièrement des structures (dans ces langages, une classe est instanciée dans l'espace du garbage collector et une structure sur la pile). C'est tout de même un concept interressant, il est vrai que l'effet de a+=b ne devrait jamais être différent de a=a+b, même si en C++ c'est possible pour des questions d'optimisation.

Citation:

---

Envoyé par Jean-Marc.Bourguet

Je ne connais pas un langage ou ce n'est pas le cas.

---

À la réflexion, moi non plus.

Citation:

---

Peux-tu m'eclairer sur ce que tu consideres exactement par .Net? Tu en parles comme d'un langage alors que c'en est pas un. Si C++/CLI n'a pas change depuis que j'ai analyse la proposition transmise pour la normalisation ISO en fast track, c'est un sur-ensemble strict de C++ (avec quelques effets bizarres des qu'on utilise la moindre chose qui n'est pas du C++ ISO). Donc on peut y definir un operateur += faisant autre chose que a = a + b. Et je ne me souviens pas que c'etait different pour les extensions introduites par C++/CLI.

---

Je me suis en effet trompé, car je pensais que le Common Type System lui-même ne supportait pas d'opérateur += (donc, que ça s'appliquait à tous les langages supportés). En testant, je me suis rendu compte que c'était faux, et qu'en C++/CLI on peut définir un op_AdditionAssignment sur une value class... :oops:

Mais la notion d'immuabilité ou non est toujours là: Si une value class (ou struct en C#) possède des méthodes qui modifient l'objet au lieu de retourner une copie modifiée, la value class n'est pas immuable.
Et cette notion est parfaitement reproductible en C++ natif.