Plus d'appel au destructeur qu'au constructeur ?

Version imprimable

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.

Citation:

Envoyé par 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.

A vrai dire, je réagissais surtout à

Citation:

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

car je suis désolé, mais, conceptuellement parlant, il n'y a absolument rien qui justifie de l'interdire...

En effet, reprenons tout depuis le début et revenons un tout petit peu aux "basiques" (je sais, tu les connais déjà depuis longtemps ;) ):

Citation:

A quoi sert un paramètre pour une fonction :question:

Un paramètre de fonction correspond à une donnée pour laquelle la fonction appelée est incapable de définir une valeur (un état) par elle-même.

Le paramètre en question a pour résultat de déclarer une variable du type et du nom indiqué accessible au sein de la fonction.

Citation:

A quoi sert la notion de référence :question:

La notion de référence nous permet essentiellement de faire en sorte que les modifications éventuelles apportées par la fonction appelée au paramètre transmis par référence soient répercutées sur la variable qui a servi d'argument dans la fonction appelante. Accessoirement, le passage par référence permet d'éviter le phénomène de copie lié au passage par valeur

Note que j'aurais pu énoncer les choses sous un point de vue différent :
La notion de référence nous permet de transmettre une variable comme argument lors de l'appel d'une fonction en éitant le phénomène de copie de cette variable au niveau de la fonction appelée. Elle présente néanmoins "l'effet secondaire" de faire en sorte que toute modification apportée au paramètre transmis par référence au niveau de la fonction appelée sera répercutée sur la variable qui a servi d'argument au niveau de la fonction appelante.

Citation:

A quoi sert la constante :question:

La constante permet d'indiquer explicitement au compilateur qu'il doit veiller à ne pas autoriser la modification de la variable (au sens le plus large possible) auquel elle se rapporte.

Cela impose un "contrat" que le compilateur est parfaitement en mesure de faire respecter : la variable ne peut en aucun cas être modifiée.

