reutiliser le constructeur

Bonjour,
est il propre de re-utiliser le constructeur pour modifier une class non mutable lors d'un operation. Par exemple :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 struct Point { Point(float x,float y) :x(x),y(y) {} Point & operator+=(const Point &p) { this->Point::Point(x+p.x,y+p.y); return *this; } const float x; const float y; };
L'operateur += utilise le constructeur pour modifier x et y.

Citation:

Envoyé par Mongaulois

Bonjour,
est il propre de re-utiliser le constructeur pour modifier une class non mutable lors d'un operation. Par exemple :

Non, c'est dégueu ! :-)

Déjà, il me semble que l'opérateur de portée est superflu puisque « this » appartient à ta classe. Ensuite, je crois me souvenir qu'appeler directement un constructeur crée une nouvelle instance, donc ça ne servira à rien dans le cas qui t'intéresse.

Par contre, tu peux effectivement créer un nouvel objet et l'affecter à l'objet courant, repéré par this.

Code:

*this=Point(x+p.x,y+p.y);

M'enfin, bon. Si tes membres sont const, ce n'est pas pour rien. Si, en revanche, ils ne sont constants que pour être read-only vis-à-vis de l'utilisateur et que tu ne veux pas passer par une méthode pour y accéder (ce que je comprends), moi j'initialise des références constantes publiques sur des objets volatiles privés.

Citation:

Envoyé par Obsidian

Non, c'est dégueu ! :-)

En quoi c'est degueu?(j'arrive pas à comprendre pourquoi)

Citation:

Déjà, il me semble que l'opérateur de portée est superflu puisque « this » appartient à ta classe. Ensuite, je crois me souvenir qu'appeler directement un constructeur crée une nouvelle instance, donc ça ne servira à rien dans le cas qui t'intéresse.

C'est pour cela qu'il faut le this. En tout cas sous visual ça marche.
Code:

1 2 3 4 5 6 Par contre, tu peux effectivement créer un nouvel objet et l'affecter à l'objet courant, repéré par this. Code: *this=Point(x+p.x,y+p.y);
comme x et y sont const, comment fait tu l'operateur =?

Citation:

M'enfin, bon. Si tes membres sont const, ce n'est pas pour rien. Si, en revanche, ils ne sont constants que pour être read-only vis-à-vis de l'utilisateur et que tu ne veux pas passer par une méthode pour y accéder (ce que je comprends), moi j'initialise des références constantes publiques sur des objets volatiles privés.

En fin c'est un peu un fork de ce thread http://www.developpez.net/forums/d58...-constructeur/

Bon ca y est j'ai trouvé pourquoi c'est dégeu :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 struct Point { Point(float x,float y) :x(x),y(y),vect(10000000) {} Point & operator+=(const Point &p) { this->Point::Point(x+p.x,y+p.y); return *this; } const float x; const float y; const std::vector<float> vect; };
dû au vector, à chaque apel de this->Point:: Point(x+p.x,y+p.y); ca va initialiser un vect(10000000) mais il n'y as pas eu destruction de la memoire précédente. Superbe fuite memoire :aie:

dsl pour le derangement

Citation:

Envoyé par Mongaulois

En quoi c'est degueu?(j'arrive pas à comprendre pourquoi)

C'est pour cela qu'il faut le this. En tout cas sous visual ça marche.

Ben, déjà, ça ne compile pas sous GCC.
En fait, tu ne peux pas réappeler directement le constructeur puisqu'il n'est par définition valable qu'à la construction d'un objet. Dans cette optique, il faudrait détruire puis recréer x et y pour pouvoir les réinitialiser.

Citation:

Code:

*this=Point(x+p.x,y+p.y);

[/CODE]
comme x et y sont const, comment fait tu l'operateur =?

Je viens de vérifier et c'est une erreur de ma part ! Désolé. Il me semblait que l'objet lui-même étant volatile, rien n'empêchait de le réécraser entièrement à partir d'une source construite de la même façon, comporterait-elle des membres constants, mais gcc n'est pas d'accord.

Par contre, comme je disais au-dessus, tu peux très bien faire ce genre de choses :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 class Point { public: Point (float,float); const float & x; const float & y; private: float priv_x; float priv_y; }; Point::Point (float px,float py) : x(priv_x), y(priv_y), priv_x(px), priv_y(py) { }
Citation:

dû au vector, à chaque apel de this->Point:: Point(x+p.x,y+p.y); ca va initialiser un vect(10000000) mais il n'y as pas eu destruction de la memoire précédente. Superbe fuite memoire

C'est l'idée mais ce n'est pas le cas. Ton vecteur n'est pas créé dans le tas. Lorsque le précédent objet cessera d'être référencé, il sera détruit, et avec lui tout ses membres, en appelant récursivement tous les destructeurs.

Citation:

Envoyé par Obsidian

Ben, déjà, ça ne compile pas sous GCC.
En fait, tu ne peux pas réappeler directement le constructeur puisqu'il n'est par définition valable qu'à la construction d'un objet. Dans cette optique, il faudrait détruire puis recréer x et y pour pouvoir les réinitialiser.

Je viens d'essayer sous code::block, ça ne marche pas. J'était persuadé que c'est ce que fait un pool de memoire.....
Citation:
Par contre, comme je disais au-dessus, tu peux très bien faire ce genre de choses :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 class Point { public: Point (float,float); const float & x; const float & y; private: float priv_x; float priv_y; }; Point::Point (float px,float py) : x(priv_x), y(priv_y), priv_x(px), priv_y(py) { }
ha ok, pas bête

Citation:

C'est l'idée mais ce n'est pas le cas. Ton vecteur n'est pas créé dans le tas. Lorsque le précédent objet cessera d'être référencé, il sera détruit, et avec lui tout ses membres, en appelant récursivement tous les destructeurs.

