Newsgroup: it.comp.dotnet
Titolo: [VB.NET] delegates passati a un costruttore con AddresOf

Avrei una domanda banale.
 
In una classe che serve da indice e supporto ad altra classe 
con dati "pesanti" (sono sei variabili double, ma queste 
classi servono per farne array), al fine di evitare la 
duplicazione fisica dei dati, ho deciso di passare un indice 
intero ed un puntatore a funzione (DELEGATE) al suo costruttore.
 
Purtroppo ho fatto la scelta con leggerezza, pensando per 
abitudine (C++) che il puntatore a funzione, o delegate (se 
poi sono esattamente analoghi), consumasse tanto spazio 
quanto un qualsiasi puntatore o indirizzo di memoria.
 
A posteriori mi faccio un po' di paranoie, temendo il peggio 
(che vengano ad es. passati anche metadati di qualche 
natura, firma della funzione o altre info x introspezione), 
e quindi non sono nemmeno più sicuro di avere risparmiato 
spazio.
Allora vi ritorco la domanda :
quanto spazio (in byte) occupa una variabile reference di 
tipo DELEGATE, assegnabile con AddressOf Procedure ?
Inoltre : occupa uno spazio fisso ? (oddio ci spero) O 
dipende dalla funzione ?
 
grazie di ogni dritta
ciao
Soviet
 
 

Il 10/01/2012 16:06, Soviet_Mario ha scritto:
 
ad ulteriore integrazione dei dubbi precedenti.
Se inizializzo un puntatore a funzione MEMBRO non SHARED, 
quindi legato ad istanza, quando verrà richiamato da fuori 
tramite il delegato ... vedrà a sua disposizione anche i 
DATI di istanza (Quelli che non avevo voluto ricopiare) vero ?
riciao
Soviet


 quanto spazio (in byte) occupa una variabile reference
 
Che io sappia, tutte le references sono references e occupano esattamente lo 
stesso spazio (proprio come era per i puntatori).
 
Comunque tutto cio' e' documentato, devi solo spulciare un po' in MSDN...
 
-LV
 

 piccoli oggetti
 
Non e' l'unico approccio possibile, in ogni caso e' un approccio abbastanza 
convenzionale per un sistema la cui filosofia e' essenzialmente 
strongly-typed.  Value types e reference types, prima ancora che un diverso 
memory model, hanno una diversa *semantica*!  L'efficienza, come le 
performances, e' al primo posto solo nelle priorita' dei principianti: 9/10, 
un codice scritto a regola d'arte e' *anche* (aggratis!) un codice 
performante e quant'altro...
 
-LV
 

 esiste ?
 
Diversa semantica, non sintassi: ovvero come si comportano, altrimenti detto 
"cio' che ci puoi fare".  Se per esempio assegni un reference type, solo la 
reference viene copiata; per un value-type hai invece una copia in un nuovo 
oggetto, che e' infatti quello che ci si aspetta quando per esempio si 
assegna un integer ad un altro: non ci aspetti di ottere un riferimento 
all'integer di partenza.  Poi sulla storia di stack vs. heap (e questo e' 
comunque un quadro semplificato), e' da considerare che anche se i dati di 
un oggetto vanno nello heap, la reference di suo sta nello stack, ed il 
fatto di avere uno stack strutturato come e' strutturato e' cio' che 
consente cose tipo le closure... ecc. ecc., nel senso che non sono 
particolarmente esperto in materia.
 
Ma c'e' da notare che quelle di memory management (come altre) sono 
certamente questioni non semplici nei loro dettagli, ma resta il fatto che 
il selling point di .Net e' appunto il fatto di *non* avere piu' la 
necessita' di guardare dentro il cofano (se non al livello di dover 
consultare la documentazione relativa a cio' che si sta usando? qualcosa del 
genere...).  Credo che .Net sia "difficile" piu' che altro perche' e' 
abbastanza enorme, un piccolo mondo a se' di cui imparare idiomi, conoscere 
le risorse, e quant'altro...
 
In bocca al lupo con i tuoi... esperimenti!  :)
 
-LV
 
 

 nello heap, la reference di suo sta nello stack, ed il
 
"Un oggetto" li' e' ambiguo: avrei dovuto dire "un reference-type".
 
-LV