Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

[VB.NET] <StructLayout(LayoutKind.Explicit, etc etc)>

21 views
Skip to first unread message

Soviet_Mario

unread,
Jan 15, 2012, 5:51:01 AM1/15/12
to
<StructLayout(LayoutKind.Explicit, Pack:=0, Size:=16)> _
Public Class ClsImpacchettata
<FieldOffset(0)> dim M1 As Class1
<FieldOffset(0)> dim M2 As Class2
<FieldOffset(???))> dim L1 As Class3
End Class '' ClsImpacchettata


Dunque, dove avrei messo i ??? dovrei interrompere la
sovrascrittura, che mi serve per emulare una Union C-style,
ossia garantire che non possano coesistere valori su M1 e
M2, ma a partire da L1 deve proseguire occupando nuovo
spazio, quindi spostare offset avanti di quanto basta. Ma
QUANTO è ? Come lo ottengo ?
Ho tentato in vari modi di invocare Len e altre amenità, ma
mi chiede una costante.
Insomma dovrei interrompere in un punto interno della classe
il LayoutKind.Explicit e passare a LayoutKind.Sequential.

Mi piacerebbe poterlo fare enne volte a piacere, se possibile.
Suppongo che il problema possa essere diverso se Class1 e/o
Class2 sono value type o reference type (questi ultimi
occupano sempre 4 byte ??).

Grazie di ogni dritta.
Ah ... per gli esperti ed assidui, se state emigrando in
massa su qualche altro NG che si occupa di VB.NET, me lo
segnalereste mica ?
riciao
Soviet


LudovicoVan

unread,
Jan 18, 2012, 1:24:34 PM1/18/12
to
"Soviet_Mario" wrote in message
news:4f12afa8$0$1383$4faf...@reader2.news.tin.it...

> serve per emulare una Union C-style

A parte che quegli attibuti ecc. sono pensati per COM interop, perche' mai
vuoi emulare una enum C-style? Di nuovo 1 byte da recuperare ogni miliardo?
E la complessita' del codice e i byte e cicli di CPU che ti perdi con
quella?

Poi, piu' in generale: non si ottimizza mai alla cieca o a naso, ma solo a
fronte di un significativo benchmark e della relativa analisi dei colli (di
bottiglia). Per il resto, il coedice deve essere *leggibiole*, che e'
davvero l'unica cosa che conta (ovvero almeno al 99.9%).

-LV

Soviet_Mario

unread,
Jan 18, 2012, 4:51:58 PM1/18/12
to
Il 18/01/2012 19:24, LudovicoVan ha scritto:
> "Soviet_Mario" wrote in message
> news:4f12afa8$0$1383$4faf...@reader2.news.tin.it...
>
>> serve per emulare una Union C-style
>
> A parte che quegli attibuti ecc. sono pensati per COM interop, perche'
> mai vuoi emulare una enum C-style? Di nuovo 1 byte da recuperare ogni
> miliardo?