Maintenant que nous avons repris nos basiques, réfléchissons un peu au différentes combinaisons :
Variable et constante :
Il n'y a absolument rien qui t'interdise de déclarer une variable locale comme étant constante : cela ne fait rien d'autre que la transformer en "constante locale" : Je n'aurais, par exemple, aucun problème avec l'idée d'écrire un code proche de
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 /* Fonction lisant 10 fichiers dont seul le suffixe est différent */ void foo(){ std::string const base{"chemin/vers/fichier"}; std::string const ext{".ext"}; for(int i=1;i<11;++i){ std::string filename(base); filename.append(std::to_string(i) .append(ext); std::ifstream ifs(filename); if(ifs){ /* ... */ } } }
A vrai dire, j'y verrais même deux avantages :

Primo : j'indique explicitement au lecteur du code que les chaines de caractères base et ext n'ont pas vocation à être modifiée
Secundo : Je m'assure que le compilateur m'engueulera si, à un moment ou à un autre, je venais à essayer de modifier la valeur de ces chaines de caractères.

référence et constante?
Avant de nous intéresser à la raison qui nous poussera à transmettre un paramètre sous la forme d'une référence constante, intéressons nous aux raisons qui nous pousseront à transmetre un paramètre sous la forme d'une référence (non constante):

On peut décider de le faire pour deux raisons :

- Soit parce que l'on souhaite effectivement que les modifications appliquées au paramètre dans la fonction appelée soient répercutées à la fonction dans la fonction appelante. D'une certaine manière, le fait que l'on évite également la copie de l'argument n'est à considérer que comme un "bonus supplémentaire" ;)
- Soit parce que l'on souhaite effectivement éviter le phénomène de copie lié au passage par valeur. Le fait que les modifications appliquées au paramètre dans la fonction appelée soient répercutées sur l'argument utilisé dans la fonction appelante est alors considéré un "effet secondaire potentiellement non souhaitable".

D'une certaine manière, le passage par référence constante n'aura réellement du sens que si cet effet secondaire n'est ni souhaitable ni souhaité.

valeur constante?

La constante en elle-même n'indique qu'une seule chose : la fonction appelée ne peut pas modifier la variable correspondante. Le fait que l'on passe le paramètre par valeur au lieu de le passer par référence semble indiquer qu'il y aura copie. Mais la question est "le passage par référence constante évitera-t-il effectivement qu'il n'y ait construction (par copie ou non) d'une variable locale à la fonction appelée :question:"

La réponse à cette question est, malheureusement, non...

Reprenons la fonction que je présentais en exemple, et modifions la de manière à faire en sorte qu'elle accepte un paramètre indiquant le chemin à suivre pour accéder au fichier sous une forme proche de
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 void foo(std::string const & path){ std::string const base{"fichier"}; std::string const ext{".ext"}; for(int i=1;i<11;++i){ std::string filename(base); filename.append(path) .append(std::to_string(i) .append(ext); std::ifstream ifs(filename); if(ifs){ /* ... */ } } }
Le passage par référence constante est sensé éviter la création d'une copie, c'est à dire que nous l'éviterons si on appelle cette fonction sous une forme proche de
Code:

1 2 3 4 int main(){ std::string /* const */ path{"chemin/a/suivre"}; foo(path); }
Mais on ne peut ignorer le fait que de nombreux appels à cette fonction pourraient prendre la forme de
Code:

1 2 3 int main(){ foo("chemin/ecrit/en/dur"); }
Et que cela occasionnera de toutes façons la création d'une variable temporaire anonyme au niveau de la fonction appelante. A ce stade, l'intérêt du passage par référence qui est d'éviter la copie devient strictement minimal alors que celui de transmettre une valeur constante reste tout à fait capital : le compilateur nous engueulera si on essaye de modifier la valeur de ce paramètre dans la fonction appelée.

Je ne vois donc absolument rien qui puisse justifier d'un point de vue conceptuel de refuser un passage par valeur constante sous la forme de
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 void foo(std::string const path){ std::string const base{"fichier"}; std::string const ext{".ext"}; for(int i=1;i<11;++i){ std::string filename(base); filename.append(path) .append(std::to_string(i) .append(ext); std::ifstream ifs(filename); if(ifs){ /* ... */ } } }

16/03/2015, 16h52
ternel

Je suis bien d'accord avec l'intérêt de const.
Cela dit, une référence apporte un gain et aucune perte par rapport à une copie.

Pour conséquence, le fait d'être constante n'intéresse pas l'utilisateur d'une fonction prenant son argument par copie.
C'est d'ailleurs pour cela que const et volatile ne sont pas pris en compte dans la différenciation des fonctions.

Du coup, j'aurai tendance à dire qu'il vaut mieux déclarer les fonctions sans const, et les définir avec, si on en ressent le besoin.
16/03/2015, 17h30
koala01

Citation:

Envoyé par leternel

Je suis bien d'accord avec l'intérêt de const.
Cela dit, une référence apporte un gain et aucune perte par rapport à une copie.

Pour conséquence, le fait d'être constante n'intéresse pas l'utilisateur d'une fonction prenant son argument par copie.
C'est d'ailleurs pour cela que const et volatile ne sont pas pris en compte dans la différenciation des fonctions.

Du coup, j'aurai tendance à dire qu'il vaut mieux déclarer les fonctions sans const, et les définir avec, si on en ressent le besoin.

Attention, comme tu l'indiques si bien, ils ne sont pas pris en compte lors de la différenciation des fonctions (du moins pour le passage par valeur).

Je suis donc tout à fait d'accord avec ton analyse selon laquelle le fait qu'une fonction prenne son paramètre par valeur constante n'intéresse pas l'utilisateur de la fonction.

Par contre, le fait qu'une variable (éventuellement obtenue au travers d'un paramètre qui lui a été transmis) intéresse au plus haut point le développeur de la fonction et participe au respect de certains contrats, ce qui justifie à lui seul le fait de déclarer la variable (ou le paramètre) en question comme étant constant(e).

En outre, je ne partage pas ton avis en ce qui concerne l'idée de déclarer une fonction prenant un paramètre par valeur non constant et de la définir comme prenant ce paramètre sous une forme constante car, bien que le compilateur n'y fasse pas attention du tout, le lecteur du code prendra forcément la présence (ou l'absence) du mot clé const en compte.

Le fait de trouver la définition d'une fonction qui ne corresponde pas (à cause de la présence du mot clé const ou volatile) à sa déclaration contraindrait le lecteur du code à la gymnastique intellectuelle qui consiste à se rappeler que "mais oui, en effet, const et volatile n'interviennent pas dans la différentiation lors du passage par valeur".

En "lecture rapide", le lecteur risque fort de ne pas faire cette gymnastique intellectuelle et sera donc sans doute particulièrement désorienté par cette différence. Sans oublier les problèmes que cela pourrait occasionner au niveau de la recherche ou au niveau de fonctionnalités de certains IDE permettant de "switcher" entre la déclaration et l'implémentation de fonctions.

N'ayant, jusqu'à présent, pas eu le moindre argument judicieux motivant le fait de ne pas passer une valeur constante comme paramètre, et n'ayant pas d'avantage été séduit par l'idée de déclarer les fonctions sous une forme et de les définir sous une autre, j'en reste donc à mon idée première : peu importe que ce soit par valeur ou par référence, si la fonction appelée ne doit pas avoir la possibilité de modifier un paramètre qu'elle a obtenu, il faut le déclarer explicitement comme étant constant :)
16/03/2015, 18h19
Bousk

Citation:

Envoyé par koala01

Par contre, le fait qu'une variable (éventuellement obtenue au travers d'un paramètre qui lui a été transmis) intéresse au plus haut point le développeur de la fonction et participe au respect de certains contrats, ce qui justifie à lui seul le fait de déclarer la variable (ou le paramètre) en question comme étant constant(e).

Trouve-moi 1 seul exemple d'une quelconque utilité (utilité réelle, pas de "ça m'évite les fautes de frappe en modifiant un paramètre et non une variable interne à ma fonction" - va renommer correctement tes variables pour faire des étourderies pareilles) à un paramètre passé par copie constante. Un seul contrat qui nécessite qu'un paramètre soit une copie constante.
Si la réponse est, telle que ma petite expérience l'indique ainsi que le bon sens, un bon gros AUCUN, alors je vous renvois vers la lecture de mon 1° post et oui je n'ai aucun regret à indiquer à mes étudiants qu'une copie const en paramètre est une bétise et n'a absolument pas lieu d'être, et qu'en tant que telle, donc on ne l'écrit pas.

Pour me répéter : que le contrat indique une copie constante est absurde : c'est déjà une copie, donc l'original n'est pas modifié, donc il peut bien en faire une copie, ça m'en touche une sans bouger l'autre et je m'en tamponne l'oreille avec une babouche à clochette.
Et c'est bien tout ce qui m'intéresse dans le contrat avec cette fonction : l'objet que je lui passe en paramètre n'est pas altéré!

Citation:

Je ne vois donc absolument rien qui puisse justifier d'un point de vue conceptuel de refuser un passage par valeur constante sous la forme de

oui tout comme on peut mettre des ; à l'infini en fin d'instruction, après les accolades d'un for, ... des exemples stupides existent à la pelle, ça n'en est pas moins des bétises qu'il vaut mieux faire comprendre à un étudiant/débutant que de le laisser errer dans son capharnaüm.

Citation:

"mais oui, en effet, const et volatile n'interviennent pas dans la différentiation lors du passage par valeur".

En "lecture rapide", le lecteur risque fort de ne pas faire cette gymnastique intellectuelle et sera donc sans doute particulièrement désorienté par cette différence.

Un lecteur, rapide ou non, n'en aura strictement rien à faire de la constante, il ne s'intéressera qu'à l'absence de référence ou pointeur pour savoir que son objet n'est pas altéré par l'appel à cette fonction.
17/03/2015, 00h03
JolyLoic

Je suis en léger désaccord avec deux points dans la discussion précédente :
- Le passage par référence est forcément plus rapide : Ce passage permet de l'aliasing entre les différents paramètres, ce qui peut empêcher le compilateur de générer le code le plus optimal possible. Certaines personnes ont mesuré un réel impact sur du code de production où on allait plus vite en passant des std::string par copie que par référence constante. Il y a aussi quelques cas rares (on initialise une donnée à partir de la valeur passée en argument, cette valeur pouvant être un temporaire) où le passage par copie peut économiser la création d'un objet supplémentaires dans certains cas d'utilisation. Alors certes, le conseil classique reste d'actualité. Mais ce n'est pas forcément une vérité absolue.

- Le const ne sert à rien pour un passage par valeur : Certes, le const dans un tel cas ne modifie en rien l'interface de la fonction. Il n'en fait d'ailleurs pas partie. Et globalement, il aura peu d'effet sur le code généré (peu, mais pas aucun : je peux bien entendu manipuler une classe qui propose deux surcharges différentes selon que l'objet est const ou pas, aux performances différentes, par exemple). Mais si j'ai envie dans l'implémentation de ma fonction de m'assurer que je ne modifie pas par erreur la valeur de ce paramètre passé par copie, pourquoi vouloir m'empêcher de mettre en place cette sécurité supplémentaire ? Est-ce que le fait de déclarer const des variables locales est légitime (je pense que oui, légitime même si pas indispensable) ? Si oui, déclarer const des paramètres passés par valeur l'est aussi, car c'est exactement la même chose.
20/03/2015, 17h05
koala01
Citation:

Envoyé par Bousk

Trouve-moi 1 seul exemple d'une quelconque utilité (utilité réelle, pas de "ça m'évite les fautes de frappe en modifiant un paramètre et non une variable interne à ma fonction" - va renommer correctement tes variables pour faire des étourderies pareilles) à un paramètre passé par copie constante. Un seul contrat qui nécessite qu'un paramètre soit une copie constante.

J'espère, en effet, ne jamais perdre la tete au point d'oublier, au moment d'implémenter une fonction, que j'ai décidé qu'une variable (locale ou reçue au travers d'un paramètre) n'avait pas lieu à être modifiée ;)

Cependant :

Citation:

Si la réponse est, telle que ma petite expérience l'indique ainsi que le bon sens, un bon gros AUCUN, alors je vous renvois vers la lecture de mon 1° post et oui je n'ai aucun regret à indiquer à mes étudiants qu'une copie const en paramètre est une bétise et n'a absolument pas lieu d'être, et qu'en tant que telle, donc on ne l'écrit pas.

Je reste en total désaccord avec toi sur ce coup :

Le mot clé const indique très clairement la volonté du développeur qui implémente une fonction, au même titre que le choix judicieux des identifants (noms de type, de variable, de paramètres, ...) permet d'indiquer très clairement le but ou la raison d'être de chaque élément.

Je ne vais, très certainement pas développer une fonction en me disant "tiens, telle variable ne sera jamais modifiée" et essayer de la modifier dix lignes plus bas (et je te l'ai dit, j'espère ne jamais arriver à ce stade) : je ne suis pas encore assez sénile pour le faire.

Par contre, j'estime que mon code doit être la meilleure source possible de documentation pour tous ceux qui devront le lire / le modifier par la suite. Cela sous entend également le type qui devra s'intéresser à ce que j'ai écrit dans dix ans, parce qu'il vient de reprendre la (maintenance? évolution ?) d'un projet auquel je n'aurai plus pensé depuis longtemps.

A ce titre le mot clé const présente un avantage énorme : lorsque tu le rencontre, tu sais exactement quelles étaient les intentions du développeur : la valeur ne sera pas modifiée. Cela va de pair avec un corrollaire des plus agréables d'ailleurs : Si la valeur est correcte lorsqu'elle est définie, tu n'as plus besoin de t'en inquiéter par la suite, elle restera correcte quoi qu'il arrive. (y compris, et essentiellement lorsque le débuggeur rentre en jeu ;))

Citation:

Pour me répéter : que le contrat indique une copie constante est absurde : c'est déjà une copie, donc l'original n'est pas modifié, donc il peut bien en faire une copie, ça m'en touche une sans bouger l'autre et je m'en tamponne l'oreille avec une babouche à clochette.
Et c'est bien tout ce qui m'intéresse dans le contrat avec cette fonction : l'objet que je lui passe en paramètre n'est pas altéré!

Je te comprends, mais, à mon sens, cela va beaucoup plus loin que cela...

Tu connais mon point de vue : je préférerai toujours un code qui fonctionne correctement à un code rapide s'il doit en arriver à faire n'importe quoi.

A ce titre, un code const-correct apporte énormément de garanties que l'on ne pourrait avoir avec un code non const-correct qu'en le décortiquant avec le plus grand soin.

Dé lors, c'est peut être absurde, mais c'est viscérale chez moi : si je devais "pénaliser" le fait de transmettre par valeur constante et / ou par référence non constante des paramètres qui devraient (en toute logique) être transmis par référence constante, je pénaliserait le passage par référence non constante bien plus fermement (et fortement) que le passage par valeur constante.

Et cela, pour une raison bien simple :

Il suffira de transformer la valeur constante en référence constante dans le prototype pour résoudre les problèmes de performances, sans avoir à modifier la moindre ligne d'implémentation, vu que tout a déjà été mis en oeuvre pour respecter la constance des valeurs.

A contrario, tu ne peux pas forcément avoir ce genre de garantie avec un passage par référence non constante : cela demande beaucoup plus de travail pour s'en assurer et, surtout, cela pourrait mener à des dérives au niveau du code pour éviter que le paramètre ne soit modifié qui pourraient prendre une forme (caricaturale, je te l'accorde ;) ) proche de
Code:

