Discussion :

[yan]

Tu veux que la validite de quelque chose depende du code qui n'est pas visible? Ou alors j'ai mal devine pourquoi tu voudrais pouvoir assigner alors qu'il y a des membres qui sont des references.

Ce que tu veut dire, c'est que les références rende le code moi compréhensible, bancale et plus favorable aux bugs?

En faite c'est pour continuer sur l'idée de ce thread
http://www.developpez.net/forums/d58...-constructeur/

et avoir une class avec des accès non mutable (d'où les références const) mais qui peut être assignable.

[Médinoc]

Code :

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

1
2
3
4
5
6
    Point & operator+=(const Point &p)
    {
        Point tmp(x+p.x, y+p.y);
        std::swap(*this, tmp);
        return *this;
    }

Problème résolu.

Ben non.
L'implémentation standard de swap() fait au moins deux affectations et une affectation/copie, donc ça se mort la queue.
Ou sinon, montre-moi ton implémentation personnelle de swap() je ne vois aucun moyen qui ne fasse pas appel à const_cast<> sur les membres.

[Médinoc]

Pour le coup des références, je pense que je me suis trompé et qu'on peut faire un truc viable, vu qu'on n'a pas besoin de les modifier:

Code C++ :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
#include <alogorithm>
 
//Je reprends le coup des références déjà mentionnées, 
//mais cette fois je donne un constructeur de copie
//et un opérateur d'affectation personalisés.
class Point
{
public:
	Point(float, float);
	Point(Point const &);
	Point& operator= (Point const &);
	void Swap(Point &);
 
	float const &x;
	float const &y;
private:
	float priv_x;
	float priv_y;
};
 
namespace std
{
template<>
inline void swap(Point &left, Point &right)
{
	left.Swap(right);
}

Code C++ :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
Point::Point(float px, float py)
 : x(priv_x), y(priv_y), priv_x(px), priv_y(py)
{
}
 
//Constructeur de copie:
//on n'essaie pas de copier les références,
//on les assigne à nos propres membres.
Point::Point(Point const &src)
 : x(priv_x), y(priv_y), priv_x(src.priv_x), priv_y(src.priv_y)
{
}
 
Point& Point::operator= (Point const &src)
{
	Point tmp(src);
	Swap(tmp);
}
 
//On n'essaie pas de swapper les références,
//seulement les variables internes (non-const)
void Point::Swap(Point& other)
{
	std::swap(priv_x, other.priv_x);
	std::swap(priv_y, other.priv_y);
}

Ainsi, les références servent uniquement à accéder au champ de l'objet courant. Comme des accesseurs, mais en plus "simple" et plus bizarre.

Mais dans tous les cas, les variables privées ne peuvent être const.

[Jean-Marc.Bourguet]

Ce que tu veut dire, c'est que les références rende le code moi compréhensible, bancale et plus favorable aux bugs?

Je veux dire que l'idee que tu exprimes ici

Comme les ref pointe sur des variables privé non const, elle se retrouve être assignable non?

que j'ai compris comme: le compilateur devrait generer un operateur d'assignement parce que les references pointent vers des membres fait dependre la validite du code utilisateur (utilisateur de l'assignation) d'un detail d'implementation (tous les constructeurs initialisent les references vers les membres) qui en prime peut ne pas etre facilement observable a l'endroit ou on l'utilise.

En faite c'est pour continuer sur l'idée de ce thread
http://www.developpez.net/forums/d58...-constructeur/

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
template <typename T>
class Point
{
   T myX, myY;
public:
   Point(T x, T y) : myX(x), myY(y) {}
   // Point(Point const&);
   // Point& operator=(Point const&);
   // ~Point();
 
   void swap(Point const& other) { swap(myX, other.myX); swap(myY, other.myY); }
   T x() const { return myX; }
   T y() const { return myY; }
};
template <typename T>
void swap(Point<T>& l, Point<T>& r)
{
   l.swap(r);
}

et je ne me casse pas plus la tete. Mais bon, je ne suis pas un specialiste de la geometrie calculatoire (je ne sais meme pas quelle est la traduction francaise consacree de computational geometry).

[Jean-Marc.Bourguet]

Ainsi, les références servent uniquement à accéder au champ de l'objet courant. Comme des accesseurs, mais en plus "simple" et plus bizarre.

Et avec un risque non négligeable de consommer 2X plus de memoire par rapport a la version sans elle mais avec des accesseurs. Je veux bien que le compilateur peut les optimiser, mais je ne suis pas sur que ce soit fait pas beaucoup d'entre eux.

[yan]

et je ne me casse pas plus la tete. Mais bon, je ne suis pas un specialiste de la geometrie calculatoire (je ne sais meme pas quelle est la traduction francaise consacrée de computational geometry).

Cette class n'est qu'un exemple.
C'est pour voir comment concevoir un class avec des accès non mutable (d'où les références const) mais qui peut être assignable.

Et avec un risque non négligeable de consommer 2X plus de memoire par rapport a la version sans elle mais avec des accesseurs. Je veux bien que le compilateur peut les optimiser, mais je ne suis pas sur que ce soit fait pas beaucoup d'entre eux.

Pour des int je suis d'accord. Mais pour des objet lus gros comme des vector?

[Jean-Marc.Bourguet]

Mais pour des objet lus gros comme des vector?

Je ne suis pas sur du tout que je donnerais facilement une semantique de valeur a des objets gros.

[loufoque]

Ben non.
L'implémentation standard de swap() fait au moins deux affectations et une affectation/copie, donc ça se mort la queue.
Ou sinon, montre-moi ton implémentation personnelle de swap() je ne vois aucun moyen qui ne fasse pas appel à const_cast<> sur les membres.

C'est pourtant le seul moyen d'avoir une exception-safety forte, ce qui en fait l'idiome à privilégier.
Si le constructeur ne lève pas d'exception, des optimisations sont en effet possibles, et on peut espérer que le compilateur les fera.

Affecter chaque champ un à un ne peut pas garantir une sémantique rollback.

[Jean-Marc.Bourguet]

C'est pourtant le seul moyen d'avoir une exception-safety forte

Depuis quand?

C'est un moyen qui a l'avantage de pouvoir etre mis en place quasiment systematiquement.

Trivialement, si aucun membre n'a une affectation capable de jeter une exception, une affectation membre a membre n'a aucun probleme; si un seul membre a une affectation capable de jeter une exception, l'affecter en premier suffit.