Discussion :

[zais_ethael]

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?

[Jean-Marc.Bourguet]

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.

[Médinoc]

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 C++ :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[Luc Hermitte]

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

[Jean-Marc.Bourguet]

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.

[zais_ethael]

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.

[Jean-Marc.Bourguet]

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.