Plus d'appel au destructeur qu'au constructeur ?

Version imprimable

Voir 40 message(s) de cette discussion en une page

Le C++ c'est chaud...

J'ai un petit programme que j'ai essayé de simplifier au maximum

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
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
using namespace std;
#include <string>
#include <vector>
#include <stdio.h>
 
class ebovar
{
public:
      union {
          int i;
          float f;
          bool b;
          string *s;
          void *o;
      };
 
// var is null
	ebovar() : i(0) {
		printf("++ create NULL\n");
	}
	~ebovar()
	{
		printf("-- delete ebovar %d\n", i);
	}
 
// integer function
	ebovar(int v) {
		i = v;
		printf("++ create int %d\n", i);
	}
	operator int() { return i; }
};
 
/********************************************************************
**
** Operateur +
**
********************************************************************/
 
ebovar operator+(ebovar left_op, ebovar right_op)
{
	return (ebovar)((int)left_op + (int)right_op);
}
 
int main(int _argc, char **_argv)
{
	ebovar _a = 10;
	ebovar _b = 12;
	ebovar _result = _b + _a;
}

il affiche

Code:

1
2
3
4
5
6
7
8
++ create int 10
++ create int 12
++ create int 22
-- delete ebovar 12
-- delete ebovar 10
-- delete ebovar 22
-- delete ebovar 12
-- delete ebovar 10

Comment puis-je avoir 3 appels au constructeur de ma classe et 5 appels au destructeur ?
Qu'est ce que j'ai manqué ?

11/03/2015, 11h25
Ehonn

Bonjour

C'est à cause des copies des paramètres par l'opérateur + :

Citation:

Envoyé par webshaker

ebovar operator+(ebovar left_op, ebovar right_op)

Tu n'as pas l'affichage des créations car tu n'as pas écrit le constructeur par copie de ta classe (le compilateur l'a fait pour toi).
11/03/2015, 12h28
webshaker

Ah ouais!!!

comme ce sont des classes j'ai remplacer par

Code:

ebovar operator+(ebovar &left_op, ebovar &right_op)

Ca ne pourra qu'alle plus vite !
Merci.
11/03/2015, 13h18
Ehonn

Pas besoin de pouvoir modifier les opérandes :

Code:

ebovar operator+(ebovar const & left_op, ebovar const & right_op)

Il faudra corriger l'opérateur de conversion en entier de ta classe :

Code:

int operator int() const { return i; }

Citation:

Envoyé par webshaker

Ca ne pourra qu'alle plus vite !

Pour les types qui font la taille des types primitifs, ça ne va pas plus vite.
Les deux codes (ebovar operator+(ebovar const & left_op, ebovar const & right_op) et ebovar operator+(ebovar const left_op, ebovar const right_op)) sont acceptables ici.
11/03/2015, 14h18
webshaker

Merci.

Tu peux vaguement m'expliquer à quoi sert le const ?
Si je le met, il ne m'est plus possible d'utiliser d'appeler les méthode de l'object dans la fonction qui surcharge le +

Ca me dit

Code:

error: passing 'const ebovar' as 'this' argument of 'float ebovar::getFloat()' discards qualifiers

Ca change quoi de ne pas le mettre ?
11/03/2015, 14h19
Bousk

Citation:

Envoyé par Ehonn

Les deux codes (ebovar operator+(ebovar const & left_op, ebovar const & right_op) et ebovar operator+(ebovar const left_op, ebovar const right_op)) sont acceptables ici.

Sauf que faire un passage par copie constante n'a aucun intérêt. Donc ebovar operator+(ebovar const left_op, ebovar const right_op) est à oublier.
Et je vois pas pour quelle raison tu crois ça acceptable ? :weird:

Les fonctions d'une classes (aussi appelées méthodes) sont liées à une variable automatique, this, qui est un pointeur vers l'objet sur lequel la fonction est appelée.
Ainsi, si f est un ebovar, f.getFloat()provoque l'appel de la fonction ebovar::getFloat() avec this=&f.

Or, il n'est pas possible de prendre un pointeur modifiant sur une valeur constante.
Il faut donc un moyen de définir this non pas comme un ebovar* mais comme un ebovar const*.
L'astuce, c'est de placer un const sur la fonction elle-même.
Code:

1 2 3 4 5 6 7 8 9 10 11 12 class ebovar { //je passe les détails... public: //déclaration float getFloat() const; //déclaration en place float getFloat() const {/* ... */} }; //définition en dehors d'une fonction membre. float ebovar::getFloat() const {/* ... */}

Bon...
A chaque nouvelle ligne de code un nouveau problème ;(
J'ai donc solutionné mon problème de constructeur et destructeur en passant tout par référence.

Maintenant je veux ajouter une nouvelle surcharge pour pouvoir ajouter un int à un ebovar.

Code:

1
2
3
4
ebovar operator+(ebovar &left_op, int ivalue)
{
	return (ebovar)(left_op.i + ivalue);
}

Et ça fonctionne !!!

Donc je decide de gérer un nouveau type de variable puisque mon ebovar est sensé être un variant.
j'ajoute donc le code suivant

Code:

1
2
3
4
5
6
	ebovar(float v) {
		f = v;
		var_type = EBO_FLOAT;
		printf("++ create int %d\n", i);
	}
	operator float() { return f; }

Et là, ca marche à moitié seulement.
ebovar _result = _a + _b; ça compile et ça marche
ebovar _result = _a + 8; ça compile et ça marche
par contre ebovar _result = _a + _b + 8; ça ne compile pas du tout.

C'est chaud non ?

Code:

1
2
3
4
test.cpp: In function 'int main(int, char**)':
test.cpp:78: error: ambiguous overload for 'operator+' in 'operator+(ebovar&, ebovar&)(((ebovar&)(& _b))) + 8'
test.cpp:78: note: candidates are: operator+(int, int) <built-in>
test.cpp:78: note:                 operator+(float, int) <built-in>

Le code complet est là.

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
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
using namespace std;
#include <string>
#include <map>
#include <stdio.h>
 
#define EBO_INT				0
#define EBO_FLOAT				1
#define EBO_STRING			2
#define EBO_ERROR				3										// Operation fire error
#define EBO_BOOL				EBO_INT + 4							// BOOL is a specif INT
#define EBO_NULL				EBO_INT + 8							// NULL is a specif INT 
#define EBO_ARRAY				EBO_ERROR +	32
#define EBO_OBJECT			EBO_ERROR + 64
 
class ebovar
{
public:
	int var_type;
	union {
		int i;
		float f;
		bool b;
		string *s;
		map<ebovar, ebovar> *m;
		void *o;
	};
 
// var is null
	ebovar() {
		i = 0;
		var_type = EBO_NULL;
		printf("++ create NULL\n");
	}
	~ebovar()
	{
		printf("-- delete ebovar %d\n", i);
		i = 1;
		return;
	}
 
// integer function
	ebovar(int v) {
		i = v;
		var_type = EBO_INT;
		printf("++ create int %d\n", i);
	}
	operator int() { return i; }
 
// float function
	ebovar(float v) {
		f = v;
		var_type = EBO_FLOAT;
		printf("++ create float %d\n", i);
	}
	operator float() { return f; }
};
 
/********************************************************************
**
** Operateur +
**
********************************************************************/
 
ebovar operator+(ebovar &left_op, ebovar &right_op)
{
	return (ebovar)(left_op.i + right_op.i);
}
 
ebovar operator+(ebovar &left_op, int ivalue)
{
	return (ebovar)(left_op.i + ivalue);
}
 
int main(int _argc, char **_argv)
{
	ebovar _a = 10;
	ebovar _b = 12;
	ebovar _result = _a + _b + 8;
}

11/03/2015, 15h25
Ehonn

Citation:

Envoyé par Bousk

Sauf que faire un passage par copie constante n'a aucun intérêt. Donc ebovar operator+(ebovar const left_op, ebovar const right_op) est à oublier.
Et je vois pas pour quelle raison tu crois ça acceptable ? :weird:

Le passage par copie constante a un intérêt sémantique (mais pas plus).

Remplace ton :

Citation:

Envoyé par webshaker

operator float() { return f; }

par :

Code:

float operator float() const { return f; }

Les const te permettent d'interdire les modifications et donc peuvent permettent d'éviter des erreurs d'étourderies.
11/03/2015, 15h39
webshaker

Alors un complément d'information utile est que j'ai g++ 4.1
lequel visiblement ne gère pas le C++11

du coup
explicit operator int() { return i; } me renvoit

Code:

test.cpp:47: error: only declarations of constructors can be 'explicit'

et
float operator float() const { return f; } me renvoit

Code:

test.cpp:55: error: return type specified for 'operator float'

Je pense que je vais commencer par une mise a jour de g++ !
11/03/2015, 15h55
Ehonn

Vire le type de retour que j'avais mis...

Code:

operator float() const { return f; }
11/03/2015, 16h32
webshaker

Bon.

Ca fonctionne en effet, sauf que j'ai pas compris pourquoi.
Je vais un peu chercher sur Internet, histoire de ne pas griller toutes mes cartouches sur ce forum d'un coup ;)

Merci en tout cas.
11/03/2015, 16h50
Bousk

Citation:

Envoyé par Ehonn

Le passage par copie constante a un intérêt sémantique (mais pas plus).

Sauf à vouloir gâcher de la mémoire, ça n'a strictement aucun intérêt.
Si un paramètre est const, il sera const&, s'il est copié, on s'en moque qu'il soit const.
12/03/2015, 08h42
Ehonn

Depuis quand int const gâche de la mémoire...
int const est acceptable, ce n'est pas le seul, mais il reste acceptable...
12/03/2015, 10h42
Bousk

Depuis quand on parle de type primitif ?
Les types primitifs sont passés pas copie, et quand on passe un paramètre par copie, on s'en moque de la constance ou pas, c'est une copie.
Maintenant va t'amuser à passer par copie une vraie structure/classe, puis éclate-toi à la transférer sur plusieurs niveaux d'appels par copie. Chaque copie est un gachis de mémoire pur et dur, et la constance n'a strictement aucun intérêt.
L'appelant s'en moque, il s'agit d'une copie et donc ce qu'il passe en paramètre n'est pas affecté: c'est tout ce qui l'intéresse.
Le développeur de la méthode, au mieux s'en moque, au pire est gêné: on lui fournit une copie constante, qu'il ne peut donc pas modifier, et il doit alors refaire sa propre copie pour agir dessus si nécessaire. Intérêt de la copie const : pire que nulle.
Une signature de fonction c'est un contrat, pas des mot-clés mis bout à bout par hasard. const& assure que l'objet ne sera pas modifié. La copie également puisqu'il sera copié lors du passage. Une copie const apporte strictement aucune information, sauf que le programmeur de la méthode est mauvais, sait pas ce qu'il fait (il a vaguement entendu qu'il fallait passer const les paramètres quand nécessaire), ou a oublié un symbole &.

Quand un étudiant me montre une copie constante, je le renvois illico. Soit il fait une copie et il assume et il sait le justifier. Soit il fait une const&.

Citation:

Envoyé par webshaker

Ca fonctionne en effet, sauf que j'ai pas compris pourquoi.
Je vais un peu chercher sur Internet, histoire de ne pas griller toutes mes cartouches sur ce forum d'un coup ;)

Une méthode const assure que le this (l'objet, ses variables internes) n'est pas modifié. Sur un objet const tu ne peux utiliser que des méthodes const.
12/03/2015, 10h52
webshaker

Merci Bousk,

J'avais fini par trouver un tuto plutôt bien fait qui explique les effets du const sur la surcharge des opérateurs (entre autre).
12/03/2015, 12h52
Ehonn

Citation:

Envoyé par Bousk

Depuis quand on parle de type primitif ?

Depuis le message #4.

Passer des copies constantes m'a déjà permis d'éviter des erreurs d’inattention (tentative de modification de la mauvaise variable).
12/03/2015, 13h48
ternel
Pour information, la constance d'un paramètre de fonction n'a pas à être respectée dans l'implémentation.
Considérons:
Code:

1 2 3 4 5 int doubler(int const); int doubler(int a) { return 2*a; }
Ces deux fonctions sont la même pour l'édition de lien.
Du coup, effectivement, pour l'appelant, ca ne change rien.

Lu sur cppreference.com (partie parameter list):

Citation:

The type of each function parameter in the parameter list is determined according to the following rules:
1) First, decl-specifier-seq and the declarator are combined as in any declaration to determine the type.
2) If the type is "array of T" or "array of unknown bound of T", it is replaced by the type "pointer to T"
3) If the type is a function type F, it is replaced by the type "pointer to F"
4) Top-level cv-qualifiers are dropped from the parameter type (This adjustment only affects the function type, but doesn't modify the property of the parameter: int f(const int p, decltype(p)*); and int f(int, const int*); declare the same function)
13/03/2015, 17h09
koala01

Salut

Citation:

Envoyé par Bousk

Depuis quand on parle de type primitif ?
Les types primitifs sont passés pas copie, et quand on passe un paramètre par copie, on s'en moque de la constance ou pas, c'est une copie.
Maintenant va t'amuser à passer par copie une vraie structure/classe, puis éclate-toi à la transférer sur plusieurs niveaux d'appels par copie. Chaque copie est un gachis de mémoire pur et dur, et la constance n'a strictement aucun intérêt.
L'appelant s'en moque, il s'agit d'une copie et donc ce qu'il passe en paramètre n'est pas affecté: c'est tout ce qui l'intéresse.
Le développeur de la méthode, au mieux s'en moque, au pire est gêné: on lui fournit une copie constante, qu'il ne peut donc pas modifier, et il doit alors refaire sa propre copie pour agir dessus si nécessaire. Intérêt de la copie const : pire que nulle.
Une signature de fonction c'est un contrat, pas des mot-clés mis bout à bout par hasard. const& assure que l'objet ne sera pas modifié. La copie également puisqu'il sera copié lors du passage. Une copie const apporte strictement aucune information, sauf que le programmeur de la méthode est mauvais, sait pas ce qu'il fait (il a vaguement entendu qu'il fallait passer const les paramètres quand nécessaire), ou a oublié un symbole &.

Quand un étudiant me montre une copie constante, je le renvois illico. Soit il fait une copie et il assume et il sait le justifier. Soit il fait une const&.

Une méthode const assure que le this (l'objet, ses variables internes) n'est pas modifié. Sur un objet const tu ne peux utiliser que des méthodes const.

Dans l'absolu, tu n'a pas tord : soit on passe une référence constante, soit on passe une copie.

Mais, à mon sens, c'est le fait de passer un paramètre par copie qui est un gâchis de mémoire et non le fait que cette copie soit constante.

Car la notion de constante est totalement transversale par rapport à tout le reste : la constance d'une donnée permet juste de préciser un contrat (disons le franchement : un invariant) indiquant ce qui est acceptable ou non pour une donnée particulière et qui se résume en "on peut (ou non) modifier la donnée en question" (et donc n'appeler que des fonctions qui s'engagent à ne pas modifier l'objet en question ... ou plus).

Je suis donc tout à fait d'accord avec toi : la transmission par copie constante d'un paramètre est très certainement suboptimale, quel que soit le type du paramètre transmis. MAIS il est tout aussi vrai que le fait que la constance répond à une problématique tout autre que le fait de passer le paramètre par copie et qu'il peut donc être parfaitement justifié de passer (du moins conceptuellement parlant) une copie ... constante comme paramètre à une fonction.

Techniquement parlant, ce sera du gâchis de mémoire, parce qu'il faudra "re-copier" la copie sous une forme non constante si on envisage de la modifier, mais uniquement parce que l'on parle de copie, non parce que l'on parle de constance ;)

D'ailleurs, si tu y regarde d'un peu plus près, il n'est pas rare de transmettre un paramètre par référence constante à une fonction et de constater que la première chose que le fait à l'intérieur de cette fonction est... d'en créer une copie temporaire que nous pourrons manipuler (et modifier) à notre gré ;)
13/03/2015, 17h20
Bousk

En même temps, ça fait 3 posts que je le dis qu'une copie c'est un gachis de mémoire. Et que const n'a rien à voir et ne sert à rien. Donc je vois pas comment tu peux comprendre/croire que je lie le const à un gachis de mémoire... :roll: sauf à extrapoler quand la copie constante nous force à refaire une copie non constante, ce qui est un double gachis mémoire, mais dont la source est toujours la copie inutile.

Voir 40 message(s) de cette discussion en une page