Opérateur new[] et template

**progfou** · 06/03/2007, 17h49

Bonsoir tout le monde !
J'alloue un tableau de template (je ne sais pas si ça se dit...) ainsi :

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

).
Comme je dois être bigleux, est-ce que l'un de vous voit l'erreur ?

Merci d'avance !

**roulious** · 06/03/2007, 18h16

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.

**loufoque** · 06/03/2007, 20h34

acquiert les ressources dans le constructeur et libère les dans le destructeur.

**progfou** · 06/03/2007, 23h07

Peux-tu détailler ?
Je ne comprends pas trop...

**roulious** · 06/03/2007, 23h13

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.

**progfou** · 07/03/2007, 09h10

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

Merci !

**progfou** · 07/03/2007, 09h39

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

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

**Patriarch24** · 07/03/2007, 09h47

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.

**progfou** · 07/03/2007, 10h04

J'explique dans le détail, dans le code, je vais avoir, par exemple, une déclaration dans un header, typiquement :

Code :

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

class QuelqueChose : public DynBuf<Truc>

Et une instanciation de type :

Code :

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

QuelqueChose tableau[2];

Dans une autre classe.

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

Code :

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

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

**Patriarch24** · 07/03/2007, 11h25

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

Code :

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

QuelqueChose* tableau[2];

**progfou** · 07/03/2007, 11h38

Mmh, pour le pointeur, ça ne me parle guère

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

**Laurent Gomila** · 07/03/2007, 12h03

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

Code :

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

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 ?

**Jean-Marc.Bourguet** · 07/03/2007, 13h40

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.

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

Mystere en effet.

**progfou** · 07/03/2007, 14h25

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 !

**Laurent Gomila** · 07/03/2007, 14h30

Est-ce que tu appelles bien uninit() ? Est-ce que tu ne pourrais pas appeler uninit() dans le destructeur au cas où tu oublierais ?

**Médinoc** · 07/03/2007, 14h31

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

**progfou** · 07/03/2007, 14h34

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

.

**progfou** · 07/03/2007, 15h00

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 ?