1 2 3 4 5 6 7 void foo(Type & ref){ Type cache(ref); /* modification de ref à sa guise ici * ... */ ref = cache; }
Encore une fois, je comprends ton point de vue et je le respecte au plus haut point. Simplement, je ne suis pas tout à fait d'accord avec toi (bien que globalement d'accord sur le principe ;) )

EDIT : En fait, ce que je voulais surtout dire lorsque j'ai décidé d'intervenir sur cette discussion pourrait se résumer à ceci : Je suis tout à fait d'accord que le passage d'un paramètre par valeur constante n'est pas bon, mais c'est "moins pire" et "plus facile à accepter" grâce à la valeur "informative" (au sens le plus large possible du terme) du mot clé const que les autres erreurs que l'on pourrait commettre au niveau du passage de paramètres ;)
23/03/2015, 09h28
ternel
Citation:
Envoyé par koala01

A ce titre, un code const-correct apporte énormément de garanties que l'on ne pourrait avoir avec un code non const-correct qu'en le décortiquant avec le plus grand soin.

Dès lors, c'est peut être absurde, mais c'est viscérale chez moi : si je devais "pénaliser" le fait de transmettre par valeur constante et / ou par référence non constante des paramètres qui devraient (en toute logique) être transmis par référence constante, je pénaliserait le passage par référence non constante bien plus fermement (et fortement) que le passage par valeur constante.

