Discussion :

[emmr.rida]

Bonjour,
J'ai une classe comme :

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
 
class foo
{
protected :
    wchar_t *buffer;
public :
    operator wchar_t *()
    {
         return buffer;
    }
};
...
wchar_t *buf = (wchar_t *)fooobj;
...
delete[] buf; //DANGER!

J'ai changé en const mais ça n'a pas empêcher l'exécution de delete[].
Je veux pas opter pour le retour d'un autre buffer car je vais oubliger les autres à faire un delete[] après chaque (wchar_t *)fooobj.

Merci

[3DArchi]

Bonjour,
1/Solution documentaire : retourner un const en indiquant dans le contrat de ta classe que l'adresse retournée ne peut être deleté. Par exemple, std::string.c_str() te retourne un char* mais je te déconseille vivement de faire un delete dessus.
2/Ne jamais renvoyer ton pointeur : les traitements devraient être dans foo ou une classe amie (donc de confiance) de foo.
3/Utiliser un pointeur intelligent pour que personne ne soit tenté de faire des delete.

[Médinoc]

Mais un pointeur intelligent possède déjà le même problème: Il n'empêche pas de faire un delete sur les données qu'il pointe.

Pour moi, la solution la plus évidente est la 1. La 2 est plus compliquée, mais peut-être meilleure à long-terme à moins qu'on ait besoin d'extensibilité.

Edit: Ou peut-être retourner un itérateur?

[3DArchi]

Mais un pointeur intelligent possède déjà le même problème: Il n'empêche pas de faire un delete sur les données qu'il pointe.

Effectivement. Mais d'une certaine façon tu n'as plus à faire à un pointeur mais à une valeur. Donc, tu n'es plus tenté par le delete.

Pour moi, la solution la plus évidente est la 1.

Et pas forcément la plus choquante, d'autant s'il s'agit de pouvoir injecter la donnée dans une interface C par exemple et auquel cas la 2 ne pourrait s'appliquer.

La 2 est plus compliquée, mais peut-être meilleure à long-terme à moins qu'on ait besoin d'extensibilité.

C'est clair. Elle permet surtout de masquer l'implémentation effective de buffer pour se concentrer sur le service de haut niveau proposé par foo.

[JolyLoic]

Et peut-être utiliser une fonction avec un nom explicite, plutôt qu'un opérateur de conversion, qui pourrait être appelé là où on ne veut pas.

[emmr.rida]

@ 3DArchi
Merci pour l'article. Très intéressent. C'est mon premier projet C++ depuis des années. Je voulais éviter l'utilisation des templates et autres structures de données complexes mais bon. Je crois que j'ai pas le choix.

@ JolyLoic
Je crois que delete[] obj.GetBuffer(); causera les mêmes problèmes.

[Médinoc]

Mais paraîtra peut-être plus suspect.

[3DArchi]

@ 3DArchi
Merci pour l'article. Très intéressent. C'est mon premier projet C++ depuis des années. Je voulais éviter l'utilisation des templates et autres structures de données complexes mais bon. Je crois que j'ai pas le choix.

Effectivement, et c'est même plutôt une bonne démarche que de s'intéresser à ces choses peut être un peu nouvelles pour toi mais indispensable pour réaliser du code C++ fiable.

@ JolyLoic
Je crois que delete[] obj.GetBuffer(); causera les mêmes problèmes.

Pour ce cas particulier, je pense que tu te poses un faux problème. Si tu as besoin d'exposer ton buffer, alors exposte le (en constant) et à charge de l'utilisateur de ta classe de ne pas faire de delete. C'est le contrat (de confiance) qui lie ta classe et ses clients. C'est une erreur d'être (trop) défensif par rapport à ce contrat.

[emmr.rida]

Exposer mon buffer pour des raisons d'utilisation de la bibliothèque standard pour affichage ou autre. L'autre altérnative qui est d'exposer une copie du buffer risque de générer des fuites de mémoire ainsi qu'une perte de performances surtout pour une classe qui est instanciée massivement durant l'exécution du programme.

[JolyLoic]

@ JolyLoic
Je crois que delete[] obj.GetBuffer(); causera les mêmes problèmes.

Oui, mais quelqu'un qui ferait delete[] obj.internalBuffer() ne serait pas simplement étourdi, mais mal intentionné...

[emmr.rida]

Oui c'est vrai, mais je préfére comme même ne pas prendre le risque de tomber dans ce cas et l'autre :

Code :

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

1
2
3
4
 
wchar_t *buffer = obj.GetBuffer();
...
delete[] buffer;

[Jean-Marc.Bourguet]

Si tu veux empêcher delete, n'expose pas le pointeur. Si tu exposes le pointeur, tu ne peux pas empêcher d'appliquer delete dessus.

Suivant la raison pour laquelle tu veux exposer le pointeur, tu peux encapsuler le résultat, mais si c'est pour des raisons de compatibilité avec des interfaces ayant besoin d'un pointeur, rien n'empêche ces fonctions de faire un delete quelque part.

[emmr.rida]

Oui, je voie.
Merci pour vos réponses.