no ... per uno scopo in effetti pensato male. Ossia, volevo
rinforzare il fatto che un oggetto potesse avere un unico
stato interno.
Ma ho fatto un errore marchiano, perché semanticamente i
campi esistono a prescindere dalla loro corretta valorizzazione.
Poi mi sono accorto che la presenza di un valore (tipo un
"long") non necessariamente produceva una condizione di
errore in un eventuale "single" con lo stesso indirizzo
fisico, tantomeno era vero il contrario, dato che non ci
sono condizioni di errore in un long (salvo forse un MSB a
1, segno negativo, e gli altri bit zero ... ma non sono
sicuro che dia un errore, mentre non tutti i long mappano su
single di senso compiuto (tipo hai i bit di mantissa zero e
di esponente nonzero, o viceversa, o per caso becchi pattern
specifici tipo +INF o NaN e così via).
Quindi a ben vedere la presenza FISICA di un solo dato alla
volta, non mi rafforzava per niente l'accessibilità logica,
e tutto si deve poggiare cmq sul bit field.

Il risparmio di spazio ci può stare lo stesso, perché ho
oggetti molto difformi da piazzare dentro (ma non ricordo se
dovevo copiarli o mi bastava linkarli con una reference).




> E la complessita' del codice e i byte e cicli di CPU che ti
> perdi con quella?
>
> Poi, piu' in generale: non si ottimizza mai alla cieca o a naso, ma solo

in realtà non sto ottimizzando, specie per la velocità (un
filino allo spazio ci guardo, ma non tanto).
Cerco solo di tenere le fila di una cosa che mi sta
sfuggendo di mano.

> a fronte di un significativo benchmark e della relativa analisi dei
> colli (di bottiglia). Per il resto, il coedice deve essere *leggibiole*,

concordo pienamente ! Effettivamente sto seguendo la prima
massima di Stroustrup : make it work, before you make it
faster (e sono lontano ancora dalla seconda : and KEEP it
work, while you make it faster)

> che e' davvero l'unica cosa che conta (ovvero almeno al 99.9%).

Sto faticandoci a capirmi, in effetti, seppure è davvero lo
sforzo maggiore.

ciao
Soviet

> -LV
>


LudovicoVan

unread,
Jan 19, 2012, 6:33:57 AM1/19/12
to
"Soviet_Mario" wrote in message
news:4f173efa$0$1375$4faf...@reader2.news.tin.it...

> Poi mi sono accorto che la presenza di un valore (tipo un
"long") non necessariamente produceva una condizione di
errore in un eventuale "single" con lo stesso indirizzo
fisico, tantomeno era vero il contrario

Un long ha 64 bit e un single ne ha 32, per cui non mi rida' tanto, d'altra
parte e' vero che per entrambi vale la regola che tutte le combinazioni di
bit sono valide: ovviamente nel caso del single, ci sono combinazioni che
mappano a NaN o ad una delle infinities e, nel caso del long, per es.
0x8000000000000000 non e' altro che Int64.MinValue, visto che la
rappresentazione e' in complemento a due...

Senza stare ora a commentare punto per punto, in generale mi fai venire in
mente che se avessi una semplice reference a Object potresti appunto
metterci dentro qualunque cosa vuoi... Ovvero, piu' seriamente, penso che
forse devi affinare un po' di piu' le tue asce riguardo ad un uso piu'
spinto appunto della tipizzazione stretta...

-LV

Soviet_Mario

unread,
Jan 19, 2012, 9:45:02 AM1/19/12
to
Il 19/01/2012 12:33, LudovicoVan ha scritto:
> "Soviet_Mario" wrote in message
> news:4f173efa$0$1375$4faf...@reader2.news.tin.it...
>
>> Poi mi sono accorto che la presenza di un valore (tipo un
> "long") non necessariamente produceva una condizione di
> errore in un eventuale "single" con lo stesso indirizzo
> fisico, tantomeno era vero il contrario
>
> Un long ha 64 bit e un single ne ha 32,

d'accordo ho scritto un refuso : intendevo long con double
(o integer con single)

> per cui non mi rida' tanto,
> d'altra parte e' vero che per entrambi vale la regola che tutte le
> combinazioni di bit sono valide: ovviamente nel caso del single, ci sono
> combinazioni che mappano a NaN o ad una delle infinities e, nel caso del
> long, per es. 0x8000000000000000 non e' altro che Int64.MinValue, visto
> che la rappresentazione e' in complemento a due...
>
> Senza stare ora a commentare punto per punto, in generale mi fai venire
> in mente che se avessi una semplice reference a Object potresti appunto

quando ho "lasciato" il C++, ho dovuto giurare sulla tomba
della nonna bonanima che non avrei quantomeno mai dichiarato
nessuna variabile Object :) o usato il late binding.


> metterci dentro qualunque cosa vuoi... Ovvero, piu' seriamente, penso
> che forse devi affinare un po' di piu' le tue asce riguardo ad un uso
> piu' spinto appunto della tipizzazione stretta...

tra i miei tanti problemi con NET non penso che ci sia la
tipizzazione stretta in sé (tant'è vero che tra le cose che
più amavo di C++ c'erano proprio i template di template di
template etc). Semmai non riesco a usare ancora in modo
proficuo le informazioni di tipo dinamico recuperate
dall'introspezione per altri usi che non diagnostici.
Sto solo leggendo le procedure dinamiche di costruzione di
tipi, ma è incasinato e non mi ci oso ancora avventurare.
ciao
Soviet

>
> -LV
>


0 new messages