Discussion :

[dj.motte]

Bonjour,

Je demande si la STL avec ses avantages supposées ne fabrique pas une machine à gérer des objets, mais moins des pointeurs sur ces objets.

Par exemple pour gérer un "vector" de type pointeur sur T ( T*) il faut faire du code supplémentaire et ennuyeux et parfois sans succès.

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
 
#include  <iostream>
#include  <vector>
using namespace std ;
void do1()
{
   vector < double * > v ;
 
   for ( size_t i = 0 ; i < 16 ; i++ )
   { 
     double * z = new double( 1 + (i) * 10) ;
     v.push_back( z  )  ;
   }
   cout << v  ;
 
   // pour supprimer 
   delete v[2] ;  // ajouté sinon caca
   v.erase( v.begin() + 2 ) ;
 
   double * x1 = new double(-100.005) ;
   v.insert( v.begin() + 6, x1 ) ;  // ok 
 
   // pour réduire le vecteur
   for( size_t i = 7 ; i < v.size(); i++ )  //ajouté sinon caca
   delete v[i];
   v.resize(7);
 
   // pour affecter
   double * x2 = new double( -1 ) ;
   delete v[1]; // ajouté sinon caca
   v[1] = x2 ;
 
   // alors ce qui suit c'est la catastrophe 
   // fill( v.begin(), v.end(), x2 ) ;
   cout << v ;
 
   // Enfin le Chorus final 
   for( size_t i = 0 ; i < v.size() ; i++)
   delete v[i];
}
 
int main()
{
  do1() ;
  return 0 ;
}

Evidemment pour maintenir la stabilité du code des concepteurs les utilisateurs doivent faire des efforts.

Pour le pointeur sur T faut-il s'en remettre au magique pointeur ?

Salut.

[Matthieu Brucher]

Pour le pointeur sur T faut-il s'en remettre au magique pointeur ?

Pointeurs intelligents ? Oui. Ou à un boost::ptr_vector.

[loufoque]

Ton code plus haut n'est pas exception-safe.

Tu peux avoir un vecteur de pointeurs, mais dans ce cas, il contient seulement des adresses. Si tu veux que le vecteur soit responsable de la durée de vie des objets pointés, faut utiliser autre chose...

[dj.motte]

Ton code plus haut n'est pas exception-safe.

Tu peux avoir un vecteur de pointeurs, mais dans ce cas, il contient seulement des adresses. Si tu veux que le vecteur soit responsable de la durée de vie des objets pointés, faut utiliser autre chose...

Mouais pas terrible le vector de pointeurs. Il faudrait utiliser quoi au juste ?

salut.

[Matthieu Brucher]

Pointeurs intelligents ? Oui. Ou à un boost::ptr_vector.

Mouais pas terrible le vector de pointeurs. Il faudrait utiliser quoi au juste ?

Réponse dans le texte.

[dj.motte]

Réponse dans le texte.

C'est bien ce que je pensais. Le std::vector c'est à usage finalement assez naïf. C'est simple tant que l'on est sur le type T. Après il faut des prothèses pour y arriver.

Et boost::ptr_vector ça fait partie de la STL ?

[JolyLoic]

Je ne suis pas d'accord avec ce point de vue. Un vector est une méthode de stockage. Il est fait avant tout pour stocker des objets (et je ne vois pas ce qu'il y a de "naïf" là dedans. Dans de nombreux cas, c'est pile poil ce que je veux faire).

Il peut aussi très bien stocker des pointeurs, mais il ne fera que ça que ça. Les stocker sans pour autant interférer avec le durée de vie des objets pointés. Et heureusement, d'ailleurs, car il y aurait autant de cas où cette interférence poserait problème que de cas où elle ferait ce qu'il faut (objets partagés entre plusieurs conteneur, pointeur sur un objet non alloué dynamiquement,...).

