Opérateur new[] et template

Version imprimable

Bonsoir tout le monde !
J'alloue un tableau de template (je ne sais pas si ça se dit...) ainsi :
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 template<class T> class DynBuf { public: DynBuf(): m_uiBufferSize(0), m_pT(NULL) {} ErrVal init( UInt uiBufferSize ) { ROT( NULL != m_pT ); m_pT = new T [ uiBufferSize ]; ROT( NULL == m_pT ); m_uiBufferSize = uiBufferSize; return Err::m_nOK; } ErrVal uninit() { if(NULL != m_pT ) { delete [] m_pT; m_pT = NULL; } m_uiBufferSize = 0; return Err::m_nOK; } etc.
J'ai utilisé un détecteur de fuites mémoire, et il me dit que l'allocation faite avec le new pose problème (il ne me dit pas ce qui ne va pas :aie: ).
Comme je dois être bigleux, est-ce que l'un de vous voit l'erreur ?

Merci d'avance !

06/03/2007, 18h16
roulious

Tu as une fuite de mémoire possible si tu appelles init deux fois de suite : dans ce cas, l'adresse du bloc précédemment alloué est perdue.
06/03/2007, 20h34
loufoque

acquiert les ressources dans le constructeur et libère les dans le destructeur.
06/03/2007, 23h07
progfou

Peux-tu détailler ?
Je ne comprends pas trop... :aie:
06/03/2007, 23h13
roulious

Il pense à l'idiome du RAII. La mémoire est allouée dans le constructeur et libérée dans le destructeur, ce qui te garantit une gestion correcte et pas de fuite.
07/03/2007, 09h10
progfou

Ca suppose que je change tout le code...
Effectivement, ce serait nettement meilleur !
Je vais regarder ça.

Merci !

Bon, j'ai beau tourner et retourner ça dans tous les sens, je ne vois pas comment modifier ma classe...

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
template<class T>
class DynBuf
{
public:
  DynBuf(): m_uiBufferSize(0), m_pT(NULL) {}
 
  ErrVal init( UInt uiBufferSize )
  {
    ROT( NULL != m_pT );
    m_pT = new T [ uiBufferSize ];
    ROT( NULL == m_pT );
    m_uiBufferSize = uiBufferSize;
    return Err::m_nOK;
  }
 
  ErrVal uninit()
  {
    if(NULL != m_pT )
    {
    delete [] m_pT;
    m_pT = NULL;
    }
    m_uiBufferSize = 0;
 
    return Err::m_nOK;
  }
 
  T& get( UInt uiOffset ) const
  {
    AOT_DBG(uiOffset >= m_uiBufferSize);
    return m_pT[uiOffset];
  }
 
  Void set( UInt uiOffset, T t )
  {
    AOT_DBG(uiOffset >= m_uiBufferSize);
    m_pT[uiOffset] = t;
  }
 
  Void setAll( const T& rcT )
  {
    for( UInt n = 0; n < m_uiBufferSize; n++ )
    {
      m_pT[n] = rcT;
    }
  }
 
  T& operator[] (const UInt uiOffset)
  {
    AOT_DBG(uiOffset >= m_uiBufferSize);
    return m_pT[uiOffset];
  }
 
  const T& operator[] (const UInt uiOffset) const
  {
    AOT_DBG(uiOffset >= m_uiBufferSize);
    return m_pT[uiOffset];
  }
 
  Void clear()
  {
    ::memset( m_pT, 0, sizeof(T) * m_uiBufferSize );
  }
 
  UInt size() const
  {
    return m_uiBufferSize;
  }
 
protected:
  UInt m_uiBufferSize;
  T*   m_pT;
};

L'inconvénient, c'est que j'ai des dizaines d'appels utilisant init()...
J'aimerais avoir le moins de modifications possibles...

07/03/2007, 09h47
Patriarch24

Tes fonctions init et uninit sont des codes de constructeur/destructeur respectivement. Déplace donc ce code dans le constructeur/destructeur de ta classe.
Et si tu veux éviter de changer le reste du code (ce qui à mon avis n'est pas une bonne idée...), tu peux laisser les fonctions init et uninit qui ne feront que retourner la valeur ok.
07/03/2007, 10h04
progfou
J'explique dans le détail, dans le code, je vais avoir, par exemple, une déclaration dans un header, typiquement :

Code:

class QuelqueChose : public DynBuf<Truc>

Et une instanciation de type :

Code:

QuelqueChose tableau[2];

Dans une autre classe.

L'appel à init se fait alors, dans le code :
Code:

1 2 tableau[0].init( UneTaille); tableau[1].init( UneAutreTaille);
Mon problème est donné, si je modifie le constructeur, il ne connaitra pas la taille à passer (aujourd'hui dans init)...
07/03/2007, 11h25
Patriarch24

Si tu veux différer la construction et connaître la taille, utilise des pointeurs :

Code:

QuelqueChose* tableau[2];
07/03/2007, 11h38
progfou

Mmh, pour le pointeur, ça ne me parle guère :aie: .
Je ne vois pas pourquoi ça diffère la construction ??

Si j'utilise ce pointeur, dans le code, là où on appelle init() actuellement, comment je fais appel au constructeur ?
07/03/2007, 12h03
Laurent Gomila

Citation:

Si j'utilise ce pointeur, dans le code, là où on appelle init() actuellement, comment je fais appel au constructeur ?

Code:

Tableau[0] = new QuelqueChose(...parametres...);

Mais bon, c'est pas forcément la meilleure solution non plus. Autant faire une classe de tableaux qui puisse se construire par défaut puis se redimensionner.

Il y a une raison pour laquelle tu n'utilises pas std::vector ?
07/03/2007, 13h40
Jean-Marc.Bourguet

Citation:

Envoyé par Laurent Gomila

Autant faire une classe de tableaux qui puisse se construire par défaut puis se redimensionner.

C'est presque ce qu'il a. Je ne comprends pas que ses assertions (en supposant que les ROT en soit, sinon qu'est-ce) ne se declanchent pas si il y a une mauvaise utilisation.

Citation:

Il y a une raison pour laquelle tu n'utilises pas std::vector ?

Mystere en effet.
07/03/2007, 14h25
progfou

Citation:

Il y a une raison pour laquelle tu n'utilises pas std::vector ?

Oui, le code ne doit pas utiliser cette classe (raisons plus profondes que j'ignore, on m'a juste dit de ne pas le faire).

Les ROT() sont bien sûr des assertions :).
Edit: les assertions ne se déclenchent pas, mais j'ai quand même une fuite mémoire.
Ne connaissant pas bien les outils de profiling mémoire, j'ai utilisé "deleaker" sous visual studio, qui m'en indique une au new correspondant au code que j'ai mis ici.
Si vous connaissez un outil qui sache faire cela bien (windows ou linux), je prends !
07/03/2007, 14h30
Laurent Gomila

Est-ce que tu appelles bien uninit() ? Est-ce que tu ne pourrais pas appeler uninit() dans le destructeur au cas où tu oublierais ?
07/03/2007, 14h31
Médinoc

Ça ressemble plutôt à des anti-assertions : Vu l'utilisation qui en est faite, il semblerait qu'elles gueulent si l'expression est vraie.
07/03/2007, 14h34
progfou

Je viens de créer un destructeur avec un delete[] au cas où :).
Je vais tester.

Quand aux assertions, il y en a de toutes sorte ;).
07/03/2007, 15h00
progfou

Suite au test, le destructeur est appelé correctement, les appels aboutissent à une sortie sans delete[], donc erreur de la part de l'outil de profiling ?
07/03/2007, 15h21
loufoque

Citation:

Envoyé par Patriarch24

Si tu veux différer la construction et connaître la taille, utilise des pointeurs :

Code:

QuelqueChose* tableau[2];

Pas besoin de pointeur ou d'allocation dynamique pour différer la construction.
07/03/2007, 15h24
progfou

Si tu pouvais détailler ?
07/03/2007, 18h04
loufoque

Je vois pas trop ce qu'il y a à détailler.
Pour différer la construction il suffit d'appeler le constructeur sur une zone mémoire brute, qui peut très bien être allouée sur la pile par exemple.

Ce qui signifie alors qu'il ne faut appeler le destructeur explicitement et que si le constructeur a bien été appelé etc. On a d'ailleurs les mêmes problèmes avec l'allocation dynamique.
On peut fortement limiter ces problèmes on enveloppant ça dans une classe qui utilise en plus un booléen pour savoir si la mémoire est initialisée ou pas. C'est ce qu'est boost.optional.

De toutes manières, tu ne devrais pas avoir à différer la construction. Ici le problème c'est parce que tu utilises des tableaux. Utilise std::vector à la place et plus de problème.
07/03/2007, 18h11
progfou

Je ne peux pas utiliser std::vector, il faut lire !
08/03/2007, 09h57
Patriarch24

Citation:

Je vois pas trop ce qu'il y a à détailler.
Pour différer la construction il suffit d'appeler le constructeur sur une zone mémoire brute, qui peut très bien être allouée sur la pile par exemple.

Ce qui signifie alors qu'il ne faut appeler le destructeur explicitement et que si le constructeur a bien été appelé etc.

Ca s'appelle un placement new. Je ne vois pas vraiment l'intérêt d'utiliser cette technique dans du code en dehors de l'écriture d'un allocateur.

Citation:

On a d'ailleurs les mêmes problèmes avec l'allocation dynamique.

Quels problèmes ? Celui d'appeler explicitement le destructeur ? Cette solution est complexe et fortement sujette à erreurs (notamment parce qu'on oblige à appeler le destructeur explicitement, ce qui n'est pas vraiment naturel).

Citation:

On peut fortement limiter ces problèmes on enveloppant ça dans une classe qui utilise en plus un booléen pour savoir si la mémoire est initialisée ou pas. C'est ce qu'est boost.optional.

On peut aussi lever des exceptions depuis les constructeurs pour signifier que quelque chose s'est mal passé.

Citation:

De toutes manières, tu ne devrais pas avoir à différer la construction. Ici le problème c'est parce que tu utilises des tableaux. Utilise std::vector à la place et plus de problème.

Absolument d'accord. J'aimerais aussi comprendre pourquoi cette restriction sur l'utilisation de std::vector...
08/03/2007, 10h17
progfou

La question du std::vector est (apparemment, moi je ne fais que faire ce que l'on me demande) une raison de portabilité du code.
08/03/2007, 10h51
Patriarch24

Portabilité ? Mais c'est standard ! Donc ça devrait être portable !!
08/03/2007, 11h08
progfou

Par curiosité, comment changer le code pour utiliser std::vector ?
Et puis, si je veux faire passer l'idée, il me faut argumenter (et sec !), donc prouver que c'est mieux, et expliquer que ça fonctionnera dans tous les cas...
08/03/2007, 11h13
Patriarch24
C'est simple :
Code:

1 2 std::vector<QuelqueChose> v; v.push_back(QuelqueChose(/*...*/));//ajoute un élément en fin de vecteur
Les vecteurs sont des tableaux dynamiques (ce qui permet de ne pas avoir à connaître leur taille par avance). On peut utiliser tous les algorithmes standards dessus (voir l'entête algorithm), ce qui évite de réinventer la roue, et son utilisation est parfaitement semblable à celle des tableaux (accès aux éléments via l'opérateur [] notamment, ou par la fonction at pour checker les bornes).

Pour plus d'informations, il vaut mieux lire la doc dessus (ici par exemple).
08/03/2007, 11h21
progfou

Dans mon cas, j'ai :

Code:

QuelqueChose tableau[2];

Je peux écrire :

Code:

std::vector<QuelqueChose> tableau[2];

?

Du coup, je conserve mes delete ?
Qu'est-ce que ça change concrètement quand à ma classe ?
08/03/2007, 11h31
poukill

Code:

std::vector<QuelqueChose> tableau;

suffit

Les méthodes pour rajouter des éléments sont:
push_back() : vers la fin
push_front() : au début
insert() : ou tu veux (moins rapide)

Après, tu peux réserver de la mémoire si tu veux, mais ce n'est pas nécessaire, avec la méthode reserve();

Voilà! :D
08/03/2007, 11h31
Patriarch24

Citation:

std::vector<QuelqueChose> tableau[2];

Non juste :

Citation:

std::vector<QuelqueChose> tableau;

Si tu veux réserver deux emplacements, tu fais :

Citation:

std::vector<QuelqueChose> tableau(2);

qui appelle le constructeur de std::vector en réservant deux emplacements.

Du coup, plus besoin d'appeler delete car le vector sera détruit en même temps que l'objet englobant. Attention cependant : si le vecteur contient des pointeurs, il faudra les détruire soit même (le conteneur n'a pas cette responsabilité).