Newsgroup: it.comp.lang.c++
Titolo: Memoria statica o dinamica?

Ciao a tutti,
avrei una domanda: nel seguente codice (2 righe di main()) cosa succede?
int main()
{
int a, b;
int mat[a][b];
/*...*/
}
Il compilatore non si lamenta. Ma all'esecuzione Windows si pianta e Linux no.
Ho pensato che a run-time venisse allocata una memoria *statica* pari al valore iniziale 
(non noto a priori) di a e di b. Tuttavia la quantita di memoria statica dovrebbe essere 
nota prima dell'esecuzione, giusto?
Quindi qualcuno sa con esattezza come viene gestita la memoria della matrice mat?
Grazie


Come hai potuto verificare il comportamento e' indefinito, dipende da come e' 
implementato il compilatore.
Lo standard vuole che una array statico debba avere una dimensione costante, quindi:
o un literal
o una variabile dichiarata const
Non so pero' cosa realmente accada in win o linux. Un comportamento 
completamente sicuro potrebbe essere quello di allocare 2^32 - 1 locazioni per 
variabili intere, ma mi sembra decisamente improponibile!
Mi metto anch'io in attesa di ulteriori chiarimenti
-- 
Paolo

> int mat[a][b];
Scusa ma *a* e *b* non sono state inizializzate quindi possono valere un
qualsiasi valore casuale compreso nella dimensioni del tipo *int*.
Quindi se il tipo int e' grande 4 bytes potrebbe venire allocata memoria per
un totale di 2^32 * 2^32 * 4 bytes nella peggiore delle ipotesi. Tale
quantitativo di memoria potrebbe mandare in "crisi" (uso un eufemismo) il
sistema.
O mi sbaglio?
Ciao.
-- 
~~~~Slaine Mc Roth~~~~
**Linux User# 312607**
"L'intero problema si riduce a questo: la mente umana e' in grado
di dominare cio' che ha creato?"
                (Paul Valery)

 sistema.
Esatto! E' proprio quello che ho scritto...
Il punto è che con "mat[a][b]" dovrei fare riferimento a della memoria statica la cui 
quantità (smentitemi se sbaglio) dovrebbe essere nota al tempo di compilazione, non di 
esecuzione.
Quello che chiedo è: come viene gestita la memoria di "mat"? Forse che il compilatore, non 
conoscendo la quantità di memoria da riservare (essendo a e b non inizializzati), ne riserva 
una di default che decide lui?
Ciao!

 lui?
ok parliamo di draghi viola.
probabilmente avrai usato gcc per compilare quella "cosa".
gcc offre una estensione, richiesta peraltro dal c99 ( e quindi 
mediamente gratis per gcc ) per "variable length automatic arrays".
<cite from="una pagina a caso da google">
Variable-length automatic arrays are allowed in ISO C99, and as an 
extension GCC accepts them in C89 mode and in C++. (However, GCC's 
implementation of variable-length arrays does not yet conform in detail 
to the ISO C99 standard.) These arrays are declared like any other 
automatic arrays, but with a length that is not a constant expression. 
The storage is allocated at the point of declaration and deallocated 
when the brace-level is exited.
  </cite>
quello che succede quindi usando gcc 3.x dove x <= 4
è che vanga allocato sullo stack ( che notoriamente per lo standard non 
esiste ) un array[][] grande a*b dove a e b sono due variabili non 
inizializzate.
Altro punto: lo standard non permette array di size 0
ora questo è quello che potrebbe succedere con uno specifica versione di 
uno specifico compilatore con specifici flag settati ( o non settati ).
Tutti gli altri compilatori possono o meno comportarsi in modo diverso ( 
  ed è più che lecito che lo facciano ).
Perché hai fatto una domanda inutile?
-- 
sbi

 una di default che decide lui?
Premesso che stiamo parlando di un'estensione allo standard, il
meccanismo puo' funzionare, posto che a e b siano inizializzate,
perche' mat[][] e' una variabile locale ed e' quindi allocata sullo
stack.
Al momento della sua allocazione il compilatore sa dove trovare a e b
e semplicemente riserva in cima allo stack uno spazio di a * b *
sizeof(int) bytes.
Se a e b sono troppo grandi, per scelta o per caso... bum!
Ciao,
Nicola

 Perché hai fatto una domanda inutile?
Per sapere e poi non la ritengo inutile (la domanda, il codice magari sì)
Ciao

 Se a e b sono troppo grandi, per scelta o per caso... bum!
o magari 0 :))
-- 
RiK0
Non credo negli schemi non vincenti.