Maintenant, si on veut avoir une gestion de la durée de vie d'objets pointés, c'est justement le rôle de smart pointeurs. Un vector<shared_ptr<T>> ou un vector<unique_ptr<T>> ou autre permet de croiser tous les types de gestion de durée de vie avec vector ou un autre conteneur. Ce design orthogonal me semble un design intéressant.

boost::ptr_vector ne fait pas partie de la STL. Je ne pense pas qu'il lui sera intégré un jour, je n'ai vu aucune proposition en ce sens. Ca fait longtemps que je n'ai pas regardé, mais je ne vois pas a priori ce qu'il apporte par rapport à vector<unique_ptr> (sauf que ce dernier n'existe pas encore forcément, il est assez récent, mais là on parle en terme d'évolution du langage).

[dj.motte]

Bonjour

JolyLoic écrit :

boost::ptr_vector ne fait pas partie de la STL. Je ne pense pas qu'il lui sera intégré un jour, je n'ai vu aucune proposition en ce sens. Ca fait longtemps que je n'ai pas regardé, mais je ne vois pas a priori ce qu'il apporte par rapport à vector<unique_ptr> (sauf que ce dernier n'existe pas encore forcément, il est assez récent, mais là on parle en terme d'évolution du langage).

Eh oui c'est tout le problème. boost::ptr_vector ne fait pas partie de la STL.
Maintenant on pouvait légitimement penser que le std;;vector soit à même de gérer des pointeurs, où du moins pare à cette éventualité de manière propre.
Avec un type pointeur certains constructeurs du std::vector
provoque un plantage regrettable.

De plus l'utilisation de pointeurs est souvent nécessaire pour faire jouer le polymorphisme. Cette idée de vouloir éradiquer l'utilisation de pointeurs ne me semble pas adaptée à la spécificité du C++.

Il me parait finalement plus logique de faire deux implémentations : une pour le type T et l'autre pour le type T*. Evidemment ça devient volumineux...

[Matthieu Brucher]

Il me parait finalement plus logique de faire deux implémentations : une pour le type T et l'autre pour le type T*. Evidemment ça devient volumineux...

Non, si tu mets des objets par pointeurs dans un vecteur, ils peuvent être créé par valeur à un autre endroit, ou dans plusieurs vecteurs, ...

[Goten]

Bonjour

JolyLoic écrit :


Eh oui c'est tout le problème. boost::ptr_vector ne fait pas partie de la STL.
Maintenant on pouvait légitimement penser que le std;;vector soit à même de gérer des pointeurs, où du moins pare à cette éventualité de manière propre.
Avec un type pointeur certains constructeurs du std::vector
provoque un plantage regrettable.

De plus l'utilisation de pointeurs est souvent nécessaire pour faire jouer le polymorphisme. Cette idée de vouloir éradiquer l'utilisation de pointeurs ne me semble pas adaptée à la spécificité du C++.

Il me parait finalement plus logique de faire deux implémentations : une pour le type T et l'autre pour le type T*. Evidemment ça devient volumineux...

Pour le polimorphisme les pointeurs intelligent sont là aussi. Pour vector ils t'on donné la solution au dessus.

Eradiquer les pointeurs en C++ est vraiment le point important. On dit bien que un pointeur est toujours un pointeur de trop (je parle de pointeur brut) car ils entrainent trop de soucis de gestion.

[dj.motte]

Non, si tu mets des objets par pointeurs dans un vecteur, ils peuvent être créé par valeur à un autre endroit, ou dans plusieurs vecteurs, ...

Bof je ne comprends pas bien cette découverte. Je ne vois aucun inconvénient à ce que le vecteur possède les pointeurs en laissant en plus à l'utilisateur la possibilité de décider de leurs sorts. La solution la plus riche est sans doute la meilleure mais implique un surcout d'implémentation.

[Matthieu Brucher]

Bof je ne comprends pas bien cette découverte. Je ne vois aucun inconvénient à ce que le vecteur possède les pointeurs en laissant en plus à l'utilisateur la possibilité de décider de leurs sorts. La solution la plus riche est sans doute la meilleure mais implique un surcout d'implémentation.

