Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
[VB.NET] delegates passati a un costruttore con AddresOf
29 views
Skip to first unread message
Soviet_Mario
Jan 10, 2012, 10:06:29 AM1/10/12
to
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
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
Soviet_Mario
Jan 10, 2012, 10:21:25 AM1/10/12
to
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
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
LudovicoVan
Jan 18, 2012, 1:18:43 PM1/18/12
to
"Soviet_Mario" wrote in message
news:4f0c5409$0$1386$4faf...@reader2.news.tin.it...
> non sono nemmeno più sicuro di avere risparmiato spazio.
Ah, adesso capisco: stai cercando di risparmiare un byte ogni 2
fastastiliardi, attraverso un codice che ti ci vuole un mese solo a capire
che cosa vuol dire... :)
> 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
news:4f0c5409$0$1386$4faf...@reader2.news.tin.it...
> non sono nemmeno più sicuro di avere risparmiato spazio.
fastastiliardi, attraverso un codice che ti ci vuole un mese solo a capire
che cosa vuol dire... :)
> quanto spazio (in byte) occupa una variabile reference
stesso spazio (proprio come era per i puntatori).
Comunque tutto cio' e' documentato, devi solo spulciare un po' in MSDN...
-LV
Soviet_Mario
Jan 18, 2012, 4:41:10 PM1/18/12
to
Il 18/01/2012 19:18, LudovicoVan ha scritto:
> "Soviet_Mario" wrote in message
> news:4f0c5409$0$1386$4faf...@reader2.news.tin.it...
>
>> non sono nemmeno più sicuro di avere risparmiato spazio.
>
> Ah, adesso capisco: stai cercando di risparmiare un byte ogni 2
> fastastiliardi,
beh non proprio.
> "Soviet_Mario" wrote in message
> news:4f0c5409$0$1386$4faf...@reader2.news.tin.it...
>
>> non sono nemmeno più sicuro di avere risparmiato spazio.
>
> Ah, adesso capisco: stai cercando di risparmiare un byte ogni 2
> fastastiliardi,
In una lista di oggetti (Che contengono array
tridimensionali di double, diciamo fino a qualche centinaio
di coordinate, ho messo un puntatore alla funzione di
istanza di quella classe che mi legge internamente tali
coordinate, ma non ero sicuro di come trattasse la
reference, acc. a me)
> attraverso un codice che ti ci vuole un mese solo a
> capire che cosa vuol dire... :)
Eh, quello a prescindere ! LOL.
>
>> 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...
aggiornato non lo conosci in modo corretto, tante volte
formuli la query come ce l'hai in testa "tu" e non focalizzi
le pagine di interesse.
Purtroppo sono ben lontano da una padronanza minimale di NET
(per fortuna più passa il tempo e più il rapporto di amore /
odio propende per la seconda ... salvo la multiple
inheritance e l'odio per le interfacce), e sto perdendo
praticamente il vizio di riscrivere contenitori ed oggetti
esistenti per abusare a piene mani di quelli built in (a
parte la serializzazione, che non mi entra e non mi piace)
In più non ho capito la scelta filosofica di fondo tra
ValueTypes e RefTypes ... ho un vago sospetto che la
persistenza dei primi sia stata prevista essenzialmente per
ragioni di efficienza nel passaggio/copia di piccoli oggetti
(per i quali invocare meccanismi elefantiaci di GC,
reference count, liste di attesa della distruzione, etc,
sarebbero stati un costo eccessivo, nonostante magari
l'omogeneità di accesso). Però magari nemmeno ci ho preso
ciao
Soviet
>
> -LV
>
LudovicoVan
Jan 19, 2012, 6:24:51 AM1/19/12
to
"Soviet_Mario" wrote in message
news:4f173c71$0$1388$4faf...@reader2.news.tin.it...
e' proprio un'applicazione performance-critical ed il famoso bottle-neck in
qualche funzione super-annidata, stai comunque risparmiando una goccia nel
mare. Ma quello che cerco di comunicare qui e' un'indicazione generale: il
codice va prima di tutto scritto a regola d'arte (o, da manuale), con
leggibilita', semplicita' e (conseguentemente) manutenibilita' al primo
posto. Ottimizzare (per esempio denormalizzando, oppure andando a limare
sui cicli di CPU o sui singoli byte) viene sempre dopo e sempre e solo dove
e quando serve, e ovviamente ha un costo rispetto ai criteri ideali di
partenza, cioe' ci si perde in leggibilita', manutenibilita' ecc.
> > Comunque tutto cio' e' documentato, devi solo spulciare un po' in
> > MSDN...
>
> A volte non trovo gli argomenti perché se il gergo specifico
> aggiornato non lo conosci in modo corretto, tante volte
E' vero che d'acchitto non e' di facile lettura, ma se prendi l'abitudine di
consultare la documentazione ogni volta che stai usando qualcosa che non usi
proprio tutti i giorni (personalmente la considero parte integrante del
lavoro quotidiano), la documentazione si fa rapidamente piu' chiara, e come
si chiamano le cose e dove trovarle piano piano viene fuori pure. Te lo
dico anche per esperienza personale, visto che ho cominciato con Microsoft e
.Net una decina di anni fa, prima usavo altro (in particolare il Borland
Delphi, che e' OO Pascal, per applicazioni Windows) e ricordo anch'io di
avere avuto difficolta' inizialmente: ma poi tutto si fa piu' chiaro.
> salvo la multiple inheritance e l'odio per le interfacce
A me non piace l'abuso delle interfacce in nome della testability (un'altra
delle ovvie aberrazioni), ma per il resto non bisognerebbe avere certe
avversioni. L'ereditarieta' multipla a volte si', farebbe comodo, ma ad
oggi non ho ancora trovato nulla che non si potesse costruire ugualmente al
costo forse di una minima duplicazione di codice e magari di qualche
capriola con i generics...
In generale, la filosofia dietro .Net e' quella di fornire un framework
molto potente ma allo stesso tempo ragionevolmente semplice da usare e senza
tutte le super-complicazioni del codice nativo. Questo consente alti
livelli di produttivita' e relativamente pochi "sbattimenti" anche a chi non
e' un super-professionista e non mastica C++ e WinAPI a colazione. Questo
ovviamente pero' viene al costo di qualche sofisticazione in meno, ma se
proprio .Net ti sta stretto, l'unico consiglio sarebbe quello di passare a
C++ nativo appunto: ma in realta' non lo consiglio, a meno che non sono i
proverbiali progetti segreti per la NASA... :)
> e sto perdendo praticamente il vizio di riscrivere contenitori ed oggetti
> esistenti per abusare a piene mani di quelli built in (a parte la
> serializzazione, che non mi entra e non mi piace)
That is very good, there is never point in reinventing the wheel,
soprattutto se il framework in questione ti offre delle soluzioni built-in
di alta qualita'. C'e' veramente poco margine per le ottimizzazioni in user
code in .Net...
> In più non ho capito la scelta filosofica di fondo tra ValueTypes e
> RefTypes ... ho un vago sospetto che la persistenza dei primi sia stata
> prevista essenzialmente per ragioni di efficienza nel passaggio/copia di
> 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
news:4f173c71$0$1388$4faf...@reader2.news.tin.it...
> Il 18/01/2012 19:18, LudovicoVan ha scritto:
> In una lista di oggetti (Che contengono array tridimensionali di double,
> diciamo fino a qualche centinaio di coordinate, ho messo un puntatore alla
> funzione di istanza di quella classe che mi legge internamente tali
> coordinate, ma non ero sicuro di come trattasse la reference, acc. a me)
Un centinaio di oggetti per i 24 byte dei tre double fa 2.4K, cioe' se non
> In una lista di oggetti (Che contengono array tridimensionali di double,
> diciamo fino a qualche centinaio di coordinate, ho messo un puntatore alla
> funzione di istanza di quella classe che mi legge internamente tali
> coordinate, ma non ero sicuro di come trattasse la reference, acc. a me)
e' proprio un'applicazione performance-critical ed il famoso bottle-neck in
qualche funzione super-annidata, stai comunque risparmiando una goccia nel
mare. Ma quello che cerco di comunicare qui e' un'indicazione generale: il
codice va prima di tutto scritto a regola d'arte (o, da manuale), con
leggibilita', semplicita' e (conseguentemente) manutenibilita' al primo
posto. Ottimizzare (per esempio denormalizzando, oppure andando a limare
sui cicli di CPU o sui singoli byte) viene sempre dopo e sempre e solo dove
e quando serve, e ovviamente ha un costo rispetto ai criteri ideali di
partenza, cioe' ci si perde in leggibilita', manutenibilita' ecc.
> > Comunque tutto cio' e' documentato, devi solo spulciare un po' in
> > MSDN...
>
> A volte non trovo gli argomenti perché se il gergo specifico
> aggiornato non lo conosci in modo corretto, tante volte
consultare la documentazione ogni volta che stai usando qualcosa che non usi
proprio tutti i giorni (personalmente la considero parte integrante del
lavoro quotidiano), la documentazione si fa rapidamente piu' chiara, e come
si chiamano le cose e dove trovarle piano piano viene fuori pure. Te lo
dico anche per esperienza personale, visto che ho cominciato con Microsoft e
.Net una decina di anni fa, prima usavo altro (in particolare il Borland
Delphi, che e' OO Pascal, per applicazioni Windows) e ricordo anch'io di
avere avuto difficolta' inizialmente: ma poi tutto si fa piu' chiaro.
> salvo la multiple inheritance e l'odio per le interfacce
delle ovvie aberrazioni), ma per il resto non bisognerebbe avere certe
avversioni. L'ereditarieta' multipla a volte si', farebbe comodo, ma ad
oggi non ho ancora trovato nulla che non si potesse costruire ugualmente al
costo forse di una minima duplicazione di codice e magari di qualche
capriola con i generics...
In generale, la filosofia dietro .Net e' quella di fornire un framework
molto potente ma allo stesso tempo ragionevolmente semplice da usare e senza
tutte le super-complicazioni del codice nativo. Questo consente alti
livelli di produttivita' e relativamente pochi "sbattimenti" anche a chi non
e' un super-professionista e non mastica C++ e WinAPI a colazione. Questo
ovviamente pero' viene al costo di qualche sofisticazione in meno, ma se
proprio .Net ti sta stretto, l'unico consiglio sarebbe quello di passare a
C++ nativo appunto: ma in realta' non lo consiglio, a meno che non sono i
proverbiali progetti segreti per la NASA... :)
> e sto perdendo praticamente il vizio di riscrivere contenitori ed oggetti
> esistenti per abusare a piene mani di quelli built in (a parte la
> serializzazione, che non mi entra e non mi piace)
soprattutto se il framework in questione ti offre delle soluzioni built-in
di alta qualita'. C'e' veramente poco margine per le ottimizzazioni in user
code in .Net...
> In più non ho capito la scelta filosofica di fondo tra ValueTypes e
> RefTypes ... ho un vago sospetto che la persistenza dei primi sia stata
> prevista essenzialmente per ragioni di efficienza nel passaggio/copia di
> piccoli oggetti
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
Soviet_Mario
Jan 19, 2012, 9:37:34 AM1/19/12
to
Il 19/01/2012 12:24, LudovicoVan ha scritto:
> "Soviet_Mario" wrote in message
> news:4f173c71$0$1388$4faf...@reader2.news.tin.it...
>> Il 18/01/2012 19:18, LudovicoVan ha scritto:
>
>> In una lista di oggetti (Che contengono array tridimensionali di
>> double, diciamo fino a qualche centinaio di coordinate, ho messo un
>> puntatore alla funzione di istanza di quella classe che mi legge
>> internamente tali coordinate, ma non ero sicuro di come trattasse la
>> reference, acc. a me)
>
> Un centinaio di oggetti per i 24 byte dei tre double fa 2.4K, cioe' se
> non e' proprio un'applicazione performance-critical ed il famoso
> bottle-neck in qualche funzione super-annidata, stai comunque
> risparmiando una goccia nel mare.
mah ... una goccia per ogni oggetto. Ma di quegli array
> "Soviet_Mario" wrote in message
> news:4f173c71$0$1388$4faf...@reader2.news.tin.it...
>> Il 18/01/2012 19:18, LudovicoVan ha scritto:
>
>> In una lista di oggetti (Che contengono array tridimensionali di
>> double, diciamo fino a qualche centinaio di coordinate, ho messo un
>> puntatore alla funzione di istanza di quella classe che mi legge
>> internamente tali coordinate, ma non ero sicuro di come trattasse la
>> reference, acc. a me)
>
> Un centinaio di oggetti per i 24 byte dei tre double fa 2.4K, cioe' se
> non e' proprio un'applicazione performance-critical ed il famoso
> bottle-neck in qualche funzione super-annidata, stai comunque
> risparmiando una goccia nel mare.
vaganti ce ne ho parecchi.
Già solo se campiono dei punti su una superficie sferica a
8-10 cerchi e 12 punti per cerchio, ho 300 double. Metti di
avere un centinaio di oggetti grafici che vagano (avanti e
indietro tra array di calcolo 3d, di rendering 2d, e altre
strutture temporanee), credo che sia più leggero spostare
solo o assegnare delle gran reference.
Anche se commetto ancora errori
L'altro giorno ho assegnato come facevo in VB 6 un array ad
un altro array. E mi sorprendevo che dopo il rendering mi
trovavo soprascritti i dati originali.
Beh, usando array.copy(sorg, dest, size) non accedeva più.
Quel che ottenevo era non di copiare i dati ma di assegnare
la reference. Buccia di banana. In VB6 invece si copiavano i
dati.
> Ma quello che cerco di comunicare qui
> e' un'indicazione generale: il codice va prima di tutto scritto a regola
> d'arte (o, da manuale), con leggibilita', semplicita' e
> (conseguentemente) manutenibilita' al primo posto.
leggibile, perdo le fila.
Questo cavolo di modellatore per cui mi sono preso una fissa
mostruosa, è già oltre le ottanta paginate di roba, e non ho
più la più vaga idea di quante classi ci siano e come
interconnesse. Il fatto che il motore funziona mi sorprende
quasi (mi sforzo di interconnettere il meno possibile, chiaro).
Ma fino al motore di calcolo ancora ci capivo abbastanza.
Ora mi è presa la fissa che voglio renderlo scriptabile, non
sono riuscito a fare il grafo di regole sintattiche come
volevo inizialmente. Pensavo di fare dei patterns di
sintassi errate a corto raggio. Poi sono passato a un
generatore di regole che produrrebbe tutte le possibili
sintassi corrette (ma sono stato ingenuo, già ho scoperto
che tra vari tipi di parentesi, metacaratteri opzionali,
delimitatori etc, l'istruzione più banale che allocava un
singolo punto dotato di nome mi ha sfornato 432 possibili
sintassi corrette ... sono rimasto basito. Devo
necessariamente rinunciare alla risoluzione analitica
lineare, iterativa diciamo, per tornare all'enunciazione
ricorsiva, di regole in termini di sotto regole, se no per
descrivere tutte le possibili enunciazioni delle istruzioni
di scripting non mi basta più il disco fisso).
Cmq sia concordo che l'esigenza di leggibilità è la priorità
suprema appena scrivi qualcosa di un po' incasinato, se no
ti ci perdi dentro.
> Ottimizzare (per
> esempio denormalizzando, oppure andando a limare sui cicli di CPU
dell'efficienza delle singole istruzioni o containers vari.
Sullo spazio dipende, a volte lo spreco è eclatante e non
difficile da limare, allora da fastidio lasciarlo in loco.
Ma per spreco essenzialmente intendo le operazioni di copia
fisica di parametri dentro e fuori lo stack, o magari
eseguire miriadi di concatenazioni su stringa da pochi byte
ognuna, o redim una dietro l'altra. Ci sono cose che son
proprio brutte come design.
Per le stringhe sto cominciando a usare StringBuilder (che
forse è più simile alle vecchie BStr che non il classico
tipo String di NET, che non è poi tanto simile al vecchio).
E per gli array, sempre più spesso liste, che non
ridimensionano per niente.
> o sui
> singoli byte) viene sempre dopo e sempre e solo dove e quando serve, e
> ovviamente ha un costo rispetto ai criteri ideali di partenza, cioe' ci
> si perde in leggibilita', manutenibilita' ecc.
>
>> > Comunque tutto cio' e' documentato, devi solo spulciare un po' in >
>> MSDN...
>>
>> A volte non trovo gli argomenti perché se il gergo specifico
>> aggiornato non lo conosci in modo corretto, tante volte
>
> E' vero che d'acchitto non e' di facile lettura, ma se prendi
> l'abitudine di consultare la documentazione ogni volta che stai usando
> qualcosa che non usi proprio tutti i giorni (personalmente la considero
> parte integrante del lavoro quotidiano), la documentazione si fa
> rapidamente piu' chiara, e come si chiamano le cose e dove trovarle
> piano piano viene fuori pure. Te lo dico anche per esperienza personale,
Inoltre da qualche anno i periodi di urgenza estrama sono
rarefatti. Giusto da 3 settimane mi son messo a costruire
questo modellatore (che graficamente non ha grosse pretese,
ragiona solo in termini wireframe, non ha nemmeno il
concetto di superficie ... e probabilmente non riuscirò a
estenderlo a posteriori)
> visto che ho cominciato con Microsoft e ..Net una decina di anni fa,
> prima usavo altro (in particolare il Borland Delphi, che e' OO Pascal,
> per applicazioni Windows) e ricordo anch'io di avere avuto difficolta'
> inizialmente: ma poi tutto si fa piu' chiaro.
>
>> salvo la multiple inheritance e l'odio per le interfacce
>
> A me non piace l'abuso delle interfacce in nome della testability
> (un'altra delle ovvie aberrazioni), ma per il resto non bisognerebbe
> avere certe avversioni.
touchè !
> per applicazioni Windows) e ricordo anch'io di avere avuto difficolta'
> inizialmente: ma poi tutto si fa piu' chiaro.
>
>> salvo la multiple inheritance e l'odio per le interfacce
>
> A me non piace l'abuso delle interfacce in nome della testability
> (un'altra delle ovvie aberrazioni), ma per il resto non bisognerebbe
> avere certe avversioni.
> L'ereditarieta' multipla a volte si', farebbe
> comodo, ma ad oggi non ho ancora trovato nulla che non si potesse
> costruire ugualmente al costo forse di una minima duplicazione di codice
> e magari di qualche capriola con i generics...
abbuffate. L'altra settimana sono riuscito per la prima
volta a fornire l'overload (con un delegato) dell'operatore
standard CompareTo e fare in modo che con una riga
(list.sort) mi si implementasse lo zordering tridimensionale
di segmenti di estremi noti.
Spero che dentro la pancia usi un algoritmo O(n) o almeno
O(n log(n)), tipo il quicksort. Ma poi non sono stato a
indagare, mi pareva di averlo letto.
>
> In generale, la filosofia dietro .Net e' quella di fornire un framework
> molto potente
> ma allo stesso tempo ragionevolmente semplice da usare e
> senza tutte le super-complicazioni del codice nativo.
di basso e medio livello è doccia fredda. Io non l'ho
trovato facile né naturale. Ma pace, un po' alla volta ci si
assuefà.
> Questo consente
> alti livelli di produttivita' e relativamente pochi "sbattimenti" anche
> a chi non e' un super-professionista e non mastica C++
singola e i template non proprio robusti effettivamente l'ho
avuti perché venivo proprio dal C++ (anche da VB 6, ma .NET
è un po' più simile al C++ che al VB 6 imho, al di la della
somiglianza delle parole chiave del basic, che infatti sono
state ampliate).
> e WinAPI a
> colazione. Questo ovviamente pero' viene al costo di qualche
> sofisticazione in meno,
scrivere codice con pochi effetti sotto il cofano, diciamo.
E quando invece scrivi delle righe che immagini ne
sottendano centinaia nascoste, ti raccapezzi a fatica.
> ma se proprio .Net ti sta stretto, l'unico
quel che può dare.
Poi Murphy insegna che se un vestito ti va largo in 100'000
punti salvo un paio, andrai a cozzare proprio contro quel
paio dove ti servirebbe qualcos'altro :-)
Il che avviene perché se vieni dai template "veri" del C++
pensi in modo diverso, e pensare in un modo e adattarlo non
è mai una strada indolore
> consiglio sarebbe quello di passare a C++ nativo appunto: ma in realta'
> non lo consiglio,
pure ha, sia chiaro), ma per la compattezza del codice che
puoi produrre, e la possibilità di astrarre in modo
vertiginoso. D'altra parte come RAD per costruire le
interfacce GUI e il debug al volo, con tutte le versioni di
VB mi ero sempre trovato molto bene, e ora comincio a
trovarmi anche in NET (in particolare è veramente possente
il debugging integrato)
> a meno che non sono i proverbiali progetti segreti per
> la NASA... :)
>
>> e sto perdendo praticamente il vizio di riscrivere contenitori ed
>> oggetti esistenti per abusare a piene mani di quelli built in (a parte
>> la serializzazione, che non mi entra e non mi piace)
>
> That is very good, there is never point in reinventing the wheel,
> soprattutto se il framework in questione ti offre delle soluzioni
> built-in di alta qualita'. C'e' veramente poco margine per le
> ottimizzazioni in user code in .Net...
nemmeno capito bene la filosofia di fondo.
Quando non capisci tutto, credo che sia meglio lasciar fare :)
>
>> In più non ho capito la scelta filosofica di fondo tra ValueTypes e
>> RefTypes ... ho un vago sospetto che la persistenza dei primi sia
>> stata prevista essenzialmente per ragioni di efficienza nel
>> passaggio/copia di 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*!
(e non avere il GC che cmq va dietro le quinte) che altra
differenza di notazione esiste ?
> 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...
ciao
Soviet
>
> -LV
>
LudovicoVan
Jan 19, 2012, 9:05:17 PM1/19/12
to
"Soviet_Mario" <Soviet...@CCCP.MIR> wrote in message
news:4f182aa9$0$1387$4faf...@reader1.news.tin.it...
cui non penso nemmeno: tu poni quesiti di programmazione in uno user group
di programmazione, ed io rispondo (o ci provo) ai quesiti che poni. Cio'
che scriviamo e' pubblico ed altri potrebbero giovarsi delle informazioni (o
disinformazioni, a seconda dei casi) che ci stiamo scambiando. Che e' anche
il motivo per cui su certe cose mi ripeto...
>>> In più non ho capito la scelta filosofica di fondo tra ValueTypes e
>>> RefTypes ... ho un vago sospetto che la persistenza dei primi sia
>>> stata prevista essenzialmente per ragioni di efficienza nel
>>> passaggio/copia di 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*!
>
> mah ... tipo ? A parte non poter definire/istanziare con NEW (e non avere
> il GC che cmq va dietro le quinte) che altra differenza di notazione
> 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
news:4f182aa9$0$1387$4faf...@reader1.news.tin.it...
> Il 19/01/2012 12:24, LudovicoVan ha scritto:
>> "Soviet_Mario" wrote in message
>> news:4f173c71$0$1388$4faf...@reader2.news.tin.it...
>>> Il 18/01/2012 19:18, LudovicoVan ha scritto:
> si ma tu sei programmatore di mestiere. Io no, solo hobby.
E pensi che sia una scusa valida? :) No, il fatto e' che quella e' cosa a
>> "Soviet_Mario" wrote in message
>> news:4f173c71$0$1388$4faf...@reader2.news.tin.it...
>>> Il 18/01/2012 19:18, LudovicoVan ha scritto:
> si ma tu sei programmatore di mestiere. Io no, solo hobby.
cui non penso nemmeno: tu poni quesiti di programmazione in uno user group
di programmazione, ed io rispondo (o ci provo) ai quesiti che poni. Cio'
che scriviamo e' pubblico ed altri potrebbero giovarsi delle informazioni (o
disinformazioni, a seconda dei casi) che ci stiamo scambiando. Che e' anche
il motivo per cui su certe cose mi ripeto...
>>> In più non ho capito la scelta filosofica di fondo tra ValueTypes e
>>> RefTypes ... ho un vago sospetto che la persistenza dei primi sia
>>> stata prevista essenzialmente per ragioni di efficienza nel
>>> passaggio/copia di 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*!
>
> mah ... tipo ? A parte non poter definire/istanziare con NEW (e non avere
> il GC che cmq va dietro le quinte) che altra differenza di notazione
> esiste ?
"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
LudovicoVan
Jan 19, 2012, 10:05:06 PM1/19/12
to
"LudovicoVan" <ju...@diegidio.name> wrote in message
news:jfai55$aer$1...@speranza.aioe.org...
> 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
"Un oggetto" li' e' ambiguo: avrei dovuto dire "un reference-type".
-LV
news:jfai55$aer$1...@speranza.aioe.org...
> 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
-LV
0 new messages