Discussion :

[Lavock]

Cf. Le principe que je viens d'évoquer. En gros, il y a des cas ou oui, il est plus intéressant de faire leaké du code... Pour de la programmation kernel, c'est invraisemblable, pour de l'applicatif, ça dépend. Et encore, c'est sans compter sur les poolers, et la perte de perf du au cache-fault.

Après, il font compté aussi sur les poolers, rendant moins lourdes les opérations d'allocation et de désallocations. Heureusement que il temporisent un peu les demande à l'OS...

Ensuite, le temps gagné en évitant les cache-faults et presque aussi long que le temps perdu en désalocation/reallocation... Et le meilleur moyen de les éviter reste encore de grouper la mémoire, donc de la désallouer le plus souvent possible.

Au final, le LLTINT et généralement préférable quand il n'y a effectivement pas de lendemain...

D'ailleurs, suite à ta remarque et à ton "incontinence" mémoire, je te conseil de tester les codes suivants :

Code :

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

1
2
3
 
for(int i=0; i<1000000; ++i)
   char* ptr = new char[10];

et

Code :

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

1
2
3
4
5
 
for(int i=0; i<1000000; ++i) {
   char* ptr = new char[10];
   delete [] ptr;
}

Après, faire un calloc alors qu'on en a pas besoin, c'est stupide, c'est vrai.

A la question : pourquoi l'OS met la mémoire à 0 ? J'aurais dit pour des raisons de sécurité, mais je ne suis pas spécialiste.

[JolyLoic]

Laisser des objets dans une zone non utilisée n'est pas un gain de temps ?

Ca dépend de quels objets on parle. S'il s'agit d'entiers, pourquoi pas. Mais maintenant, s'il s'agit de données qui on un pointeurs vers une grosse zone de mémoire, sans libérer ces objets, cette mémoire annexe ne serait pas libérée. Si ces objets maintiennent ouvert un fichier, ces fichiers ne seront pas fermés...

En gros, si les objets ont un destructeur, il vaut mieux appeler ce dernier quand on fait clear. Certaines personnes ont proposer de détecter ce genre de situation à la compilation, pour faire des raccourcis dans la gestion d'objets n'ayant pas de destructeur.

[Lenoa]

@Lavock: Tu parles bien de la même chose que moi là ? Parce que en fait c'est juste laisser des objets "non pointés", c'est-à-dire pointés mais dont la valeur n'est plus accessible, et qui vont bien être détruits. Du coup, ton exemple ne marche pas (enfin une victoire )

@JolyLoic: Alors faire deux versions (template et spécialisée types de base) ?
Exemple (beaucoup simplifié ) :

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
 
template<typename T> class vector_base
{
protected:
  T* begin_, last_, end_;
public:
  ~vector_base() { delete_(begin_, last_); /* detruit de begin_ a last_ */ }
  // ...
};
template<typename T> class vector_deleting : private vector_base<T>
{
public:
  using vector_base; // Pas sur
  void clear()
  {
    while(last_ != begin_)
    {
      --last_;
      delete last_;
    }
    delete begin_; // OU delete last_
  }
};
 
template<typename T> class vector_not_deleting : private vector_base<T>
{
public:
  using vector_base; // Pas sur
  void clear()
  {
    last_ = begin_;
  }
};
 
template<typename T> class vector : private vector_deleting
{
  public:
    using vector_deleting; // Pas sur ...
};
class vector<short> : private vector_not_deleting
{
  public:
    using vector_not_deleting; // Pas sur ...
};
class vector<unsigned short> : private vector_not_deleting
{
  public:
    using vector_not_deleting; // Pas sur ...
};
class vector<int> : private vector_not_deleting
{
  public:
    using vector_not_deleting; // Pas sur ...
};
class vector<unsigned int> : private vector_not_deleting
{
  public:
    using vector_not_deleting; // Pas sur ...
};
class vector<long> : private vector_not_deleting
{
  public:
    using vector_not_deleting; // Pas sur ...
};
// ...

[Lavock]

Hum, je me disais bien que j'avais louper quelque chose...
...
...
+1 >< !

[edit]

@Lavock: Tu parles bien de la même chose que moi là ? ... enfin une victoire

=> M'enfin ta pas relever lorsque je parlais de leak au début !

[Lenoa]

Message 1 : +1 à qui ? Et j'avais pas fait gaffe au mot leak
Message 2 : Je n'ai montré qu'un code très (très (très (très (très)))) grossier

[Lavock]

Jolyloic. J'ai "posté" en même temps que toi.

Oui, d'ailleur j'ai supprimé le message... So-useless je me suis dit >< !

[Arzar]

Lenoa, la lib c++ de VS2008 fait déjà ce que tu proposes.
vector::clear() est implémentée sous la forme :

Code :

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

1
2
3
4
5
 
void clear()
{	// erase all
   erase(begin(), end());
}

Avec erase :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
iterator erase(const_iterator _First_arg,
   const_iterator _Last_arg)
{	// erase [_First, _Last)
   iterator _First = _Make_iter(_First_arg);
   iterator _Last = _Make_iter(_Last_arg);
 
   if (_First != _Last)
   {	
      _Destroy(_Ptr, _Mylast);
     _Mylast = _Ptr;
   }
}

Destroy possède deux versions, une pour les types de base (int, double...) qui ne fait rien :

Code :

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

1
2
3
4
5
6
7
 
template<class _Alloc> inline
void _Destroy_range(typename _Alloc::pointer _First,
typename _Alloc::pointer _Last, _Alloc& _Al,
_Scalar_ptr_iterator_tag)
{	// destroy [_First, _Last), scalar type (do nothing)
}

Et une deuxième pour tous les autres types, qui appelle le destructeur de chaque objet du conteneur.

Code :

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

1
2
3
4
5
6
7
8
9
 
template<class _Alloc> inline
void _Destroy_range(typename _Alloc::pointer _First,
typename _Alloc::pointer _Last, _Alloc& _Al,
_Nonscalar_ptr_iterator_tag)
{	// destroy [_First, _Last), arbitrary type
   for (; _First != _Last; ++_First)
      _Al.destroy(_First);
}

[Lenoa]

@Lavock: On est d'accord
@Arzar: Bien, mais pourquoi c'est pas dans la norme ? C'est çà que je demande

[JolyLoic]

C'est une question de qualité d'implémentation. Ne pas forcer tous les gens à le faire, mais le permettre quand même, pour les gens qui ont envie de faire un effort supplémentaire.