D'où la possibilité d'avoir plusieurs implémentations dépendant de vector<> pour faire différentes choses.

[dj.motte]

Salut,

Goten écrit :

Eradiquer les pointeurs en C++ est vraiment le point important. On dit bien que un pointeur est toujours un pointeur de trop (je parle de pointeur brut) car ils entrainent trop de soucis de gestion.

Cela me paraît bien naïf. Moi ça ne gêne pas d'avoir à gérer des pointeurs. Ils ne sont pas si méchants que cela.

[JolyLoic]

J'ai l'impression qu'on tourne en rond...

Tu pars du point que gérer des pointeurs nus n'est pas une mauvaise pratique, mais comme un vecteur de pointeurs nus ne les gère pas comme tu veux, il y a un problème avec les vecteurs, ils devraient avoir une surcharge pour T*.

Je pars dans l'autre sens. C'est le rôle des pointeurs intelligents de gérer les données pointées, selon le mode que l'on a en tête. Les vecteurs acceptent des pointeurs intelligents, donc il n'y a pas de problème avec les vecteurs.

Le gros problème que je vois dans ton raisonnement, c'est qu'il n'y a pas 1 façon de gérer les pointeurs, mais des tas. Or on ne peut faire qu'une seule surcharge de vector sur T*. Quel devrait être son comportement ? Devrait-elle se comporter comme un vector<unique_ptr<T>> (je suis seul à posséder les objets pointés), comme un vector<shared_ptr<T>> (on peut être plusieurs à posséder les objets pointés), comme un vector<weak_ptr<T>> (je ne possède pas les objets pointés, ils sont gérés de manière partagée par quelqu'un d'autre que moi), un vector<ClonePtr<T>> (mes objets ont une sémantique de valeur), un ...

Quel que soit le choix fait, il aurait de graves problèmes. Tu semble proposer l'équivalent moral de vector<unique_ptr<T>>, avec une destruction des objets pointés quand on détruit le vecteur. Comment dans ce cas je peux gérer :

Code :

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

1
2
vector<Eleve *> touteLaClasse;
vector<Eleve *> redoublants;

Une surcharge de vector comme tu la proposes serait inutilisable dans ce cas.

Après, si on a N modes de gestion des objets pointés, et M types de conteneurs différents, on peut développer N*M classes (c'est l'approche boost::ptr_vector), mais c'est lourd, et non évolutif.

Avec la solution par pointeurs intelligents, on développe seulement N pointeurs intelligents, M conteneurs, et on peut les croiser dans tous les sens, et mettre un pointeur intelligent développé par A dans un conteneur développé par B sans que A et B n'aient jamais eu à se rencontrer.

Une autre solution serait de développer des classes conteneurs avec un paramètre template indiquant sous forme de policy le mode de gestion des objets pointés. Mais cette policy ressemblerait en fait fortement à un smart pointer, et comme le smart pointer a aussi de la valeur en dehors des collections, autant l'utiliser directement.

[CedricMocquillon]

Moi ce que je trouve dommage avec les conteneurs, c'est qu'il n'y a pas de distinction entre le conteneur et le contenu:
ce code ne compile pas

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
 
#include <vector>
#include <algorithm>
#include <iostream>
 
class A
{
private:
  std::vector<int> m_vect;
 
public:
  A(std::vector<int> const& init) : m_vect(init) {}
 
  std::vector<int> const& f() const throw() { return m_vect; }
};
 
int main(void)
{
  int i = 0;
  std::vector<int> l_vect(10);
  for (i=0; i<10; ++i)
    l_vect[i] = i;
 
  A a(l_vect);
  a.f().front() = 0;
 
  return 0;
}

alors que c'est le conteneur que je souhaiterai constant et non son contenu (donc par exemple, pas de possibilité de faire des push_back mais par contre pouvoir modifier ses éléments). Il faut donc passer par le code suivant:

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
 
#include <vector>
#include <algorithm>
#include <iostream>
 