Et cela, pour une raison bien simple :

Il suffira de transformer la valeur constante en référence constante dans le prototype pour résoudre les problèmes de performances, sans avoir à modifier la moindre ligne d'implémentation, vu que tout a déjà été mis en oeuvre pour respecter la constance des valeurs.

A contrario, tu ne peux pas forcément avoir ce genre de garantie avec un passage par référence non constante : cela demande beaucoup plus de travail pour s'en assurer et, surtout, cela pourrait mener à des dérives au niveau du code pour éviter que le paramètre ne soit modifié qui pourraient prendre une forme (caricaturale, je te l'accorde ;) ) proche de

Code:

1 2 3 4 5 6 7 void foo(Type & ref){ Type cache(ref); /* modification de ref à sa guise ici * ... */ ref = cache; }

Encore une fois, je comprends ton point de vue et je le respecte au plus haut point. Simplement, je ne suis pas tout à fait d'accord avec toi (bien que globalement d'accord sur le principe ;) )

EDIT : En fait, ce que je voulais surtout dire lorsque j'ai décidé d'intervenir sur cette discussion pourrait se résumer à ceci : Je suis tout à fait d'accord que le passage d'un paramètre par valeur constante n'est pas bon, mais c'est "moins pire" et "plus facile à accepter" grâce à la valeur "informative" (au sens le plus large possible du terme) du mot clé const que les autres erreurs que l'on pourrait commettre au niveau du passage de paramètres ;)
C'est de ce point de vue que je regrette que ce soit la référence constante qui demande un spécifieur plutot que la référence modifiante.

J'aurai préféré qu'une référence constante soit notée avec le &, et une référence modifiante avec volatile&
Au moins, les références modifiantes seraient explicites, et demanderait un gros travail.
Cela dit, question sémantique du langage, ce choix aurait été moins bon.