Newsgroup: it.comp.lang.visual-basic
Titolo: Problemino: Stack contro Heap

Ho un problemino.
Ho un tipo privato dichiarato in una classe cosě:
' --- in una classe 
private type ohTipo
	numeroScarpe as long 
	....
end type
Lo devo allocare nello heap anzichč nello stack.
Se ho una Sub fatta cosě:
sub prova
dim tp as ohTipo
end sub
tp viene allocato nello stack appena entro nella sub.
Quello che vorrei fare č poterlo dichiarare nello heap (per evitare stack
overflow in caso di chiamate ricorsive e per altri motivi).
In C++ mi pare che sia sufficiente preporre un "new" in VB mi vengono in mente
un po' di cose, ma sono tutte un po' campate in aria...
Qualcuno ha suggerimenti?
termoPilucco

 In C++ mi pare che sia sufficiente preporre un "new" 
beh, dati gli obiettivi quantitativi che stai affrontando, penso 
che anche il NEW del C++ non potrebbe essere affrontato a cuor 
tanto sereno in realtà. Quantomeno ci vorrebbe un fastidioso 
blocco  try...catch  per testare il fallimento di allocazione.
ciao
cccp++mario


persistenti.
Ecco... alla fine è la stessa cosa.
Lo stack è limitatissimo, e a me serve allocare un tipo piuttosto corposo in
memoria.. in effetti fra le mie ipotesi avevo in mente anche quello che
suggerisci:
sub usatipo
dim arrTipo() as ohTipo
redim arrTipo(0) 
end if
Dovrebbe funzionare (più tardi provo) :)
Nel caso, magari riesco a usare lo stesso stratagemma per i parametri delle sub
(che finiscono sempre nello stack).
termoPilucco

 end if
Premesso che "end if" non è esattamente quello che volevo scrivere, la
cosa funziona eziogreggiamente.
termoPilucco
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 termoPilucco
Se vuoi un'allocazione dinamica nello heap perche' non usi un oggetto 
anziche' un tipo?
Lokar
-- 
Sito Comune: 
http://www.it-lang-vb.net/
Manifesto: 
http://www.it-lang-vb.net/docs/Manifesto.txt
Statuto: 
http://www.it-lang-vb.net/docs/Statuto.txt
UGIdotNET - 
http://www.ugidotnet.org
 

>> end if
altra considerazione, forse inesatta ma è un controllo che 
potresti fare tu
l'involucro contenitore del safearray occupa circa 20 byte 
minimo, uan variant (che può contenere un array in modo 
indiretto) ne occupa sedici.
Non si potrebbe tentare di allocare solo una variant come 
oggetto locale ? Cioè o dei dubbi in realtà, 1) non sono sicuro 
che "arrTypo" non sia in ogni caso soltanto una reference a 
qualcosa di posizionato altrove, nel qual caso il mio 
suggerimento è peggiore perché come reference,
ossia come SafeArray * *, occuperebbe solo 4 byte contro i 16; 
2) che si possa fare uan redim su una variant in modo pulito (se 
non assegnando una matrice e sarebbe daccapo).
3) Il consiglio di Lokar, se non ti serve come temo mappare su 
direttamente su disco le tue strutture utente, è in effetti il 
più elegante e trasparente e occupa meno stack di tutti. Se ti 
serve fare get e put la cosa invece si fa più rognosa (è una 
delle caratteristiche più odiose delle classi del VB secondo me).
ciao
cccp++mario


 piů elegante e trasparente e occupa meno stack di tutti.
Il problema č proprio lě: devo mappare su disco con get e put.
In effetti potrei lavorare in memoria con le classi e, in fase di
scrittura su disco, mappare i membri della classe in quelli di un istanza
della struttura.
Avrei del lavoro extra da fare a livello di cpu, ma il collo di bottiglia
rimane sempre il disco.
Perň, ho fatto una marea di test e lo stack overflow mi sta uccidendo.
Nella versione btree che ho pubblicato sembra (ma non lo assicuro) non
esserci problema neanche con 100 milioni di chiavi long.
Nella versione che ho portato avanti (in cui le chiavi sono stringhe fisse
di 40 caratteri) mi si blocca per stack overflow dopo poche decine di
migliaia di inserimenti anche con l'accorgimento dell'array dinamico, che,
tra l'altro, č esteticamente rivoltante :)
Ho idea che il problema sia altrove (forse la versione su stringa ha
qualche difetto, anzi ne sono sicuro a questo punto), ma mi piacerebbe
piallare tutte le routine ricorsive e renderle lineari per vedere un po'
se funzionano le cose.
Solo che la cosa sta diventando un pelo lunga... e pensare che ho fatto
tutto per evitare di distribuire DAO/ADO con i quali la stessa si faceva
in quattro righe senza problemi di sorta...


 se funzionano le cose.
Ok... ho piallato tutte le routine ricorsive della versione con chiavi
long.
Adesso il tutto è circa il 10% più veloce (si risparmino una marea di
passaggi di parametri alle funzioni), anche se il codice è di gran lunga
meno elegante...
Proverò a rimodificare il tipo della chiave da long a stringa per vedere
se i problemi sono risolti.
A questo punto non può più darmi stack overflow, ma, in caso di errori,
potrebbe non terminare la procedura.
