Opérateur new[] et template

Version imprimable

Voir 40 message(s) de cette discussion en une page

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 ?

Voir 40 message(s) de cette discussion en une page