Newsgroup: it.comp.lang.c++
Titolo: class Contenitore

//La domanda è alla fine del listato
#include <iostream>
#include <vector>
using namespace std;
class Store
 {
 public:
 Store(){};
 virtual ~Store(){};
 };
class Contenitore
 {
 public:
 vector <Store*> GlobalObj;
 vector <Store*>::iterator p;
 void AddObj(Store *Obj)
  {
     GlobalObj.push_back(Obj);
   cout << "Ora contengo " << GlobalObj.size() << " oggetti" << endl;
  }
 void DeleteObj(Store *Obj)
  {
  p = GlobalObj.begin();
   for (int k=0;k<GlobalObj.size();k++)
        {
        p+=k;
      if (GlobalObj[k] == Obj)
     {
     GlobalObj.erase(p);
     }
        }
  }
 ~Contenitore()
  {
  for (int k=0;k<GlobalObj.size();k++)
   {
   Store *S = GlobalObj[k];
   delete S;
   }
  }
  };
class Oggetto : public Store
 {
 public:
 Contenitore *Cont;
  Oggetto(Contenitore *C)
   {
   Cont = C;
   Cont->AddObj(this);
   cout << "Oggetto creato" << endl;
   }
  ~Oggetto()
   {
   Cont->DeleteObj(this);
   cout << "Oggetto distrutto" << endl;
   }
 };
void func()
 {
 Contenitore A;
 Oggetto  *B = new Oggetto(&A);
 Oggetto C(&A);
 }
int main()
 {
 func();
 return 0;
 }
Lo scopo della classe contenitore è quello di tenere traccia di tutti gli
oggetti creati (a prescindere se nell'heap o nello stack) e di distruggerli
nel caso non lo abbia fatto il programma stesso. La cosa mi pare funzionare
(a me, magari sbaglio), ma mi chiedo se non è possibile raggiungere lo
stesso risultato senza l'uso della classe Store, ci ho provato ma non riesco
a capire come far "conoscere" le due classi, contenitore e oggetto.
N.B. ovviamente non mi interessa in questa sede l'uso di auto_ptr et
similia, la mia domanda è se è possibile eliminare la classe Store e se il
programma è corretto (ci potrebbero essere perdite di memoria?).
Grazie

 programma è corretto (ci potrebbero essere perdite di memoria?).
Mi /sembra/ di si a parte l'errore che ti ho segnalato.

 far "conoscere" le due classi, contenitore e oggetto.
Aggiungi una forward declaration di Oggetto prima della dichiarazione di
Contenitore e sposta le implementazioni dei metodi di Contenitore sotto la
dichiazione di Oggetto. Ad ogni modo, la tua soluzione è più generica in
quanto evita la dipendenza di Contenitore da Oggetto. Derivando anche
Contenitore da una base astratta, dotata di metodi AddObj() e DeleteObj(),
puoi eliminare anche la dipendenza di Oggetto da Contenitore.
Max


Infatti, ricopio pari pari la tua soluzione, grazie.


Questa non l'ho proprio capita. Dipendenza in che senso, e quali problemi
potrebbe comportare (tieni conto che Oggetto sta per diventare padre di una
30ina di classi)


Sicuro sia una buona idea? Io non lo farei. Salvo casi particolarissimi,
trovo che non sia mai una buona idea derivare da classi concrete. (Su
questo sono un po' integralista.)
Ad ogni modo, qual è la funzione di Contenitore? Soltanto quella di
garantire il clean-up degli oggetti allocati nello heap? Se è solo questa,
io avrei in mente una soluzione migliore per ottenere lo stesso effetto,
che non obbliga a derivare tutte le classi dallo stesso oggetto. (Non mi
riferisco a una soluzione basata su smart pointer, ma proprio a una classe
come la tua che tenga traccia degli oggetti allocati nello heap e li
distrugga alla fine.)
Max

 io avrei in mente una soluzione migliore per ottenere lo stesso effetto...
Hai tutta la mia attenzione in proposito.
(cmq grazie per i suggerimenti)

 oggetto globale visto che può essercene solo uno.
in questo caso la cosa migliore e` usare il pattern Singleton.
 
ciao Anto
-- 
Antonio Cuni, 20 anni, studente
Brainbench C++ Master: 4.73, higher than 99% of all previous test takers.
C Language: 3.79, higher than 92% of all previous test takers.
Guida C/C++ di Programmazione.it: 
http://cpp.programmazione.it

 in questo caso la cosa migliore e` usare il pattern Singleton.
Mi aggancio a questa domanda per farne una OT: dove si possono trovare 
informazioni / libri sui pattern piu' diffusi? Ovviamente gratis ;-)
Grazie.
-- 
Andrea Bergia - studente
Linux Registred User #281550

informazioni / libri sui pattern piu' diffusi? Ovviamente gratis ;-)
Di gratis mi viene in mente Thinking in Python di Bruce Eckel che non
tratta di Python ma dei pattern. Il linguaggio usato è comunque Python
e non C++, alcune cose possono essere riciclate in altri linguaggi,
altre no.
Il link è 
http://www.mindview.net/Books/TIPython
.
-- 
Marco Barisione (ICQ 84277092)

 Grazie.
se mastichi l'inglese: comp.software.patterns
(anche se non e' molto frequentato, a dire il vero... :-( )
-- 
Ciao by Allanon

 informazioni / libri sui pattern piu' diffusi? Ovviamente gratis ;-)
non sono un grande esperto di pattern e sono anche un po' a corto di 
link...
cmq sul sito di Bruce Eckel e` possibile scaricare sia Thinking in 
Patterns, che usa Java come linguaggio di esempio, che Thinking in 
Python, che e` la riscrittura del precedente usando Python al posto di 
Java.
Se invece passiamo ai libri stampati il riferimento classico e` "Design 
Patterns" dei GoF, mentre se cerchi qualcosa di C++-specific consiglio 
l'ottimo "Modern C++ Design" di Alexandrescu: non e` un libro specifico 
sui pattern, pero` alcuni capitoli illustrano l'implementazione in un 
C++ super-riusabile di alcuni di essi.


 Java.
Ok grazie, ho scaricato entrambi. Appena avro' tempo li leggero ;-) Ciao.


 
L'idea a cui mi riferivo sfutta l'overloading dell'operatore new. Raccolgo
e semplicifico qualche frammento di mio codice e ti posto qualcosa di
funzionante (tanto per rendere l'idea).
Max

 foglie sono classi concrete (e da quelle non si deriva). 
E`  possibile  impedire  la  derivazione di  una  classe? Qualcosa  come
"final" in Java (lo so che non c'e` in C++).
ciao
Kronos
-- 
Home: 
http://kronoz.cjb.net
La somma dell'intelligenza sulla terra e` una costante.
La popolazione e` in aumento.

 "final" in Java (lo so che non c'e` in C++).
Che io sappia no. Comunque, sinceramente che te ne faresti scusa? Se e' un 
progetto closed-source non c'e' problema, basta che nessuno scriva una 
classe derivata. Se e' open source non si sa mai cosa potrebbe venire 
fuori a derivarla. E comunque vai (in parte) contro l'approccio OOP. Non 
credo sia una necessita' cosi' fondamentale.


 foglie sono classi concrete (e da quelle non si deriva)
pensavo ci fosse qualche "trucco".
ciao
Kronos
-- 
Home: 
http://kronoz.cjb.net
Quando un uomo porta dei fiori a sua moglie senza motivo, 
un motivo c'e`.