[white_tentacle]

Est-ce que ça ne serait pas le cas typique d'utilisation d'un boost::weak_ptr ?

[Jean-Marc.Bourguet]

Est-ce que ça ne serait pas le cas typique d'utilisation d'un boost::weak_ptr ?

N'ayant aucune idée de pourquoi il faut obtenir un pointeur, j'ai du mal à voir s'il s'agit d'un cas où l'utilisation d'un weak_ptr est possible, sans parler de typique.

weak_ptr sert normalement quand on a des shared_ptr (donc quand la responsabilité de la durée de vie d'un objet est partagée, si on a des shared_ptr sans qu'il y ait partage de cette durée de vie, on est déjà dans de l'atypique) et qu'il faut conserver des pointeurs qui ne partagent pas la responsabilité de la durée de vie sans qu'on puisse être sûr que l'objet sera bien toujours valide.

[cynique]

Bonjour,
J'ai une classe comme :

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
 
class foo
{
protected :
    wchar_t *buffer;
public :
    operator wchar_t *()
    {
         return buffer;
    }
};
...
wchar_t *buf = (wchar_t *)fooobj;
...
delete[] buf; //DANGER!

J'ai changé en const mais ça n'a pas empêcher l'exécution de delete[].
Je veux pas opter pour le retour d'un autre buffer car je vais oubliger les autres à faire un delete[] après chaque (wchar_t *)fooobj.

Merci

Personne ne l'a fait, donc il faut que je te demande: Pourquoi est-ce que tu veux exposer le buffer?

C'est un tableau, alloué avec new [], et pour moi, ça dit que tu as besoin d'un "wchar_t operator [](int)" ou peut-être "wchar_t operator[](size_t)". Puis l'utilisateur peut faire:

Code :

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

1
2
3
4
5
6
 
  foo bar;
 
  // ...
 
  wchar_t ch = bar[1];

Si tu écris "wchar_t &operator [](size_t)", on peut faire:

Code :

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

1
2
3
4
5
6
 
  foo bar;
 
  // ...
 
  bar[2] = 'H';

Mais aussi:

Code :

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

1
2
3
4
5
6
 
  foo bar;
 
  // ...
 
  delete[] &foo[0];

Pour éviter ça:

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
20
21
22
23
24
25
26
27
28
29
30
31
 
  class foo
  {
    wchar_t *buffer;
  public:
    // ...
    class foo_gate
    {
      wchar_t &m_ch;
    public:
      foo_gate( wchar_t &the_char ) : m_ch(the_char) {}
      foo_gate &operator =( wchar_t new_char ) { m_ch = new_char; }
 
      operator wchar_t() { return m_ch; }
    };
 
    foo_gate operator[]( size_t index )
    {
      return foo_gate( buffer[index] );
    }
  };
 
  foo bar;
 
  // ...
 
  ch = bar[3];  // Note 1
 
  bar[4] = ch;  // Note 2
 
  wchar_t *p = &bar[0];  // Note 3

Note 1: ch = bar.operator[](3).operator wchar_t();

Note 2: bar.operator[](4).operator =(ch);

Note 3: Cette ligne ne compile pas parce que "&bar[0]" est un "foo::foo_gate *".

C'est possible que la performance soit un peu pire, mais un bon compilateur fixera ça.

Bonne Chance!

[emmr.rida]

J'ai besoin d'exposer le buffer pour des raisons d'affichages sur console à l'aides des fonctions de la bibliothèque standard et ça le temps de développer mes propres routines d'affichage prenant l'objet de la classe exposant le buffer (pour le moment!) comme paramètre et non pas le buffer interne lui même.
Concernant ta solution, je dois exposer le buffer tout entier et non pas les éléments wchar_t.

Merci.

[JolyLoic]

Mmm, tu veux pouvoir faire :

Code :

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

cout << maClasse << endl;

Si c'est bien ça, c'est tout simple à écrire, et ça t'évitera des soucis.

http://cpp.developpez.com/faq/cpp/?p...teur_affichage

Sinon, tu pourrais préciser ?

[emmr.rida]

Merci JolyLoic, l'article est très intéressant.

Ce que je peux comprendre à partir de cette discussion, c'est qu'il faut préviligier code fiable au lieu d'un code s'exécutant très vite exposant des pointeur vers des données internes d'une classe. Exemple :
Pour une classe qui gère une chaine de caractères, au lieux d'utiliser le constructeur acceptant un pointeur vers une chaine de caractères pour copier les objets du même type...

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
classe foo
{
    foo(wchar_t *str)
    {
        buffer = new wchar_t[wcslen(str)];
        wcscpy(buffer, str);
        ...
    }
    ...
    operator wchar_t *();
};

Utiliser un code un petit peu long mais fiable...

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
class foo
{
    foo(foo &f)
    {
         buffer = new wchar_t[foo.GetLength()];
         for(int i = 0; i < foo.GetLength(); i++) buffer[i] = foo[i];
         ...
    }
    ...
    wchar_t operator[](int index);
}

Merci les gars

[Médinoc]

Ils manquent cruellement de const, tes deux derniers codes...