J'ai pas tout compris... Mais avec visual, ca compile et ca me fait une jolie fuite memoire avec ce code
Code:

1 2 3 4 5 6 7 8 9 10 11 int main() { Point p(2,3); while(1) { p+=Point(3,2); } return 0; }
[edit]
voila comment faire la même chose avec gcc
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 struct Point { Point(float x,float y) :x(x),y(y),vect(10000000) {} Point & operator+=(const Point &p) { new(this) Point(x+p.x,y+p.y); return *this; } const float x; const float y; const std::vector<float> vect; };

C'est plutôt ton code avec gcc qui contient une fuite! Le destructeur de vect n'est jamais appelé!

Citation:

Envoyé par Médinoc

C'est plutôt ton code avec gcc qui contient une fuite! Le destructeur de vect n'est jamais appelé!

sous visual ceci compile

Code:

this->Point::Point(x+p.x,y+p.y);

et fait aussi une fuite memoire.

Le problème de faire des classes avec des membres const, c'est que tu ne peux pas les affecter ni les swapper. Résultat, tu n'as plus trop le choix: Tu dois faire des membres non-constants, même si ton interface publique est constante.

Code:

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
28
29
30
#include <vector>
#include <algorithm>
 
class Point
{
public:
	Point (float,float);
	//On laisse constructeur de copie et opérateur d'affectation par défaut
	void Swap(Point &);
 
	float x() const { return priv_x; }
	float y() const { return priv_y; }
	std::vector<float> const & vect() const { return priv_vect; }
 
private:
	float priv_x;
	float priv_y;
	std::vector<float> priv_vect;
};
 
namespace std
{
 
template<>
inline void swap< Point, Point >(Point &a, Point &b)
{
	a.Swap(b);
}
 
}

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
#include "Point.hpp"
 
Point::Point (float px,float py) :
 priv_x(px), priv_y(py), priv_vect(10000000)
{
}
 
void Point::Swap(Point &other)
{
	std::swap(priv_x, other.priv_x);
	std::swap(priv_y, other.priv_y);
	std::swap(priv_vect, other.priv_vect);
}

Citation:

Envoyé par Médinoc

Le problème de faire des classes avec des membres const, c'est que tu ne peux pas les affecter ni les swapper. Résultat, tu n'as plus trop le choix: Tu dois faire des membres non-constants, même si ton interface publique est constante.

C'est ce que j'ai compris.
J'aime bien l'astuce de Obsidian.
Code:

1 2 3 4 5 6 7 8 9 10 11 12 class Point { public: Point (float,float); const float & x; const float & y; private: float priv_x; float priv_y; };

Mais la présence de références ne rend-elle pas l'objet non-assignable de toute façon?

Si tu veux faire ce genre de choses, il faut faire
Code:

1 2 3 4 5 6 Point & operator+=(const Point &p) { this->~Point(); new(this) Point(x+p.x,y+p.y); return *this; }
mais cela n'est pas du bon style. En particulier, c'est fragile dans les cas ou le constructeur peut jeter des exceptions (on se retrouve avec un objet detruit qui le sera une deuxieme fois).

Citation:

Envoyé par Médinoc

Mais la présence de références ne rend-elle pas l'objet non-assignable de toute façon?

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

Citation:

Envoyé par Mongaulois

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

Pourquoi?

car les variables privé son mutable

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
class Point
{
    public:
    Point (float xx,float yy)
     :priv_x(xx),priv_y(yy),x(priv_x),y(priv_y)
     {}
 
    Point & operator =(const Point & p)
   {
      priv_x = p.x;
      priv_y = p.y;
      return *this;
   }
 
       const float & x;
       const float & y;
 
    private:
       float priv_x;
       float priv_y;
};

Citation:

Envoyé par Mongaulois

car les variables privé son mutable

Le probleme n'est pas les membres prives mais la presence de references. Ce a quoi elles sont initialisees, c'est du detail d'implementation et n'influence pas la validite du code (imagine que les constructeurs ne soient pas inline par exemple).

Citation:

Envoyé par Jean-Marc.Bourguet

imagine que les constructeurs ne soient pas inline par exemple.

J'ai du mal à comprendre.
Si le constructeur n'est pas inline, c'est sensé changé quelque chose?? :koi:

Citation:

Envoyé par Mongaulois

J'ai du mal à comprendre.
Si le constructeur n'est pas inline, c'est sensé changé quelque chose?? :koi:

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.

Construire un objet à une adresse où un objet existe déjà est un comportement indéfini.
Il ne peut y avoir qu'un seul objet à une adresse.

Citation:
Envoyé par Jean-Marc.Bourguet
Si tu veux faire ce genre de choses, il faut faire
Code:

1 2 3 4 5 6 Point & operator+=(const Point &p) { this->~Point(); new(this) Point(x+p.x,y+p.y); return *this; }
mais cela n'est pas du bon style. En particulier, c'est fragile dans les cas ou le constructeur peut jeter des exceptions (on se retrouve avec un objet detruit qui le sera une deuxieme fois).
Code:

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.

Citation:

Envoyé par Jean-Marc.Bourguet

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.

Citation:
Envoyé par loufoque
Code:

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.

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:

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:

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.

Citation:

Envoyé par Mongaulois

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

Citation:

Envoyé par Mongaulois

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.

Citation:

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

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).

Citation:

Envoyé par Médinoc

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.

Citation:

Envoyé par Jean-Marc.Bourguet

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.

Citation:

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?

Citation:

Envoyé par Mongaulois

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.

Citation:

Envoyé par Médinoc

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.

Citation:

Envoyé par loufoque

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.