class B
{
private:
  std::vector<int*> m_vect;
 
public:
  B(std::vector<int*> const& init) : m_vect(init) {}
 
  std::vector<int*> const& f() const throw() { return m_vect; }
};
 
 
int main(void)
{
  int i = 0;
  std::vector<int*> l_vect(10);
  for (i=0; i<10; ++i)
    l_vect[i] = new int(i);
 
  B b(l_vect);
  *(b.f().front()) = 100;
  std::cout << *(l_vect[0]) << std::endl;
 
  return 0;
}

Cette fois-ci ça compile. J'avais cependant lu il me semble sur ce forum que cela allait évoluer avec la nouvelle norme qui impliquerait alors que les vecteurs de pointeurs constant interdirait alors la modification des éléments pointés (j'espère que ce ne sera pas le cas car il y aura alors complète assimilation entre le conteneur et le contenu qui sont pourtant deux concepts différents)

[white_tentacle]

En fait, c'est un problème de définition de la constance.

Il me semble raisonnable de dire que si j'appelle une fonction f qui prend un const T& en paramètre, alors, je suis sûr que :

Code :

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

1
2
3
4
T t1;
T t2 = t1;
f(t2);
t2 == t1

Tout autre comportement me semblerait déraisonnable.

Pour ton problème, je pense que passer par un wrapper qui ne fournit que l'interface dont tu as besoin est la meilleure solution (avec des templates, ceci peut être fait simplement pour tous les containers, et avec les concepts de C++0x, encore mieux).

[dj.motte]

Bonjour,

Tu pars du point que gérer des pointeurs nus n'est pas une mauvaise pratique, mais comme un vecteur de pointeurs nus ne les gère pas comme tu veux, il y a un problème avec les vecteurs, ils devraient avoir une surcharge pour T*.

Non. Je vais jusqu'à penser qu'il devrait y avoir deux types d'implémentation pour un conteneur.

La première reste std::vector.
La seconde serait i_vector gérant le type T* .

Pour i_vector on aurait :

Code :

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

1
2
3
4
5
6
 
template < typename T >
class i_vector
{ T ** g_data ;
   ...
};

Ainsi pour gérer vecteur sur type T :
vector< eleve > v ;
et pour le T* :
i_vector< eleve > v ;

Mais bon ça fait beaucoup de code supplémentaire, appliqué à tous les conteneurs de la STL.

Je me souviens qu'à l'époque Borland avait développé des classes conteneurs qui permettaient cette différence entre T et T*.

Pour ce qui est des boost pointeurs je ne me prononce pas ce n'est pas la STL. Mais comme avancé cela pourrait faire partie de la STL dans le futur.

[Médinoc]

Mais ensuite, comment détruit-on un eleve?
Comment le vector_i sait-il qu'il doit faire un delete, ou appeler une fonction DeleteEleve(), ou faire un Release() parce qu'il y a comptage de références, etc.?

Ce n'est pas au vector_i de savoir ça. C'est au pointeur intelligent que tu mets dans ton vector normal...

[JolyLoic]

Pour ce qui est des boost pointeurs je ne me prononce pas ce n'est pas la STL. Mais comme avancé cela pourrait faire partie de la STL dans le futur.

Les pointeurs intelligents de type shared_ptr et weak_ptr font déjà partie du TR1 du standard C++ (depuis 2005 sauf erreur de ma part, les compilateurs courant les fournissent tous désormais). Unique_ptr fera partie de la prochaine version, et demande les R-Value references pour être mis en place..

[loufoque]

La vraie solution c'est std::vector<std::unique_ptr<T>>
Sauf que ça, c'est du C++0x.

C'est pour ça qu'en C++03, tu as trois solutions :
- boost::ptr_vector<T>, la plus efficace
- std::vector<clone_ptr<T>>, la meilleure à mon goût (mais t'as intérêt à utiliser du COW si tu veux pas des performances desastreuses)
- std::vector<std::shared_ptr<T>>, qui change la sémantique des objets contenus.