Discussion :

[deubelte]

Bonjour
J'ai un morceau de code assez étrange:

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
void UneFonction (const MaClasse& IT_member) {
        if (isSet && (__d != ::VSIVOTKind_float))
        {
            this-> VSIVOT::~VSIVOT();
            memset(this, 0, sizeof(*this));
        }
__d = ::VSIVOTKind_frabasis;
 
     if ( !isSet )
        {
            _uneVariable_ = new MaClasse;
            isSet = 1;
        }
 
*(_uneVariable_) = IT_member;

En gros, il appelle lui même son propre destructeur, puis il appelle la fonction memset, qui fixe à 0 la plage libérée. OK.

Ensuite, il se reconstruit à la volée.

C'est assez rare de voir çà. Qu'en pensez vous? Ce code a été fait à mon avis par quelqu'un d'expérimenté, donc je ne critique pas à priori.
Mais j'aimerais savoir ce que vous en pensez, quels sont les cas dans lesquels on a besoin de faire ca.

merci

[DonQuiche]

Ce code a été fait à mon avis par quelqu'un d'expérimenté, donc je ne critique pas à priori.

Je n'en suis pas si sûr. D'abord la présence d'une variable nommée "uneVariable" me fait lever les yeux au ciel et ensuite il vérifie la valeur de isSet alors que celle-ci ne peut être que fausse (si elle ne l'était pas à l'entrée de la fonction elle l'est dorénavant suite au memset). Enfin il assigne une nouvelle valeur au pointeur uneVariable sans détruire l'ancienne valeur qu'il venait juste d'instancier, ce qui crée une fuite mémoire.

Maintenant, concernant l'appel explicite au destructeur, pourquoi pas s'il s'agit de nettoyer la classe afin de la recycler. L'appel à memset ne fait que réinitialiser les champs que le destructeur n'avait aucune raison de nettoyer.

EDIT: boulette

[deubelte]

Je n'en suis pas si sûr. D'abord la présence d'une variable nommée "uneVariable"

j'ai oublié de précisé que c'est moi qui a modifié les noms. En vrai, ca s'appelle pas comme ca.

[deubelte]

Comme il déréférence, il me semble que c'est plutôt une assignation.

Exactement. Il alloue une plage mémoire dont l'adresse est récupérée dans uneVariable, puis il fait appel à l'operateu =.

Un appel explicite au destructeur + memset semble plutôt tordu, de fait.

Pq?

Après tout pourquoi ne pas avoir une fonction de nettoyage, qu'on peut appeler du destructeur et de ce point de code?

Je sais pas, c'est pas moi qui a fait ce code.

[therwald]

Un appel explicite au destructeur + memset semble plutôt tordu, de fait.

Pq?

Parce que dans l'utilisation, normale, un appel destructeur se fait implicitement à la suite de la fin de vie de l'objet (sortie de scope d'un objet local, appel à l'opérateur delete). On peut torturer le système mais comme le montre ton étonnement ce n'est pas une manière très claire de coder...

Je sais pas, c'est pas moi qui a fait ce code.

Ma question était réthorique, c'était une manière de présenter ce qui me semblerait un codage plus propre de cette réinitialisation de l'objet.

[deubelte]

Parce que dans l'utilisation, normale, un appel destructeur se fait implicitement à la suite de la fin de vie de l'objet (sortie de scope d'un objet local, appel à l'opérateur delete). On peut torturer le système mais comme le montre ton étonnement ce n'est pas une manière très claire de coder...

Indépendamment de savoir si c'est bien ou pas bien, je voudrais savoir ce qui a amené le developpeur à faire ceci. En gros, que fait la fonction UneFonction. Pour moi, elle consiste à virer l'information qui se trouve dans la plage mémoire pointée par this, puis en renseigner dans la même plage mémoire l'information contenue dans IT_member.

[therwald]

Enfin il assigne une nouvelle valeur au pointeur uneVariable sans détruire l'ancienne valeur qu'il venait juste d'instancier, ce qui crée une fuite mémoire.

Comme il déréférence, il me semble que c'est plutôt une assignation. Un appel explicite au destructeur + memset semble plutôt tordu, de fait. Après tout pourquoi ne pas avoir une fonction de nettoyage, qu'on peut appeler du destructeur et de ce point de code?

[DonQuiche]

Comme il déréférence, il me semble que c'est plutôt une assignation.

Oups, oui, en effet, au temps pour moi.