Newsgroup: it.comp.lang.c++
Titolo: aiuto! veramente strano...

continuo a non risolvere/capire il problema.
ho una classe (State) con dentro un array di DATALENGHT interi 
una classe (HashTable) con dentro un'array di N State.
ebbene se metto un valore di DATALENGHT troppo alto (parlo di 200 o 300 non 
di veramente troppo alto) mi dà segmentation fault in fase di istanziazione 
della classe HashTable.
Secondo voi perchè?
Aiutatemi perchè veramente non riesco a spiegarmelo.
Allego parte del codice.
P.S. la hashtable è ancora provvisoria...per ora è solo un semplice array.
//## classe State ###################################################
#define DATALENGHT 500
class state {      
public:
  static int numstates;//numero di stati instanziati
  int idstate;         //id dello stato
  int data[DATALENGHT];
   state();
   ~state();
   void print();
};
int state::numstates=0;
state::state(){
   idstate = state::numstates++;
   for (int i=0; i<DATALENGHT ; i++) {
     data[i]=idstate+i;
   }
}
//## classe HashTable ###################################################
#include <state.h>
#define DIM_HT_LIST 5              
 
class hashTable {
public:
    state list[DIM_HT_LIST]; 
    state *getState( int numstato ); //per ora ancora non è una vera ht ;)
   hashTable();
   ~hashTable();
   void print();       
};
hashTable::hashTable(){
}
hashTable::~hashTable(){
}
//## il codice chiamante è semplicemente
hashTable ht;
Ovviamente in un main.
Grazie!

 Grazie!
Prova a mettere
hashTable ht;
fuori dal main per vedere se il problema sta nello stack che straborda.
Nel caso ti funzioni, o allarghi lo stack, e cio' dipende dalle opzioni del
tuo compilatore o al posto di allocare staticamente la hashTable nel main,
la allochi dinamicamente con una new e alla fine liberi con una delete.
Maurus

 Maurus
Daniele.


Dovresti cercare un buon manuale di C++ che ti spieghi la differenza fra
heap , stack e altri concetti di memoria.
Scaricati "Thinking in C++" di Bruce Eckel da 
www.bruceeckel.com
 oppure
guardati qualche tutorial su C++, heap e stack facendo ricerche su google o
vai su 
www.programmazione.it
 dove trovi varie cose interessanti.
Maurus

 heap , stack e altri concetti di memoria.
bhč...quelli + o - sono chiari...
č come configurare il g++ per poterli gestire che non mi č chiaro ;-)


Comunque, una volta che hai capito, anche con prove empiriche, ma sarebbe
meglio con l'help del tuo compilatore, che a volte fornisce funzioni
proprietarie apposite, a quanto ammonta l'ampiezza dello stack, poi ti
regoli nelle decisioni se allocare dinamicamente o staticamente dei dati.
Ma quando hai bisogno di tanti bytes per i tuoi dati, per sicurezza utilizza
l'allocazione dinamica, anche se non stai sforando lo stack.
Maurus

 una delete.
Per me e' meglio usare un auto_ptr<hashTable> ht = new hashTable;
Visto che l'hanno inserito apposta, usiamolo...


Hai ragionissima Enrico!
Sara' che li uso poche volte perche' dimentico sempre che esistono ma sono
utilissimi per non avere memory leak.
Ricordiamo a chi li usa poco (come me) che non vanno usati per i contenitori
standard (vector, list, map...)
Maurus

 Maurus
Daniele

 contenitori standard (vector, list, map...)
non vanno usati con qualunque cosa crei ne una copia per accedervi, in 
quanto il costruttore di copia trasferisce il possesso del puntatore 
alla copia, invalidando quello dell'originale

 alla copia, invalidando quello dell'originale
beh, detta cosi` e` un po' troppo restrittiva. In generale gli auto_ptr 
non vanno usati quando valgono queste due condizioni:
1) e` necessario ottenere una copia dell'auto_ptr
2) la copia e l'originale devono essere indistinguibili
Se il requisito 2 non e` fondamentale per la nostra applicazione allora 
possiamo usare tranquillamente auto_ptr.
Ad esempio un uso *utilissimo* degli auto_ptr e` questo:
std::auto_ptr<MyClass> foo()
{
     ....
     return std::auto_ptr<MyClass>(new MyClass);
}
In questo modo siamo sicuri che in nessun caso ci sara` un memory-leak: 
se l'utente chiama foo() senza memorizzare il risultato il compilatore 
creera` un temporaneo che sara` subito distrutto; allo stesso modo foo() 
e` sicura anche in presenza di eccezioni.
Nota che tutto questo funziona proprio grazie al fatto che al momento 
della return creiamo una copia dell'auto_ptr, ma non ci interessa che la 
copia sia indistinguibile dall'originale.
ciao Anto
-- 
"Computer science is not about computers any more than astronomy
is about telescopes." -- EW Dijkstra