Discussion :

[Alain Defrance]

J'ai créer une liste chainé qui permet ce type d'ecriture :

Code :

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

1
2
3
4
5
6
7
8
 
  CListe<int *> plop;
  plop += new int(5);
  plop += new int(14);
  plop += new int(30);
  plop[1] = new int(89);
  std::cout << "il y en a " << plop.getNombre() << std::endl;
  plop.afficher(); //methode de test. qui affiche tout les elements a l'indirection des entiers.

Bon jusque la tout marche bien mais c'est biensur pas parce que ca marche que c'est bien.

Quand j'utilise l'operateur d'indexation je remplace la valeur du pointeur pour lui donner la nouvelle adresse seulement l'instance precedant n'est pas delete, et donc a chaque resaisie j'ai une instance en memoire que je ne controle plus et j'aimerais gerer cela.

voici le code de l'operateur :

Code :

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

1
2
3
4
5
6
7
8
 
  T &operator[](unsigned int rang)
    {
      CCellule<T> *uneCellule = premier;
 
      for(int i = 0; i< rang;i++, uneCellule = uneCellule->getSuivant());
      return *uneCellule->getPtInformation();
    }

Je ne peut pas delete l'anciene instance puis resaisir par le return systematiquement (par la reference) car certaines fois l'operateur est utilisé en lecture seulement.

Toute idée est bienvenue.

[NiamorH]

A part utiliser des smart pointers je ne vois pas trop comment tu pourrais t'en sortir.

[Alain Defrance]

Hum j'ai pas toujours entendu du bien des smarts pointeur ni de leurs efficacité.

Je me retrouve bien bloqué, j'ai peut-etre un idée mais je suis pas certain que ca soit le top je m'explique.

Je pourait gerer la liste de tout les pointeur instancé depuis l'instanciation de la class de liste, puis regulierement checker et virer celles qui font plus parti de la liste, on reprend le principe de garbage collector.
Avantage je sais que ma liste ne saturera pas la memoire inutilement.
Desaventage pour une utilisation succinte la liste sera plus lourde.

[JolyLoic]

Si on veut différentier les accès en lecture de ceux en écriture, la solution classique est de ne pas retourner directement l'élément, mais un proxy vers cet élément. charge à ce proxy de supprimer l'élément si on appelle l'opérateur= dessus.

Par ailleurs, j'ai l'impression que ta liste est du coup uniquement prévue pour gérer des pointeurs (puisque tu veux deleter les éléments au besoin). Dans ce cas, plutôt que de déclarer une CListe<int*>, il me semblerait plus clair de déclarer une CPtrList<int>.

[NiamorH]

Les smart pointers c'est vaste.
Comme dit Loïc, cela peut simplement être une classe qui encapsule ton pointeur pour détecter l'operateur =, sans entrer dans le comptage de référence.
En écrivant bien la chose avec des inlines, il est possible qu'il n'y ait même pas d'overhead.

Par contre, comme tu à l'air de te soucier de l'optimisation, j'aimerais bien savoir quel genre d'appli tu fais et ce qui t'amène à vouloir optimiser ?
Deuxieme question : est ce vraiment de simples ints que tu compte mettre dans ta liste?

Si non, peut être que les small objects de Loki pourraient t'intéresser également.

[Alain Defrance]

A vrais dire ce programme sera utilisé pour justifier la competence objet dans l'un de mes projets de fin d'année (BTS IG dev).
En temps normal j'aurais simplement utilisé une list<T> je pense mais afin de pouvoir bien parler de l'objet a mon oral, j'ai préféré créer moi meme mon contenneur.

Ensuite l'application devras stocker des objet en tout genre (puisque j'ai un ensemble de class metier).

A savoir que j'aurait certainement une interface graphiqure .Net donc avec un ramasse-miette qui fera en sorte que mes instances stocké seront géré.

Si j'insiste pour avoir une class de liste bien propre c'est qu'il va certainement m'interroger dessu, et que si je peut eviter le genre de quesion "comment on peut liberer l'espace reservé sur les ancienes instances ?"

La class doi pouvoir stocker du static comme du dynamique si je presente ca comme un moyen "universel"

Code :

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

1
2
 
Si on veut différentier les accès en lecture de ceux en écriture, la solution classique est de ne pas retourner directement l'élément, mais un proxy vers cet élément. charge à ce proxy de supprimer l'élément si on appelle l'opérateur= dessus.

C'est a dire ?
Je comprend pas tres bien ou tu veux en venir, tu peut codder un petit exemple ?

[Alain Defrance]

Apres plusieurs test j'ai créer une class "tampon" qui stock l'information et a laquette je veux surcharger l'operateur = pour detecter si c'est une lecture ou une ecriture comme vous me l'avez conseillé.

j'ai donc

Code :

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

1
2
3
4
5
6
 
  T &operator[](unsigned int rang)
    {
      CTampon<T> tmp(*informationAt(rang));
      return tmp.getInformation();
    }

quand la surcharge de l'operateur = de la classe CTampon ca donne ca

Code :

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

1
2
3
4
5
6
7
8
9
10
 
  T &getInformation()
    {
      return information;
    }
 
  void operator=(T Ainformation)
    {
      std::cout << "OPERATEUR BIEN APPELE";
    }

Et visiblement la surcharge n'est pas appellé.
Je ne comprend pas puisque je return dans CListe[i] un CTampon qui recoit une valeur avec =

[EDIT] En fait non c'est normal puisque ca marche pas puisque je retourne l'information et non pas la class de Tampon.

[JolyLoic]

L'idée est un truc du genre (code non testé, même pas relu) :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
template <class T> 
class proxy
{
  proxy(T* myData);
  T* myData;
  T* operator->() {return myData;} // accès en lecture
  void operator=(T*newData) // accès en écriture
  {
    delete myData;
    myData = newData;
  }
};

Et on modifie l'opérateur[] de la liste pour qu'il renvoie un proxy<T>

[Alain Defrance]

alors c'est ce que j'avait essayer d'implementer en fesant mal, je vais continuer par la, merci beaucoup d'avoir passé un peu de temps a m'aider je vais m'en sortir.

[EDIT] Tout est testé et marche parfaitement, merci beaucoup